Variable substitution

[kaykhan]

I have an argocd application

https://argo-cd.readthedocs.io/en/stable/user-guide/multiple_sources/

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  sources:
  - repoURL: 'https://prometheus-community.github.io/helm-charts'
    chart: prometheus
    targetRevision: 15.7.1
    helm:
      valueFiles:
      - $values/charts/prometheus/values.yaml
  - repoURL: 'https://git.example.com/org/value-files.git'
    targetRevision: dev
    ref: values

my values.yaml looks like this

nameOverride: ${db_name}
...
someOtherField: abc-${db_name}-def

is there some way for me to inject the value of db_name into the .yaml

Such that any occurrence of ${db_name} found in the .yaml will get substituted for a value.

[LittleWat]

+1 for this. FluxCD supports this: https://fluxcd.io/flux/components/kustomize/kustomizations/#post-build-variable-substitution

[Elyytscha]

this would violate gitops core principles, as files with such substitutions are not fully declarative anymore because you can't apply them with kubectl oder build them witt kustomize anymore without an imperative process which substitutes those variables.

what flux did there is really really bad, that just shows that they didn't understand what gitops means and how its implemented.

i highly recommend to not integrate such an 'feature' into argocd, if this gets integrated it MUST be possible to disable this 'feature' via config.

[LittleWat]

Thank you for your feedback. Let me elaborate on the explanation.

I believe the variable substitution feature would be beneficial in the following situation:

Let’s say we have 50 teams, and each team has three environments: dev, stage, and prod, using Kustomization.

There is a variable, cluster_domain, which all 50 teams need to use, but it has different values for each environment:

• In dev, it would be https://dev-foo.com
• In stage, it would be https://stage-foo.com
• In prod, it would be https://prod-foo.com

With FluxCD, you can handle this by using variable substitution as follows:

• Prepare a configmap for each environment that contains the cluster_domain.
• Then, for each team, configure Flux’s post-build-variable-substitution to read this configmap.
  By doing this, the cluster_domain setting for each environment will be written in a single location.

Without this feature, you could still use Kustomize patches to set up the configuration for each team and environment. However, each team would need to write the setting for their specific environment, which means you’d have to write the cluster_domain configuration in 50 places (one for each team). This would violate the DRY principle.
We would like to avoid patching usage as much as possible.

If ArgoCD does not have variable substitution, how would it handle this situation? (Sorry, I'm still a beginner of ArgoCD and there would be a better idea to handle this. 🙇 )

FluxCD, of course, allows you to disable this feature by not configuring the post-build-variable-substitution setting. (It will not be used if you don’t set it: https://fluxcd.io/flux/components/kustomize/kustomizations/#post-build-variable-substitution)

Thank you!

[Elyytscha]

thats all are things which 1. are possible 2. are prohibited with intend in kustomize.

Without this feature, you could still use Kustomize patches to set up the configuration for each team and environment. However, each team would need to write the setting for their specific environment, which means you’d have to write the cluster_domain configuration in 50 places (one for each team). This would violate the DRY principle. We would like to avoid patching usage as much as possible.

you can't say you want another feature which is bad because it violates gitops core principles, because you dont want to use the features which where made for that use case.

we do exactly the same, we have a kustomize base, we have multiple envs aka overlays in folders, all those env's share configs through replacements or patches or config map generators https://github.com/devopsjourney1/mykustomapp/blob/master/solution/overlays/dev/config.properties

you have defaults in your base, if you need to change those in an overlay you patch it,
if you need to reuse things you use replacements
if you want to share and merge env variable sets for deployments you use a config map generator.

FluxCD, of course, allows you to disable this feature by not configuring the post-build-variable-substitution setting. (It will not be used if you don’t set it: https://fluxcd.io/flux/components/kustomize/kustomizations/#post-build-variable-substitution)

If a dev CAN use this, i as SRE/DEVOPS MUST be able to prohibit the dev from using this in argocd with hardly disabling this feature.

the whole kustomize / gitops thing is all about k8s manifests fully declarated, that means every k8s files needs to be able to be deployed as singleton, without a logic which needs to substitute things first before the file can get applied. having such substitions in place would make so much things immpossible, even stackrox/kube-linter couldn't lint such files anymore

to quote kustomize opinions on that topic:

Kustomize isn't designed to be a templating engine, it's designed as a purely declarative approach to configuration management, this includes the ability to use patches for overlays (overrides) and reference resources to allow you to DRY (Do-Not Repeat Yourself) which is especially useful when your configuration powers multiple Kubernetes clusters.

[kostis-codefresh]

Without this feature, you could still use Kustomize patches to set up the configuration for each team and environment. However, each team would need to write the setting for their specific environment, which means you’d have to write the cluster_domain configuration in 50 places (one for each team). This would violate the DRY principle.

They wouldn't need to do that. You can reuse stuff even with Helm (with Helm value hierarchies) and Kustomize (with Kustomize components) keeping DRY. Have you seen those?

[kostis-codefresh]

Regardless of the GitOps principles, what you are asking is an overkill because you are trying to add another templating layer on top of Helm and application sets.

I have written about this here https://codefresh.io/blog/how-to-structure-your-argo-cd-repositories-using-application-sets/ (check -antipatterns 1 and 2 in that article).

The solution is to use Helm value hierarchies (in case of Helm) and Kustomize components in case of Kustomize.