Three questions and answers: How do you find the optimal GitOps tools?

Anyone who converts their Kubernetes environment to GitOps needs a suitable operator. The main choices are Argo CD and Flux. It is also necessary to design the company’s GitOps process. In an interview, iX title author Johannes Schnatterer explains what is important.

Advertisement

Johannes Schnatterer does dev, ops, training and consulting at Cloudogu. His current focus is on the cloud, containers, continuous delivery and GitOps.

The GitOps operators Argo CD and Flux provide similar functionality. Can they still be fundamentally distinguished in some way? What can make the difference in favor of one or the other tool?

There are actually many small differences. But most will not be relevant for many. A rule of thumb is that Argo CD is aimed more at end users and Flux is easier to integrate into other products. As the article shows, both also offer possibilities to be used in exactly the opposite way.

In my experience, what is often relevant with Argo CD is that it comes with an in-house UI and templating functionalities (ApplicationSets). For many, Flux feels lighter and more Kubernetes-native, easier to install and update, and offers better UX for Helm. It also offers innovations in the support of OCI registries and Terraform.

However, some of these points can be put into perspective. For example, Argo CD core is a lighter configuration of Argo CD, and Weaveworks offers various UIs for Flux.

What further steps are necessary when designing your own GitOps process?

Knowing the requirements is necessary to select the right operator, for example do you want to deploy applications or infrastructure? What communication structures does your facility have? How many teams, projects, departments or applications do you have? What infrastructure, such as a Kubernetes cluster, do you have or want to have? Which environments or stages do you have? And what is the transition between them (promotion)? Do you want to realize short-lived preview environments based on pull requests? These considerations help in choosing the operator and overcoming the GitOps chasm of mapping the real world to infrastructure.

Advertisement

Is there help for this or does everyone have to think for themselves how to design their GitOps process?

In general, there is intentionally no standard for the one GitOps process because, according to Conway’s Law, it depends on the communication structures of an organization. However, some recurring patterns can be identified from experience. In addition to the decision for an operator, the structuring of the repositories, promotion between the environments, number of operators and wiring of the operators are pending.

Mr. Schnatterer, thank you very much for the replies! A cover article in the new iX provides a detailed comparison between Argo CD and Flux, while another presents practical GitOps patterns. In addition, the September issue, which is available now, takes a close look at Microsoft’s cloud meltdown and the forensic tool Velociraptor.

In the “Three Questions and Answers” series, iX wants to get to the heart of today’s IT challenges – whether it’s the user’s point of view in front of the PC, the manager’s point of view or the everyday life of an administrator. Do you have suggestions from your daily practice or that of your users? Whose tips on which topic would you like to read in a nutshell? Then please write to us or leave a comment in the forum.

(jvo)

Go to home page
#questions #answers #find #optimal #GitOps #tools