GitOps practices are becoming especially relevant in 2021, boosted by the increasing use of Kubernetes in all types of organisations, a step forward from Infrastructure as Code (IaC). The configurations that are necessary to bring an application to a container environment are growing day by day, and if we take into account the number of working environments that are usually in place, this amount is becoming difficult to manage. And let’s not talk about having to do a rollback because of an unsuccessful configuration. But what if I tell you that applying GitOps solves this problem and that going back to a previous version can be as easy as a “Control + Z”?
One of the main advantages of GitOps is what is known as the source of truth, a repository where the current version of the configuration of the elements we must have deployed is located. By having to apply every change to this source of truth, we can keep track of all versions and easily restore a previous version and have a record of it.
Implementing GitOps on Kubernetes
One of the most widely used tools for implementing GitOps on Kubernetes is ArgoCD. This is because ArgoCD is a very simple tool, with a single purpose, which makes it great. Its function is to keep the configuration in the Kubernetes cluster marked in a Git repository. With every change we make to that Git repository, Argo will detect the modification and take care of the necessary commands to get to the new state in the Kubernetes cluster. This is very relevant, because unlike other tools, ArgoCD works in a declarative way. This means, for example, that if I declare in a file (hosted in Git) that I want 3 replicas of this application and that it can be accessed externally with a URL X, ArgoCD will make sure that this configuration is the one that exists in the cluster. The use of declarative language instead of imperative makes the adoption of these technologies much easier, since for each change we do not have to tell Kubernetes which commands to execute, but rather the target snapshot, ArgoCD takes care of executing the necessary commands to be able to get to the target snapshot.
Once ArgoCD has implemented that statement, it monitors manual changes on the platform, and in case they occur, it has two behaviours. The first, and more common for the uninitiated in GitOps, warns that someone or something has modified the state of the cluster. The second is more imposing, as it detects this modification and starts executing commands to return to the previous state of the cluster, which appears in Git as the current state.
The learning curve of ArgoCD is low for those who are already used to working with Kubernetes, but the hardest part as always is the change management to get the operations in the cluster always done through this tool and start working on GitOps.
ArgoCD is a CNCF project and is available with support within OpenShift. This means that Telefónica’s Cloud Garden users also have this support.