Argo CD is widely used in native Kubernetes environments to enable not only GitOps workflows, but also help with traditional CI/CD processes be more Cloud Native. Currently, Argo CD only focuses on Kubernetes manifests and leaves other; traditional; components to be managed by a broker (i.e. Crossplane, AMC, etc).
The disadvantage of this approach is that there’s a lot of overhead to run an entire platform for things that could easily be a Terraform script or an Ansible Playbook. Many organizations that are embracing Kubernetes and Cloud Native still need a method to manage/sync non Cloud Native infrastructure with tools made specifically for the Infrastructure-as-Code era.
Argo CD needs a controller to be able to handle such things so Argo CD can handle taking the source of truth (in Git) and using “infrastructure plugins” to apply/run scripts.
The Group/Version Would be: infra.argoproj.io/v1alpha1
The Kind will depend on which provider is being used
My proposal is to refactor this controller (which was a Proof of Concept/Proof of Tech) to be more generic.
Ansible is the natural choice, as it’s been widely adopted by infrastructure administrators and SREs alike. Ansible fits in really well because it also uses YAML for its declarations. Some things that can be used/leveraged
While Argo CD supports deploying Helm charts into releases; it does so by first running “helm template” to produce “raw” YAML. While this is fine for some, other organizations that went “all in” on Helm don't like the fact that helm ls doesn’t work on the cluster and require a more “native” way of interacting with Helm. The idea is to use the Helm Golang library. Some resources:
Terraform is another IaC tool that is widely used and is very popular. Much like Ansible, Terraform has been adopted by Operations and SREs alike. Some resources:
Summary
Argo CD is widely used in native Kubernetes environments to enable not only GitOps workflows, but also help with traditional CI/CD processes be more Cloud Native. Currently, Argo CD only focuses on Kubernetes manifests and leaves other; traditional; components to be managed by a broker (i.e. Crossplane, AMC, etc).
The disadvantage of this approach is that there’s a lot of overhead to run an entire platform for things that could easily be a Terraform script or an Ansible Playbook. Many organizations that are embracing Kubernetes and Cloud Native still need a method to manage/sync non Cloud Native infrastructure with tools made specifically for the Infrastructure-as-Code era.
Argo CD needs a controller to be able to handle such things so Argo CD can handle taking the source of truth (in Git) and using “infrastructure plugins” to apply/run scripts.
The Group/Version Would be:
infra.argoproj.io/v1alpha1The Kind will depend on which provider is being used
My proposal is to refactor this controller (which was a Proof of Concept/Proof of Tech) to be more generic.
Ansible
Ansible is the natural choice, as it’s been widely adopted by infrastructure administrators and SREs alike. Ansible fits in really well because it also uses YAML for its declarations. Some things that can be used/leveraged
Helm
While Argo CD supports deploying Helm charts into releases; it does so by first running “helm template” to produce “raw” YAML. While this is fine for some, other organizations that went “all in” on Helm don't like the fact that
helm lsdoesn’t work on the cluster and require a more “native” way of interacting with Helm. The idea is to use the Helm Golang library. Some resources:Terraform
Terraform is another IaC tool that is widely used and is very popular. Much like Ansible, Terraform has been adopted by Operations and SREs alike. Some resources: