DevOps is pivotal to organizations’ digital transformation strategy today, which they use to encourage transparency, accountability, and faster processes at work. GitOps is the next wave of revolution in DevOps that expedites processes and adds tremendous efficiency to work. It is a continuous deployment model, used to build cloud-native applications and automate the deployment of hundreds of applications into Kubernetes in a day. You can read four strategies for application deployment in a Kubernetes environment here.
Besides, GitOps Argo CD helps developers deliver continuously on the Kubernetes cluster and monitor applications to ensure continuous delivery and effective IT operations. Let us understand this better.
Everyone who has successfully worked on infrastructure as code (IAC) is a true creator of the concept of GitOps. One of the objectives of implementing GitOps is to integrate an end-to-end test suite. If you have migrated all deployments into the Kubernetes cluster and redesigned the delivery workflows, you would know that a regular approach is inefficient. Argo CD GitOps, as a tool, keeps all configurations in sync and applies the desired state directly (and only from Git). These are the primary features of GitOps-
One of the ways to set up GitOps principles is to use Argo CD as a part of the Argo project. Argo CD is a Kubernetes-native declarative continuous delivery tool that follows the GitOps methodology and accelerates application deployment and lifecycle management without any compliance or security issues.
Argo CD has many benefits, for instance, it provides an extensive command-line interface (CLI) to integrate Argo CD with any continuous integration system. It can also be integrated with templating tools— Helm, ksonnet and Kustomize, other than yml files—to define the desired state of an application. It allows manual as well as automated syncing of applications to their desired state. Here are some of the features of Argo CD:
Argo CD has been implemented as a Kubernetes controller, which continuously monitors the running applications and compares the current (live) state with the specified state in a Git repository (called desired target state).
A deployed application whose current state deviates from the target state is considered out of sync. Argo CD reports and visualizes the differences while providing facilities to sync the current state back automatically or manually to the desired target state. Any changes made to the desired target state in a Git repository can be applied automatically and reflected in specific target environments.
Just like Kubernetes, Argo CD has its own control plane, including an API server, a repository server, and a controller. These three components are important components in Argo CD.
Argo CD repository server caches the Git repository associated with each application deployed in the Kubernetes cluster. It generates Kubernetes manifest that are deployed in the cluster from a Git source code, applying configuration management tools and plugins when necessary.
Argo CD API server allows interacting Argo CD from the web UI and CLI. Besides, Argo CD’s Application controller is responsible for monitoring the applications that are deployed in the cluster.
Argo CD provides an Application CRD (custom resource definition) that maps the configuration code of a given Git repository to a Kubernetes namespace. Argo CD does not connect to an application code repository. When building a new application code version that you want to deploy to an environment, you can either:
This will help in separating the developer (to manage the App code) and DevOps (to manage the running application).
Once you have created the configuration in a Git repository, it is time to choose the type of language you want your configuration to be written in. As mentioned above, Argo CD supports helm charts, kustomize files, jsonnet declarations or plain yaml files.
Using helm charts allows you to use parameter overrides or sub-charts later. Argo CD does not need a running tiller instance. It renders the chart with helm and applies the resources directly to Kubernetes.
Step 1: If you want CICD pipelines for your applications using ArgoCD, you need to integrate the Jenkins CI tool with ArgoCD.
Step 2: You can separate the application repository from the manifest repository, as mentioned above.
Step 3: Changes to the master application repository will trigger your pipeline and build a docker image.
Step 4: Once a docker image is created, Jenkins pushes it to a Docker registry and commits the respective docker image tags into a GitOps repository.
Step 5: The automated commit will update the docker image version in the manifest repository and notify the ArgoCD about the changed sets.
Step 6: Argo CD automatically detects this change and triggers the sync to change the state of resources as per the Git repository.
Step 7: Sync action is triggered through a webhook action from Jenkins CI after commit or after a regular polling interval.
Step 8: Argo CD runs as a controller on the Kubernetes cluster, which continuously monitors running applications and compares the current state with the desired target state (as specified in the GitOps repository).
Step 9: The controller detects an out-of-sync application state, which is done by diff-in Helm manifest template outputs and optionally takes corrective action.
While there are few more tools available in the market as Argo CD, it is recommended to use Argo CD to deliver and monitor applications continuously on the Kubernetes cluster. Argo CD helps in faster and secure deployments while providing effective web UI to monitor applications.