Argo CD Self-Heal, Sync Windows and Diffing
In the previous lesson, we finally deployed our application with the help of Argo CD. But that was only the first deployment, out of many to come. In this lesson, we are going to figure out what happens when we change our Kubernetes configuration, either manually with kubectl
or properly, with a Pull Request.
First, let’s see what happens if we go to the Terminal and execute kubectl edit deployments/pgadmin-production
. I will change the number of replicas to be just 2 and save it. Now let me head over to Argo CD UI. We almost instantly see, that our application is out of sync. And if we check the diff, we will see that Argo wants to reset replicas back to 3.
Notice that it does not automatically do it for us - we need to click on the Sync button manually. Or, we can also go to App Details, click on Edits, scroll down to Sync Policy section and Enable Auto-Sync. This is not enough, though. With only Auto-Sync enabled, Argo will only automatically apply changes that happened in the repository, but it will not roll back manual changes. To achieve this, we also need to enable Self Heal. Once enabled, Argo CD will get rid of my manual change, and set replicas back to 3, the value that we have in git.
Now let’s see how it works for the proper git-based change. I’ve prepared a pull request, that changes the number of prod replicas to 2. If I merge this Pull Request, Argo CD will instantly apply this change. This is great, but I actually want to see what exactly is going to change before merging this. To do this, I can run Argo CD CLI. There is an app diff
command, which accepts new revision as an argument. Argo CD will use this revision to compare with the current state:
argocd app diff pgadmin --revision cargo-100-example
Unsurprisingly, it shows me that the number of replicas will change to be 2. Now, before I finally merge this, I would like to ensure that Argo CD deploys this change only at night. For this, I can use a feature called Sync Windows
. For this, I need to go to the Project configuration, and click on Add Sync Window
button.
I will select all hours between 9pm and 3am and only from Monday to Friday. I want this window to be valid for all applications, namespaces and clusters of this project. After I am done with creating it, let me merge my Pull Request. Now I will head over to the application page in the Argo CD. We can see that it’s out of sync, but due to the sync window, deployment is blocked.
Now I will go back to the window settings and select current time to be inside the window. Now the window is active, and if I go back to the application page, we will see that Argo CD applies the change.
That’s it for this lesson and, actually, that’s it for this lightning course! At this point, you know all the main components of Argo CD and how they are connected together. We’ve deployed an application, and learned how to re-deploy it, as well as how to reconcile our infrastructure with the state in Git.
Here' the same article in video form for your convenience:
Series "Argo CD Lightning Course"
- What is Argo CD, and why would you need GitOps?
- Argo CD Installation and Architecture
- Argo CD Clusters and Repositories - Two Core Components
- How to deploy Applications within Projects in Argo CD
- Argo CD Self-Heal, Sync Windows and Diffing
- Argo Ecosystem: Argo CD, Argo Workflows, Argo Events, Argo Rollouts, Argo Everything