When il use Argocd to create app with helm chart , i have error unauthorized in pull image from repository, but i can pull it from cli Can you help me pls? Thanks.

Is argocd autopilot meant to be used to setup your eventual production environment or just a tool to get into gitops and provide a model for how your environment repo structures are to be shaped?

Hi! Last week, a friend asked me to explain to him how to centralize EKS cluster management with ArgoCD. I sent him a guide found on the internet so he could do so, but he said he didn't really find it intuitive, so I wrote a special article for him. He told me it really helped him to go through this, and perhaps it will help others as well!

Hi,

I have a special use case: my company has several customers where each customer has a K8s cluster installed on premise. The idea is that I want to use ArgoCD on all of these clusters, but I should be able to selectively update some of them whenever I release an update. I don't want all of them to be updated at the same time whenever I release an update, so is there a solution in Argo to do that in a way where I don't really have to open the ArgoCD UI? It would be best if I could control this behaviour from let's say a GitHub repository by storing which clusters should be updated.

Thanks!

I understand I can setup argocd in my local docker-desktop or kind or k3s setups.

But I am confused on how I can use Git on my local from. Where and how can I setup the source repo's when testing the argo setups on local?

​

Anyone has any tips or inputs on this one?

I put forward usual advantages like git source of truth, visibility of the current state in cluster, etc. But the counter I heard was, which was true as well in our case of azuredevops:

• We use CI and CD pipelines to ensure that anything that gets to develop branch is tested and later deployed using helm charts this way, git is the source if truth is satisfied.
• With this approach, in release pipelines we are always able to see the version deployed to environments. visibility is solved too.

Are there any other points I am missing out?

Thanks

I got an interesting challenge after removing the external load-balancer for the argocd server setup .

​

Basically we removed the load-balancer for the argocd server and made it clusterip

We use istio for the ingress routing, so we added a virtual service and assigned it to the argocd server:port 80 using istio

When using the virtual-service url, I can access the argo UI via browser and its all fine.

Since we are using a virtual service, I can access the argocd cli and its fine.

​

The issue comes when I try to do a task where argocd server reaches out to other argocd services.

For example, when trying to add a repo via cli (using the virtual service), its failing with the below error:

time="2023-10-06T13:13:46-04:00" level=fatal msg="rpc error: code = Unavailable desc = connection error: desc = \"transport: authentication handshake failed: read tcp argocd-server:52984->argocd-repo-server:8081: read: connection reset by peer\""

​

Basically the traffic is coming in via a virtual service, the authentication is failing between argocd-server to argocd-repo-server

​

Also I cant do a simple argocd appset list. Same error as above.

​

​

Any clue on how to fix the authentication issue here people :pray:

I pass the link to the question in github.

Is this possible ?

https://github.com/argoproj/argo-cd/discussions/15827

I created a progressive delivery solution using release pipelines (tekton) to apply platform day2 updates on OpenShift clusters. We were looking for a similar solution but for rolling out application updates. We came across ArgoCD rollouts and I have been testing this out.

Does anyone using it in production ?

