ArgoCD : With great power comes great complexity.

9 min readSep 10, 2023

In the ever-evolving landscape of container orchestration and cloud-native technologies, Kubernetes has emerged as the de facto standard for managing containerized applications. Its ability to automate deployment, scaling, and management of containerized workloads has revolutionized the way we build and run applications.

But with great power comes great complexity. As organizations adopt Kubernetes for their infrastructure needs, they face new challenges: How do you effectively manage the deployment of applications in a Kubernetes environment? How do you track and control the changes made to your applications?

Enter ArgoCD, a powerful and indispensable tool in the world of Kubernetes. ArgoCD is an open-source GitOps continuous delivery tool that streamlines the deployment of applications to Kubernetes clusters. In this blog post, we will delve into the essence of ArgoCD, exploring what it is, why it’s pivotal in modern Kubernetes operations, and how it seamlessly integrates into the Kubernetes ecosystem.

What is ArgoCD?

At its core, Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. It leverages the principles of GitOps, a methodology that uses Git repositories as the single source of truth for defining and managing the desired state of applications. One of my favorite features is that there’s no need for constant “helm upgrade.” Even in the event of a server failure, you have all your Helm charts safely stored in Git. This means you can quickly redeploy them on a new server without any hassle.

Declarative Configuration: With ArgoCD, you tell it exactly how you want your application to deploy, and it makes sure it stays that way. Imagine you have a website, and you want to specify that it should always have a blue background. You tell ArgoCD that the background should be blue, and ArgoCD keeps checking to ensure it remains blue. If someone accidentally changes it to red, ArgoCD changes it back to blue automatically.

Automated Synchronization: ArgoCD keeps an eye on your application settings (helm charts, etc) stored in a special place (GIT) and makes sure your actual application matches those settings.

Rollback and Versioning: ArgoCD helps you “undo” changes to your application when something goes wrong, just like pressing “Ctrl+Z” to undo a mistake in a document. Suppose you make changes to your website, but it breaks and looks terrible. ArgoCD allows you to go back in time to when your website looked good and worked well, so your users don’t notice any issues. You have the flexibility to either update the image tag in Helm, and Argo will revert to the previous state automatically, or you can utilize the UI to initiate a rollback to a specific revision of your application.

Multi-Cluster Management: For organizations with complex environments, ArgoCD provides the ability to manage applications across multiple Kubernetes clusters, ensuring consistency and centralization of configuration management.

Prerequisite:

Git repo
Kubernetes cluster
Helm charts
Kubectl tool configured (default location is ~/.kube/config)

Installation:

Installing ArgoCD is straightforward, you can set it up by applying a YAML file within your Kubernetes cluster.

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

This will create a new namespace, argocd, where Argo CD services and application resources will live. You can check resources with kubectl.

kubectl get all -n argocd

By default, the Argo CD API server is not exposed with an external IP. To access the API server you use port forward method. Kubectl port-forwarding can also be used to connect to the API server without exposing the service.

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

You can access the ArgoCD API server at https://localhost:8080. However, in a production environment, I recommend setting up an internal load balancer with an ingress for the ArgoCD server. This configuration allows you to access the Argo dashboard even when its service type is set to ClusterIP.

Feel free to refer to the following ingress.yaml as a template:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argocd-ingress
  namespace: argocd
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-1:1234567890:certificate/abcd-efghi-ejk # replace with your certificate ARN
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    alb.ingress.kubernetes.io/ssl-redirect: '443'
    alb.ingress.kubernetes.io/group.name: production
    alb.ingress.kubernetes.io/scheme: internal
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=argo-access-logs,access_logs.s3.prefix=argo-access-logs # replace
spec:
  rules:
    - host: "argocd.your-domain.com" # replace
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: argocd-server
                port: 
                  number: 80

Upon applying this configuration, it will create an internal load balancer within your AWS region. This assumes that you have the Load Balancer Controller installed in your EKS cluster. After setup, you can direct your domain to point to this load balancer.

Following the deployment, if you encounter the ‘Too Many Redirects’ error while trying to access the ArgoCD dashboard in your web browser, you can resolve this issue by making a simple modification to the ArgoCD ConfigMap. Add the following YAML configuration block to the ConfigMap.

kubect edit cm argocd-cmd-params-cm -n argocd

data:
  server.insecure: "true"

