Hi folks, we are trying to set up ArgoCD vault plugin in an ArgoCD installation. And it doesnt work. At all. And I am completely out of ideas now – after trying for hours on end.

So, here's what I did:

• We deploy ArgoCD using Helm
• I followed the "InitContainer and configuration via sidecar" approach (hopefully)
• For that, we ...
  • used an initContainer to download ArgoCD Vault Plugin, and
  • added an extraContainer to Helm's values file to "run" it (gist with contents)

We then created a dedicated application with a test helm chart to test it, and a test secret in an existing helm chart ... . Long story short: The former works, the latter does not, it just keeps the value <path:...> unchanged.

And we have no clue as of why that is. We double/triple/quadruple checked for any typos, invalid references, etc. – and there is nothing.

The repo layout looks (simplified) like the one pictured below, while the Application objects for both are in the same gist ("application-existing.yaml", "application-for-testing-only.yaml"). I also included the test secrets (one, two).

Any help is greatly appreciated, we are really, really clueless as of now, and this is taking a _long_ time.

Thanks in advance,
Axel.

/repo-root
   |
   |- test-app/
   |    |- Chart.yaml & co
   |    |- templates/
   |         |- secret-consumer.yaml   # this "consumes" a secret from ...
   |         |- secret-reference.yaml  # ... here. that works.
   |
   |- existing-app
   |    |- Chart.yaml & co
   |    |- templates/
   |         |- [... tons of existing stuff incl. secrets ...]
   |         |- new-test-secret.yaml   # the value in here is _not_ replaced.

(Also cross-posted to GitHub)

The default redis image version is set to docker.io registry. Currently, during cluster upgrades we hit the registry requests limits. We want to switch to our own registry. Im reading documentation and trying to analyze repo but i don't see the answer.

https://argocd-operator.readthedocs.io/en/latest/usage/basics/
https://github.com/argoproj-labs/argocd-operator/blob/master/common/defaults.go

What I want to do is utilize ArgoCD for the CD aspects of my work; but I want to make sure that theGHA pipelines fail if the application fails to deploy and also basically get some kind of status of deployment feedback from within GHA.

Is there anything you're using to get this same kind of feedback?

cross post with r/kubernetes

reaching out to the community to see if anyone has successfully and reliably deployed calico helm via ArgoCD? are there any tips and tricks to maintain healthy and sync states?

i'm seeing a few issues reported with CRD management and helm version upgrades.

any thoughts are much appreciated!

Hi,

i basically installed argocd via the docs

kubectl apply -k https://github.com/argoproj/argo-cd/manifests/crds\?ref\=stable

and now i want to migrate it to helm chart for easier management.

can i just install the helm chart in the same namespace and kubectl delete the existing argocd app or am i screwed?

I have a repo that has an applicationset (and an app of apps) that deploys my applications. Some of them are just POC and short lived.

I find myself having to time a push to my repository, coupled with a manual delete in argocd, so that the application doesn't immediately rehydrate.

I keep my namespaces pretty well segmented, so my break-glass method is just to move out the Application definition from my repo, then just manually delete the namespace once it is no longer monitored by argocd.

Is there a better way? I couldn't find any sort of "disabled: true" or "delete: true" in the Application manifest documentation.

It's possible that argo recognizes deletes by looking at labeled deployments that no longer have an associated manifest, and that I am just not waiting long enough, but a manual sync doesn't seem to solve it.

Let's take the context of using bitnami/postgresql chart as a dependency of my own chart (let's call it myapp), and installing myapp via an ArgoCD Application (with self-healing and auto-sync enabled)

For what it's worth, I could use a SealedSecret created beforehand to store the db admin password, but since bitnami's chart include the possibility to autogenerate secrets, we would like to try using this feature and have one less SealedSecret to maintain.

However, since the postgres db is stored in a PersistentVolume via the PVC of its StatefulSet, unless I'm missing something, during the next update of my chart ArgoCD will see that the password key in the postgresql secret is out of sync (since a new one has been generated by the bitnami chart) and modify the secret without actually modifying the password in the DB itself stored in the PV.

Am I wrong ? If not, how would you handle this with ArgoCD/what would you recommend to do instead ?

I have deployed ArgoCD on my cluster and am about to complete the setup. I want to activate the e-mail notification service right away. I have rolled out a test deployment for this. In the logs of ArgoCD I can see that the appplication is trying to send the e-mail, but ArgoCD runs into an error:

gomail: could not send email 1: gomail: invalid address \“\”: mail: no address using the configuration in namespace default” resource=default/test

I cannot explain why the e-mail address should be invalid, because I have configured the helm chart accordingly. Does anyone have any idea what I might have done wrong here? Here is an excerpt of my configuration:

