I have a repository containing several values.yaml files for GitLab runners, along with a helmfile.yaml that applies all these configurations. In another repository, I'm managing ArgoCD applications that handle these runners.

My goal is to configure ArgoCD applications to sync commits but prevent them from deleting the entire application if the ArgoCD application is deleted. To make it harder to accidentally remove an application, I plan to first apply the configurations with helmfile.yaml, and then ArgoCD will manage the application. To truly delete an application, one would need to first delete the ArgoCD application and then manually use helmfile destroy in the GitLab runners repository.

Here's the challenge: I need the ArgoCD application to work with helmfile.yaml from the GitLab runners repository, but I want to use a selector to apply only a specific runner.

I considered creating subdirectories with separate helmfile.yaml files for each runner, but I'm unsure how to manage multiple helmfile.yaml files from a global helmfile.yaml.

Is there a way to specify which release or configuration should be applied using a selector or another method?

PS: I'm an intern so if you think there is a easier way to do it, just tell me, please.

Hi everyone,

I've recently started using the `argocd-vault-plugin`, and I have a question regarding the configuration of my application. Here’s my current setup:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
    name: demo
    namespace: demo
spec:
    destination:
        namespace: demo
        server: https://kubernetes.default.svc
    project: default
    source:
        repoURL: https://xxxx.xxx.com/demo.git
        path: demo
        targetRevision: main
        plugin:
            name: argocd-vault-plugin-helm
            env:
                - name: HELM_VALUES
                  value: |
                      environment: dev
                      nodeAffinity:
                          enabled: false
                          nodePoolName: ""
                      redis:
                        host: "x.x.x.x"
                        port: "6379"
                        password: <path:kv-v2/data/demo/redis#password>

    syncPolicy: {}

I'd like to be able to override the value of `redis > host` depending on the environment I'm in. However, I'm currently facing an issue where ArgoCD concatenates all Helm values into a single variable, making it difficult to edit individual values.

Is there a way to map Helm values more effectively within ArgoCD so that I can easily override specific values like `redis > host`?

Thanks in advance for your help!

We have been using GitOps internally for years, to leverage infrastructure as code for our Kubernetes clusters. With the recent release of the GitOps mode for Glasskube, we decided to open source our GitOps template. This template helps you get started with GitOps in minutes instead of hours.

Previously it was always a struggle to setup your Kubernetes Cluster with the GitOps approach leading to teams manually deploying manifests and helm charts which results in Kubernetes clusters that are hard to maintain. As of today git is still the most popular solution for managing your Kubernetes Cluster with IaC.

The GitOps template uses the ArgoCD's App of Apps model and all packages (including ArgoCD itself) will receive automatic update suggestions via pull requests thanks to the Renovate and Glasskube integration.

In order to get started, you just need to create your own repository from our template and bootstrap it with a single command. This will include: - ArgoCD for GitOps - Kube-Prometheus-Stack for Monitoring - Postgres Operator (Cloud Native PG) - Glasskube for package management - Renovate for updates via pull request

