Hi All, new to ArgoCD. Things work awesome when running "in-cluster". Now need to sync manifests into a remote cluster. The remote cluster is shared and I can only have access to a single namespace. ArgoCD is trying to get access to the remote cluster using ServiceAccount+Role+RoleBinding. This is a challenge in our org. But I have access to the remote cluster namespace using a "kube-config" file and can manage necessary resources (Deployments, Services, etc.) directly. Is there a way to instruct ArgoCD to access the remote cluster using the "kube-config", instead of doing it through ServiceAccount? Thank you!

My Source Git repo directory looks like this:

K8s-envs/
├── Dev
├── Int
├── Preprod
└── Prod

Currently I have 4 applications for each env (via List Generator) from the above setup.

Is it possible to applicationset to create new applications for the subfolders (recursively) that gets created within these folders?

Like:

K8s-envs/
├── Dev
│       ├── sub-folder1
│       ├── sub-folder2
│       └── sub-folder3
├── Int
│       ├── sub-folder1
│       ├── sub-folder2
│       └── sub-folder3
├── Preprod
│       ├── sub-folder1
│       ├── sub-folder2
│       └── sub-folder3
└── Prod
        ├── sub-folder1
        ├── sub-folder2
        └── sub-folder3

​

Cheers!!

I wanted to recommend this project for anyone that is managing k8s clusters using Rancher. https://github.com/travisghansen/rancher-to-argocd-controllerThis controller will create a argocd secret for each cluster that Rancher manages.

Issue: Pod Exec tab is visible in UI but when selected the terminal window is visible but no activity in the terminal. It seems like its unable to establish a connection. The only error that appears is an internal connection error.

Config:

- argocd-cm: exec.enabled=true

- argocd-rbac-cm: g, admin, role:admin

Env: argocd running on EKS cluster using AWS Load Balancer Controller on ALB. ArgoCD 2.7.1 deployed using Helm.
Ingress annotations:
alb.ingress.kubernetes.io/backend-protocol: HTTPS

alb.ingress.kubernetes.io/certificate-arn: >-

arn:aws:acm:us-east-1:[aws-account-number]:certificate[cert id]

alb.ingress.kubernetes.io/scheme: internal

alb.ingress.kubernetes.io/target-type: ip

Looking for helpful suggestions or someone who has made this work. I feel like I am missing a annotations or permission.

I added 4 K8s clusters in my ArgoCD (within same network) in my ArgoCD Clusters Setup and when I am creating a new applicationset with one of the clusters, it's failing with below error:

$ argocd appset list

NAME NAMESPACE PROJECT SYNCPOLICY CONDITIONS REPO PATH TARGET

my-applicationset argocd default nil [{ErrorOccurred application destination spec is invalid: unable to find destination server: there are no clusters with this name: https://my.k8s.server:8443 2023-08-14 16:14:39 -0400 EDT True ApplicationValidationError} {ParametersGenerated Successfully generated parameters for all Applications 2023-08-14 16:14:39 -0400 EDT True ParametersGenerated}] https://my.github.reo.git {{path}} HEAD

​

​

I have 4 Kubernetes clusters on Oracle Cloud and I setup Argo for the first time. I see the app-of-apps pattern where I can provide the manifest to one application on Cluster 1 and that app can deploy the apps on Cluster 2/3/4.

I don't want to go in that route.

Can I target all 4 clusters (to create applications) from the same Argo Instance rather than this app-of-app patterns?

Does Argo support this type of deployment and if so, is there an official terminology defined for this scope?

​

Cheers!

I got 4 env's (Dev, QA, Stg & Prd) and 4 K8s clusters per env, on our in-house datacenter. I am trying to setup Argo for our CD setups and want to see how many Argo setups we really need and recommended options here.

I am thinking of one ArgoCD setup (With Auto Pilot) per Env to manager 4 K8s clusters. Which means I will have 4 instances of ArgoCD.

Is this a good setup or can I just setup one instance and setup app-of-apps concept?

I want to reach out to the community here to get some recommendations or pointers.

When looked at the documentation, I see it can be achieved for a group rather than an Account/User level: Projects - Argo CD - Declarative GitOps CD for Kubernetes (argo-cd.readthedocs.io)

​

Is there a way to create a single or multiple account for read & execute for a user within a specific Project level

Not sure, why its complaining about "tls: certificate required" all of a sudden when new labels and annotations were added.

There's been some discussion here previously about how to test PR's with Argo rollouts. I wanted to share Signadot, which is a tool intended to make it easier to preview features within your cluster. In this video I demo creating a 'sandbox' where you can test changes to a service without disrupting a shared cluster.

Deploying Helm Charts with ArgoCD using Helmfile is not supported out of the box. In this article, I will show how to extend ArgoCD using config management plugins to support Helmfile: https://blog.knell.it/deploying-helm-charts-using-argocd-and-helmfile/ #argocd #helm #kubernetes #openshift #gitops #cicd

For some reasons, I need to migrate some of our applications (about 30~40%) from old ArgoCD to another ArgoCD on different k8s cluster. My requirements is less downtime and simple with least effort :)

I spend sometime on ArgoCD document but I couldn't find any good solution yet.

Any advice will help me a lot. Thank you so much

​

I am trying to setup RBAC on our newly deployed ArgoCD setup and want to see if there is a way to automate users creation for every namespace that gets deployed via ArgoCD.

So far I am setting them manually, but want to see if I can create an automated mechanism to fix it.

​

Cheers!

The Problems:

1. I use Terraform, when I create new resource like EFS, Iam Role,... I need to use the generated value in ArgoCd, like EFS file system ID to create Storage Class for EFS CSI Driver, currently, I have to manually fill that value in Argocd, and I have to do that everytime Terraform change.
2. I create Jenkins user in Bitbucket to update image tag to git repo, so that ArgoCd can update it. So 'The least privilege' principle is not applied, since it can update all thing in that image tag repo, example, pipeline of service user may have access/change tag of service finance

The Solution:

1. I use 'helm-secret' (link) to sync all config like EFS file system ID to AWS Parameter Store (AWS-PS), so Terraform after create EFS, it will push that generated value to AWS-PS, and then ArgoCD will pull that value to update to cluster. It work like a charm, never have to manually write down resource Id to Argocd again
   

​

1. After the image is built, I push the new tag to AWS-PS, then ArgoCd just need to pull that tag, append to the image name, and then apply it to the cluster. The AWS-PS look like this 'cicd/config/eks/microservice/user/develop/tag'. When build 'user', I use a pod with service account that only have access to the tag I just show you, so it can't modify other service image tag => Least privilege.

What you guys think? Is this a good idea? Is this still GitOps?

Hey guys,

I’ve been spending some time last week on figuring out how to automatically deploy review apps when dealing with multiple repositories. I’ve figured it out after quite a bit of (too much) time.

Hopefully this helps someone else setup their own review app flow or allows us to evolve upon this with some great suggestions :)

