GitOps101 — ArgoCD’s Definition and Architecture (Bonus Part)
This is the seventh (and last) article in a series of (6+1 bonus =) 7 articles.
This series was written by Alper Peker and Yağız Küçükkambak, from OBSS DevOps Team.
Hello, yet again, from the GitOps101 series. This part unlike the others is dedicated to a tool rather than a demo or process. In this article, we will talk about ArgoCD’s features, pros and cons.
Definition
Unsurprisingly we will start with what ArgoCD is. ArgoCD is a tool that does justice to the continuous delivery name. The appropriate application states can be automatically deployed by ArgoCD in the designated target environment. The main feature of this delivery tool is to get your deployments in sync with the changes made to the application repository. It provides automation, auditability, and ease of usage.
Difference
So what is the difference compared to other CD tools you may ask? ArgoCD uses the “Pull Model” instead of the “Push Model” which is adopted by the traditional CD tools. The push model, as its name suggests, starts the action from the change in the repo/artifact. In both of these scenarios, everything begins with the same two steps: commit to the repository and CI stages being completed successfully. At this point, the Push Model has the CD stage where the selected tools make the deployment to the Kubernetes cluster via commands. On the other hand in the Pull Model, ArgoCD tracks the changes in the repo and then synchronizes the Image with the new tag to the Kubernetes cluster.
There are many pros that ArgoCD brings to the table. Firstly ArgoCD has a very functional UI which makes it easy to see and manage the sync status of the repo, health checks of the currently running deployment and pods, and the overall status of your projects with all this info being updated in real-time.
Furthermore, ArgoCD also reduces the effort needed to deploy since both the Developer and the DevOps engineer will only be concerned about the updates on the Git Code. What’s more, this also provides better security since the only access to the deployment environment will be made by ArgoCD.
Arhitecture and Structure
Having said that, how does ArgoCD work? How does it provide such ease? To be able to understand, we will have a glimpse of the architecture of ArgoCD. ArgoCD has 3 main components: an API/Web Server, a Repo Server, and an Application Controller.
Repo Server, controls the repository in which the source code is stored. Cloning operations and generation of the Kubernetes manifests are done by the Repo Server.
API/Web Server exposes the API for UI and CLI usage, meaning that any command executed or any button pressed in the UI is connected to the API Server. Mainly this component is responsible for the Application Management and Operations namely the creation/deletion of the applications as well as the sync and rollback operations. Lastly, the authentication process is also managed by this component.
The final main component is the Application Controller and its functionality consists of the management of the Kubernetes Cluster. The gathering of real-time data displayed in the UI, deployment of the applications set in the ArgoCD, and the operations done by the user are some of the done thanks to the Application Controller.
Apart from the main components, there are some additional components that ArgoCD makes use of. Those are; Redis for caching, Dex for making use of the external identity providers, and an Application Set that automates the generation of Argo CD Applications.
Getting Started with ArgoCD
Now let us set up an instance of ArgoCD. Usage and post-setup steps are defined in the earlier stages of the GitOps101 series. Before we begin, there are 3 prerequisites to installing ArgoCD to desired Kubernetes Cluster.
- Having a Kubernetes Cluster ready to go
- Have your kubeconfig file
- An already configured CoreDNS
First allow us to create a namespace for ArgoCD and apply the manifest file to our cluster in order to create the deployment, service, and pods.
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yamlThen, it is necessary to configure the CLI. So as to achieve this first get the CLI tool from ArgoCD’s GitHub repository. Then install the downloaded file and copy the executable as an environment variable. Finally, you can remove the downloaded file.
curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
sudo install -m 555 argocd-linux-amd64 /usr/local/bin/argocd
rm argocd-linux-amd64ArgoCD is not exposed to an external IP by default so we need a way to access the API Server. This is possible using two methods. These methods are LoadBalancing and Port Forwarding. For the scope of this mini tutorial, we will go with Port Forwarding since it is the easier option. After the command is run the API Server will be accessible from port 8080 of the localhost.
kubectl port-forward svc/argocd-server -n argocd 8080:443To complete the setup and start using ArgoCD a login is required. By default, there is an admin password that is embedded in the files of the deployment. It is possible to change the admin password but do not forget to delete the file where the default admin password is stored. Also of course the CLI client must be able to reach to API Server for the login. After getting the password use the login command with the hostname where ArgoCD is exposed.
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo
argocd login <ARGOCD_URL>Use the following command to change the password.
argocd account update-passwordThank you for all the time and attention. This was an overview of the ArgoCD tool which was a crucial part of our GitOps101 series. Hope to meet again in another article.