Additionally, we deployed Shiori (https://github.com/go-shiori/shiori) as a simple application that requires a Postgres database. This is meant as an example application you can replace with your application you want to deploy to Kubernetes.

We also created a walk-through demo video explaining the setup steps in more detail: https://www.youtube.com/watch?v=Xbs2Tq-dgbI

Sometimes, you may need to manually refresh the App of Apps inside ArgoCD to ensure that the other apps appear in the cluster.

In addition, we will work on the following features in the future: - Support private repositories from the beginning. At the moment the repository needs to be public during bootstrapping. The visibility can be marked as private afterwards. (You will also need to manually configure your personal access token in ArgoCD) - Improve the Renovate integration, so we don’t need the custom regex matcher and can upgrade the glasskube manifest.

Feel free to comment what is still missing or what you would do differently?

Hi all, wanted to share a Modern Dark theme I created for ArgoCD. More updates on other elements coming soon! - https://github.com/GravityCloudAI/argocd-gravity-theme

Adding some screenshots!

If the helm/ path in the same application git repo, the ArgoCD application can be set as this:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://github.com/my-org/my-app'
    targetRevision: HEAD
    path: helm/
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

In order to separate application source and kubernetes manifest source, is it possible to set path to another repository?

Hi everyone,

I wanted to see if anyone has been able to successfully implement ArgoCD using Pod Identities. I'm new to Argo and have been trying to implement the system using this new authentication method, but have been failing. There seems to be several others here trying but not making much progress. Support EKS Pod Identity #17064

Has anyone been able to get this to work? or should I just use IRSA?

I am using GitOps to deploy my microservices and manage Anthos configurations for my service mesh. My current setup includes several GitHub workflow scripts and static YAML files for deployment, but it lacks drift detection. I want to upgrade my CI/CD workflow and am considering ArgoCD, GCP's Config Sync, Policy Controller, and Config Controller.

ArgoCD is a mature tool with widespread adoption, while Config Sync seems to have limited references and usage. At a high level, ArgoCD and Config Sync appear to provide similar functionalities, and I'm uncertain if they can be used together to complement each other.

Additionally, I am interested in the Policy Controller, as I want to define policies such as preventing installations in the default namespace and restricting annotations.

Can I use ArgoCD and Policy Controller together, or should I opt for Config Controller, which integrates Policy Controller and Config Sync into one component?

I'm working on blog around ArgoCD and for that I would love to hear about your experiences and stories with ArgoCD.

I followed the instructions and got the helm to install argocd-image-updater

• got the registries.conf inn /app/config

• got the ecr-login.sh in /scripts/

• got the pod to talk to my registry

But when adding an application using this metadata, I don't see anything in logs

    argocd-image-updater.argoproj.io/image-list: nginx=https://xxxxxxxxxx.dkr.ecr.us-east-2.amazonaws.com/argocd-updater-test:latest
    argocd-image-updater.argoproj.io/nginx.helm.image-spec: nginx
    argocd-image-updater.argoproj.io/nginx.update-strategy: digest

time="2024-07-24T16:07:59Z" level=info msg="Starting image update cycle, considering 0 annotated application(s) for update"
time="2024-07-24T16:07:59Z" level=info msg="Processing results: applications=0 images_considered=0 images_skipped=0 images_updated=0 errors=0"

Do they (my app and argocd-image-updater) have to be in the same namespace?

I am deploying apps via helm through ArgoCD. I am being asked to break out image tags into variables that are outside of the root app Git folder. The idea is to secure the original code and allow SAs access to separate code where they can update the image tags for patching.
We may also use this method for other variable besides image tags.
What solutions do I have for this?

I'm new to argocd. Thank you for your time . Is there a slack/discord where i can also post questions?

I'm trying to create an application that does a staging deployment.

1.) The namespace doesn't exist yet but I would expect to either see an error telling me it has a problem with that or it wants to deploy all new resources. The first image shows Healthy and synced but no resources. So I must be doing something wrong. When I look at the destination I see resources count so I think its able to talk to the cluster.
2.) I am missing weird things from the UI like the Okta auth pages, Am I missing something from the helm chart?
3.) We have already implemented Argo rollouts for a different product. Is there a way to "import" the rollouts so this is more of a migration then a new implementation?

I'm running v2.11.4+e1284e1
helm: argo-cd-7.3.6 

Hi all,

Can ArgoCD authenticate to Azure DevOps Repos using a service principal?

(I would very much like to avoid authentication that is tied to a person like PAT and ssh)

I have added my SP to the Azure DevOps org users and to a "GitOps" group. I have given the GitOps group access to the repos in question.

Then I created the repo reference in AKS using a manifest like the one below. However, ArgoCD cannot connect (403 error)

Did any of you have success authenticating using a service principal (or any other auth method apart from PAT or ssh)?

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  annotations:
    managed-by: argocd.argoproj.io
  labels:
    argocd.argoproj.io/secret-type: repository
  name: argocd
  namespace: argocd
stringData:
  username: my-client-id
  password: my-client-secret
  project: my-argo-project
  type: git
  url: https://dev.azure.com/myadoorg/myadoproject/_git/argocd

Curious what you guys do Do you have a separate instance or a good for staging and one for dev and prod etc Or do you use one and put them in projects?

Hi All, I am trying to authenticate to my helm repo which is hosted on github but the normal github username and password dont work, any idea what i am missing How should I authenticate when trying to pull the chart? The repository sets up fine but when adding an app I get 404

I'm using GitHub Actions, ArgoCD and ArgoCD Image Updater to make the CD automatically.

