Support to writing back the yaml to files about kustomize HOT 9 CLOSED

Doesn't seem like #245 addresses this issue, which is similar to #227 but for separating each resource.

for example:

kustomize build production | csplit - --prefix='production.' --suffix-format='%03d.yaml' --elide-empty-files --keep-files /---/ '{*}'

Is one workaround to splitting the resulting output into separate files, but all context is lost. Would be nice to have something similar to helm template where a comment is added to each resource indicating where it originated from.

from kustomize.

Hi @monopole and co., I also would like to request support to writing the kustomize output to files instead of only stdout. The reason I'd like this is for debugging the output to verify if a particular resource was correctly "kustomized". Imagine I have 10 resources (in my current use case it's already 9) managed by the same kustomization. In this case I'd like to write all the kustomized resources to a separate directory and then inspect them in one-by-one in my editor. I know I could write all of them to a single file, but when having 10 or more resources this single file becomes already gigantic and it's hard to navigate around.

So in summary I think it would be really helpful to have the ability to write the kustomized resources as seperate files to a directory.

from kustomize.

You can also use labels with kubectl to only apply certain objects

kustomize build ~/someApp | kubectl apply -l app=foo -f -

from kustomize.

kustomize in general wants to support a fork/rebase workflow in which one has a fork of someone else's repo, and occasionally does git rebase to capture changes which then become part of your workflow. So we don't want to overwrite the base (would could be just one big YAML file with many resources).

That's why there's currently no attempt to retain any kind of mapping between objects and the file they came from (or the order in which the objects appeared in those files).

i.e. I don't want to apply a deployment and thus replacing 100% of my instances,
but have a blue/green approach.

Could you take a look at hello world example but replace (staging, production) with (blue, green), and describe why that pattern does or does not work
for your case?

from kustomize.

@monopole what if we write to a release dir instead of overwriting the base? You can add a release dir in the kustomization file where all the modified resources would be written to.

from kustomize.

Yep, apply label filtering works, but it's an imperative approach in that the label filter isn't necessary captured in version control (unless you store a script obviously).

I'd like a clearer explanation of what problem @Raffo wants to address with blue/green deployment. One can use different kustomization files to involve different sets of resources (that what overlays are).

from kustomize.

Hi, thanks for the quick and detailed answer and sorry for the short explanation in the original post.

I haven't followed myself the development of this tool so what I asked might be entirely out of the goals of the tool. If this is the case, please feel free to close this issue.

That said, you definitely deserve more details: I was not thinking of overwriting the base, more like having the possibility of having an output folder for the the templates with the replaced parts. You can think of this as a dist or out folder, not to be committed in the repo, but something to use for applying resources while keeping the repository setup clean and more importantly reusable between environments (staging, production).
The use case would be to have a single central repository where I would keep the kubernetes yamls, separated from the source of the applications. While this might look like an antipattern from some point of views, it would be needed in my case to allow to reuse configuration and scale the knowledge regarding Kubernetes in the organization.

For the blue/green use case, I never want to just run kubectl apply -f deployment.yaml for an already existing deployment as this is missing the whole idea of incrementally rolling out new versions of an application, by never replacing 100% of the pods of my app.
In that case, I'd love to deploy a different deployment.yaml (i.e. by giving a deployment a different name and labels) and then do the shift gradually (i.e. by changing the number of pods of the two deployments). I understand that this is out of scope for the tool, but it'd be possible to mimic this in a deploy script/pipeline if I would possess the deployment.yaml with already the parts replaced/configured by kustomize, which should be exactly what I though this tool is for.

I hope this clarifies my initial message.

from kustomize.

We will add -o to write the output to a file. #245

from kustomize.

To do a blue/green deployments with kustomize we can seperate bases (between deployments and other kubernetes objects) and adding 2 overlays: one for the blue step, another for the green step.
This seems to satisfy the current use case I am experiencing, but it would be nice it we could control the outputted content/files a little better.

from kustomize.