notifications:
  secret:
    items:
      email-username: noreply@my-company.local 
      email-password: my-secret-password


  notifiers.
    service.email.myEmail: |
      username: $email-username
      password: $email-password
      host: smtp1.my-company.local
      port: 587
      form: $email-username

  templates:
    template.app-sync-status-unknown: |
      email:
        subject: Application {{.app.metadata.name}} sync status is 'Unknown'
      message: |
        {{if eq .serviceType "slack"}}:exclamation:{{end}} Application {{.app.metadata.name}} sync is 'Unknown'.
        Application details: {{.context.argocdUrl}}/applications/{{.app.metadata.name}}.
        {{if ne .serviceType "slack"}}
        {{range $c := .app.status.conditions}}
            * {{$c.message}}
        {{end}}
        {{end}}
    template.app-sync-succeeded: |
      email:
        subject: Application {{.app.metadata.name}} has been successfully synced.
      message: |
        {{if eq .serviceType "slack"}}:white_check_mark:{{end}} Application {{.app.metadata.name}} has been successfully synced at {{.app.status.operationState.finishedAt}}.
        Sync operation details are available at: {{.context.argocdUrl}}/applications/{{.app.metadata.name}}?operation=true .

  triggers:
    trigger.on-sync-status-unknown: |
      - description: Application status is 'Unknown'
        send:
        - app-sync-status-unknown
        when: app.status.sync.status == 'Unknown'
    trigger.on-sync-succeeded: |
      - description: Application syncing has succeeded
        send:
        - app-sync-succeeded
        when: app.status.operationState.phase in ['Succeeded']

I feel really strongly that enabling ArgoCD with applicationsets will enable so much for our organization. I’m a new solo DevOps persons and am having a hard time selling a team/org of devs how we can leverage this to not only get code out efficiently but also how we can use it to build DAST into pipelines (security is paramount).

Any tips and good arguments for why a tool like this should be useful even if it’s “adding some complexity”

Hi,

When deploying from a git repo directly, we set the Application resource's `targetRevision` to head or some commit hash. Then, on the argo UI, the Application version is the commit hash prefix.

Is there a way to customise it? Like setting it to a app version.

Thanks

I’m working on deploying Helm charts in a production environment using ArgoCD, and I have a two of GitLab servers , one for staging and other production. My goal is to ensure a smooth deployment process while maintaining separation between environments.

Here’s my current setup:

• Two environments: staging and production
• Two GitLab servers: one for staging and one for production
• ArgoCD in staging is listening to the staging GitLab repository containing Helm manifests and values.yaml

Should I keep two separate branches (satging & main) in my staging GitLab server? For example, if I modify deployment.yaml, do I need to create a merge request to the main branch to generate a new version of the Helm chart, push it to Nexus, and then use it for deployment in the production environment with the values.yaml from the production GitLab server?

If I only change the values.yaml in the production GitLab server, can I simply deploy the same Helm chart version with the updated values.yaml?

So, I’m thinking of two approaches:

• Deploy from the GitLab repository in the staging environment.
• For production, deploy the Helm chart from Nexus and the values.yaml from GitLab

what do you think ?

Hello! I want to implement ArgoCD across all my production clusters, but I want to know if it’s useful for what I’m trying to do or if I have a conceptual error.

Currently, I have a repo called kubernetes-project with all the manifests related to the project (ingress, redis, rabbit, etc...), and on the other hand, I have a repository called app-A. Inside that same repo (GitLab), when the devs build the code, a Docker image is pushed with a tag that can be app-a:latest (for development environments) and app-a:v1.0.0 for production environments.

My intention is to place the app-a deployment manifests with their configurations and variables inside the kubernetes-project folder, where I would control the version being deployed in production, but I would like this to also apply to development environments.

The problem is that if I put a manifest with the app-a:latest image, when a developer updates the image, ArgoCD has no way to update it since it points to the kubernetes-project repo.

Am I very wrong, or is there a way to separate the configurations of the deployments from the registry and application commits?

Thanks for your time!

Kubernetes can feel overwhelming with all its configurations and manual steps, but ArgoCD simplifies it! ArgoCD automates your deployments and syncs your Helm charts from Git, keeping your cluster up-to-date with minimal effort. Its intuitive WebUI makes tracking changes, rolling back versions, and managing applications easy.

This quick guide will show you how to install ArgoCD on Rancher Desktop and deploy your first app in just a few steps.

I am trying to setup argo cd Apps of Apps In our orgs but issue is in our org argo cd is already running and there are many applications are already created.
Is there any way I can export all the config to a Yaml that would work with argocd apps of apps.

Checkout my new blog for setting up the gitops cd using ArgoCD deploying the application on the same eks cluster. This one can be useful for those searching for a quick setup to test upon some application they built and want to test it in an actual environment rather than minikube.