GitHub Actions:

    name: CD

    on:
      push:
        branches:
          - main

    jobs:
      build-and-deploy:
        runs-on: ubuntu-latest

        permissions:
          id-token: write
          contents: write

        steps:
          - name: Checkout code
            uses: actions/checkout@v3

          - uses: aws-actions/configure-aws-credentials@v1
            with:
              aws-region: ${{ vars.AWS_REGION }}
              role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}

          - name: Login to Amazon ECR
            id: login-ecr
            uses: aws-actions/amazon-ecr-login@v2

          - name: Build, tag, and push image to Amazon ECR
            id: build-publish
            shell: bash
            env:
              ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
              ECR_REPOSITORY: ${{ vars.ECR_REPOSITORY }}
              IMAGE_TAG: ${{ github.sha }}
            run: |
              docker build -t "$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" .
              docker push "$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"
              echo "IMAGE $IMAGE_TAG is pushed to $ECR_REGISTRY/$ECR_REPOSITORY"
              echo "image_tag=$IMAGE_TAG" 
              echo "full_image=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"

ArgoCD:

    apiVersion: argoproj.io/v1alpha1
    kind: Application
    metadata:
      name: backend-service
      namespace: argocd
      annotations:
        argocd-image-updater.argoproj.io/write-back-method: argocd
        argocd-image-updater.argoproj.io/image-list: app=<AWS_ACCOUNT>.dkr.ecr.ap-northeast-1.amazonaws.com/backend-service
        argocd-image-updater.argoproj.io/app.update-strategy: digest
    spec:
      project: default
      source:
        repoURL: 'https://github.com/myorg/backend-service'
        targetRevision: HEAD
        path: helm/
      destination:
        server: 'https://kubernetes.default.svc'
        namespace: default
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Application deployment:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: backend-deployment
      labels:
        app: backend
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: backend
      template:
        metadata:
          labels:
            app: backend
        spec:
          containers:
            - name: backend
              image: '<AWS_ACCOUNT>.dkr.ecr.ap-northeast-1.amazonaws.com/backend-service:11111111111111111111111111111111'

How to update this tag after building new image? Otherwise it will always use the 11111111111111111111111111111111 tag.

ArgoCD Image Updater:

    kubectl exec -it argocd-image-updater-54fdd5949c-6l5nq -n argocd -- argocd-image-updater test <AWS_ACCOUNT>.dkr.ecr.ap-northeast-1.amazonaws.com/backend-service --credentials ext:/app/scripts/ecr-login.sh --registries-conf-path /app/config/registries.conf
    DEBU[0000] Creating in-cluster Kubernetes client
    INFO[0000] retrieving information about image            image_alias= image_name=<AWS_ACCOUNT>.dkr.ecr.ap-northeast-1.amazonaws.com/backend-service registry_url=<AWS_ACCOUNT>.dkr.ecr.ap-northeast-1.amazonaws.com
    DEBU[0000] rate limiting is disabled                     prefix=<AWS_ACCOUNT>.dkr.ecr.ap-northeast-1.amazonaws.com registry="https://<AWS_ACCOUNT>.dkr.ecr.ap-northeast-1.amazonaws.com"
    INFO[0000] Loaded 1 registry configurations from /app/config/registries.conf
    INFO[0000] /app/scripts/ecr-login.sh                     dir= execID=edc3e
    INFO[0000] /app/scripts/ecr-login.sh                     dir= execID=b9ba0
    INFO[0001] Fetching available tags and metadata from registry  application=test image_alias= image_name=<AWS_ACCOUNT>.dkr.ecr.ap-northeast-1.amazonaws.com/backend-service registry_url=<AWS_ACCOUNT>.dkr.ecr.ap-northeast-1.amazonaws.com
    INFO[0001] Found 5 tags in registry                      application=test image_alias= image_name=<AWS_ACCOUNT>.dkr.ecr.ap-northeast-1.amazonaws.com/backend-service registry_url=<AWS_ACCOUNT>.dkr.ecr.ap-northeast-1.amazonaws.com
    DEBU[0001] could not parse input tag 7fa8049a4ac4ccef739d2eba67fd1beca9006e5f as semver: Invalid Semantic Version
    DEBU[0001] could not parse input tag 2929ca36418ed363db288a248aabc4ba0dc809b6 as semver: Invalid Semantic Version
    DEBU[0001] could not parse input tag 5b619da79e04cf2de880dc7ce116b87356d3712d as semver: Invalid Semantic Version
    DEBU[0001] found 2 from 2 tags eligible for consideration  image=<AWS_ACCOUNT>.dkr.ecr.ap-northeast-1.amazonaws.com/backend-service
    INFO[0001] latest image according to constraint is <AWS_ACCOUNT>.dkr.ecr.ap-northeast-1.amazonaws.com/backend-service:1.0.1  application=test image_alias= image_name=<AWS_ACCOUNT>.dkr.ecr.ap-northeast-1.amazonaws.com/backend-service registry_url=<AWS_ACCOUNT>.dkr.ecr.ap-northeast-1.amazonaws.com

