🚀 Download our latest eBook - Adopt Kubernetes in Weeks 🚀
ArgoCD is a Continuous Delivery (CD) tool that has gained popularity in DevOps for performing application delivery onto Kubernetes. It relies on a deployment method known as GitOps. GitOps is a mechanism that can pull the latest code and application configuration from the last known Git commit version and deploy it directly into Kubernetes resources. The wide adoption and popularity are because ArgoCD helps developers manage infrastructure and applications lifecycle in one platform.
To understand ArgoCD in-depth, we must first understand how Continuous Delivery works for most application teams and how it differs from GitOps.Â
Continuous Delivery (CD) is a software delivery process/ framework that enables developers to continuously push their code changes into the production servers without accessing the infrastructure through a push-based pipeline. This process reduces the time a code takes to reach its end users and improves release velocity. It is a repeatable process that enables scaling your application to address the growing demands of end users.
Continuous delivery is a part of the application delivery lifecycle that deploys the application post-build into a resource. In this context, our infrastructure will be Kubernetes without the use of ArgoCD. Alternatively, if we use Jenkins, the process will be as follows.
‍
Before the rise of Kubernetes, CD most applications teams enabled CD with tools like Jenkins and Spinnaker. The architecture of Kubernetes is complex, and these tools could not efficiently deploy into Kubernetes and deploy without errors due to the complexity of Kubernetes architecture. These issues made using tools like Jenkins challenging to work with Kubernetes.Â
‍
Challenges with traditional CD while deploying into Kubernetes:Â
The continuous delivery into Kubenbrtes can be made efficient with Argo CD, which works on the principle of GitOps. Before understanding GitOps, let us understand Push vs. Pull based CI/CD in the upcoming section on GitOps.
Traditional CD and GitOps differ on the core principles of push and pull-based deployments.
Most CI/CD processes work on a push mechanism, which means things move to their respective destination at the trigger of an event. For example, when a developer has finished writing his code, he must execute a set of commands to move his code into the server for deployment. In a Kubernetes environment, the developer has to configure the clusters using tools like Kubectl and Helm in the pipeline to apply changes.
‍
Argo is a CD tool that uses a pull-based mechanism. A pull-based CD mechanism means the destination triggers an event to pull the data from the source(git)Â to deploy at the destination. Argo CD, which resided inside the cluster for reasons explained later on the blog, pulls the most recent verified version of code into the cluster for deployment. There are a lot of benefits to this model, like improved security and ease of use.
‍
This pull-based mechanism is called GitOps, where the source code management systems like Git are treated as the only source of truth for application and configuration data.Â
‍
Argo CD works in a reversed flow mechanism as compared to push-style deployments. The new mechanism enables ArgoCD to run from inside a Kubernetes cluster. Kubernetes faces challenges with the traditional CD mechanism because CI/CD tools, like Jenkins, sit outside the cluster, whereas Argo CD sits inside the cluster. While inside the cluster, Argo CD pulls changes from git and applies them to the residing cluster. Instead of pushing changes like older generation tools by being inside the cluster, ArgoCD prevents sensitive information from being exposed to other tools outside the Kubernetes cluster and environment.Â
‍
Argo CD can be set up in two simple steps.
‍
When Argo CD monitors change, it automatically applies them to the Kubernetes cluster. When developers commit the new code updates to the Git repository, automated CI pipelines will auto-start the build process and build the container image. Then as per the configurations, the CI pipeline will push and update the Kubernetes manifest files. The pipelines will update the new image version name and details on the `deployment.yaml` file. Argo CD can track this new update, pull the image, and deploy it onto the target cluster.
‍
When the Kubernetes cluster is ready, Argo CD sends a report about the status of the application and that the synchronization is complete and correct. ArgoCD also works in the other direction, monitoring changes in the Kubernetes cluster and discarding them if they don’t match the current configuration in Git.
1. Separate git repositories for application source code and apps configuration
2. Separate git repo for system configurations.
‍
The main reason for having separate repositories for application source code and app configurations is because app config code is not only present in the deployment file but also in the configmaps, secrets, storage, svc, etc. Kubernetes uses. These files change independently from the source code.Â
‍
When a Developer or DevOps wants to change a `service.yaml` file, which is an application configuration and not a part of the software code, he has to run the whole CI pipeline to sync those changes into production. The CI pipeline will run only when a code change is updated. Clubbing the app configurations and software code together makes the setup complex and inefficient.Â
‍
So as soon as DevOps changes the config on the git repository, Argo CD will become aware of the changes and update the destination cluster as it constantly monitors the repo as soon as config files change in the Git repository.
‍
If a new code commit is pushed into the git repository and the changes are applied to the cluster with Arog CD auto sync, the cluster fails. DevOps can revert to the previous working state from the list of the last known best repository versions, just like a Windows restore point. Also, one need not process the laborious process of manually riveting every cluster and doing a clean-up, as Argo CD will do that all by itself.
‍
Argo CD is watching the git repository and changes in the cluster. Anytime a change happens in the git repository or the cluster, Argo CD will compare the two states to check for any misconfigurations or differences. If they don't match the desired state defined in the git repo with the actual state of the cluster, Argo CD will become active and quickly sync the cluster as described in the cluster. So, in that case, if someone goes and makes manual changes in the cluster, Argo CD will detect it and sync to the desired state. It overrides the manual changes.
‍
The automatic override helps the system stay stable and guarantees that the git repository is the only source of truth at any point in time. It also provides full transparency of the cluster and lets it become a snowflake cluster.
When a cluster completely crashes, and one has to build it from scratch, Argo CD can be pointed to the git repository, where the complete cluster configuration is defined. It will recreate the same state as the previous one. This is a fully autonomous process where developers and DevOps do not have to worry about disaster recovery post-clean-up processes. This is possible because Argo CD accepts the cluster configuration as code in a declarative way.
Production clusters must have limited access, and only some of your team members should be allowed access. To configure different access rules to these clusters, Argo CD can enable approvals for pull requests for authorized developers and engineers. This helps in managing the cluster permissions. No need to create cluster role and user account on Kubernetes.
Non-human users like CICD tools or other peripheral tools in the DevOps ecosystem outside the cluster can be configured in Argo CD, which resides inside the cluster. This architecture of Argo CD ensures that those credentials remain inside the cluster making the system robust and secure.
Argo CD is a Kubernetes native CD tool that supports and reads various Kubenrtes manifest files such as YAML, Ksonnet, Jsonnet, Helm charts and Kustomize. It can follow updates to branches, tags, or pinned to a specific version of manifests at a Git commit.
‍
 Argo CD control plane consists of three main components:
‍
‍
Accessing the Git repository is always time-consuming for Argo CD; accessing the git Repo every time will constitute a pull request. Hence, this internal Repository Service makes a local cache of the application manifest and Git repositories on the Kubernetes cluster a replica of the git repository. It is responsible for generating and returning Kubenrtees manifests on input data like repository URL, Git revisions( branch, tags), application path, and template-specific settings; the server generates Kubernetes manifests.
Argo CD can detect changes in Git and sync with the repo due to the Application Controller component. This feature enables syncing out-of-date or modified destination configurations to the last approved git version. The application controller syncs between the local cache created by the Repo service and the git repository because it is a less resource-intensive process.  The application controller can also be configured to accept direct changes in code and configuration at the destination without reverting back to the last known configuration on Git. This authority must be granted only to a selected team resource. When this direct change is made it notifies the DevOps and developers about the difference in the configuration to update the Git repositories.
The API server, like a Kubernetes API server, is a service to expose the components of Kubernetes and ArgoCD to interfaces like a CLI or web GUI or other third-party tools. The APIs are primarily used to carry out functionalities like:
Want to start with a simplified GitOps deployment for free but without any hassle? Then try Devtron open-source platform for GitOps.
Do you need any help to setup GitOps deployment along with multi-cluster and multi-cloud visibility and controls with Kubernetes dashboard?
.svg)
.svg)
.svg)