apiVersion: v1
data:
  server.insecure: "true"
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"ConfigMap","metadata":{"annotations":{},"labels":{"app.kubernetes.io/name":"argocd-cmd-params-cm","app.kubernetes.io/part-of":"argocd"},"name":"argocd-cmd-params-cm","namespace":"argocd"}}
  creationTimestamp: "2023-08-08T09:57:26Z"
  labels:
    app.kubernetes.io/name: argocd-cmd-params-cm
    app.kubernetes.io/part-of: argocd
  name: argocd-cmd-params-cm
  namespace: argocd
  resourceVersion: "3627768"
  uid: 1104f150-cd0b-4793-b088-deb2ed6dcdb8

This configuration change allows for a secure connection to the ArgoCD dashboard and should eliminate the issue of excessive redirects.

Great! Now you can access ArgoCD dashboard with your domain.

Oops! A password is required, but you won’t find it by using ‘kubectl get pods’ since it provides the pod name, not the password. In many cases, applications store their passwords in a Kubernetes Secret. These secret values are typically base64-encoded. However, it’s essential to note that updating the secret doesn’t automatically change the application password. To retrieve the initial admin password, you can use the following command. Username is admin.

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Great! you can login now.

You have the option to manage ArgoCD using either the user interface (UI) or the command-line interface (CLI). Currently, I’m using the UI, as both methods provide the same functionality. However, if you prefer to use the CLI, you can install the ArgoCD CLI tool. Installing it on a Mac is straightforward,

brew install argocd

but on a Linux machine, you can obtain the binary and set it up.

curl -LO https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
chmod +x argocd-linux-amd64
sudo mv argocd-linux-amd64 /usr/local/bin/argocd

To login using CLI you can use argocd command

argocd login argocd.your-domain.com --grpc-web

You will be prompted to enter the username and password for the admin. You can use the same password that was used to log in to the dashboard earlier.

Lets learn some of the core concepts in argo

Application source type: Which Tool is used to build the application.
Eg: Helm, Kustomize, etc.
Application: It is basically what actually deploys the application. We create applications to get stuff deployed.
Target state: The desired state of an application, as represented by files in a Git repository.
Live state: The live state of that application. What pods etc are deployed.
Sync status: Whether or not the live state matches the target state. Is the deployed application the same as Git says it should be?
Sync: The process of making an application move to its target state. E.g. by applying changes to a Kubernetes cluster.
Sync operation status: Whether or not a sync succeeded.
Refresh: Compare the latest code in Git with the live state. Figure out what is different.
Health: The health of the application, is it running correctly? Can it serve requests?

After accessing you should first configure cluster in argocd.

Its simple just go to settings → Clusters → add cluster. We are using the same cluster in which argo is installed so add “https://kubernetes.default.svc”

Next, let’s create a project within ArgoCD. Think of it as creating a dedicated folder to organize all your applications neatly. To do this, navigate to the Settings → Projects → and then click on “New Project.” Here, you can provide a name for your project, add a description if you like, and then simply click on “Create.” For example, you can name your project “Stage”.

Next, you’ll want to establish a connection between your repository and ArgoCD. This connection allows ArgoCD to continuously monitor your repository and keep your applications in sync with the defined configurations. Go to settings → Repositories → connect repo.

You have the option to connect your repository using various protocols, such as HTTPS or SSH. If you choose SSH, you’ll need to include your private key. For HTTPS, you can utilize a username and password for authentication. To complete the setup, provide a name for the project, specify the Git repository URL, select the project you’ve created, and then create the connection. I’m creating a test application using HTTPS. Since this is a public repository, there’s no need for a username and password for authentication.

Now finally create application. Click on New app on home page.
Give your app the name guestbook, use the project test, and leave the sync policy as Manual

Connect the https://github.com/argoproj/argocd-example-apps.git repo to Argo CD by setting repository url to the github repo url, leave revision as HEAD(You can also set branch here)and set the path to guestbook.For Destination, set cluster URL to https://kubernetes.default.svc (or in-cluster for cluster name) and namespace to app.

After filling out the information above, click Create at the top of the UI to create the guestbook application

Now that our application is prepared for deployment, click on the app to review the resources it will generate.

Click on sync and application will be deployed.

You can also create application with the help of argocd cli (if configured).

argocd app create guestbook \
  --repo https://github.com/argoproj/argocd-example-apps.git \
  --path guestbook \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace app \
  --project test \
  --sync-policy none \
  --revision HEAD \
  --values values.yaml

The application has been successfully deployed. You can also verify this using the kubectl tool. With that, our deployment process is complete!

kubectl get all -n app

I believe you now understand why Argo is considered the best choice for GitOps.

You can also check for my friend blog here for detailed instructions for using argo with CLI with practical demonstration.

I am open to further discussions on automation & DevOps. You can follow me on LinkedIn and Medium, I talk about DevOps, Learnings & Leadership.

ArgoCD : With great power comes great complexity.

Written by Abhishek Yadav