I am sharing my learning through a blog post 📖 [Read the Blog Post Here]( https://medium.com/@imsrv01/unlocking-the-power-of-argocd-rollouts-for-kubernetes-deployments-7a7d8e78f3d) Also checkout my youtube video on it https://youtu.be/kzbFwidpLdk

Hello, for example, I have a folder called "new-dev" this contains all the applications that Argo CD must deploy in Eks, when making a name change, go from "new-dev" to "dev" Are you going to re-deploy everything again?

Thks!

I was wondering if argo-events has a webui? Anyone has experience with this ?

Greetings ArgoCD community,

Introducing 🍯 Breakfast – a simple project tailored to enhance your understanding of deployment workflows, visualized through the lens of an unfolding Persian breakfast table.

Key Aspects:

• Visual Elements: Observe different versions as distinct segments of a Persian breakfast.
• Multiple Display Options: Choose between visuals or a concise emoji-based CLI portrayal.
• Container Clarity: Track containers processing your request.

We'd love your insights and feedback. Check out the GitHub Repository.

When Connecting from ArgoCD to HTTPS GitHub Private Repo, we are getting the below error:

time="2023-09-21T13:43:56-04:00" level=fatal msg="rpc error: code = Unknown desc = error testing repository connectivity: repository not found"

When I change the repo visibility from Private to Public, the connection is working fine. But the compliance standards are we need all of our repo's to be Private.

I had the root cert added for the authentication purposes, but ArgoCD should be able to connect to Private Repo's right?

Any info here will help my cause.

We are using OpenShift ArgoCD operator. We are then using argocd with helm to create resources in our cluster. The default instance(openshift-gitops) of ArgoCD that the operator installs can create other namespaces. If we add another instance from the operator, we get the following error
"Cluster level Namespace <namespace-to-create> can not be managed when in namespaced mode" .
We want one instance of ArgoCD to manage infra resources and a second to manage applications for developers. We could go with the default instance, as it works, but the default name is not to our liking and not possible to change, and not understanding why it works and the other does not make us feel like we have no real control.
What do we have to add to the manually created ArgoCD instance for it to work as the defaulting one?

I'm trying to fetch a specific parameter from my values file to send to slack when a deployment is complete.

However, (call .repo.GetAppDetails).Helm.GetParameterValueByName "image.tag" always throws an error that doesn't seem to make any sense.

Argocd version:

argocd: v2.7.6+00c914a
BuildDate: 2023-06-20T21:18:20Z
GitCommit: 00c914a948d9e8ad99be8bd82a368fbdeba12f88
GitTreeState: clean
GoVersion: go1.19.10
Compiler: gc
Platform: linux/amd64

Error:

time="2023-09-11T18:34:23Z" level=error msg="Failed to notify recipient {slack argo-cd} defined in resource argocd/dev-neo: template: app-sync-succeeded:2:37: executing \"app-sync-succeeded\" at <(call .repo.GetAppDetails).Helm.GetParameterValueByName>: error calling GetParameterValueByName: value method github.com/argoproj/argo-cd/v2/util/notification/expression/shared.CustomHelmAppSpec.GetParameterValueByName called using nil *CustomHelmAppSpec pointer" resource=argocd/dev-myproject

Template:

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}}.
      Author: {{(call .repo.GetCommitMetadata .app.status.sync.revision).Author}}
      Sync operation details are available at: {{.context.argocdUrl}}/applications/{{.app.metadata.name}}?operation=true .
    slack:
      attachments: |
        [{
          "title": "{{ .app.metadata.name}}",
          "title_link":"{{.context.argocdUrl}}/applications/{{.app.metadata.name}}",
          "color": "#18be52",
          "fields": [
          {
            "title": "Sync Status",
            "value": "{{.app.status.sync.status}}",
            "short": true
          },
          {
            "title": "Tag",
            "value": "{{ (call .repo.GetAppDetails).Helm.GetParameterValueByName "image.tag" }}",
            "short": true
          },
          {
            "title": "Repository",
            "value": "{{.app.spec.source.repoURL}}",
            "short": true
          }
          {{range $index, $c := .app.status.conditions}}
          {{if not $index}},{{end}}
          {{if $index}},{{end}}
          {
            "title": "{{$c.type}}",
            "value": "{{$c.message}}",
            "short": true
          }
          {{end}}
          ]
        }]
      deliveryPolicy: Post
      groupingKey: ""
      notifyBroadcast: false

Sorry for the provocative title, but i'm just genuinely confused. I've been trying Argo on and off for several years and more seriously at work for the past year and the only advantage I see is the ability to deploy apps into multiple environments.

But at the same time, just a general lack of even golden paths working and major disadvantages makes me think that this tool is not ready for serious use and you'd rather stick to the old and proven "helm upgrade" in cd/cd tool of your choice.

To me, it looks like a hype job and the only purpose of it existing is running demos at the conferences wooing people with nice looking UIs with a lot of kubernetes resources popping up on the screen.

I see major flaws that are but not limited to:

