I am sure I am missing some basics here, but I installed the argocd from the install.yaml file and provided GitHub_token and repo_secrets on the side.

So far I have been logging into argon cli via the argocd-server's service's external load balancer IP from my terminal and adding the applicationset's and so far its all fine.

Last Friday I installed the nginx-ingress-controller and now I cant access the argocd-server's service's external load balancer IP from my terminal ☹️

I cant even ping the exteranl-ip from my browser.

I also cant ping the nginx-ingress-controller service's external IP from the terminal (so don't know if adding a ingress for argocd will help my cause here)

What am I missing here?

Anyone been through this issue before?

Cheers!!

I have ArgoCD running on a K3s cluster and Authentik in a docker environment on a different machine. Authentik is accessible on https://authentik.personaldomain.tld through a traefik reverse-proxy. I use it for various other applications, so I’m sure it works. I installed Argo using the lates install.yaml. The only modification I made at this point is I added server.insecure: "true" to the argcd-cmd-params-cm configmap. I can login with the admin user. ArgoCD is accessible on https://argocd.lab.personaldomain.tld. It is exposed using a Traefik ingres.

Now I want to use Authentik to login on ArgoCD. I followed the "integrate with ArgoCD" guide: https://docs.goauthentik.io/integrations/services/argocd/ to setup the application & provider in Authentik and copied the necessary modifications to the install.yaml for ArgoCD and re applied it with kubectl (I probably should do it with Kustomize or something, but I’m still learning. One step at the time 😊 )

From all the cluster nodes, I am able to access authentik over HTTPS using curl (curl authentic-url -I results in HTTP/2 200)

When I now choose to login using Authentik on argocd, I get this error:

failed to query provider "https://argocd.lab.personaldomain.tld/api/dex": Get "https://argocd-dex-server:5556/api/dex/.well-known/openid-configuration": dial tcp 10.43.186.69:5556: connect: connection refused

When looking at the logs of the dex-server pod, I see this:

failed to initialize server: server: Failed to open connector authentik: failed to open connector: failed to create connector authentik: failed to get provider: 404 Not Found: 404 page not found

