An Introduction to ArgoCD

This blog post is a translation of a Japanese article posted on May 29th, 2020.

Hello, I am Masuyama from the Sreake team.

As an SRE, I primarily manage applications in an EKS environment. Since we use ArgoCD for our operations, I would like to introduce it in this post.

What is ArgoCD?

ArgoCD is a CD tool designed for GitOps-based deployments in Kubernetes environments. It allows you to deploy manifests written in Helm or Kustomize. While Flux is a similar tool, I believe ArgoCD offers the following advantages:

• Since it adheres to GitOps principles, you can verify manifest changes using kubectl diff before deployment, in addition to checking differences via Pull Requests.
• It provides visualization for deployed applications (as well as the deployment process itself).

For this article, I will use an example of an application managed by Helm in an EKS (1.15) environment.

※ GitOps refers to the practice of using a Git repository as the single source of truth for all code involved in infrastructure provisioning and application deployment.

Installation Steps

We will proceed with the installation following the official procedure.

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

Once the Pods are up and running, you can access the interface via port forwarding.

$ kubectl get pod -n argocd
NAME                                                                       READY   STATUS    RESTARTS   AGE
argocd-application-controller-5f649bb745-24rkn   1/1     Running   0          51s
argocd-dex-server-58846d888-z22bv                     1/1     Running   0          51s
argocd-redis-fc585c648-fr4gl                                   1/1     Running   0          51s
argocd-repo-server-75b76ffb57-ddlk9                     1/1     Running   0          51s
argocd-server-75f9b64869-jcl9x                              1/1     Running   0          51s

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

$ kubectl get pod -n argocd -l app.kubernetes.io/name=argocd-server

※ If you wish to reset the admin password, run kubectl edit secret argocd-secret -n argocd and delete both admin.password and admin.passwordMtime. After restarting the argocd-server, the password will revert to the current Pod’s name.

We are now ready to deploy. If you want to try deploying something immediately, I recommend checking this guide.

Next, let’s look at the deployment units.

Deployment Units

ArgoCD manages deployments using the Application CRD (hereinafter referred to as “Application”). By referencing a Helm (or Git) repository within an Application and deploying that Application, you can deploy the manifests contained in the Chart.

# aws-alb-ingress-controller のサンプル
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: aws-alb-ingress-controller
  namespace: argocd
spec:
# どのAppProjectに所属させるかを指定します。
# AppProjectはArgoCDのCRDで、ユーザの権限を制限する場合などに利用出来ます。
# ここでは、最初から存在するdefaultを利用します。
  project: default
# デプロイ先を設定します。
# ここでは、ArgoCDのクラスタを指していますが、別Clusterを指定することも出来ます。
  destination:
    namespace: kube-system
    server: https://kubernetes.default.svc
# Helmリポジトリを指定します。Gitリポジトリも指定可能です。
# Gitリポジトリの指定方法
#   source:
#      repoURL: https://github.com/argoproj/argocd-example-apps.git
#      ブランチ、タグなどが指定可能です
#      targetRevision: HEAD
#      Chartのpathを指定します。
#      path: guestbook
  source:
    chart: aws-alb-ingress-controller
    repoURL: http://storage.googleapis.com/kubernetes-charts-incubator
    targetRevision: 0.1.10
    helm:
      parameters:
      - name: clusterName
        value: hogehoge
      ...

Official sample: https://argoproj.github.io/argo-cd/operator-manual/declarative-setup/

Additionally, when deploying multiple Charts, ArgoCD allows for grouping by managing multiple Applications within a single Application. For instance, you can treat a Namespace as a single Application and define multiple Applications within it.

To achieve this grouping with Helm, you must specify multiple Applications in the Chart of the Helm (or Git) repository referenced by the main Application.

Here is a sample of the Git repository structure.

$ tree
.
├── charts
│   ├── Chart.yaml
│   └── templates
│       ├── applicationA.yaml
│       ├── applicationB.yaml
│       ├── applicationC.yaml
│       └── applicationD.yaml
└── default.yaml

$ cat default.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: default
  namespace: argocd
spec:
  project: default

source:
    repoURL: GitリポジトリのURL
    targetRevision: master
    path: charts

destination:
    server: https://kubernetes.default.svc
    namespace: argocd

syncPolicy:
    automated:
      prune: false
      selfHeal: true

Deployment Methods

ArgoCD allows you to configure a sync policy. This setting determines whether synchronization happens automatically via Git or through manual deployment. When using manual Sync, you can review the Diff as shown below:

Once you confirm there are no issues with the differences, the deployment is executed by selecting SYNC → SYNCHRONIZE.

ArgoCD manages deployment logs, which can be viewed in HISTORY AND ROLLBACK.

If any issues arise during deployment, the ROLLBACK function is available. Simply select the target Revision from the history and click Rollback to initiate the deployment of that specific Revision.

Conclusion

In this post, I introduced ArgoCD. It is a user-friendly and convenient CD tool packed with features like GitOps support, Diff checking, Rollback capabilities, and visualization.

There are several topics I couldn’t cover this time, such as ArgoCD authentication/authorization, Secret encryption, and pipelines using Argo Events. I hope to cover these in a separate article in the future.