GitOps is rapidly gaining popularity as a continuous implementation solution that offers full application and infrastructure management through a Git-based workflow. But on this path to (workflow) wealth, organizations quickly encounter two obstacles that prevent their GitOps adoption.
First, the available GitOps tool is overwhelmingly Kubernetes-centric. Aside from “born-in-the-cloud” companies, most organizations rely on a mix of technologies from on-prem and cloud worlds to Kubernetes. Using GitOps to define and implement applications on Linux VMs is very different from doing so with Kubernetes, which puts developers at the complexity of managing these multiple pipelines. Second, no matter what infrastructure developers implement applications for, GitOps lacks a centralized portal to help monitor and support those applications.
For organizations facing these GitOps adoption challenges, DevOps teams need to find a solution to take GitOps beyond Kubernetes and do so while sparing developers from extensive complexity.
Proposed way to simplify GitOps adoption
The following workflow enables GitOps as a developer-friendly approach to implementing applications for any infrastructure using available open source tools and new workflow components. The strategy allows organizations to define a standard application definition, enabling GitOps tools like ArgoCD to implement applications to Kubernetes or Linux-based servers in the same way.
In addition to this simplicity, developers also get an Internal Developer Platform (IDP) that simplifies administration and support after implementation, again regardless of how applications were implemented. The solution further provides the full benefits of GitOps, including features such as operational control to ensure that implemented applications match desired Git-declared modes.
GitOps Workflow Components
This strategy here for standardizing application definition in GitOps utilizes the following open source and workflow components:
- Shipa Cloud: An application-as-a-code platform for implementing a standard application definition for any pipeline.
- K8s GitOps cluster: A central GitOps cluster (diagram above with ArgoCD and Shipa provider installed).
- K8s-app1-repo: An example of application repo including an application definition for rollout to Kubernetes with ArgoCD (available on GitHub).
- Sn-app2-repo: Another example of application-repo with an application definition for implementation on an Amazon EC2 machine (available on GitHub).
- K8s app cluster: A GKE-hosted Kubernetes cluster where we will implement the K8s app1 application.
- EC2 machine: An AWS EC2-hosted Linux server where we will implement the sn-app2 application.
K8’s App Cluster and EC2 Machine each connect to a Shipa policy framework (if you are interested, you can learn more about creating policy frameworks and binding them to clusters or Linux servers).
Simplification of GitOps with a standard application definition
In this example, we will implement the K8s app1 application for Kubernetes and the Sn-app2 application for EC2. Let’s look at each application definition:
You may have noticed some similarities. Apart from the name, the team owner and the policy framework, the application definitions are identical.
Let’s now look at the application implementation definitions:
The applications are defined in the same way. This standard application definition allows DevOps to move between control plans such as VMware VMs and Kubernetes or between clouds switching from EC2 to GCE without affecting the developers. This frees developers to focus directly on development while giving DevOps full freedom to introduce new infrastructural advances.
To start implementing applications with this approach, you need to have ArgoCD installed on your cluster. Throughout this example, we will be using the ArgoCD UI.
Implementation of k8s-app1 application
First, we will define a few basic options for the Kubernetes application:
Note that under Destination, Cluster URL is https: //kubernetes.default.svc, as opposed to telling ArgoCD the exact cluster to which the application should be implemented. This is because ArgoCD communicates locally with the Shipa provider via API requests, eliminating any need to configure different clusters or different ArgoCD instances for multiple clusters.
After clicking the Create button, the ArgoCD dashboard displays the sound and synchronized application.
The Shipa Cloud dashboard also displays the application as created and implemented and offers robust information for application management.
With absolutely no knowledge of Kubernetes or the application’s underlying infrastructure, developers can use this dashboard to view application lifecycle information, connect the application to event management tools, check logs, and take advantage of additional application management features.
Implementation of the sn-app2 application
In the same way, we will use the ArgoCD UI to implement the application for EC2:
Click Create and this application will appear on the ArgoCD dashboard, healthy and in sync.
The sn-app2 application is now also available to manage using the Shipa dashboard.
As this example shows, developers can now implement and manage applications in the same way, regardless of the underlying infrastructure that supports them. Using this workflow strategy, DevOps can implement GitOps without increasing complexity or being tied to Kubernetes tools. DevOps can actually use the architectural components that serve them best – for example, by swapping ArgoCD, GKE and EC2 used in this example for FluxCD, AKS or other options – while providing a simple, consistent, efficient experience for developers.