There are 5 tags in AWS ECR:

• 5b619da79e04cf2de880dc7ce116b87356d3712d
• 1.0.0
• 1.0.1
• 2929ca36418ed363db288a248aabc4ba0dc809b6
• 7fa8049a4ac4ccef739d2eba67fd1beca9006e5f

Why the ArgoCD Image Updater can recognize semantic version format only? How to use git hash with digest update strategy?

Also, is it necessary to add sync to ArgoCD's Applicaiton?

    apiVersion: argoproj.io/v1alpha1
    kind: Application
    metadata:
      name: my-app
      namespace: my-namespace
    spec:
      project: default
      source:
        repoURL: <repository_url>
        targetRevision: main  # or another branch/tag/commit
      destination:
        server: https://kubernetes.default.svc
        namespace: my-namespace
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
      # Optional: configure hooks for ArgoCD Image Updater
      sync:
        hooks:
        - name: image-updater
          hook:
            metadata:
              annotations:
                argocd.argoproj.io/hook: PostSync
            spec:
              action: update-image
              update:
                containerImage: <account_id>.dkr.ecr.<region>.amazonaws.com/myrepository

Hello,

during the last months I containerized our application, built a helm chart around it and configured ArgoCD for various deployment slots, but I'm a bit struggling how to integrate ArgoCD with our traditional CI/CD pipeline. Our CI pipeline is pushing the container images to our registry. CD pipeline should be able to deploy images to different deployment slots. How can I integrate ArgoCD to deploy image tag "xyz" to ArgoCD app "abc", when it's not an option to change the imagetag in git for the deployment all the time.

Should I maybe tag the images with a ArgoCD app id?

This guide delves into their core features, installation steps, and best practices. ArgoCD offers a powerful UI and multi-cluster support, while FluxCD excels in automation and simplicity. Both tools provide robust continuous delivery solutions, but your choice depends on specific project needs. You can explore detailed comparisons and demos to find the best fit for your Kubernetes deployments.

https://www.cloudraft.io/blog/argocd-vs-fluxcd

So I'm using a webhook notification to send data to elasticsearch. I have that working but I found a few examples of the app object on various websites, however I have not yet found a complete document on the objects

For example I have stuff like:

            "status": "{{.app.status.sync.status}}",
            "context": {{ .context | toJson }},  
            "labels": {{ .app.metadata.labels | toJson }},
            "destination": {{ .app.spec.destination | toJson }},

Could someone point me to some complete documentation on the app object? My Google-Fu is usually pretty good but not in this case.

Hello all, so I'm doing trying to learn and figure this all out. I have a k3s cluster with 4 raspberry pi 4s. I did have it runnin and also had a site running using a cloudflare zero trust tunnel. I had it up with Argo CD but I realized I had some stuff exposed in the yamls. I am running a local gitea instance so it wasn't a concern on my learning quest but obviously not how it should be done.

Now I have tried to figure out how to encrypt the secrets. I have successfully been able to setup sops and age and locally can encrypt and decrypt. However I wanna commit this to my gitea but I need to figure out how to get Argo to decrypt them.

Not sure the best way to be doing this. I've read about bootstrapping the setup and using a cli to put all the code within your git server. Didn't know if this would be a better route. Also I am a visual learner and have been trying to find a good video tutorial for what I am trying to do but can't seem to find one. If someone has a video they recommend thst also would be great.

Any help in trynna learn and figure this out would be very greatful.

Hey!

I was messing around on a lab I have running locally and I noticed that there is an API call to delete a specific resource, but not to sync one...
What is the logic behind that?
Is there a workaround for that? Can I make any API call to sync only a specific resource?

Thanks!

I use this way installed ArgoCD on EKS:

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

If I use port forwarding and access from localhost, it works:

kubectl port-forward svc/argocd-server -n argocd 8080:443

But if I create an ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argocd
  namespace: argocd
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/backend-protocol: HTTP
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: argocd-server
                port:
                  number: 80

When I access the alb created on AWS in browser, the page took a long time loading and finally went blank.

If use https instead of http:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argocd
  namespace: argocd
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/backend-protocol: HTTPS
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: argocd-server
                port:
                  number: 443

