Argo GitOps Engine Update

Argo GitOps Engine is a library that implements core GitOps features such as resource diffing and the ability to use various synchronization strategies.

Originally used to power Argo CD, it was open-sourced by the Argo team to democratize GitOps. Their goal was to enable others to quickly build specialized tools that implement specific GitOps use cases, such as bootstrapping a Kubernetes cluster or decentralizing management of namespaces. The GitOps Engine was started as a partnership between Intuit and WeaveWorks and is now being driven by Intuit, Red Hat, and GitLab.

At GitLab, we took an interest in the GitOps Engine as we wanted to build our solution on battle-tested, open-source tools, and decided to become contributors.

It has been six months since the first version of the GitOps Engine has been released. In this post, we’ll recap what has happened with the project so far and explore what’s coming next.

Enhancements And Bug Fixes

Let’s start with functional changes. The GitOps Engine has received a lot of new features and stability improvements since it was released six months ago. The list is pretty long and includes the following notable changes:

• Namespace auto-creation. The feature allows GitOps Engine consumers to automatically create the namespace in the target Kubernetes cluster.
• Compatibility with Helm hooks. The improvement resolves the discrepancy between the way GitOps Engine and Helm delete hooks resources.
• Namespace and Custom Resource Definitions (CRD) creation. GitOps Engine automatically creates Kubernetes Namespaces and CRDs before creating any dependent Kubernetes resource.
• Improved Diffing. Client-side diffing is now much more accurate and matches the Kubernetes server-side diffing.

In addition to new features, the GitOps Engine has received a lot of bug fixes and in general, is more robust now. However, for us, the features and bug fixes are not the most exciting news.

Argo GitOps Engine now has a new Consumer!

Argo CD is no longer the only consumer of GitOps Engine. We are happy to announce that the GitLab Kubernetes Agent is now also an official GitOps Engine consumer! The GitLab team collaborated with the Argo Team to create new Kubernetes integration for GitLab that uses the Argo GitOps Engine.

GitLab is a DevOps platform, delivered as a single application. Everything from Agile planning and source code management to CI/CD and monitoring is included out-of-the-box. Integration with Kubernetes is a core GitLab capability. GitLab is actively adding new Kubernetes management features and the GitLab Kubernetes Agent is the most recent addition. The Agent provides a cluster-side active component to integrate the Kubernetes cluster with GitLab in a more secure way by leveraging GitOps Engine!

GitLab team evaluated several options and chose the GitOps Engine because it provided the level of abstraction we were aiming for and provided a lot of features out-of-the-box that we’d have to otherwise build from scratch. An additional benefit of the GitOps Engine is that it provides an implementation of complex patterns such as Pre and Post Sync Hooks, Synchronization waves that are already adopted, and validated by multiple Argo CD users. Additionally, GitOps Engine significantly simplifies the implementation of advanced features such as visualization of detected configuration drifts and health assessments that are required by the GitLab roadmap.

What Does It Mean For The Project?

Going forward, there are a few things you can expect to see now that the Intuit, Red Hat and GitLab teams are collaborating together on making the Argo GitOps Engine better.

First of all, joining efforts means more features and better code quality for both Argo CD and GitLab. During the last six months, Argo and Gitlab teams contributed around 60 changes including the features listed above and multiple code quality improvements. Together we’ve significantly reduced the number of dependencies in GitOps Engine, cleaned up the public API, and fixed several issues caused by race conditions. Simply put, together we can deliver more value to both communities.

Another important benefit of using the shared library is that Argo CD and GitLab now have a shared implementation of GitOps. That means you can use the same Kubernetes resource annotations in your Git repository to control the GitOps synchronization process in both GitLab and Argo CD. This is a big step forward towards creating a unified GitOps process for Kubernetes that other projects can adopt as well.

What Is Coming Next?

As the Argo and GitLab teams continue to collaborate, we plan to contribute even more features to the GitOps Engine that are currently only available in Argo CD. By open-sourcing these capabilities, we others will adopt GitOps Engine and contribute to it as well. The list includes:

• Extensible Kubernetes resources health assessment framework gitops-engine#48
• Resource diffing customization settings gitops-engine#178
• The unified naming convention for resource annotations gitops-engine#43

We are hoping that other GitOps products also adopt GitOps Engine so that it becomes a standard way to reconcile and synchronize Kubernetes resources.