This page looks best with JavaScript enabled

DevOps Toolchain: Argo CD

1. What Problem Argo CD Solves

1.1 Starting from GitOps

GitOps originated from a blog post published by Weaveworks in 2017: GitOps - Operations by Pull Request. In it, Alexis introduced a deployment approach that treats Git as the single source of truth.

In GitOps practice, we need to define software infrastructure in a Git repository for management. That software infrastructure includes infrastructure such as IaaS and Kubernetes, as well as the applications themselves. Anyone can modify the software infrastructure by submitting a Pull Request, and that modification is then applied by an automated program.

This approach lets everyone focus on developing new features instead of getting bogged down in tedious operational work such as installation, changes, and migration. At the same time, the whole process has a complete operational record and permission approval management.

1.2 Argo CD Can Put GitOps into Practice

Argo CD is a GitOps continuous deployment tool built on Kubernetes as its infrastructure. Below is the architecture diagram from the Argo CD community:

  1. Argo CD pulls the application’s configuration from a Git Repo and deploys it into a Kubernetes cluster.
  2. When someone adds a feature, they submit a Pull Request to the Git Repo to modify the application’s deployment configuration and wait for it to be merged.
  3. After the Pull Request is merged, a Webhook triggers Argo CD to perform the update.
  4. The application is updated and a notification is sent.

It is easy to understand: automate the operations process and deploy continuously.

1.3 Powerful and Easily Extensible Argo CD

For ordinary Kubernetes operations scenarios, the functionality described above is sufficient. But for complex scenarios involving multiple clouds, multiple platforms, and multiple middleware components, more needs to be considered.

In Argo CD’s processing logic, four components are defined:

  • Event Source, which connects to various event messages
  • Sensor, which converts messages into triggered actions
  • Eventbus, a message subscription and routing system
  • Trigger, which triggers actual external actions

For operations staff, the main things to understand are two points:

  • What events can Argo CD handle? AMQP, AWS SNS, AWS SQS, Cron Schedules, GCP PubSub, GitHub, GitLab, HDFS, File Based Events, Kafka, Minio, NATS, MQTT, K8s Resources, Slack, NetApp StorageGrid, Webhooks, Stripe, NSQ, Emitter, Redis, Azure Events Hub

  • What actions can Argo CD handle and execute? Argo Workflows, Standard K8s Objects, HTTP Requests, AWS Lambda, NATS Messages, Kafka Messages, Slack Notifications, Argo Rollouts CR, Custom / Build Your Own Triggers, Apache OpenWhisk

2. Deploying Argo CD on Kubernetes

  • Create a namespace and deploy Argo CD

Here we choose the latest version released at the time: 1.8.3

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

The Argo CD community also provides an HA deployment mode; kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.8.3/manifests/ha/install.yaml is used for production environments.

  • Change the service to type NodePort for easier access
1
kubectl patch svc argocd-server -p '{"spec": {"type": "NodePort"}}' -n argocd
  • Check the services
1
2
3
4
5
6
7
8
9
kubectl -n argocd get svc

NAME                    TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
argocd-dex-server       ClusterIP   10.233.34.191   <none>        5556/TCP,5557/TCP,5558/TCP   5m37s
argocd-metrics          ClusterIP   10.233.54.3     <none>        8082/TCP                     5m36s
argocd-redis            ClusterIP   10.233.18.86    <none>        6379/TCP                     5m36s
argocd-repo-server      ClusterIP   10.233.3.171    <none>        8081/TCP,8084/TCP            5m36s
argocd-server           NodePort    10.233.61.3     <none>        80:31808/TCP,443:30992/TCP   5m36s
argocd-server-metrics   ClusterIP   10.233.36.228   <none>        8083/TCP                     5m36s
  • Check the admin account password
1
2
3
kubectl get pod -n argocd |grep argocd-server

argocd-server-7d597d9bcd-6nzct        1/1     Running   0          22m

Here the admin password is the Pod’s name: argocd-server-7d597d9bcd-6nzct .

  • Log in to the Argo CD UI page by opening http://{HOST_IP}:31808

Log in with the account admin and the password argocd-server-7d597d9bcd-6nzct.

3. Installing the CLI Tool

  • Download the CLI command-line tool

Here we install it on Linux as an example:

1
2
curl -sSL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/download/v1.8.3/argocd-linux-amd64
chmod +x /usr/local/bin/argocd
  • Log in to the Argo CD deployed on the Kubernetes cluster

Replace HOST_IP with the host’s IP address and use the CLI to log in to the cluster.

1
2
3
4
argocd login {HOST_IP}:31808 --username admin --password argocd-server-7d597d9bcd-6nzct

'admin' logged in successfully
Context '{HOST_IP}:31808' updated
  • Update the admin password for easier login next time
1
2
3
4
argocd account update-password --account admin --current-password argocd-server-7d597d9bcd-6nzct --new-password password

Password updated
Context '{HOST_IP}:31808' updated

This changes the admin password to password.

4. Creating an Application with the CLI

  • Create an application

You can create an application through the UI, but to let you quickly try Argo CD by copy and paste, here we create it with the CLI tool.

1
argocd app create guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path guestbook --dest-server https://kubernetes.default.svc --dest-namespace default

Parameter description:

- repo, specifies the Git repository
- path, specifies the relative path of the deployment files in the Git repository
- dest-server, the cluster's access address
- dest-namespace, which namespace to deploy to

Under the https://github.com/argoproj/argocd-example-apps/tree/master/guestbook directory there is a yaml declaration of one deployment and one service.

  • View the created service in the page

Wait a while and view the details; you can see the application’s topology diagram.

  • View the created service with kubectl
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
kubectl get all -n default
NAME                                READY   STATUS    RESTARTS   AGE
pod/guestbook-ui-65b878495d-wjmxh   1/1     Running   0          60s

NAME                   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/guestbook-ui   ClusterIP   10.233.55.230   <none>        80/TCP    61s
service/kubernetes     ClusterIP   10.233.0.1      <none>        443/TCP   12d

NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/guestbook-ui   1/1     1            1           60s

NAME                                      DESIRED   CURRENT   READY   AGE
replicaset.apps/guestbook-ui-65b878495d   1         1         1       60s
  • Delete the application and clean up the environment
1
argocd app delete guestbook

Not only is the application deleted from Argo CD’s records, the related workloads are also deleted in Kubernetes.

5. Summary

This article mainly introduced Argo CD’s very basic functionality and demonstrated it by creating an application.

In fact, Argo CD’s capabilities go far beyond this. For example, after modifying the Git Repo, the changes can be synced to Kubernetes for an update; after modifying the image, an update is triggered automatically. As can be seen from the architecture diagram above, Event Source and Trigger can satisfy many automated deployment needs.

On the other hand, when updating Kubernetes, Argo CD also supports Kustomize, Helm, Ksonnet, Yaml, Json, and custom extended resource description methods, which is very convenient to use.

6. References


微信公众号
WRITTEN BY
微信公众号