What are GitOps and ArgoCD?
The study excerpt on PKOS 4th week study
GitOps is a cutting-edge approach to Continuous Deployment (CD) that enables developers to deploy apps more quickly and often. It is based on the idea that you can compare the planned and actual states of the production environment with a declarative description of those states in a Git repository using an automated process.
The most important part of the GitOps process is done by the tool ArgoCD, which makes sure that the state of the repository and the state of the production environment are always the same. It gives you tools to automatically or manually sync the current state with the state you want it to be in, and it shows you what the difference is.
Instead of giving a list of instructions, declarative tools let you manage settings by describing a desired state. For instance, you might say “there are 10 Redis servers” rather than “create 10 Redis servers and tell me whether it worked or not.” This strategy ensures the intended condition and facilitates system recovery and observation.
Declarative technologies provide version control for configuration files that specify your infrastructure in addition to your code. You can version manage the YAML files used by Kubernetes to specify your deployments, services, daemon sets, etc. To provision Kubernetes on Amazon, you may also utilize Terraform, which uses Git for version control.
In short, GitOps is a set of processes for managing Kubernetes manifest files in Git and deploying them to the cluster as Git-stored manifests — All systems should be declarative, and if you manage them with Git, you have a single source of truth (SSOT), along with the benefits of Git like versioning. The state of the system follows the version in Git — the system is deployed based on the Kubernetes manifest stored in Git, so if you want to deploy an older version of your system, you can use a command like git revert.
Approved changes are automatically applied to the system — Once the declared manifest is registered and maintained in Git, it should be automatically applied to the system whenever a change (such as a code modification) is made, and no credentials should be required for each deployment to the cluster. Users should be alerted when deployments fail — Once the system state has been declared and kept under version control, a system should be in place to alert users if a deployment fails.
Designing a GitOps pipeline is a powerful way to automate the deployment. It is recommended to use at least two Git repositories — an app repo for the source code and the manifest files for deployment, which include monitoring manifests, service manifests, and MQ manifests.
The most well-liked GitOps deployment strategy is the push type. When the Git repository is modified, the structure starts a pipeline. The quantity of deployment environments does not affect it, and adding or altering deployment environments is as easy as adding or updating access information. Due to its simple design, which leads to its popularity, it has the drawback of disclosing security information to the public.
Another deployment strategy is the pull type, which involves a separate operator in the cluster you wish to deploy to. When there is a discrepancy, the operator maintains the cluster based on the manifest of the Git Repo and regularly checks the manifest of the Git repo with the deployment environment. Since the operator is executing in the same environment as the app as opposed to the Push Type, it is possible for it to function without disclosing any security information.
ArgoCD pulls new image versions from the Docker registry and updates the Git repository with the new definition for deployment. However, it does not handle the CI part of the pipeline. A separate tool and process must be used for CI, as ArgoCD is agnostic to how images end up in the registry.
It deploys using the Argo application and Argo project as its two main CRDs (Custom Resource Definitions).
1. Argo Application — Each app represents a single source code repository where your Kubernetes configuration resides for deployment to the cluster. The repo should consist of all resources (helm templates, kustomize or yaml manifest files) intended to be deployed by ArgoCD
2. Argo Project — Groups Argo applications into sub-categories
Your Kubernetes configuration for cluster deployment is stored in a single source code repository called an Argo application. The repository should have every resource (like YAML files or Helm templates) that will be used for ArgoCD deployment. But an Argo project divides up Argo applications by subcategories.
The “Apps of apps” concept is first introduced as an Argo Application CRD by ArgoCD, which contains the settings of all needed tools in the cluster, and is subsequently deployed as well. Three groups of projects were developed and included in the production level: 1) ArgoCD, the default 2) k8s-related toolings like Prometheus and Istio — 3) Other PaaS apps like Airflow or Spark.
ArgoCD’s synchronization feature can be suspended for debugging, troubleshooting, and experimentation. But if it is turned back on before all changes made by hand to ArgoCD resources have been saved and put back into the repository, it will undo those changes. Easy to rollback — Yeah!
