About five years after Jez Humble and David Harley released their book on Continuous Delivery, Kubernetes entered the public stage and with it, a new way to think about server management hit the mainstream. Instead of defining what needs to be done to get a server into the desired state, why not define said state and let the reconciliation loop take care of getting there? And with this shift in thinking, the way CI/CD was implemented also shifted.
Weaveworks, a product company that originally focused on networking products like the Container Networking Interface (CNI), introduced GitOps, a way to do CI/CD that puts Git in the center. The idea being that Git was already quite popular among developers, so why not use it as the single source of truth for the desired workload states as well? This also tied in well with DevOps principles, which made the developers responsible for both the code and the configuration of their applications. As a result, source code and configuration could be delivered together in one bundle.
In the past, different environments like development, staging, and production were often set up and configured differently. This meant that even though all changes were pushed through and tested on these environments, devs could never be certain how their code would behave in production. With GitOps, the configuration is now part of the deliverable, which (almost) guarantees the same setup and behavior in each environment.
Additionally, Git provides a near-immutable paper trail for all changes, which makes it easy to audit past releases.
#GitOps & Argo CD
The GitOps principle does not specify how the desired change should make its way from the Git repository to the production environment. As a result, teams are free to use any tool or practice that works for them, as long as it takes the defined state from a Git repository and applies it to the target infrastructure.
Argo CD is a popular GitOps tool which leverages Kubernetes’ Operator pattern to define deployments as Custom Kubernetes Resources, making it a true Cloud Native approach. Operators make use of the reconciliation loop by regularly checking the cluster’s current state, comparing it with its desired state, and acting if there is any discrepancy between the two.
Argo CD can directly connect to a multitude of repositories (e.g., one repository per microservice) and monitor them for changes. As soon as changes are detected, Argo CD can deploy these to the desired environment (i.e., a namespace on a Kubernetes cluster). Deployment can also be configured more granular, e.g., deploy changes on branch X to namespace X but branch Y to namespace Y.
It also provides a UI which visualizes the relationship between the resources Argo CD manages.
#Throwing Loft into the mix
Argo CD makes managing workloads as simple as clicking a button, but what about the underlying infrastructure?
Loft offers a variety of tooling on top of Kubernetes, designed to provide a simple and clean interface for developers working with Kubernetes. For example, it enables the creation and management of lightweight virtual clusters, perfect for development and testing. With v3.0, Loft offers an Argo CD integration, which can take your delivery pipeline to the next level.
The Argo CD integration is enabled on a per-Project basis. Just head to Project Settings ⇾ Argo CD, toggle the Argo CD Integration option and add the information for the desired Argo CD instance.
#Virtual Clusters in Argo CD
Whether your Loft project already has existing virtual clusters or you are creating new ones. You can add them directly to Argo CD by toggling the Add to Argo CD option.
When creating an Argo CD Application, you should now be able to choose your virtual clusters from the dropdown.
Using this pattern makes it easy to separate the responsibilities of the platform and development teams: Loft still manages the virtual cluster itself, whereas Argo CD manages the lifecycle of the workloads.
#Authentication & Authorization
If you’re managing a big organization with multiple teams and intricate access rules, you’re probably getting good use out of Loft’s User Management feature already.
On the side of Argo CD, an RBAC feature to configure access to Argo CD resources and actions is available. With the Loft x Argo CD integration, Loft can be used as OIDC provider to attach the RBAC rules to individual users and teams. This is especially useful when you have different teams managing Loft and Argo CD.
To activate Argo CD roles for members of a Loft project, you first need to make sure that both the Loft and Argo CD instances have publicly available domains.
By default, Argo CD comes with two roles: Admin and ReadOnly. Custom roles need to be defined in a configmap.
Navigate to the Project Settings in the Loft UI. In the Argo CD tab, toggle “Enable SSO Integration”. Enter the URL for your Argo CD instance. In the below dropdown, you can now choose one or more active Argo CD roles.
By using Argo CD and Loft, the lifecycle management of both workloads and infrastructure are abstracted and can be handled via a graphical user interface, making it quicker and easier to understand dependencies and problems inside your system.
With Loft’s Argo CD integration (currently available in beta v3.0), these tools can now interact together seamlessly.
Do you have any feedback or questions for us? Join our Slack community, we’d love to hear from you!