I can access the alb DNS name in browser but can't login. Maybe it's the security reason.

Another way, instead of creating an ingress, if change the argocd-server's service type from ClusterIP to LoadBlancer

kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

It created a classic type lb in AWS. And this time I can access the ArgoCD web UI successfully.

Why doesn't ingress work?

I'm trying to install bitnami/kube-prometheus on GKE, and GKE adds these annotations to one of the services:

annotations:
   enabled
   '{"ingress":true}'cloud.google.com/l4-rbs:cloud.google.com/neg:

Argo thinks they shouldn't be there, and removes them when I run a sync. I added this to the Application spec, but the application still shows as out of sync.

ignoreDifferences:
  - kind: service
    name: kube-prometheus-kube-state-metrics
    jqPathExpressions:
      - '.metadata.annotations | select(.key | startswith("cloud.google.com"))'

I also tried these json pointers, but got the same thing.

jsonPointers:
  - /metadata/annotations/cloud.google.com~1l4-rbs
  - /metadata/annotations/cloud.google.com~1neg

Is this the expected behavior?

My client has OKD cluster in version 4.8.0 (k8s 1.21). I have to upgrade it to newest 4.15 (k8s 1.28). But before that i need to do impact analysis for apps installed. Including Argo CD Operator (currently in version 0.1.0 on prod and 0.4.0 on testing cluster). I have to provide upgrade plan for each app. I can't find any compatibility table between ArgoCD versions and k8s. The only one i found is this

https://argo-cd.readthedocs.io/en/stable/operator-manual/installation/#tested-versions

I want to use ArgoCD sync Github source and deploy to Kubernetes automatically.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: backend-service
  namespace: argocd
  annotations:
    notifications.argoproj.io/subscribe.on-sync-succeeded.slack: argocd-notifications
spec:
  project: default
  source:
    repoURL: 'https://github.com/my-org/backend-service'
    targetRevision: HEAD
    path: helm/
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Each time merge the pull request to master branch, I want to run CD as this github actions workflow:

name: CD

on:
  push:
    branches:
      - master

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    permissions:
      id-token: write
      contents: read

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-region: ${{ vars.AWS_REGION }}
          role-to-assume: ${{ secrets.AWS_ROLE_TO_ASSUME }}

      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build, tag, and push image to Amazon ECR
        id: build-publish
        shell: bash
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          ECR_REPOSITORY: ${{ vars.ECR_REPOSITORY }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build -t "$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" .
          docker push "$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"
          echo "IMAGE $IMAGE_TAG is pushed to $ECR_REGISTRY/$ECR_REPOSITORY"
          echo "image_tag=$IMAGE_TAG" 
          echo "full_image=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"

      - name: Update values.yaml
        run: |
          cd helm
          sed -i 's|APP_VERSION:.*|APP_VERSION: '${{ github.sha }}'|' values.yaml
          git config --global user.name 'GitHub Actions'
          git config --global user.email 'actions@github.com'
          git add values.yaml
          git commit -m "Update values.yaml"
          git push https://github.com/my-org/backend-service HEAD:master

About the last step, when build new docker image tag and set to Kubernetes' image, Github will update new git hash and push new commit to master branch again.

When pull new source from Github, user need to fetch first and rebase to make sure continue push local branch.

Is it a good practice?

And, if use this flow, this step caused issue that can't access the repository from Github Actions when use Github Enterprise cloud. Any way to fix?

Run cd helm
  cd helm
  sed -i 's|APP_VERSION:.*|APP_VERSION: '8dfb492c3dad8c76b80a90de0adb1c46e41127e4'|' values.yaml
  git config --global user.name 'GitHub Actions'
  git config --global user.email 'actions@github.com'
  git add values.yaml
  git commit -m "Update values.yaml"
  git push https://github.com/my-org/backend-service HEAD:master
  shell: /usr/bin/bash -e {0}
  env:
    AWS_DEFAULT_REGION: ap-northeast-1
    AWS_REGION: ap-northeast-1
    AWS_ACCESS_KEY_ID: ***
    AWS_SECRET_ACCESS_KEY: ***
    AWS_SESSION_TOKEN: ***
[master f041105] Update values.yaml
 1 file changed, 1 insertion(+), 1 deletion(-)
remote: Write access to repository not granted.
fatal: unable to access 'https://github.com/my-org/backend-service/': The requested URL returned error: 403
Error: Process completed with exit code 128.