To begin with, let’s review what ArgoCD is for and how far ArgoCD’s functionalities go. Then, we will see a typical use case of application deployment using ArgoCD and the advantages of its implementation. Finally, we will comment on the conclusions we have drawn in terms of pros and cons, and we will analyze what other tools complement ArgoCD to further optimize the process of integration and continuous deployment of applications.<\/p>\n
What is ArgoCD?<\/h2>\n
ArgoCD is a tool that allows us adopt GitOps<\/a> methodologies for continuous deployment of applications in Kubernetes clusters.<\/p>\n The main feature is that ArgoCD synchronizes the state of the deployed applications with their respective manifests declared in git. This allows developers to deploy new versions of the application by simply modifying the git content, either with commits to development branches or by modifying main branch. Its user-friendly user interface allows us to visualize very well the content, structure and state of the clusters as well as manipulate resources.<\/p>\n Can ArgoCD automate the entire CI\/CD process of an application?<\/p>\n No, ArgoCD takes care of deploying the application once the artifact already exists in a container registry, such as Dockerhub or ECR. This implies that previously the application code has already been tested and containerised in an image. At the end of this article we will talk about what options currently exist to accomplish this previous task in an automated gitops way.<\/p>\n As we have already explained, ArgoCD synchronizes the state of deployed applications with their respective manifests declared in git. But it does not refer to the git repository of the application code itself, but to a separate repository, as best practices suggest, that contains the application’s kubernetes infrastructure code, which can be in the form of helm charts, kustomize application, ksonnet…<\/a><\/p>\n To better explain the main benefits offered by ArgoCD let’s see an use case example.<\/p>\n In this example we will see how ArgoCD can deploy either applications developed by third parties, which have their own helm chart maintained by another organization, or one of our own where we have defined the chart ourselves.<\/p>\n For the example we will deploy a monitoring stack consisting of Prometheus, Grafana and Thanos using their helm charts.<\/p>\n ArgoCD deploys the applications through a custom object called Application<\/a>. This object has as attributes a source and a destination. The source can read several formats, in this exaple our application object will read and deploy helm charts from a chart repository, and charts from a git repository. The destination is the cluster to which the content of the source will be deployed. In the application configuration we can enable that ArgoCD automatically keeps the state of the deployed kubernetes objects synchronized with the configuration indicated in the source (charts\/git). This option is very interesting because it ensures that ArgoCD is going to be aware every few minutes that everything is still in sync, by contrast, deploying applications directly with helm commands only ensure synchronization at the time of deployment.<\/p>\n Now that we have explained what the Application object is, for our monitoring-stack, we are going to create four. Why four applications if there will only be 3 services in the stack? (Prometheus, Grafana and Thanos).<\/p>\n ArgoCD also offers the possibility of creating groups of applications that follow the “app of apps pattern<\/a>” concept. This is an ArgoCD application that deploys other applications and so on recursively. In the case of our monitoring stack, we are going to create a fourth application that will deploy the other 3 applications, the parent application will be called “monitoring-stack”.<\/p>\n To create an application we can define an ArgoCD Application manifest, as indicated in this page<\/a> of the documentation. We can also do it by command line<\/a>. But ArgoCD has a great UI that allows you to create applications manually as well, you can see how here<\/a>.<\/p>\n The “monitoring-stack” application will point its source to a git repository with a Helm chart. This chart will contain the manifests of the other three applications in the “templates” directory in yaml format. These files are Application<\/a> object definitions that point to the relevant official Helm chart of each service. Using the “values files”, we will be able to deploy different versions in different environments.<\/p>\n Once the templates of the “monitoring-stack” chart have been defined, we will create the parent ArgoCD Application, and in source we will point to the previously mentioned repository. ArgoCD will detect that it is a helm chart and we can indicate the path of the specific values file, for example “prod_values.yaml”.<\/p>\n At the end of the manual configuration of the application, in the user interface we will see how all the created objects are represented, organized in a hierarchical way.<\/p>\n Since the applications are synchronized with our repository, and the charts are parameterized with templates and values. To deploy a new version of any of our applications we will only have to modify the values file through git commits. As a note, using ArgoCD Image Updater<\/a> can save us from doing this last step manually, or even having to develop a complex pipeline to update the values.yaml file in git when we want to deploy the new image. In this example we have created an application that points to a repository that creates applications which point to official helm charts, but this hierarchical loop can be extended much further, following the “app of apps pattern”.<\/p>\n Another interesting feature of ArgoCD is that it allows us to deploy applications in different clusters. There are several ways to do this, but the most direct way is through the Application Set resource. The relative ease of installation that ArgoCD has is another positive point to take into account, here you can consult the steps<\/a>.<\/p>\n If we want to go a step further and automate the entire CICD process in Kubernetes, we can complement ArgoCD with the rest of the tools presented by the Argo project<\/a>. As a solution to the added complexity of installing and managing all these Argo project tools, some applications that encompass this entire stack have already been released allowing us to configure the pipelines for integration and deployment from a simplified higher level layer. Below we mention a couple of them, although in this post we are not going to analyze the particular functionalities.<\/p>\n
\nOnce the code has been modified in git, ArgoCD detects, via webhook or periodic checks every few minutes, that there have been changes in the application manifests. It then compares the manifests declared in git with those applied in the clusters and updates the latter until they are synchronised.<\/p>\nUsing ArgoCD<\/h2>\n
![\"\"](\"https:\/\/geko.cloud\/wp-content\/uploads\/2021\/10\/Screenshot-2021-10-29-at-13.39.28-300x248.png\")
![\"\"](\"https:\/\/geko.cloud\/wp-content\/uploads\/2021\/10\/Screenshot-2021-10-29-at-12.35.05.png\")
![\"\"](\"https:\/\/geko.cloud\/wp-content\/uploads\/2021\/10\/Screenshot-2021-10-29-at-14.40.16-1024x476.png\")
\nArgoCD will detect the changes in the repository and apply them in the kubernetes cluster through a rolling update deployment.<\/p>\n![\"\"](\"https:\/\/geko.cloud\/wp-content\/uploads\/2021\/10\/Screenshot-2021-10-29-at-14.54.37.png\")
\nThis tool periodically queries the latest tags in our image repository looking for new artifacts to deploy. This way, once it has found a new one, it takes care of automating the deployment process by editing the git configuration with the name of the new tag.
\nIt is worth mentioning that there is not yet a stable version of ArgoCD Image Updater but it is expected soon.<\/p>\n
\nIn its manifest we can specify a list of clusters where to deploy simultaneously with different paths of the repository. Since in our repository we can specify different versions for each cluster.<\/p>\nAutomation of the entire CICD process with Argo tools<\/h2>\n
\nBy combining Argo Events, Argo Workflows, ArgoCD and Argo Rollouts, further automation is possible following best practices in the current continuous integration standards.
\nVictor Farcic explains it very coherently in this video<\/a>.<\/p>\n