We ve actually got an experimental

Question

We ve actually got an experimental `garden plan` command on a branch somewhere We ll be rolling this out in the coming months That s essentially a dry run deploy with the added capability of rendering out e g Helm values with all Garden template strings fully resolved making it a great fit for e g handing over to GitOps based CD systems while using Garden s templating abilities

bright-policeman-43626 · Answer

Nice seems like this is already in the pipeline then < icy furniture 17516> this is beautiful Thanks

swift-garage-61180 · Answer

< curved intern 91221> and I wrote this during a hackathon last year so we ll need to adapt it for Bonsai and do some wrapping up and documenting but it should be relatively straightforward once we decide to prioritise it

curved-intern-91221 · Answer

Yes we have the changes from the hackaton in the branch https github com garden io garden tree plan command

icy-furniture-17516 · Answer

wow nice

icy-furniture-17516 · Answer

adding < quaint dress 831> as I mentioned this to him as well

quaint-dress-831 · Answer

< icy furniture 17516> I ve created this as a feature request in our GitHub we ll keep you updated https github com garden io garden issues 4658

icy-furniture-17516 · Answer

Getting back to this thread if you don t mind because I have a question Not sure if you made any progress with this on a different branch but I would be interested in the way this supposed to work

icy-furniture-17516 · Answer

The question is whether the plan command would be something that could dump kubernetes manifests to stdout or to a specific directory perhaps

icy-furniture-17516 · Answer

It would be a nice way to detach the source code and the actual deployment artifacts so that we can version and ship these artifacts separately from the source

icy-furniture-17516 · Answer

The way I imagine this would work run `garden publish` to build and push images to a registry run `garden plan` or similar that does not build anything but dumps k8s manifests with the previously built image references somewhere hand it over to some gitops workflow so that it can safely manage deployments no matter it has to roll something out or roll something back

icy-furniture-17516 · Answer

The dry run deploy thing that < swift garage 61180> mentioned would ideally do that but I m not sure if it would be the same as what I originally thought about when I was thinking of what plan should do Actually it doesn t have to know anything about the previously applied manifests that will be the job of the gitops tool

icy-furniture-17516 · Answer

Also as far as I know garden does not support removing stuff that were deployed before but that do not exist anymore in the modules

icy-furniture-17516 · Answer

That s again something that the gitops tool can handle if it has the manifests

icy-furniture-17516 · Answer

Long story short I just wanted to clarify that the thing we primarily need is the dry run thing with manifests instead of a nice plan view that could highlight changes

swift-garage-61180 · Answer

We haven t done any more work on the plan command since we first prototyped it but the prototype did basically what you re describing It creates fully materialized deployables e g Kubernetes manifests or Helm charts with all Garden template strings resolved and writes them into a local directory which is also configurable Separately it also generates and logs diffs with the currently deployed resources All that said we d need to find the time to prioritise wrapping it up for one it was written for 0 12 so there would be some refactoring to do to apply it on top of 0 13 Glad to hear you re interested in it would be really cool to roll it out

icy-furniture-17516 · Answer

Could this work for container type actions or just for kubernetes

icy-furniture-17516 · Answer

Not a big deal if not I think since we can keep the container builds and write kubernetes deploy actions separately

swift-garage-61180 · Answer

We had already implemented this for `container` `helm` and `kubernetes` services which are now Deploys in 0 13

icy-furniture-17516 · Answer

I ve tried to merge that experimental branch onto 0 12 and would like to give it a try to see what it does Is there a containerized way to build garden or I should go with what is described in the contributing guide and try to build on my local machine

bright-policeman-43626 · Answer

Yes you can follow the contributing guide to get the binary and then just do an alias like `alias gdev= path to binary `

icy-furniture-17516 · Answer

Update I haven t been able to get to the bottom of a build issue when I was trying to build garden locally but then I ran out of time Also next day I realized that even if I could generate k8s manifests I would still need to transform them so that I can add templating to it for example to be able to set image names and so on So I chose to refactor all of our container and kubernetes modules into a single chart with enable disable flags to control the component I want to activate for a given module

icy-furniture-17516 · Answer

I wanted a single chart because it s much easier to manage

icy-furniture-17516 · Answer

so I have a base chart module that has all the components disabled in it and when I define a module I can use this chart as a base and enable the single component I need

icy-furniture-17516 · Answer

I have 8 modules 1 2 1 2 container kubernetes and took me a day to refactor

icy-furniture-17516 · Answer

we have some other modules as well that we didn t want to include in this chart used for demo contents and so on but those are still fine in garden

icy-furniture-17516 · Answer

I love the way we could solve this because now we can have an image build and ship it along with the chart as a release artifact

icy-furniture-17516 · Answer

I forgot to mention that we are still looking for the plan functionality for the dev demo environments that we find easier to deploy manually for now but for a production setup the aggregated helm chart seems to be a better simpler solution for multiple reasons