Table of contents
- Introduction
- Criteria for Comparing Argo CD vs Tekton vs Jenkins X
- At a Glance Comparison
- Argo CD
- Deployment and Ease of Use
- Integrations and Configurability
- How Tuned Is It for Kubernetes?
- Coverage of GitOps Workflow
- Community, Maturity, and Popularity
- Tekton
- Deployment and Ease of Use
- Integrations and Configurability
- How Tuned Is It for Kubernetes?
- Coverage of GitOps Workflow
- Community, Maturity, and Popularity
- Jenkins X
- Deployment and Ease of Use
- Integrations and Configurability
- How Tuned Is It for Kubernetes?
- Coverage of GitOps Workflow
- Community, Maturity, and Popularity
- Conclusion
- That’s all, folks!
Introduction
In this article, we’re going to take a look at three different CI/CD tools that have grown in popularity over the last couple of years: Argo CD, Tekton, and Jenkins X.
If you’re reading this article, you’re either considering implementing GitOps in your organization to manage your operational workflows, or you’ve already done so. You have probably also considered cloud-native platforms and tooling such as Kubernetes. In order to implement GitOps with Kubernetes, it’s crucial to carefully choose CI/CD tools that make sense for your use case.
We’ll assume that you are already familiar with GitOps and Kubernetes. Gitlab provides a great video on the topic of GitOps. In addition, the Kubernetes documentation itself provides a clear explanation that should get you started.
Criteria for Comparing Argo CD vs Tekton vs Jenkins X
To provide an apples-to-apples comparison, we will evaluate each one on the following criteria:
Deployment and Ease of Use
Integrations and Configurability
How Tuned Is It for Kubernetes?
Coverage of GitOps Workflow
Community, Maturity, and Popularity
With that said, let’s dive right in.
At a Glance Comparison
The following table compares each project according to the criteria discussed above. You can use it as a cheat sheet for your own comparison.
Argo CD
Argo CD was developed by Intuit and released as open-source under the Apache 2.0 license at the beginning of 2018. Intuit was initially using Spinnaker, but they wanted something lighter weight that would improve their build and deployment times as well as streamline their GitOps workflow when using Kubernetes.
Argo CD bills itself as a declarative GitOps Continuous Delivery (CD) tool for Kubernetes. At a high level, there are a few key features to note:
Ability to deploy and sync applications to Kubernetes clusters automatically or manually
Drift detection, correction, reporting, and visualization via the UI
Support for multiple Kubernetes clusters and multi-tenancy with RBAC
SSO via a number of providers including GitHub, GitLab, Microsoft, LinkedIn, OAuth2, SAML 2.0, LDAP, and OIDC
WebUI and CLI
Support for webhooks via Github, BitBucket, and GitLab
A full list of features with more detailed descriptions can be found on the Argo CD Overview page in the documentation.
Deployment and Ease of Use
Deployment to a live Kubernetes cluster is simple and requires only two commands using kubectl. The CLI installs on your local machine and is supported on Windows, Mac, and Linux.
Once the initial installation is done, you’ll run a few commands to configure Argo CD for your use case. These are clearly laid out on the Getting Started page in the documentation. There is also an option to deploy a sample app for those who want to give it a spin.
Argo CD’s well-developed UI makes it extremely easy to use, even for novices. Apps can be deployed and synced via the UI or CLI. Details on resource components, status, history, logs, events, and application health are all visible in the UI.
Integrations and Configurability
Argo CD integrates well with common CI tools including Jenkins, Github Actions, CircleCI, Gitlab CI, and so on. It supports webhooks via Github, Bitbucket, and Gitlab.
You can find numerous examples of how to integrate it with managed Kubernetes providers such as EKS, GKE, and AKS on the web.
It supports most common SSO providers including GitHub, GitLab, Microsoft, LinkedIn, OAuth2, SAML 2.0, LDAP, and OIDC.
ArgoCD supports multiple ways to define Kubernetes manifests, including Kustomize, Helm, Ksonnet, Jsonnet, JSON, and YAML. It also gives you the option to define a custom configuration management plugin if you want that level of customization.
How Tuned Is It for Kubernetes?
Argo CD was designed from the start to fully support Kubernetes, and it only runs on Kubernetes. It is deployed to your Kubernetes cluster, and it integrates with your cluster in its own namespace using Custom Resource Definitions.
It works by monitoring your Git repository for changes to the Kubernetes manifests that define your application. When it detects changes, it will automatically publish them to the target cluster. If needed, changes can also be synced manually via the UI or the CLI.
One major advantage of Argo CD is its support for multi-tenancy and multiple Kubernetes clusters. This includes the ability to deploy multiple applications to multiple clusters if desired. Its support for RBAC means that teams can deploy applications to their own namespaces without the risk of affecting other teams’ applications that are running in a different namespace.
Coverage of GitOps Workflow
Argo CD aims to be a lightweight tool with limited scope, so it does not provide Continuous Integration (CI) features such as application testing and building. For that, you will need to choose your own CI tools, such as CircleCI, Github Actions, Gitlab CI, or Jenkins.
This could be viewed as an advantage since it gives engineering teams more flexibility in choosing which CI tool they think is best for their use case. On the other hand, CI isn’t included out of the box, and it needs to be configured separately (although it will integrate easily via mechanisms such as webhooks and the CLI).
Community, Maturity, and Popularity
As it was released in 2018, Argo CD is only about three years old. That said, it is in active development with multiple updates per week, and based on its scope and features, it can be considered a mature project. There are many notable names on the long list of companies that use Argo CD, including Intuit, Red Hat, Sumo Logic, Ticketmaster, Twilio, and Volvo.
Tekton
Tekton was originally part of the Knative project and is now under the auspices of the Continuous Delivery Foundation. Like Argo CD, Tekton was released in 2018 under the Apache 2.0 license.
Tekton takes a modular approach to cloud-native CI/CD by implementing components that form the building blocks needed to create a complete CI/CD ecosystem. Due to its nature, Tekton is extremely powerful, and it provides the ability to customize entities which can then be shared and reused as needed.
The biggest selling point of Tekton is its modularity, which allows for componentization, standardization, and reusability within your CI/CD workflows. The steps are operations in the CI/CD workflow that execute in containers, and they are organized into tasks that run as pods on your cluster. Tasks can be assembled and ordered within pipelines in any way that you need.
Deployment and Ease of Use
The initial installation of Tekton to your Kubernetes cluster requires only a single command. The Tekton CLI installs to your local machine, and it’s supported on Mac, Windows, and Linux.
In terms of ease of use, there is definitely a learning curve with Tekton. You need a solid understanding of CI/CD and your own requirements before it becomes truly useful. For anything beyond simple workflows, the onus is on the developer to assemble the necessary pieces into a complete CI/CD workflow.
Tekton does have a modular and extensible dashboard that provides visibility and management features; but again, additional configuration is required to make it usable for your use case.
Integrations and Configurability
Tekton’s strength is its modularity and flexibility, which allows for the assembly of complex pipelines without the need to rewrite the building blocks every time. Tekton has a catalog of pre-defined, reusable task resources, and it aims to provide more catalog features as the project progresses.
Since it will run on Kubernetes, it will integrate well across providers including AKE, GKE, EKS, or a “roll your own” Kubernetes cluster. It will also work with other CI/CD tools such as Jenkins, Jenkins X, and Skaffold.
How Tuned Is It for Kubernetes?
Tekton was designed to work natively on Kubernetes, and it incorporates Kubernetes best practices by default. On a related note, Jenkins X also uses Tekton to handle the execution and management of Jenkins X pipelines natively within Kubernetes.
Coverage of GitOps Workflow
Tekton is a complete solution, and depending on how you configure it, it will cover the entire GitOps CI/CD workflow — from integrating with a Git repository to deploying natively on Kubernetes.
Community, Maturity, and Popularity
There is a healthy community behind Tekton, and code commits are made to the project daily. It also has the support of some big names in the tech world, such as Cloudbees, Google, IBM, and Redhat, among others.
In terms of maturity, Tekton is slightly newer than Argo CD and Jenkins X. It’s still under development, and many features have not been added yet. The documentation could also use a bit of polishing here and there, but it will help you get the job done. Since Tekton enjoys widespread support and usage, it’s a viable project worth looking into if it fits your use case.
Jenkins X
Jenkins X is the cloud-native iteration of the traditional Jenkins CI/CD server. First announced in early 2018, Jenkins X was developed by Cloudbees, and it is now a project under the Continuous Delivery Foundation. Like the other projects discussed in this article, it was released under the Apache 2.0 license.
Jenkins X differs from Jenkins in that it was designed from the ground up to work for cloud-native applications using Kubernetes. Traditional Jenkins wasn’t designed to work natively with Kubernetes, and getting it to do so required implementing somewhat hacky solutions.
Jenkins X is considered to be “opinionated,” meaning that certain assumptions will be made about how things should be done in the interest of getting up and running quickly. This has the advantage of allowing developers or operations engineers to forego a steep learning curve in order to accomplish what they need without a lot of hassle. The disadvantage is that if you don’t like how Jenkins X does things, it will take more work to extend and customize it.
Some of the key high-level features of Jenkins X are:
Automated import of existing software projects
Automatic project type detection (i.e. Go, Java, Python, etc.)
Automatic pipeline creation including Jenkinsfiles and Dockerfiles
Automatic software environment creation (i.e. dev, staging, and prod)
Automatic Helm chart creation for deployments
Automated detection of changes in your repo and deployment to the appropriate software environment
CLI using the jx binary written in Go
Extensibility through the creation of plugins compatible with the jx binary
Deployment and Ease of Use
Depending on your use case, you may or may not already have a Kubernetes cluster available where you want to install Jenkins X. If you don’t, it’s recommended that you use Terraform modules to instantiate a new cluster. It’s also recommended that you run Jenkins X on its own cluster.
Once the cluster is ready, you will want to install the jx binary to your local machine. This is supported on Mac, Windows, and Linux, and depending on the installation method, it should only take a few commands.
You then install it to your Kubernetes cluster via jx boot.
In terms of ease of use, Jenkins X shouldn’t be a problem if you’re comfortable working from the CLI. There is also an Octant-based UI jx plugin that you can install.
Integrations and Configurability
In terms of Kubernetes integrations, Jenkins X is fully supported on GKE and EKS. AKS isn’t shown in the compatibility matrix, but the documentation shows that AKS installation of Jenkins X is possible. OpenShift is also supported.
As for repositories, Github is fully supported, but Bitbucket and Gitlab are currently listed in the preview state.
Hashicorp Vault is supported for secret storage.
As Jenkins X has an opinionated way of doing things, your mileage may vary in terms of configurability depending on what you want to do. Under the hood, Jenkins X is a conglomeration of various Kubernetes-related projects, including Tekton, Prow, Helm, and others. It is also made up of various plugins that extend functionality beyond the basic CLI installation.
One thing worth mentioning is that the tried-and-true Jenkinsfiles are still used and supported, and they can also be edited if necessary. Depending on how well the automation serves your needs, you may not ever need to touch it.
How Tuned Is It for Kubernetes?
Jenkins X runs natively on Kubernetes, and in fact, it was designed for Kubernetes. You should check the compatibility matrix and documentation to ensure that both your version and your provider are supported.
Coverage of GitOps Workflow
Jenkins X provides an opinionated way of getting a full CI/CD workflow into place with a lower learning curve than other options. To one extent or another, it sacrifices some flexibility in order to make things easy to set up without having a tonne of in-depth knowledge.
Jenkins X also has an opinionated way of covering the GitOps workflow. For example, a separate repository is created for each supported environment. This may or may not be acceptable, depending on how you want to structure your GitOps workflow.
Community, Maturity, and Popularity
Considering the scope of the project, Jenkins X has been progressing rapidly. There is still quite a bit of development going on, and the underlying projects that makeup Jenkins X under the hood are also in progress.
It doesn’t appear that Jenkins X is being utilized in as many companies’ production environments as Argo CD and Tekton, but that doesn’t mean it isn’t ready for production. Your best bet is to try it out for yourself and see if it meets your needs.
Conclusion
As you can see, evaluating tools for automating your own GitOps-based CI/CD workflow can be complex and challenging. It’s very important to keep your use case and your requirements in mind. You also need to make sure that you have adequate resources available for setting up and managing the solution you’re considering. Keep in mind that it will take time to evaluate, set up, configure, and test each solution. Last but certainly not least, you want to consider the learning curve involved with each solution as well as the in-house knowledge and skills available.
If you’d like to test one or more of these tools, please read our other articles.
That’s all, folks!
If you enjoyed this article, you might find the next one interesting.
Last week, we deployed to our AWS EKS cluster using Terraform. Today, we continued our Terraform series and created our K8s cluster on Azure using AKS and Terraform.
Kudos for getting all the way to the end of this article.
Stay tuned :) as we go to the next deployment, using GKE.
Feel free to reach out if you have any questions.
#YouAreAwesome #StayAwesome
Stay tuned and follow me for more updates. Don’t forget to give us your 👏 if you enjoy reading the article as a support to your author!!