We end up running and managing several Kubernetes clusters as we incorporate containers and Kubernetes. Some are used for manufacturing, others for QA, and still others for short-term development environments. We need to package and deploy applications to these clusters in a variety of situations. The types of applications we want to deploy can also differ significantly. On the one side, we have third-party apps with their Helm charts, such as Grafana, Elasticsearch, and Kafka. This software will also be distributed after being customized to our use case and pinned to a particular version. On the other side, we have custom apps that are revised and implemented on a weekly basis. In several cases, it's also several times a day.
Installing, upgrading, and running these applications on several clusters is a challenge in both cases. For a few clusters, say it's about ten, a continuous integration pipeline (like Jenkins) could be set up to deploy to each one using a design rendering method of your choosing (Helm, etc.). On a smaller scale, this method works. What if there were a hundred clusters, each with a dozen or more apps? We'll look at how to install an application in one cluster and keep it updated, as well as how to deploy several applications to different clusters.
How GitOps is best for Application Development?
One of the solutions to this challenge is GitOps. The resources running in the clusters should fit the templates or configs specified in a git repository. It also includes an agent that will download and add all new commits to the git repository to the cluster. A cronjob that clones the git repository, makes the templates and applies them to a target cluster can be the simplest type of an agent. Adopting GitOps has a number of benefits. Here are a few examples:
It becomes very simple and straightforward to undo a transition. All you have to do is revert the commit that contains the update with git.
Looking through the git repositories gives us a single source of truth about what's going on in the cluster.
Pull Requests encourage others to check and point out any issues with any configuration or code updates. It's much easier to audit and monitor improvements. Any update is logged as a commit in git.
With GitOps, deployments become declarative, meaning users decide what they want to run, and the code manages resource development and deletion. The process becomes recognizable as well. Any configuration drift can be detected and corrected quickly by the operations team.
When we use GitOps, it takes to push an update to a development cluster is significantly reduced.
ArgoCD is a declarative Kubernetes GitOps continuous distribution platform. ArgoCD attempts to compare the current state of the cluster's resources to the models created by the git repository at the most recent commit. It makes resource models from a git repository regularly and compares them to the cluster's current state. Manual synchronization through the Graphical User Interface is possible, as is setting up a post-commit webhook. It's even possible that it'll be completed automatically. The templates will be applied to the cluster after sync.
Let's get started making an ArgoCD application. We'll use a Helm chart to deploy nginx using a Deployment and a Service to keep it straightforward.
A Kubernetes Cluster (for multi-cluster deployments)
Steps to follow:
Configure the cluster. Minikube will be used to create our cluster.
If the pods are up and running, we can connect using the CLI and GUI by port forwarding to the argocd-server service. The argocd-server pod's name serves as the original admin password. To print and copy it, use the commands below. In order to log into ArgoCD, we'll need the information in the next step.
Check the status of argocd pods.
$ kubectl get pod -n argocd -l app.kubernetes.io/name=argocd-server
After obtaining the admin password, we will port-forward and log in using the "admin" account and the password we obtained in the previous stage.
Fill in this information by clicking "Create Application." We can also look at the Application Custom Resource (CR) spec created by the GUI by clicking the “Edit as YAML” button. This spec can also be modified to Fill in this information by clicking "Create Application explicitly." We can also look at the Application Custom Resource (CR) spec created by the GUI by clicking the “Edit as YAML'' button. This spec can also be modified explicitly to execute acts that the form's GUI doesn't support.
If the Application is created, this page will be available. Since automated synchronization is disabled, the app's health will be Missing, and its state will be out of sync. When we open the app, we can see a comparison for each resource. To deploy the program to the cluster, select sync from the drop-down menu.
We can verify whether Nginx is running by going to the node port IP once the application is safe and synced. To open the URL in the default window, type the following button. The default Nginx landing page will be shown.
$ minikube service nginx-service --url
By flipping to a different branch, we can simulate a commit. Click "test" and then "App Details" to verify the values to open the application.
Select edit and change the TargetRevision to "nginxV2." This is a git repository branch that has a commit that updates the Nginx landing page. Once we have made our changes, click “Sync.” A new ReplicaSet will be built. If you go to the Nginx URL, we'll notice an additional line that says, "This was deployed using ArgoCD." The following command will open the URL.