Ability to read additional environment variables within the argocd-repo-server #7189
Comments
|
We are currently using a plugin to get these vars, but that stops us from using the helm: block. So this would be a great feature to add. |
|
I think this makes sense. Rather than prefixing with |
|
Hi, I would like to work on this issue. Can you assign it to me @crenshaw-dev ? Thanks. |
thank you! |
|
I'd like this too! In my case I want to override application placeholders with global (or config map) env vars. Our use case is gitops - we want to use the same manifests but pull from different branches depending on a cluster name variable (changing branch Revision). I also see us setting parameters in apps for helm charts - dependent on global params.. |
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: $MY_CUSTOM_ENV_VAR
path: guestbook
destination:
server: https://kubernetes.default.svc
namespace: guestbook
|
|
+1 Would be so good ! Trying to achieve the same goal. Having multiple cluster and 1 applicationSet. So , for ingress route, it would be pretty handfull. |
|
I finally find time to work on this. I will schedule it to develop with our Golang community 🙏 |
|
Thank you!
|
|
Hi I am the head DevOps Engineer for the federal government. We need to be able to pass in our gitlab auth token into the url string for helm.valueFiles -https:// |
|
👍 for this, I am trying to have a dynamic targetRevision also apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: letsencrypt
namespace: argocd
spec:
project: core-services
source:
path: services/letsencrypt/manifests
repoURL: <repo>
targetRevision: $TARGET_REVISION |
|
@revaspeho theoretically you can achieve it with |
|
@mstrYoda are you actively working on this? |
|
I was able to get something to work here, I built my own docker image, removing this line from applicationset utils to allow access to the env function. Then using and applicationset with a go template apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: letsencrypt
namespace: argocd
spec:
goTemplate: true
generators:
- clusters: {}
template:
metadata:
name: '{{.name}}-letsencrypt'
spec:
project: core-services
source:
path: services/letsencrypt/manifests
repoURL: https://github.com/xxxxxxxxxxxx/argolab.git
targetRevision: '{{ env "TARGET_REVISION" }}'
directory:
recurse: true
destination:
server: https://kubernetes.default.svc
namespace: cert-manager
syncPolicy:
syncOptions:
- CreateNamespace=true
automated:
selfHeal: trueThis works, but obviously there is some security concern. But I think if we are able to set an allowlist of vars somewhere like suggested earlier on, we can perhaps just filter out env values not on the list? Something like that. I mean I am sure there could be more elegant ways to solve this. But I am happy with this so far. |
|
I have a PR that solves this, will submit it soon for review |
|
Thank you ! @danhawkins |
|
@crenshaw-dev you can assign this to me, I made a PR, any feedback to get it merged would be appreciated. |
|
As mentioned in Contributor's meeting today, we aim to address this issue by the functionality implemented in this PR: |
|
@leoluz I looked at PR #12508 and needed help understanding how that can solve the problem proposed in this issue. |
|
@leoluz i also feel it does not directly address this need. We need something like a parameterized kustomization.yaml file each cluster that reads the same application yaml. Can you explain how multiple repos get merged? |
|
@shanproofpoint @pierluigilenoci With the functionality implemented in the multi-source PR a new concept of chained manifest generation will be possible. For example, this means that you will be able to rely on a helm chart to generate your basic manifests and then implement a small CMP plugin that does the last mile manifest manipulation required by your company. |
|
@leoluz I think that chain manifest generation or CMP is an overkill for such need. Showing another example: I am managing a fleet of EKS cluster and want to manage "infrastracture" apps via app-of-apps pattern. ArgoCD is deployed once on the cluster create and right away app-of-apps manifest pointing to infrastructure manfiests is deployed. Infrastructure manifests contains an application manifest for cluster autoscaler which requires an unique clusterName to distinguish which autoscaling groups can be targetted for autoscaling. Having environment substition in application manifest this will be very straightforward:
Environment variables substitution is already there... but only for a small set of defined variables. |
|
may can you try |
|
I'm looking in to replacing fluxcd with argocd and I'm struggling with argocd not having the same idea of postBuild variable substitution that flux has. We have multiple multi-tenancy eks clusters for different environments (dev, beta, stable nonprod, stable prod), and we use variables such as the name of the cluster (needed for aws-specific helm charts), the environment, the stage (nonprod/prod), the vpc id the cluster is in, etc. via postBuild variables with flux. It would be nice if, in argocd, we could set some variables like this on the cluster objects and they could be rendered in the |
|
@maeghan-porter may you can use some approach like envsubst
|
@AndreCbrera It is not clear to me how that would work with argo? I'm new to this so maybe I'm missing something... |
Summary
When specifying an Application yaml, we would like the argocd build envirionment to include all os level environment variables or can be restricted to any custom os environment variable prefixed with ARGOCD_
Motivation
we are setting up many clusters that poll a single git repo for their entire list of applications and their configuration. however, each cluster has an identity that is used in parameterizing some deployments and custom resources either through additional annotations, environment variables or other resources like disks. we store this as a configmap of values inside the argocd namespace which then can me mounted in the argocd-repo-server as environment variables.
Proposal
just read additional os level environment variables into the argocd build environment so we can do the following:
where ARGOCD_MY_CUSTOM_ENV_VAR would be read from a configmap into the argocd-repo-server container
The text was updated successfully, but these errors were encountered: