DevOps Introduction to GitOps in a containerized context with the ArgoCD tool
During a Meetup® Event organized by our Comet', one of our consultants wanted to share his expertise on DevOps and more specifically on the GitOps approach with ArgoCD.
The DevOps approach has several objectives: to respond to a lack of productivity in the world of software development and to improve communication between teams. To optimize and complement DevOps, tools and methodologies have been created such as GitOps.
GitOps in a nutshell?
First, let's learn about Git. It is at the same time:
- a code manager that is a single source of truth that everyone interacts with.
- a directory with a history of changes.
- a branch-mechanic system that allows parallel evolutions and modifications while limiting the risk of damage.
Then there is GitOps, a methodology linked to IaC (1) (Infrastructure as Code), which defines a set of practices and rules for managing an infrastructure based on the usage of Git. Infrastructure as Code is a way to create your infrastructure declaratively. Indeed, the IaC allows you to declare the resources with a standard format that you want (JSON or YAML) so that the tool does what is necessary to instantiate the resources.
The key point is that Git is used as the sole source of truth for defining the infrastructure. The deployment is only done in "pull" mode (recovery from Git).
To summarize, GitOps stems from the evolution of methods and tools (containerization, cloud environments, etc.) linked to IaC, taking advantage of Git's capabilities (variabilization, history, etc.).
The advantages of the GitOps approach
The GitOps approach allows a simplified multi-environment management via the tree structure of the Git directory or branches. Branches represent an alternative to the code base.
Secondly, GitOps makes it possible to gain visibility and simplify knowledge sharing thanks to the unique Git directory which centralizes information.
Finally, we can use GIT for backup, history and rollback management.
However, not all projects are compatible with this approach, especially projects with a strong history (old methodology, large or monolithic application). It is difficult to separate components when everything is mixed up and complicated to make an Infrastructure as Code with the old methodologies.
GitOps in a containerized context: reminder about containers and kubernetes
- Docker (containerization tool) is a way to create applications in an isolated, minimalistic and turnkey context. From a pre-programmed template that we will call image (containing dependencies, configuration files, etc.), it will be possible to create unlimited containers according to need.
- Kubernetes is an overlay that offers a set of resources that can be defined in Yaml files. Kubernetes is declarative: it embeds the configuration describing the desired state for docker images and does what is necessary to achieve that state (check if Docker is capitalized).
In addition, Kubernetes provides certain elements, two of which are worth to name in this introduction:
- the "deployment" which are files defining the images that must be instantiated as well as the basic configurations (replication, variables, ...),
- namespaces which are virtual clusters to isolate resources.
Kubernetes installed: it is possible to use ArgoCD
It is possible to do GitOps in other contexts (Virtualization via VMs, service infrastructure on public clouds, etc.) but we will be particularly interested in GitOps in a containerized context.
The objective of ArgoCD: to perform continuous deployment (CD) in the specific case of containers and kubernetes. The CD corresponds to continuous deployment, i.e. once the test phase is completed, the application will be deployed on the production server.
The use of ArgoCD allows you to benefit from a multitude of advantages:
- An automatic synchronization of resources to do CD on kubernetes.
- Reporting of any deviations from the Git directory.
- Consumption of resources via native Kubernetes, customize or Helm..
- Centralization of projects in one place.
- Have an API (application programming interface) in the form of a CLI and REST
- Allows you to overlay rights management on the kube cluster(s).
- HMI (home machine interface) with a view by application and not by type of K8s component (unlike the kubectl command which can be a bit of a deterrent for a beginner).
In conclusion, the GitOps approach is not revolutionary, but with the arrival of infrastructure tools (cloud or containerized like ArgoCD), the latter will have to develop and become more democratic. Remy, DevOps Expert at Extia.