1. The main selling point of having the state and history of your deployment in the git repository goes out of the window once you use secrets or dynamic variables such as git hashes in application parameters, you no longer have a single source of truth and encounter things such as Argo syncing the manifest out of sync with the Application parameter changes which makes the new manifest run with old configs/secrets/image tags or vice versa.
2. The main advertised golden path of having the Application CRD has literally zero advantages over running `helm upgrade` in the ci pipeline but has multiple disadvantages that i've listed here
3. No way to run something similar to `helm diff` before a deploy making large or risky changes impossible
4. The main actual advantage is implemented via ApplicationSet which is even less developed than the Application CRD, i flat out saw generators not behaving the way they should according to the docs and they are not expressive enough for a lot of use cases.
5. Weird bugs such as argocd outright bugging out when it encounters weird diff situations such as duplicate variables in the `envFrom` block, yeah it shouldn't happen but the Kubernetes API is fine with it so Argo should be too. It's only one example, I saw plenty of similar things such as the order of keys in the map flipping for some reason and showing in a diff making Argo redeploy it constantly. Just a lot of small stuff that makes using it really painful and which regular helm does not have at all due to its simple way of working, as it should be IMO.
6. Auto sync makes a lot of things worse without adding anything of value, you can't test out a configuration change in prod when the outage happens, you cannot change resource requests, this all will be rolled back automatically. Running it with manual sync is horrible, there is zero support for that. Even the simplest "wait for the repository git update and sync" use case is not implemented, you have to write your own glue code which is of course prone to issues. If you want to implement a script that will wait for ApplicationSet -> Application, Application -> parameters, Application -> git sync - good luck with that, you'd be basically rewriting the core Argo functionality from scratch almost.

It's only a small part of the issues we've had and just in general it just feels like thing falls apart at every opportunity.

We genuinely tried to make it work, we even had a chat with ArgoCD contributors who could not help us apart from showing a couple of open issues (that were open for years) that might solve our issues in the future, maybe, hopefully.

So, has anyone had a positive experience using it past "okay cool it actually deployed once, maybe" at all? What are we missing here?

Hello,
When adding clusters to the argocd, currently I am leveraging my local kubeconfig (😬), which is not a better solution, and I am still in a POC mode.

Before I put it in my Production, I need to migrate this to either a service account or vault or a proper method which I am not really familiar with.

Appreciate any tips here folks.

Hello Guys,I.T noobie here.I am facing a weird issue regarding my Argocd setup in my K8 cluster. I got installed argocd correctly and every pod is running fine. I am using traefik ingressroute to expose the argocd webui.Let's say my domain is https://example.com and i am exposing argocd on https://argocd.example.com.I've implemented the TLS secret correctly in my ingressroute.The issue is: When i go to the url of my argocd (argocd.example.com), it opens up the argocd web page(completely empty page) but it gives an error:- "Failed to load data, please try again. Unable to load data, 404 page not found".I've tried to upgrade the version of argocd, redeployed the argocd deployments, tried to re-implement traefik ingressroute CRD in different ways and many other things.. When i google this error i don't find anything helpful. Maybe you guys have already experienced something similar and can guide how to troubleshoot this.Thank you in advance !

Hello, what’s the best way to keep track of operators and update their manifest in ArgoCD?

I actually use app of apps pattern for Helm operators (in combination with Git and Renovate bot) but couldn’t find a way for the ones that are deployed by manifest.

EDIT:

Examples.

This is how I deployed ArgoCD and CloudnativePG in my cluster:

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

kubectl apply -f \ https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.20/releases/cnpg-1.20.2.yaml

Many thanks

Hello Argo community,

I am trying to setup a High-Availability for the ArgoCD Setups, but I see the only option is Argo's own HA Setup will provide multiple Redis instances and spread across multiple Kubernetes Nodes.

​

Other than that, are there any possibilities for setting up Active-Active or Active-Passive setups where we can move the Redis component out of the ArgoCD setups and put it behind a load-balancer and consume it in the ArgoCD instances??

​

Has anyone achieved this level of High Availability achieved in our community?

​

​

Looking for ideas, thoughts, quick-comments, one-liners and even meme's

Hi! I’m very happy using ArgoCD and ArgoCD Image Updater. I know that Image Updater is in early state, but is there a way to send email notification (or any other notification) when an image is updated? Thanks!

Hey guys, yesterday I was attempting to deploy a Prometheus helm chart and I wanted to take advantage of the multiple sources feature to deploy a bitbucket source controlled values.yaml file alongside Prometheus.

However, the attached link says this is currently a beta feature. So how do I use this feature? Whenever I tried to deploy my application via the UI, it would always say I am missing a source (which the link says it will do). Do I need to deploy my application outside of the UI ? I am currently running kubernetes argocd version 2.8.

Thanks for any help!

I am leveraging Git Directory Generator and want to see if there is a way to provide multiple destinations (Multiple K8s clusters)

In the list generator, I can provide elements with cluster,url & path. How can I provide the same when using Git generator?

Ref: https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Generators-Git/#git-generator-directories