In previous articles, we deployed a GitOps infra in Kubernetes and an application using Argo CD (GitOps tool).

You know, it’s time to introduce some changes in the code to demonstrate the life cycle involved:

  1. Pull Request (When you modified the code.)
  2. Webhook to Apply automated.
  3. Clone Repository, for the first time in each new application added to Argo CD.
  4. Push the image builder.
  5. Argo will apply to Kubernetes cluster.

Remember… make simple everything as possible.

“Simplicity Boils Down To Two Things: Identify The Essential And Eliminate The Rest” – Leo Babauta

Getting started running the kubectl command to verify the deployment existed in testing namespace.

kubectl get all -n testing

Please, pay attention to the number of replicate sets. All have only one. Our goal will increase it.

  • We check this same situation in the Argo-cd application.

Clone the repository

  • Clone the repository with code application to start with the testing.
git clone

So, as commented before, our use case is referred to modifying the infrastructure pods from 1 to 3, to increase the capacity of execution horizontally.

Open the bookinfo.YAML with some editor and change line 143 , replicas 1, to replicas 3. In the image below, we introduce the change as an example.

  • Edit, change the data, commit & push the changes to the repository.
vim bookinfo.yaml
git add bookinfo.yaml 
git commit -m "Argocd: demo NGNIX deployment - scale replica to 3"
git push origin --set-upstream

Meanwhile, the Argo CD web interface shows the application in “yellow”, which means that a change happened in the repository. The code changed. And if you remember in another article, we configured the synchronization in a manual way.

  • In the case that we had selected another choice as “automated”, the changes would have happened without human intervention.

Compare the code

  • If you are a curious person, you can find the changes into +app diff button.
  • Show a similar image.

  • Now, push the SYNC button, and you can look into the web interface as the command line for the number of pods.

  • In the command line, run the command and compare it with the results that we show below.
kubectl get all -n testing

Rollback the change or introduce another

It’s possible to continue introducing changes every time the business needs it. In our testing example, only decrease the resources from 3 pods deployed to 1.

Only repeat the steps above and monitor the results from the argocd web interface.

vim bookinfo.yaml
git add bookinfo.yaml 
git commit -m "Argocd: demo NGNIX deployment - scale replica to 1"
git push origin --set-upstream

I hope that you learned something more, for your DevOps career and add value to the business.