We are switching more and more to Kubernetes to run our applications. This (re)introduces a new issue with the application lifecycle. We have the ability to change resources in a Kubernetes cluster and forget about it. Months later, when we redeploy the original manifest, the application will break. Or when we promote something from Test to Acceptance and we forget that we changed a resource after we deployed it and again we lose time researching why the application breaks.
The scenario above describes a few problems we can have with manual deployments to Kubernetes clusters.
- Mutability: We can change the Kubernetes cluster state without changing the source. This means that we have an issue when someone re-deploys the source files.
- Versioning: We don’t have any versioning of the changes. Something can break and we can’t go back. Manual changes are error prone when promoting through DTAP environments. Also, the traceability part isn’t guaranteed.
- Process: The process to manage a cluster becomes more complex
Many of the issues can be solved by switching to GitOps. According to Weaveworks, GitOps contains of four principles:
- The entire system described declaratively
- The canonical desired system state versioned in Git
- Approved changes that can be automatically applied to the system
- Software agents to ensure correctness and alert on divergence
Kubernetes is configured declaratively by defining the desired state in manifests and deploying them to a cluster. This can be saved into Git and we have our GitOps repository.
Automatically deployments and monitoring on divergence is harder to reach. We can build our own scripts to do this but there are existing tools which can handle this for us. One of these tools is Argo CD.
Argo CD describes itself as follows:
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Argo CD documentation
Argo CD offers the ability to compare and synchronize Kubernetes with GitOps and Helm repositories. It does this based on configuration which is called an Application. An Application in the Argo CD context is the configuration between a GitOps repository and a Kubernetes cluster.
The image below shows an Argo CD Application:
We can create this application using the web UI.
The advantage of the web UI is that there is almost no learning curve.
If the GitOps repository requires authentication you need to configure this first.
This can be done by following the steps below:
- Open the web UI
- Go to the gear icon in the menu bar
- Open the repositories configuration
- Click on the “Connect repo using SSH/HTTPS” button
- Fill in the form with your git configuration and press the connect button.
After this we can create the Application:
- Open the UI
- Press the New App button
- Fill in the form
- Synchronize your first Application
Argo CD now starts monitoring the state of the cluster and detects differences. Syncing the Application will deploy these differences. We also have the ability to enable auto syncing. This is a great option for development environments, and even production environments if the of the GitOps process allows it.
We can do the same steps with the Argo CD CLI.
The installation manual can be found in the Argo CD documentation.
argocd login argocd.example.com #1 Login to Argo CD with username/password argocd repo add https://git.example.com/repos/repo --username git --password secret #2 Add GitOps repository argocd app create example --repo https://git.example.com/repos/repo --path . --dest-namespace default --dest-server https://kubernetes.default.svc --directory-recurse #3 Add the application
The declarative API lets us deploy an manifest in the Kubernetes cluster to configure an Application.
The example we used above consists of changes in three manifests:
- A Secret to define the username and password of the GitOps repository
- A ConfigMap to define the GitOps repository and reference the secret
- A Custom Resource defining the Application
The secret should contain the username and password for the GitOps repository. See the example below.
We can just apply this secret in the same namespace as Argo CD.
The second step is a patch of the Argo CD ConfigMap.
– url: https://git.example.com/repos/repo
We should patch this, there is already data in this ConfigMap which should be retained. So overwriting the ConfigMap isn’t an option.
The last step is to apply a new Application.
We have seen three ways to setup a first application in Argo CD. We can now add Kubernetes manifests into the GitOps repository and start deploying to a cluster.
We can now deploy our complete landscape with Argo CD on Kubernetes. Manual actions on the cluster shouldn’t be necessary anymore and we have a nice audit trail in our GitOps repository.
It works also with other GitOps tools like Sealed Secrets which allows us to store secrets securely within our GitOps repository.