Updating Applications through GitOps Principles

Correcting two potential issues

As we’ve already discussed, any change to the cluster should start with a change of the desired state and end with the push of that change to Git. After that, it’s up to the system to converge the actual into the desired state. We already have such a system set up, and all we’re missing is to see it in action.

As we discussed in the previous lesson, we’ll need to change the address of the applications. On top of that, both apps are currently using the latest tag of their respective images. That’s bad. One should never do that, except when running in a local development environment. We need to be specific, or we risk losing control of what is running where.

With those two issues in mind, we can fix our problems by changing the latest to a specific version and devopstoolkitseries.com to a domain that will be pointing to your cluster.

Given that both the tag and the Ingress host are defined as Helm variables, we don’t need to touch the manifest in the application’s repo. More importantly, those two values are specific to the production environment, so the logical place to apply those changes is in the manifest inside the argocd-production repo. We’re already inside the local copy of that repo in our terminal session, so we can simply overwrite those two variables with new values.

View the output of yaml file

Since we prefer changing files through commands, we’ll resort to sed magic one more time.