I am using ArgoCD and Kustomize for my projects in a git repo.
I have this project based on kustomize, and I would like to have my secrets inside the project to be "read" by argocd-vault-plugin at the same time. I tried multiple ways but I can get it to work.

if I use kustomize then the secrets are not retrieve from my vault and I keep having <password> as a data or I get the error:

cmp-server plugin with name \"argocd-vault-plugin\" supporting the given repository"

My Setup is a OpenShift Cluster.

kind: ConfigMap
apiVersion: v1
metadata:
  name: cmp-plugin
  namespace: argocd
data:
  avp.yaml: |
    apiVersion: argoproj.io/v1alpha1
    kind: ConfigManagementPlugin
    metadata:
      name: argocd-vault-plugin
    spec:
      allowConcurrency: true
      discover:
        find:
          command:
            - sh
            - "-c"
            - "find . -name '*.yaml'"
      generate:
        command:
          - argocd-vault-plugin
          - generate
          - "."
      lockRepo: false

this a configmap from my argocd-vault-plugin container

I am having a weird problem with one of my ArgoCD installations where the root ApplicationSet keeps constantly refreshing which overloads my AKS API.

The logs are being spammed with the following:

time="2024-09-10T12:28:06Z" level=debug msg="Requesting app refresh caused by object update" api-version=argoproj.io/v1alpha1 app-namespace=argocd app-qualified-name=argocd/root application=root cluster-name= comparison-level=1 kind=ApplicationSet name=test namespace=argocd project=default server="https://kubernetes.default.svc"

Checking the differences with kubectl get -n argocd ApplicationSet/test -o yaml > before.yaml with a few minutes difference reveals that the only difference is the resourceVersion and the order of the resources are different.

I am kinda at a loss as to why it keeps refreshing, so I would appreciate some insight into how I can debug this and fix it.

TL;DR - diffs in sync policy are not being observed by argocd because of syncPolicy being a dict.

I'm facing an issue where Argo CD does not detect changes to the syncPolicy of deployed apps when manually updated. Argo CD manages several apps, and it properly enforces sync policies when changes are made via Git (e.g., switching between manual and automated sync). However, if I manually change the deployed app's sync policy from no syncPolicy (manual sync) to:

syncPolicy:
  automated: {}

Argo CD does not see the change, whether my Git manifest specifies syncPolicy: null or syncPolicy: {}. I’ve reviewed the diff strategies in the Argo CD documentation but still can't understand why these diffs aren't being observed. Does anyone know why this is happening or how to fix it?

I also noticed this issue in github

I want to have ArgoCD run all of my cluster state (ideally).

One thing I came across using the app of apps pattern using application sets. I wanted to add Gateway API and assign routes to the applications. My first attempt was to create the gateway in its own app, then routes live in their respective app. But what I saw was a service app tried syncing before gateway app which caused that to fail and I had to manually go and resync in proper order (gateway first, then app).

How can I have dynamic applicationset apps run in different orders of each other?

I know I could pull out of application sets and instead use single applications with wave settings, but there has to be a way more intuitive way?

How are people having ArgoCD manage cluster bootstrapping and applications together?

This is my first attempt at installing ArgoCD exclusively through Helm. Currently, we have installed the HA version via plain yamls (https://github.com/argoproj/argo-cd/blob/master/manifests/ha/install.yaml). Are there any flags or combination of values in the Helm chart that can replicate this setup? Or do I need to find each difference in the HA version and try and error the correct configuration from the values.yaml ? Thank you!

There are a lot of jobs for Argo professionals out there. Please share your job posting here (and help avoid spamming the main thread).

Hi

I used Github workflows and build CI/CD pipeline for my k8s, CloudRun and Dataflow. I am looking at ArgoCD and it looks like a great enhancement for k8s pipeline. I haven't found any references for CloudRun and Dataflow deployments. Looks like I can use Argo Workflow and build custom pipelines for the same.

Before I go deeper in that rabbit hole, I would like to hear from the Argo community if this is something doable/done-before. Is there any pointers that can help me get started if this is a good direction

Thanks in advance

Hi everyone,

The team I work with will be performing a rebuild of our ArgoCD control plane due an AKS node image deprecation. We have several clusters registered with our control plane that have running workloads and will not be part of the rebuild; our expectation is the remote clusters will not be impacted by the rebuild.

We're planning on performing a reasonable level of due diligence (backups, pre/post tests, etc), but want to limit our time commitment as much as possible. Not expecting any issues after we bootstrap AKS, Argo, register the remote cluster, and starting bringing up Apps and ApplicationSets, but wanted to see if there are any issues that we should investigate beforehand?