We recently added Argo CD as a new feature to our Nine Managed GKE. In this post, we explain how we arrived at this decision, what its advantages are and how it is used.
When we designed the development workflow for our Nine Managed GKE product at the beginning of this year, some of the goals we wanted to achieve were:
- Good knowledge sharing in the team
- Automated testing of features
- Automated release of new features
- Have a history of which changes have been made
We had a look around and found that other people successfully used something which is called GitOps. With GitOps, you use git (as the name implies) as the source of truth for declarative infrastructure and applications code. No matter which infrastructure or application should be deployed or configured, the source for it is stored in git.
To apply the current state of what is configured to real-world objects outside of git (like Kubernetes clusters, VMs, etc.), pipelines are added. With pipelines, you are able to execute tasks on specific git events (like new commits in a branch, the creation of tags, or merging into an existing branch). In combination with other features, like for example merge requests (aka pull requests as they are called at GitHub), git turns into your central action operation center.
We started to adapt our workflows, integrated new tools, and built pipelines to automate whatever had to be automated.
Today we can say that we have reached our goals. 💪
The Impact of GitOPs & How You Get to Your Argo CD Cluster
|Knowledge sharing||every change must be approved by another member of the team, which leads to know-how transfer|
|Automated testing of features||code gets tested in gitlab pipelines when committed|
|Automated release of new features||pipelines automatically rollout new software versions or configurations|
|Changes history||git versioning can tell what happened|
As we are really happy with our workflows and the resulting productivity, we want to encourage our customers to use GitOps as well when deploying to their Kubernetes clusters. One tool which supports this is Argo CD, by a company called Intuit, which we deploy in every "nine managed GKE" cluster by default. You will find the URL to your Argo CD cluster installation on runway.
Never miss an update from our engineers
Argo CD - A Powerful Tool
We have found that most of our customers are used to the classic development, staging and production environments of an application. Creating them in Kubernetes can be quite easy. Just create a namespace with the necessary deployment resources and add whatever is needed to configure your application for the specific environment (config maps, secrets, ingress, etc.) The big drawback of this approach will be configuration drift over time. Your development namespace will have all the new and cool features of the most current development version of the application, but you will need to manually move over all of the changes to the other environments. One possibility to improve the situation is to use some kind of configuration/template system (like helm charts, kustomize, jsonnet, etc.) to define the Kubernetes resources of your application. When using helm charts, you can make use of versioning and deploy different versions to your environments. However, it is still hard to keep track of which versions are deployed in which environment.
We think it is best to have all of the configuration for your environments in git. You can then create merge requests for changes in your environments, which helps to keep configuration in sync. To automatically apply all of the configuration from your git repository to your Kubernetes cluster you can make use of Argo CD.
Argo CD is a tool which will read your environment configuration (written either as a helm chart, kustomize files, jsonnet or plain yaml files) from your git repository and apply it to your Kubernetes namespaces.
Some of the features of Argo CD are:
- declarative and version controlled application deployments
- automation and traceability via GitOps workflow
- support for helm, kustomize and jsonnet application declarations
- a web UI for visualizing Kubernetes resources
- a command line interface application
- a Grafana metrics dashboard
- parameter overrides of helm/ksonnet declarations (simplifies development deployments)
- audit trails for application events and API calls
Separation of Config and Code
Argo CD provides an Application CRD which maps the configuration code of a given git repository to a Kubernetes namespace. Be aware that Argo CD does not connect to your application code repository. Argo CD explicitly recommends these best practices to have separate application code and configuration code repositories. When you are building a new application code version which you want to deploy to an environment, you can either:
- create a merge request in the configuration repository to use the new application version
- automate the update via a pipeline in the application code repository
This also allows for a separation of responsibility between the people responsible for application code and those responsible for managing running application versions. The separation of code and configuration is also one building block of Twelve-Factor apps.
Choose Your Configuration Type
Once you have created the configuration git repository, it is time to choose the type of language/system you want your configuration to be written in. As already mentioned Argo CD supports helm charts, kustomize files, jsonnet declarations, or plain yaml files. As we at nine make heavy use of helm charts, we also recommend expressing your configuration as a helm chart. Using helm charts also allows you to use parameter overrides or sub-charts later on. Don't be scared: Argo CD does not need a running tiller instance. It renders the chart with helm and applies the resources directly to Kubernetes.
The App of Apps Pattern
To depict different environments for your application, you will need to create an Argo CD Application per environment. Those Argo CD applications might be connected to different branches of your configuration repository (development, staging, etc). To initially create those resources, Argo CD provides a Web UI and a CLI application for you to do that, but there is a better way: the Apps of App pattern. As Argo CD applications can be written declaratively, it is possible to have all of them in one helm chart which then gets deployed via one 'root' Argo CD application. That way you can easily add or remove applications via GitOps.
Automation Via Pipelines
Whatever your development workflow looks like, there will be a time when a new application version needs to be deployed. Updating the running version with Argo CD is easy. You just need to change the version of the container image in the configuration repository. Argo CD will pick up the change and rollout the new version. Committing to the configuration repository can be done in a running pipeline of the application code repository. Remember that this pipeline and the necessary events leading to running it are highly customisable.
Here are some examples:
- a deploy to production happens once a new version tag has been created in the application repository
- a deploy to the staging environment happens whenever new code has been merged into the 'staging' branch of the application repository
- you create one new environment per feature branch in your application repository
- once a new production container image is ready, a merge/pull request is created in the configuration git repository
Whichever workflow you like, all you need is the necessary pipeline connecting events in your application code repository with actions leading to a change in the configuration repository.
Argo CD helps with adopting GitOps techniques for faster and more secure deployments. It provides a nice UI for tracking the current active Kubernetes resources and events. If you want to start using it on nine managed GKE, you can find all the links on runway.
Interested in our Managed Google Kubernetes (GKE)?