Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for managing env vars via kustomize #97

Open
djones6 opened this issue Apr 30, 2020 · 1 comment
Open

Support for managing env vars via kustomize #97

djones6 opened this issue Apr 30, 2020 · 1 comment

Comments

@djones6
Copy link

djones6 commented Apr 30, 2020

Feature Request

Is your feature request related to a problem?

If an application accepts configuration via a number of environment variables, these variables may have hard-coded defaults in the spec/env section of app-deploy.yaml that are suitable for (say) a development environment.

Kustomize can be used to patch values in the deployment to tailor it for different environments (eg. test or production). Kustomize has built-in knowledge of the structure of standard Kubernetes types (Deployment, Service etc) and the env section of a vanilla Deployment is recognized as a map which is keyed by the name field. It can therefore be patched either to add new entries or replace the values for existing ones.

However, Kustomize has no knowledge for custom resource types. As a result, trying to apply a Strategic Merge Patch to the env list of an AppsodyApplication CR will result in the entire list being replaced. Similarly, an SMP cannot be used to update an existing value in place.

A workaround is to use JSON patches (using kustomize's patchesJson6902 directive rather than patchesStrategicMerge), although these are also unable to refer to named elements of the list, so are limited to append/prepend, or replacing an entry by numeric index.

Another option is for all the 'dynamic' values in the env list (ie. values that may change at deploy time) to be references to ConfigMaps or Secrets, and for kustomize to define the contents of those resources instead. This would avoid needing to patch the env list at all and is the route I'm going to explore next. But I imagine it could cause surprise if patching does not behave the same as with a vanilla Deployment.

Describe the solution you'd like

To be able to apply patches to map types in the AppsodyApplication CR the same way that I can for a vanilla Kubernetes Deployment resource.

Having read around a bit, I found discussion on this topic in kubernetes-sigs/kustomize#1510 - from which I understand that it is not yet possible to educate kustomize on the structure of a custom resource, although there is an issue open for that support here: kubernetes-sigs/kustomize#2339

@arthurdm
Copy link
Member

arthurdm commented May 1, 2020

thanks for the feature request @djones6

Do you have any outlook on when that kustomize support will be coming in?

My fear is that we have a few other places that a person could also want to "kustomize", such as volumes, etc. So if we had a special extra section for env vars we would likely need to address the other spots too - and all that would be not needed anymore once the native CR kustomize support is available =)

For GitOps, is it reasonable to assume that for now each kustomize patch would contain the complete set of env vars, even if that means duplicating some key/values across environments?

Another strategy - create a ConfigMap for your "static" env vars, and use envFrom to point to that. This leaves you free to override the env array via kustomize patches.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants