Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
jx
Jenkins X provides automated CI+CD for Kubernetes with Preview Environments on Pull Requests using Cloud Native pipelines from Tekton
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
werf
A solution for implementing efficient and consistent software delivery to Kubernetes facilitating best practices.
-
-
-
kamus
An open source, git-ops, zero-trust secret encryption and decryption solution for Kubernetes applications
-
kubernetes-external-secrets
Discontinued Integrate external secret management systems with Kubernetes
-
externalsecret-operator
Discontinued An operator to fetch secrets from cloud services and inject them in Kubernetes
-
-
-
-
-
-
-
awx
AWX provides a web-based user interface, REST API, and task engine built on top of Ansible. It is one of the upstream projects for Red Hat Ansible Automation Platform.
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Websites such as awesome-gitops, which was launched by Weaveworks, or gitops.tech, which was put together by INNOQ employees, provide an introductory overview of the available tools. When you take a closer look, you will see that the listed tools can be used to perform a wide variety of tasks related to implementing GitOps, and of course they also differ from one another in terms of their adoption, maturity, and how actively they are maintained. This article identifies three categories from the various use cases: Tools for Kubernetes, supplementary tools, and tools close to infrastructure. In addition, we compiled a table that summarizes the tools and their properties. The tables also contain various Git and GitHub-based metrics (current as of February 2021) that allow you to better assess their adoption, maturity, and how actively they are maintained.
The blog post by Weaveworks, which coined the term GitOps in 2017, also names the first GitOps operator: Flux. In the meantime, this has been completely rewritten as Flux v2. In addition to Flux and Flux v2, the associated project "Flux" develops other components. Weaveworks has now handed the project over to the Cloud Native Computing Foundation (CNCF). By now, the project is in the second maturity level: incubator phase.
The blog post by Weaveworks, which coined the term GitOps in 2017, also names the first GitOps operator: Flux. In the meantime, this has been completely rewritten as Flux v2. In addition to Flux and Flux v2, the associated project "Flux" develops other components. Weaveworks has now handed the project over to the Cloud Native Computing Foundation (CNCF). By now, the project is in the second maturity level: incubator phase.
ArgoCD offers an alternative to Flux. It belongs to the Argo project, which is also based at the CNCF, and which is, just like Flux, in the second maturity level (incubator phase). A comprehensive comparison of the two GitOps operators can be found later in the article.
A newer competitor is Fleet, which is developed by Rancher. Its special ability is that it is able to manage not just one, but a fleet of clusters. PipeCD is similarly young and has an even broader focus. Like Fleet, it promises the ability to manage multiple Kubernetes clusters, and it also offers a UI. In addition, it can handle Terraform and some services from the major cloud providers.
A newer competitor is Fleet, which is developed by Rancher. Its special ability is that it is able to manage not just one, but a fleet of clusters. PipeCD is similarly young and has an even broader focus. Like Fleet, it promises the ability to manage multiple Kubernetes clusters, and it also offers a UI. In addition, it can handle Terraform and some services from the major cloud providers.
Jenkins X also offers a broader focus, but in a different area. Contrary to what the name suggests, it differs greatly from the well-known Jenkins server. It's not a monolithic tool, but rather it consists of different components, such as Tekton for running pipelines and Kaniko for building images. At the heart of Jenkins X is a CLI that the developers have rewritten for the current version 3 along with some fundamental architectural changes.
Jenkins X also offers a broader focus, but in a different area. Contrary to what the name suggests, it differs greatly from the well-known Jenkins server. It's not a monolithic tool, but rather it consists of different components, such as Tekton for running pipelines and Kaniko for building images. At the heart of Jenkins X is a CLI that the developers have rewritten for the current version 3 along with some fundamental architectural changes.
Werf positions itself somewhere between a pure GitOps operator and a full CI/CD approach. The project was started under the name dapp, and then renamed werf in early 2019. Like an operator, it can apply Kubernetes resources from Git to a cluster. However, it runs outside of the cluster. This means that it does not utilize the pull principle, which is often associated with GitOps, in which the cluster itself pulls its target state from Git. Unlike ArgoCD and Flux, werf can also build images. An operator that runs in Kubernetes is planned (as of version v1.2 beta).
One simple option that works well together with GitOps is Bitnami's Sealed Secrets operator. It manages the key material in the cluster itself. There is a CLI for encryption that requires a connection to the cluster.
SOPS that was developed by Mozilla offers significantly more options, though at the expense of a more complex configuration. Here, the key material can come from the key management systems (KMS) of the major cloud providers, from your own HashiCorp Vault, or from configured PGP keys. SOPS itself does not contain an operator, but there are different ways to use it with GitOps. Flux v2 offers native support. There is also the helm-secrets plug-in, which can also be used in ArgoCD with the manual configuration. There is also a sops-secrets operator that has been developed by a third party.
SOPS that was developed by Mozilla offers significantly more options, though at the expense of a more complex configuration. Here, the key material can come from the key management systems (KMS) of the major cloud providers, from your own HashiCorp Vault, or from configured PGP keys. SOPS itself does not contain an operator, but there are different ways to use it with GitOps. Flux v2 offers native support. There is also the helm-secrets plug-in, which can also be used in ArgoCD with the manual configuration. There is also a sops-secrets operator that has been developed by a third party.
SOPS that was developed by Mozilla offers significantly more options, though at the expense of a more complex configuration. Here, the key material can come from the key management systems (KMS) of the major cloud providers, from your own HashiCorp Vault, or from configured PGP keys. SOPS itself does not contain an operator, but there are different ways to use it with GitOps. Flux v2 offers native support. There is also the helm-secrets plug-in, which can also be used in ArgoCD with the manual configuration. There is also a sops-secrets operator that has been developed by a third party.
Kamus may represent a compromise between Sealed Secrets and SOPS. It was created especially for the GitOps use case and includes an operator. It can either manage the key material itself or obtain it from the KMS of the cloud providers. Another special feature is that Kamus encrypts secrets directly for an application. They are then decrypted by the application itself or by an init container. This means that the unencrypted secret is never present on the API server and ideally also not in an environment variable with in the container.
If you are using an external KMS in any case, then there are other options, such as the kubernetes-external-secrets operator that was originally started by GoDaddy and the externalsecret-operator from Container Solutions. If you use HashiCorp Vault, you also have the option of using the Vault Secrets operator. This works similarly to the Sealed Secrets Operator, but instead of managing its own key material, it retrieves the secrets from Vault. The CNCF Technology Radar from January 2021 provides an overview of the types of tools that are available for secrets management.
If you are using an external KMS in any case, then there are other options, such as the kubernetes-external-secrets operator that was originally started by GoDaddy and the externalsecret-operator from Container Solutions. If you use HashiCorp Vault, you also have the option of using the Vault Secrets operator. This works similarly to the Sealed Secrets Operator, but instead of managing its own key material, it retrieves the secrets from Vault. The CNCF Technology Radar from January 2021 provides an overview of the types of tools that are available for secrets management.
If you are using an external KMS in any case, then there are other options, such as the kubernetes-external-secrets operator that was originally started by GoDaddy and the externalsecret-operator from Container Solutions. If you use HashiCorp Vault, you also have the option of using the Vault Secrets operator. This works similarly to the Sealed Secrets Operator, but instead of managing its own key material, it retrieves the secrets from Vault. The CNCF Technology Radar from January 2021 provides an overview of the types of tools that are available for secrets management.
Supplementary GitOps operators can also be used for deployment strategies, such as canary releases, A/B tests, and blue/green deployments, which have now been grouped under the term “progressive delivery”. The resources of most GitOps operators are not sufficient for this. One solution is Flagger. The tool that was launched by Weaveworks is now being developed as part of the Flux project. The Argo project also has an operator for this use case: Argo Rollouts. Both offer CRs for implementing progressive delivery strategies in interaction with various ingress controllers and service meshes.
Supplementary GitOps operators can also be used for deployment strategies, such as canary releases, A/B tests, and blue/green deployments, which have now been grouped under the term “progressive delivery”. The resources of most GitOps operators are not sufficient for this. One solution is Flagger. The tool that was launched by Weaveworks is now being developed as part of the Flux project. The Argo project also has an operator for this use case: Argo Rollouts. Both offer CRs for implementing progressive delivery strategies in interaction with various ingress controllers and service meshes.
The term GitOps arose originally in the context of application deployments in Kubernetes. The tools for this use case are very mature. They are not limited to this use case, however. GitOps operators can also be used to roll out Kubernetes clusters. One scenario is to use the Kubernetes Cluster API, which was started as kube-deploy and renamed Cluster API (CAPI) in 2018. This can be implemented as follows: A GitOps operator runs in a management cluster and applies the CRs (defined by CAPI CRDs) stored in Git to the cluster. A infrastructure provider also running in the cluster reads these CRs and applies them to a target cluster.
In addition to creating Kubernetes clusters, there is also an increasing number of opportunities to use various Infrastructure-as-Code (IaC) tools, such as Terraform, with GitOps. As was already mentioned, PipeCD offers support for Terraform. Terraform's vendor, HashiCorp, now also offers an official Terraform Kubernetes operator. However, it needs access to HashiCorp's Terraform Cloud. Alternatively, there are also third-party operators that can function without Terraform Cloud, such as the one developed by Rancher. However, it is still in alpha stage.
In addition to creating Kubernetes clusters, there is also an increasing number of opportunities to use various Infrastructure-as-Code (IaC) tools, such as Terraform, with GitOps. As was already mentioned, PipeCD offers support for Terraform. Terraform's vendor, HashiCorp, now also offers an official Terraform Kubernetes operator. However, it needs access to HashiCorp's Terraform Cloud. Alternatively, there are also third-party operators that can function without Terraform Cloud, such as the one developed by Rancher. However, it is still in alpha stage.
Another popular alternative for GitOps with Terraform is Atlantis: When generating a pull request, basing on the Terraform files that are found in the Git repository, it creates the Terraform plan and adds it to the pull request as a comment. After merging, it applies the Terraform plan. Atlantis is compatible with various Git providers. It can be flexibly hosted as either a binary, a Docker image, or as a Helm chart for Kubernetes. This makes it one of the few tools that will be of interest to those who want to implement GitOps without Kubernetes. Ansible Tower (and thus its open source upstream AWX) is also independent of Kubernetes. Red Hat considers the range of features to be comparable to a GitOps operator.
Another popular alternative for GitOps with Terraform is Atlantis: When generating a pull request, basing on the Terraform files that are found in the Git repository, it creates the Terraform plan and adds it to the pull request as a comment. After merging, it applies the Terraform plan. Atlantis is compatible with various Git providers. It can be flexibly hosted as either a binary, a Docker image, or as a Helm chart for Kubernetes. This makes it one of the few tools that will be of interest to those who want to implement GitOps without Kubernetes. Ansible Tower (and thus its open source upstream AWX) is also independent of Kubernetes. Red Hat considers the range of features to be comparable to a GitOps operator.
Finally, there is one tool in particular that we should not leave out when creating a list of GitOps tools that are close to the infrastructure: Ignite, which was also launched by Weaveworks. It allows you to manage virtual machines (VMs) via GitOps. In order to do this, it runs a daemon on the physical host that can start and stop VMs in accordance with a description that is stored in a Git repository. Firecracker, which was originally launched by AWS, is used as virtualization technology.
Another installation variant is the additional ArgoCD operator. This allows the actual ArgoCD components to be installed and configured via CRD. It is not documented how you can configure ArgoCD yourself via GitOps. This is conceivable, for example, using the ArgoCD operator. It remains to be determined whether this will work reliably and, above all, whether it supports continued operation via GitOps in the event of an error.
This allows the developer to analyze their deployments and correct errors all without having to access the cluster. For authentication , there are interfaces for common protocols, such as LDAP and OIDC. Via configurable roles and groups, users can granted access the projects and applications for which they are responsible. The developers of Flux v2 are currently working on a web interface. However, it is still in an experimental state.
Flux has certain little features that ArgoCD doesn't have, such as support for SOPS and automatic updates for new image versions. However, the latter is the reasons that Flux v2 has not yet appeared in a stable version. It could be difficult to opt for a product with a version number 0.x when it is the central component in the supply chain. However, we do expect the release of a stable version here soon. One possibility to see ArgoCD and Flux v2 in action and compare their features is the GitOps Playground project that was started by the authors.