GitOps is quickly gaining popularity as a continuous deployment solution, offering full application and infrastructure management through a Git-based workflow. But on this road to (workflow) riches, organizations quickly encounter two hurdles impeding their GitOps adoption.
First, available GitOps tooling is overwhelmingly Kubernetes-centric. Aside from born-in-the-cloud companies, most organizations rely on a mix of technologies from on-prem and cloud VMs to Kubernetes. Using GitOps to define and deploy applications on Linux VMs is far different from doing so with Kubernetes, burdening developers with the complexity of managing those multiple pipelines. Second, no matter what infrastructure developers deploy applications to, GitOps lacks a centralized portal to help monitor and support those applications.
For organizations facing these GitOps adoption challenges, DevOps teams must find a solution for taking GitOps beyond Kubernetes and do it while sparing developers from sprawling complexity.
Proposed Way to Simplify GitOps Adoption
The following workflow enables GitOps as a developer-friendly approach for deploying applications to any infrastructure, using available open-source tools and new workflow components. The strategy lets organizations define a standard application definition, enabling GitOps tooling like ArgoCD to deploy applications to Kubernetes or Linux-based servers in the same manner.
In addition to this simplicity, developers also gain an Internal Developer Platform (IDP) that simplifies post-deployment application management and support, again regardless of how applications were deployed. The solution further provides the full advantages of GitOps, including features such as drift control to ensure that deployed applications match desired Git-declared states.
GitOps Workflow Components
This strategy here for standardizing application definition in GitOps leverages the following open source and workflow components:
- Shipa Cloud: An application-as-code platform for implementing a standard application definition for any pipeline.
- K8s GitOps cluster: A central GitOps cluster (diagrammed above with ArgoCD and the Shipa provider installed).
- K8s-app1 repo: A sample application repo including an application definition for deploying to Kubernetes with ArgoCD (available on GitHub).
- Sn-app2 repo: Another sample application repo with an application definition for deploying to an Amazon EC2 machine (available on GitHub).
- K8s app cluster: A GKE-hosted Kubernetes cluster, where we’ll deploy the K8s-app1 application.
- EC2 machine: An AWS EC2-hosted Linux server, where we’ll deploy the sn-app2 application.
The K8s App Cluster and EC2 Machine each connect to a Shipa policy framework (if interested, learn more about creating policy frameworks, and binding them to clusters or Linux servers).
Simplifying GitOps With a Standard Application Definition
In this example, we’ll deploy the K8s-app1 application to Kubernetes, and the Sn-app2 application to EC2. Let’s look at each application definition:
You might have noticed some similarities. Aside from the name, team owner, and policy framework, the application definitions are identical.
Now let’s look at the application deployment definitions:
The applications are defined in the same way. This standard application definition empowers DevOps to move between control planes like VMware VMs and Kubernetes, or between clouds switching from EC2 to GCE, with zero impact on developers. This frees developers to focus directly on development while giving DevOps full freedom to introduce new infrastructural advances.
Application Deployment
To begin deploying applications with this approach, you’ll need ArgoCD installed on your cluster. Throughout this example, we’ll use the ArgoCD UI.
Deploying k8s-app1 Application
First, we’ll define a few basic options for the Kubernetes application:
Notice that under Destination, the Cluster URL is https://kubernetes.default.svc, as opposed to telling ArgoCD the exact cluster to deploy the application to. 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 you click the Create button, the ArgoCD dashboard will display the healthy and synced application.
The Shipa Cloud dashboard will also show the application as created and deployed, and offer 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 incident management tools, check logs, and leverage further application management capabilities.
Deploying the sn-app2 application
In the same way, we’ll use the ArgoCD UI to deploy the application for EC2:
Click Create, and this application will show up on the ArgoCD dashboard, healthy and synced.
The sn-app2 application is also now available to manage using the Shipa dashboard.
Conclusion
As this example demonstrates, developers can now deploy and manage applications, in the same way, no matter what underlying infrastructure supports them. Using this workflow strategy, DevOps can implement GitOps without increasing complexity or being tied to Kubernetes tooling. DevOps can in fact utilize whatever architecture components serve them best – for instance, swapping ArgoCD, GKE, and EC2 used in this example for FluxCD, AKS, or other options – while delivering a simple, consistent, efficient experience for developers.
