Argo CD for Flux Users

At Akuity, we are at the forefront of GitOps. We help many of our customers across all industries with their GitOps implementation. As we anticipated, our “Argo CD vs Flux” whitepaper has gotten a lot of attention lately, and if you’re curious about how the two tools compare and contrast, please obtain your free copy of this comparison whitepaper.

The popularity of this whitepaper has sparked a lot of conversations with Akuity and the community, and some of the conversations have led to talks about migration. To that end, we’ve decided to write this blog centered around helping Flux administrators understand how they can translate some of the common GitOps paradigms from Flux into Argo CD.

Translating Flux to Argo CD

A full comparison, from a technical and philosophical standpoint, was done in depth in the aforementioned whitepaper, so we aren’t going to go too far in depth with comparisons. You can read all about comparisons by downloading the whitepaper. Instead, we are going to focus on the things that Flux users need to know when thinking about migrating from Flux to Argo CD.

Bootstrapping

One of the great things about Flux is that bootstrapping your installation is built into the user experience. With one command, you can install Flux on your Kubernetes cluster and also set up your Git repository, which quickly on-ramps you to getting started, all of which is fully automated. Although there are many ways to bootstrap your Flux installation, the method that is built-in to the Flux CLI seems to be the most popular.

Argo CD does not have bootstrapping built into the Argo CD CLI. Instead, it relies on the Administrator to use GitOps practices to achieve bootstrapping. Although this unopinionated method might produce a challenge for users looking to get started, it offers ultimate flexibility for the administrator. Here are some of the popular ways Argo CD Administrators use to bootstrap their installations that can be helpful for Flux users.

• The App of Apps Pattern
• Using ApplicationSets
• Using Argo CD Autopilot

It’s important to note that Argo CD Autopilot is a part of Argo Project Labs. The Argo Project Labs organization is an incubation area for Argo Project extensions and a place for Argo Project adjacent technologies.

One great thing about Argo CD’s unopinionated approach to bootstrapping is that you can also use Argo CD’s Helm chart to install Argo CD. Flux native bootstrapping only supports Git for bootstrapping and manual configuration must be done if Administrators elect to use the Flux Community Helm chart for installation.

Sources of Truth

When working within a GitOps framework, your source of truth is the springboard of your application deployment process. Flux users are used to having CRDs manage their source of truth. The most common ones used are the GitRepositories and HelmRepositories CRDs.

Argo CD doesn’t have a separate controller for each source. Instead, Argo CD stores source credentials in a Kubernetes Secret, then Argo CD uses the source URL in the Argo CD Application to find if it needs to use credentials or not. This provides the ability for administrators to define both repository and credentials in a Kubernetes primitive.

apiVersion: v1
kind: Secret
metadata:
  name: private-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: git@github.com:argoproj/my-private-repository.git
  sshPrivateKey: |
    -----BEGIN OPENSSH PRIVATE KEY-----
    ...
    -----END OPENSSH PRIVATE KEY-----

Administrators can also select to store credentials in a separate Secret. Types that are supported are Git, Helm, and OCI. More information can be found on how Argo CD handles sources on the official documentation page.

There are other sources that are centered around CRDs, like S3 buckets, that are built into Flux. Argo CD also supports a myriad of sources via a plugin model called ConfigManagement Plugins. Using this plugin model, Argo CD users can build integration with other sources without waiting for a controller to be built.

Application Definitions

Flux is built on top of the GitOps Toolkit, which has individual controllers for each deployment type (like Kustomize and Helm). So when you want to deploy a YAML-based application you would use the Kustomization CRD, and for a Helm chart, you would use a HelmRelease CRD.

Argo CD takes the approach of wrapping all application manifests (whether they come from a Kustomized repo, Helm repo, or a git repo with raw YAML) in an CRD called an Application. An Argo CD Application takes your source (the way it’s stored in the secret) and applies it to the supplied destination cluster. Here’s an example:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps/
    path: guestbook
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc

Here, I want to draw your attention to the .spec.source section. This is where you define if it’s a Helm Chart, Kustomized Kubernetes YAML, or a Repo with raw YAML stored. You can find out more about how to formulate your YAML for different deployment types in the Argo CD Official Application Specification page.

You may notice that the Argo CD Application CRD does not include a “dependsOn” feature that most Flux users are accustomed to. To that end, the following options are available to you.

• Using App-of-Apps with Sync Waves
• Using ApplicationSets
• Using Progressive Sync

A more holistic approach to application dependencies is Kargo. With Kargo, you can control the process of not only inter-application dependencies; but also use it for promotion across environments. Kargo is currently in its pre-alpha phase, but we are looking for feedback and suggestions!

Is Migration from Flux to Argo CD Possible?

At Akuity, we’ve talked to many end users curious about the ability to migrate from Flux to Argo CD. Since there are a lot of common patterns between the two tools, it would seem that migration should be possible. Internally ,we’ve been experimenting with this idea and developed something called MTA (Migrate to Argo CD). You can see it here in action:

Currently, MTA is in the “proof of concept” (i.e. pre-alpha) state, so it’s not quite ready to use on a production system. However, we invite you to try it out in your lab and provide us with any feedback.

We also like bug squashers, so if you have an idea or improvements; feel free to contribute!

Argo CD: Developer Experience Centricity

Argo CD has been built, from the ground up, with the developer experience in mind. There is a lot that has been built into the core of Argo CD that makes it ready to use as soon as it’s installed. Some of these features include:

• Web UI that makes it easy to manage for both administrators and developers
• Observability built into the platform so you spend less time debugging issues
• Feature-rich RBAC system that allows for true multi-tenancy
• Comfort knowing Argo is the 3rd largest project in the CNCF in terms of velocity

All these collectively make Argo CD a feature-rich platform that has toolsets for not only your developers but also administrators and platform engineers. Argo CD is also the cornerstone of the BACK stack, which makes it ideal for those who are building Internal Developer Platforms for their organization.

Conclusion

In this blog we’ve explored how a Flux user can translate Flux components into Argo CD components and how Akuity can streamline the process with the MTA utility. So, are you ready to learn more about Argo CD and wondering what the next step could be? Try out our free Argo CD and GitOps online course to learn the ins and outs of Argo CD and get hands-on experience with these concepts.

Also, we invite you to give the Akuity Platform a try with a free trial!