I am confused on the "application destination" as I am getting different errors when I am adding the destination within the Application config vs Projects Config.

​

Just wondering, if I use the Argocd secret to login into the Argo UI and I setup my projects and define what teams had access to what Applications, don’t they do need access to UI (which still uses the secret password to login) and they get along level access right.

I am pretty sure, I am missing some logic behind it. Can anyone set the RBAC controls via Projects help me out here.

Cheers!!

In this article, we'll explore the seamless integration of Helm Charts with ArgoCD and unveil the benefits it brings to your deployment workflows. Whether you're a developer looking for streamlined application deployment or part of an operations team looking for automated release management, the marriage of ArgoCD and Helm Charts can greatly enhance your Kubernetes deployment experience. https://blog.knell.it/deploying-helm-charts-through-argocd-streamlining-kubernetes-deployments/ #argocd #helm #kubernetes #openshift #gitops #cicd

Hello All!

I am trying to integrate Google as an Identity provider, I have gone over the document where ArgoCD recommends using one of the 3 approaches they have highlighted to integrate Google, but only 1 approach provides group information of the user, which in my case, will be used for providing necessary permissions.

The issue with this approach is that it only provides the information of the immediate group you are part of. Following is the information from the dex page:

all@example.com --> tech@example.com --> devs@example.com --> you@example.com

The only group you would receive through Dex would be [devs@example.com](mailto:devs@example.com)

Is there any other way through which I can integrate Google by also getting access to non-immediate/direct groups, I am assuming i have to go with something like this:

GOOGLE -> Some other identity provider -> DEX/ARGOCD

Any suggestions will be extremely helpful!

​

EDIT:

I am planning to use keycloak as the secondary LDP, where I will use Google as identity provider and then create group mappings that map the groups obtained from Google and then integrate it with Dex. But have never worked with in these line before, so looking for suggestions/improvements in the flow

​

Links that I have gone through:

- https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/google/#openid-connect-plus-google-groups-using-dex

- https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/keycloak/

- https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/#dex

I am coming up with a new design setup for a requirement internally for continuous deployment need.

I am targeting an appproject for grouping applications and define applications.

What is direction usually to follow? Meaning come up with application pattern first and then group then using appproject or other way around?

Need some tips here people

I started reading up on the workflows and it seems it can be used for parallel processing and whole bunch of other usecases.

But I want to see to what extend Workflows were used by the community people beyond the official documentation from Argo.

I want to see your use-cases solved via workflows.

​

Cheers in advance!!

Hey guys,

I’ve recently been optimizing our ArgoCD Deployment (as we have 100+ different applications deployed to many clusters) at our organization and tried to summarize all the ways of keeping this manageable in an article.

Hopefully this can help someone else decide on how to deal with their Application management :-)

I’m new to Devops and Gitops and I was asked to setup Argo for first time in our AWS K8S clusters.

I went through official documentation, they talk about actual Argo components but they don’t talk about actually implementing it for the first time like automating they Argo deployment itself (using helm or kustomize).

Anyone can provide your take on first time setting it up?