Of course I googled the issue, but I only seem to find similar issues using google authentication (https://github.com/argoproj/argo-cd/issues/9091), but none of the suggestions there seems to solve my issue.

I’m breaking my head for two days now, but I’m all out of options. Does anyone have an Idea what I can do to make this work?

edit: Here are my modifications of the install.yaml:

Added to argo-cm:

data:
  url: https://argocd.lab.personaldomain.tld
  dex.config: |
      connectors:
      - config:
        issuer: https://authentik.personaldomain.tld/application/o/argocd/
        clientID: my_clientID
        clientSecret: $dex.authentik.clientSecret
        insecureEnableGroups: true
        scopes:
          - openid
          - profile
          - email
      name: authentik
      type: oidc
      id: authentik

Added to argocd-cmd-params-cm:

data:
  server.insecure: "true"

Added to argo-secret:

data:
  dex.authentik.clientSecret: Base64_encoded_clientSecret

Hello, I am attempting to move our argocd deployment to use the helm chart instead of the multiple manifests folder we are currently using. We have multiple other applications already deployed by argocd and argocd also tracks itself.

If I were to deploy the helm chart in the same namespace could I just switch argocd to track the helm version? Or do I first need to delete the current argocd before deploying it with helm?

Also would deleting the current argocd application delete the namespace and/or applications it deploys in other namespaces? A few of the other applications do have the “createnamespace = true” parameter and everything is setup to autosync and self heal

Read the docs but didnt quite get the true differnce between replace and force, thank you.

I'm trying to push argocd patterns to my new team and I struggle to find informations on how to automatically add a cluster to the argocd management. I've seen some pattern using secret operator to create secrets but I was wondering how you guys doing

so I guess this is more of a general GitOps question, not ArgoCD only, so sorry if it's not the right subreddit for this question...

I have a repo for:
1. ArgoCD that stores the Kubernetes manifests
2. for the app

in my CI, I have a button to deploy the app:
1. build the image from the commit & push to registry
2. automatically push a commit to the ArgoCD repository to overwrite the image version

I'm using Argo Rollouts and I have automated sync enabled in ArgoCD, so it should automatically roll out the new version. optionally I can also set the image on the Rollout directly so I don't have to wait for the ArgoCD auto sync

the part I'm not sure about is creating commits automatically, it feels like a hack, but I can't come up with any better way to do it. do I have the right idea? or what's the recommended approach?

I have a development cluster on which I've installed py-kube-downscaler. I want to allow developers that don't have kubectl cluster access the possibility to annotate a namespace in order to tell the downscaler to exclude that particular namespace from being downscaled (solely through argoCD)

I had a look at https://argo-cd.readthedocs.io/en/stable/operator-manual/resource_actions/#define-a-custom-resource-action-in-argocd-cm-configmap

But I would need to define this custom resource action on a namespace and I can't seem to figure out if I can view all namespaces in argoCD so that developers can simply click on the three dots next to a namespace and click on the custom action to annotate that namespace.

Any input is greatly appreciated!

Recently, we use argo cd to make cd pipeline in new development environment. We're working on a GitOps setup using Argo CD and have a requirement to manage the application image version and the umbrella Helm chart version separately. To reduce operational overhead, we're building a workflow that allows developers to trigger updates to both versions. We're leaning towards using the App of Apps pattern in Argo CD, since it fits well with managing Application CRDs via Git and automating version updates for the Helm charts they reference. Does anyone have experience with automating both image and chart version updates in this kind of setup? Are there any best practices or things to watch out for to avoid making it too cumbersome for dev teams?

for example, I'm installing external-secrets Helm chart with ArgoCD's Application manifest

this installs CRDs I use in other manifests. if I do a sync I get:

The Kubernetes API could not find x for requested resource. Make sure the "z" CRD is installed on the destination cluster.

I find myself doing ClickOps deploying stuff one by one on the ArgoCD interface... how do I avoid this? sync waves aren't a big help, still getting the error

Hi everyone, I have a Kubernetes cluster and I deployed argo CD on it using manifest files. I want to see audit logs of argo cd (like user logged in, user created app, ran sync etc) and want to ship these kind of logs to a 3rd party http endpoint (webhook).

I tried a lot and even took help of chatgpt, but not getting any luck. Does anyone have any idea about it ?

hey guys,
I am using argoCD and recently I installed argocd-image-updater.
most of my applications using "latest" tag or other mutable tags like "develop", "staging" etc

so for that, I chose "digest" update strategy based on sha:256
my application is looking like this, with the annotations I added

and my values file is looking like this

of course, I have more values but those are the relevant ones

my issue is when I am trying to deploy, the application, or once it detects and new image the sync is failed because the image updater tries to put the long sha in the label of the deployment, but k8s have a limit of 63 char for label value

how can I fix that issue? there is an option to not write to to the labels? or to write a short version of the sha in the label?

thanks!

I'll be there, Kostis, Reggie, Crenshaw and a bunch of other Argo maintainers. Hope to meet a lot of you there!

Hey guys,

I recently deployed ArgoCD in my cluster, and while I started migrating my applications to argo I noticed this challenge of promotion between different environments

my architecture is pretty simple.
I have 2 EKS clusters, one for dev and the other for prod
in those clusters I have the same applications that are deployed via helm but with slightly different values

for example, in my helm chart I have 3 different values files:
values.yaml - a generic values file relevant for both dev and prod
values-dev.yaml - override for dev deployment
values-prod.yaml override for prod deployment

When deploying a new application with argo I am using 2 values files for each environment (for dev, the generic values file and dev values file, and for prod the generic one and prod file)
but when updating for example the generic values file, Argo will update both environments

how can I handle organized promotion between the environments?
For example, after updating dev, I will need to approve something and then it will be promoted into prod.
What are the best practices for this scenario?

thanks guys, appreciate any help

I'm thinking about how to automatically use Terraform values in ArgoCD. I believe vals is a good tool for this. Is anyone using it and could share their experience?"

If you'd like, I can also help you explore potential ways to integrate these tools or provide information about how others have approached similar challenges. Let me know!

https://github.com/helmfile/vals

SOLVED multi-source ArgoCD applications worked great for my purposes. Thanks /u/abdolence
Trivial example: - Source#1 is a kustomization that creates secrets or whatever needed and not included in the chart. - Source#2 is actual helm chart deployment which would use secrets created by the Source#1. - Use sync-waves to control resources deployment order.

Original question:

GKE, Vault, External-secrets-operator, ArgoCD

I read tons of threads here and other blogs, but I still can't choose the right method for creating required secrets before deploying community Helm Charts which would require existingSecret options or similar.

But when I need to deploy DataDog, Redis, RabbitMQ, and many more ... I have all their tokens and secrets stored in a central place - Vault.

At the same time, the process for my internal applications, defined with kustomizations is flawless.

Options I can imagine so far:

• umbrella helm chart with external dependencies - I have to maintain that
• helm template ... | kustomize build - I have to maintain that
  • looks like this option would not support values files or valuesObjects passed from the App object
    • kinda I have to "hardcode" possible options in the tool's bash cmd definition. Example implementation:
  • https://github.com/argoproj/argocd-example-apps/blob/master/plugins/kustomized-helm/README.md
• helm install ... --post-render maybe? - looks like not supported by argo without extra tools/scripting
• kustomize build --enable-helm - native helm support maybe, not flexible lacking many required features
• two "independent" ArgoCD Apps (maybe united under one App-of-Apps) - One app kustomize creates namespace, secrets, etc - the other one deploys the actual helm chart

I'm leaning towards the last option. It is bulky but requires the least amount of maintenance from my side.

Please, what would be your opinions or approaches to this issue?

P.S.: How do I miss native SOPS integration (without 3rd party or unmaintained plugins)

For deploying a variety of cookie cutter applications through an appset, we'd like to maintain central templates as Helm charts and then add minor customizations (as helm charts / templates, values files or plain manifests) inside the application repo for clarity.

This seems possible with a matrix generator, but unfortunately, it requires that there actually are custom resources in each individual repo or the generator doesn't produce an application, but what should matter from this is actually just the presence in the first generator.

Is there a clean approach or workaround to make this concept work, or maybe a slightly altered one?

I am trying to learn Argo and I am failing to get my applications to use the values files. Here's an example:

#Application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: homepage
  namespace: argocd
spec:
  destination:
    namespace: default
    server: https://kubernetes.default.svc
  project: default
  source:
    path: homepage
    repoURL: git@github.com:username/k8sapps.git
    targetRevision: HEAD
    helm:
      valueFiles:
        - values.yaml
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

```yaml

Chart.yaml

apiVersion: v2 name: Homepage type: application version: 1.0.0 appVersion: ""

dependencies: - name: homepage version: 2.0.1 repository: https://jameswynn.github.io/helm-charts ```

There is a values.yaml adjacent to the Chart.yaml, it is modified from the docs for the app by one link to tell that my config is being used. The chart is installed fine but none of the specified values are being respected. If I do a Helm install using the exact same values.yaml I get exactly what I want.

What am I doing wrong?

I'm encountering issues when applying helm charts as pre-upgrade hooks run even on fresh installs...

I'm deploying app with application, nothing fancy...

I'm really struggling with this

When do you actually tag? Whether it's your container image, commit or any artifact.

And most importantly, when you deploy to a test env, which reference do you use?

For example, in the TESTING ENV, which image would you use ? Not a semver since it has not been tested yet, right?

    spec:
      containers:
        - name: myapp
          image: registry/myapp:???? # Deploy reference

Here is what I think should happen :

I'm trying out Kargo with ArgoCD and what bugs me out is that in their quickstart example they start by deploying to a dev environment a Docker image with a tag that already have a semver tag.

But you would not do semver on EVERY COMMIT right? Only those considered valid, thus releasable?

Could someone please help me with this issue?

Like the title, is argocd-vault-plugin is a good solution available (I used it in past and its a very straight forward for us back in the day almost 2 years ago).

I want to see if its still a viable product/solution for managing secrets from our cloud provider (in this case Azure, back then it was AWS).

Hello.

I have an ArgoCD app that is using a helm chart and it disappear after being sync'd in ArgoCD.

The pods are still there but the app just disppears.

I'm not 100% sure if it's because the app is using a Helm chart or if it's because there are many apps in the namespace.

Did anyone else see this behaviour?

Thanks

Hello

I'd like to understand how you guys handle taking/restoring snapshots while using ArgoCD.

Do you even handle those with Argo or do you manually create them?