Argo Flux vs Harness - Filming My Journey
Around KubeCon North America 2019, two open source projects with similar goals— Argo and Flux— decided to form a partnership, creating Argo Flux. Reading the press brief from Intuit, Argo hails from Applatix, which was acquired by Intuit. Flux hails from Weaveworks's product called Weaveworks Cloud, which became its own project as Flux gained traction.
As GitOps practices started to come to light, Argo, Flux, and Jenkins X were toolings created to assist in the GitOps mantra. Last year I was on a New Stack Maker’s Podcast with Weaveworks discussing the current state of GitOps. My opinion differed from the strict definition prescribed by Weaveworks which had an investment in Flux, e.g. you must be using Git, Kubernetes, and infrastructure as code.
At the time of filming, the projects are still merging and learning from each other. There is not a single project or product called “Argo Flux” — it is more like Argo or Flux. The first dip in the pool together for both projects is the GitOps Engine. I had to pick either Argo or Flux as a starting point, and I went with Argo. For your own journey take a look over the taxonomy Argo uses. Similar to our posts taking a dive into Spinnaker and Jenkins X, I wanted to take a look at Argo; I had an awaiting Amazon EKS Kubernetes Cluster to leverage. The video is about 50-minutes long for a basic install. I was able to get Nginx deployed from zero to deployed, including installing a Harness Delegate into my EKS cluster in about 5 minutes at the end of the video.
My Argo [and/or] Flux Journey
I filmed the video over two nights which gave me some time off camera to absorb what I was doing.
Methodology
Deploying an image is a good starting point for many people along their journey. Depending on existing development methodologies, moving to a completely GitOps based approach can be difficult. Leveraging a Pull Request to start or end the orchestration does have a learning curve to how your projects should be structured. If you have a greenfield project this is easier than having existing artifacts and processes.
Argo compared to the other GitOps open source tooling I used was easier to install. I did run into an issue when trying to structure my project in GitHub which the answer box aka Google brought me to the issue which wasn’t clear in the documentation on how to actually get started.
The target deployment for Argo like Flux is Kubernetes. After some playing around, I did not have to leverage a package/configuration management tool like Helm or Kustomize to force my projects to conform to these tools.
Some challenges I would anticipate would be you are enabled and limited by Kubernetes. Looking at additional Argo projects such as Argo Rollouts as expected would change your Kubernetes cluster to leverage. Per the opinion of Argo Rollouts that in your deployment YAMLs will be Rollout steps. I captured my steps below to enable you to get to my stopping point.
My Steps
##Argo Flux Commands
#Install on K8s Cluster
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
#Install CLI
brew tap argoproj/tap
brew install argoproj/tap/argocd
#Expose Service
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'
#Get Service
kubectl get service -n argocd argocd-server
#external ip: dns.us-east-1.elb.amazonaws.com
#CLI Log-in
kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o name | cut -d'/' -f 2
#pw:argocd-server-84b4bb5dd5-npn59
argocd login dns.us-east-1.elb.amazonaws.com
#Update PW
argocd account update-password
#pw:ravi1234
#Get and Sync Application
argocd app get guestbook
argocd app sync guestbook
#Delete Application
argocd app delete guestbook --cascade
Harness Platform with you before, during, and after GitOps
A big draw to the Harness Platform is that we are pretty unopinionated around the infrastructure you deploy to. You don’t have to be leveraging a Git + infrastructure as code + compliant Kubernetes Cluster to leverage Harness. Taking the initial plunge into Harness is pretty easy, as we cover a wide swath of infrastructure and methodologies around how you produce and promote artifacts.
Harness does support a GitOps model, with as stringent of a definition as you and your organization is comfortable with. Leveraging the trifecta of Git + infrastructure as code + Kubernetes is certainly supported. Though, here's some food for thought— what if you are deploying to Amazon ECS or deploying an Amazon AMI or even a virtual machine?
The Harness Platform can certainly be a convention-based conduit to orchestrate all the confidence-building steps and to deploy to a wide swatch of infrastructure. Getting started with Harness is incredibly easy, sign up for a trial today and be ready to rock in moments.
Cheers!
-Ravi