Key takeaways:
The fundamental objective of DevOps is to facilitate self-service capabilities and foster collaboration between developers and operators. By integrating Crossplane within a GitOps framework, both groups now share a unified language for communication.
This eliminates the necessity for disparate workflows that might cause confusion for either party. Embracing a unified workflow for both infrastructure and applications truly embodies the ethos of DevOps.
GitOps and Terraform
The core tenets of GitOps encompass:
- The system’s configuration is articulated in a declarative manner, typically realized through Kubernetes manifests.
- The system’s definition is versioned and subjected to audit trails, typically stored within Git repositories.
- An automated software agent regularly fetches the state from Git and aligns it with the platform’s current state, commonly achieved through tools like Flux or ArgoCD.
- Continuous reconciliation ensures that any alterations made in Git are promptly mirrored within the system. Git serves as the authoritative source of truth in this context.
If you’re familiar with Terraform, you likely understand the challenges of applying GitOps to the Terraform CLI. Terraform meets the first requirement by utilizing a declarative format. However, it falls short in fulfilling the other three GitOps principles related to Git storage, automated reconciliation, and bidirectional synchronization.
Once Terraform completes its execution, it disengages from the system. Therefore, if you manually remove a resource, such as a Virtual Machine created by Terraform, the vanilla Terraform setup remains unaware of the change. Additionally, Terraform maintains its own state, which differs entirely from the definition files stored in Git.
Initially, integrating GitOps with infrastructure might seem complex. It becomes evident that to meet GitOps prerequisites, additional layers need to be incorporated atop vanilla Terraform.
However, there’s a newcomer on the scene: Crossplane!
GitOps and Crossplane
Crossplane offers capabilities akin to Terraform in creating infrastructure, yet it stands out with significant distinctions:
- Crossplane operates as a Kubernetes application, allowing it to generate various types of infrastructure.
- Definitions within Crossplane are Kubernetes manifests, aligning seamlessly with Kubernetes-native practices.
- Users have the flexibility to leverage manifests describing resources from popular cloud providers or craft custom resources tailored to their specific needs.
As a simple example here is an EC2 instance described in Crossplane:
apiVersion: ec2.aws.crossplane.io/v1alpha1 kind: Instance metadata: name: ec2-instance spec: forProvider: region: us-east-1 imageId: ami-0d23d3e4c0f9ebd1843 securityGroupRefs: - name: ex-cluster-sg subnetIdRef: name: sample-subnet1 providerConfigRef: name: example
The crucial aspect here is that the provided file adheres to the standard Kubernetes manifest format. Consequently, you can:
- Deploy it using
kubectl
. - Validate its syntax and structure using manifest verification tools like kubeval or kube-linter.
- Utilize templating functionalities with Helm or Kustomize.
- Employ any tool within the Kubernetes ecosystem for reading, managing, or storing it.
Given its standard manifest format, you can effortlessly store it in Git and manage it seamlessly with ArgoCD, enabling a comprehensive GitOps workflow. This capability holds immense significance.
By integrating ArgoCD with Crossplane, you establish a comprehensive solution for applying GitOps principles not just to applications but also to infrastructure. Envision having this capability directly accessible within your ArgoCD dashboard.