In the previous article of the series we explained how to model GitOps environments and promote an application between them. That article was laser-focused on a single application and its Kubernetes resources. In this article we will zoom out to look at several related subjects:
[…]
This manifest can be easily corrected by putting all the parameters in a values file in the same Git repository as the chart like this
[…]
Ideally all your Helm charts should be under your control and in Git so that you can get all the benefits of GitOps with them.
[…]
Note: Another Argo CD feature that you should NOT use is parameter overrides. In their most primitive form, they don’t even follow the GitOps principles. Even if you save them in Git, again you have a mix of Argo CD and Kubernetes information in the same place (mixing category 1 and category 2 information).
The purpose of Argo CD application CRDs is to work as a “wrapper” or “pointer” to the main Kubernetes manifests. The thing that matters is the Kubernetes manifests(category 1) and Argo CD manifests(category 2) should always have a supporting role.
[…]
Unfortunately, we see a lot of companies that use the Application CRD as their main unit of work instead of the actual Kubernetes manifests.
[…]
It also means that looking at a Git repository by itself isn’t a clear indication of what the desired state is, instead, each application can have its own separate target revision that needs to be understood and compared to another Git repository for the full picture.
[…]
Here is an example taken from the GitOps certification
[…]
Let’s look at a real-world example. You can find an example repo at https://github.com/kostis-codefresh/many-appsets-demo
[…]
Each application set simply mentions the overlays defined in the Kubernetes manifest. Here is for example the “qa” appset
[…]
Essentially anything the administrator wants to do corresponds to a simple Git action
[…]
The benefits of multiple Git repositories are visible both in performance and in usability aspects. Especially for developers, multiple Git repositories are preferable as they can focus on the Kubernetes manifests of their respective applications instead of forcing them to deal with applications that are not part of their team.
[…]
So we can update the previous picture and include another Git repository for infrastructure applications for the team that handles infrastructure.
This way as a developer on my team I can check out a Git repository that has only the stuff that I am interested in. The respective Argo CD application is super fast as well as the CI system that touches this Git repository. There is a minimal number of Git conflicts and if you want to apply additional security constraints you can use the existing Git mechanisms offered by your Git provider
[…]
