We recently announced the new Codefresh GitOps Cloud, the easiest way to promote changes across Argo CD applications–even across different clusters.
With Codefresh GitOps Cloud, you can model your own promotion flow with a graphical editor (although YAML is still available). You define exactly how an application reaches production, including all the requirements and approval gates your organization needs.
With Codefresh, environment information gets modelled in the platform itself. An environment can be any cluster or namespace in a cluster or any combination of the two. This means for Codefresh, your environments are first-level constructs, not just naming conventions.
At the same time, you can enrich your applications with extra information, like source code features, JIRA tickets, unit testing results, and other aspects of the software lifecycle that aren’t normally known to Argo CD.
After speaking with several teams about our new offering, we realized the most exciting feature for many folks is the new capability of connecting your existing Argo CD instance to the Codefresh platform.
We briefly described in the announcement blog post that you can now keep your existing Argo CD installation and still get all the benefits of the GitOps Cloud. We didn’t explain, however, how the integration works under the hood and why it helps teams that have already progressed in their GitOps journey. In this post, we share the technical details on how Codefresh interacts with your own Argo CD instance.
The user experience
It all starts with the installation instructions.
Here, you verify that you have all the requirements for installing the Codefresh GitOps runtime. The wizard also provides you with a full Helm command that you can run in your own Kubernetes cluster to get everything up and running. It’s also possible to use Terraform or any other similar method to install your Codefresh runtime.
Note that the traditional method (installing all Argo projects from scratch) is still available. Our documentation page has more information, including all the requirements and limitations for both options.
So, how does this work? What does Codefresh install in your cluster?
Architecture of the GitOps runtime
The image below shows all the components of the GitOps runtime. These include the other 3 Argo projects (Rollouts, Events, Workflows) and a set of custom components that contain part of the Codefresh control plane.
You can find a full description of what all these components do on our runtime documentation page.
Notice that Argo Rollouts is special. You also need to run it on each cluster that you wish to deploy applications to (if you follow progressive delivery).
Because our users operate across a wide variety of applications, we support 2 communication modes for the runtime:
- Outbound-only communication is more secure and easier to install, but might be less performant (because the runtime polls the Codefresh control plane).
- Inbound communication is more complex to set up as you need to open firewall ports in your infrastructure, but can offer performance benefits.
The Codefresh runtime supports both ways! You can install the Codefresh runtime and expose it via standard Kubernetes ingress or set up a tunnel-based solution that needs no exposed ports.
This means you can decide what’s best for your organization based on your risk requirements versus ease of installation.
Below is the updated architecture diagram with a tunnel-based solution.
Now you can clearly see the direction of traffic. All network streams start from your own cluster and point to the Codefresh control plane. This means you can easily install the GitOps runtime in clusters that are behind a firewall and not accessible on the public internet.
Here’s the architecture diagram for an ingress-based installation.
Notice again the direction of traffic and, more specifically, the arrow that joins the “GitOps Client(UI)” with the GitOps runtime.
Communication with your own Argo CD instance
We also need to explain how the GitOps runtime retrieves info from your Argo CD instance. As we explained in the announcement, Codefresh GitOps is not just a wrapper over Argo CD. It adds more features and defines all the missing pieces (like environments and promotions) that teams require when they move to GitOps-based CD.
The Codefresh platform needs to know what your Argo CD instance is doing. This information is retrieved by standard Kubernetes events.
When you want to deploy a new version of your application (or promote it via the Codefresh UI), a commit happens in Git. Argo CD then syncs the changes and publishes the details in the Kubernetes API.
The event reporter component of the GitOps runtime subscribes to the same Kubernetes API and retrieves all changes that happened to the Argo CD application. The reporter also asks the Argo CD server for the live manifests, as it resides on the cluster.
All this information is then forwarded to the Codefresh control plane and is accessible to the Codefresh dashboards.
Now you know exactly how that GitOps runtime interacts with your own Argo CD instance. As you can see, there’s nothing you need to change in your existing Argo CD installation.
Conclusion
We hope you now understand better how Codefresh GitOps Cloud works, and, more specifically:
- The requirements
- What gets installed in your cluster
- The role of the Codefresh control plane
- How network traffic flows between all components
- What data stays within your premises, and what’s accessed by the Codefresh platform
Ready to start your GitOps journey with Codefresh? Try GitOps Cloud free for 45 days now.