Jenkins X vs Harness - Filming my Journey
Jenkins is one of the most influential tools in the DevOps movement in the last decade. Hailing from Hudson, Jenkins has ushered in Continuous Integration to the masses. Though pundits might refer to Jenkins as the “DevOps Duct Tape” meaning if you have Jenkins, you check the box for DevOps. As the DevOps movement continues to mature, DevOps is certainly not one tool and a culmination of people, process, and technology.
The Jenkins Platform ecosystem continues to evolve as any popular software platform would. About a year ago I gave commentary to The New Stack around perceived confusion of the different distributions of Jenkins. Though I never dipped my toes into Jenkins X until now. Similarly to the video journey we did around Spinnaker vs Harness, a fresh pair of eyes looking to leverage Jenkins X for the first time.
I am pretty familiar with Jenkins but have not been hands-on with more stringent GitOps concepts/definitions which are represented in Jenkins X. Prepping for your own look at Jenkins X, look at the Jenkins X Concepts prior to getting started. I had a simple goal to deploy an Nginx image from Docker Hub on an awaiting Amazon EKS Kubernetes cluster. The video is a little over 90 minutes in length. After navigating some installation complexity where I had to downgrade versions of Helm and kubectl I had on my machine, I waved the white flag. 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.
Let’s Get to Jenkins X’in
Without further ado, here is the video. Yes, I had a green shirt on for our team’s virtual St. Patrick’s day celebration.
Methodology
Being in the distributed systems/platform engineering world for a while, low hanging fruit for a test process is to just deploy Nginx these days. I am a fan of using Amazon EKS for a Kubernetes Cluster as I can spin one up pretty fast with EKSCTL.
I have the ability to spin up AWS resources as needed and as an administrator make sure IAM roles, etc are in place. Used the answer box aka Google to find answers and leveraged documentation from the Jenkins X Project and CloudBees.
I first started running into some hurdles with having Helm V3 and kubectl 1.17.4 on my MacBook Pro. Per the JX Installer I needed to downgrade to Helm V2 and a kubectl version less than 1.17.0 which in time would certainly mature. The second hurdle I ran into was my EKS Cluster name had upper case characters as I am a fan of camel case. The JX Installer scripts would change the jx-requirements.yml with a lower case cluster name. With the lower case cluster name, the AWS CLI could not find the cluster as the AWS EKS CLI is case sensitive.
Those hurdles were overcome though since I was starting from scratch and had administrator-level access to my AWS Account, local machine, and GitHub repository. What got me was the learning curve for a stringent GitOps model. If the project I was working was greenfield and we purpose-built the project to mold well to a GitOps model, then more of the moving parts would make sense.
The Jenkins X project is changing by leveraging Tekton as the pipeline engine which was news to me. I did not attempt to more of a difficult deployment e.g a canary deployment to lessen the learning curve on Jenkins X and now Tekton. Thank goodness that CloudBees recently created a beta UI so I could see all of the pipeline steps that were being run in a quickstart. Listing my steps to get you to where I was in my Jenkins X journey.
My Steps
Before you spin up resources, make sure to take a look over the Jenkins X Components and a diagram from the project. I went through the Jenkins X Getting Started guide and Quickstart to the best of my ability never seeing the guide before. I included some helper items if you are like me and had newer versions of Helm and kubectl. Also including the EKSCTL parameters when creating and deleting an EKS cluster.
#Jenkins X Steps
#CLI Install for Mac OS
brew install jenkins-x/jx/jx
#Get Installables
jx boot
#Configure AWS Cloud Provider for Install
#https://jenkins-x.io/docs/getting-started/setup/boot/clouds/amazon/
#jx-requirements.yml
clusterConfig:
provider: eks
cluster:
clusterName: deploy-to-me
#Install HelmV2 [and remove HelmV3]
#https://medium.com/@Joachim8675309/install-helm3-helm2-on-macos-d65f61509799
brew uninstall helm
brew install helm@2
echo 'export PATH="/usr/local/opt/helm@2/bin:$PATH"' >> ~/.bash_profile
helm init
#Remove KubeCTL and install earlier version [prior to 1.17.0]
#https://www.benpickles.com/articles/72-downgrading-kubectl-with-homebrew
#https://github.com/kubernetes/kubectl/releases
brew uninstall --ignore-dependencies kubectl
curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.16.8/bin/darwin/amd64/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
kubectl version --client
#Reset Kubeconfig
aws eks --region us-east-1 update-kubeconfig --name deploy-to-me
kubectl get ns
#Run jx boot
cd jenkins-x-boot-config/
jx boot
#Generate a Git Bot Token
https://github.com/settings/tokens/new?scopes=repo,read:user,read:org,user:email,write:repo_hook,delete_repo
#Install Jenkins X UI
#https://docs.cloudbees.com/docs/cloudbees-jenkins-x-distribution/latest/user-interface/install
jx add app jx-app-ui --version 0.1.49
#Merge PR
https://github.com/repo/environment-deploy-to-me-dev/pull/1
#Launch a Quickstart
jx create quickstart -f http
#name: jenkins-x-quickstart
#Check on Quickstart
jx get activity -f jenkins-x-quickstart -w
#Helper Methods
eksctl create cluster \
--name deploy-to-me \
--version 1.15 \
--region us-east-1 \
--nodegroup-name standard-workers \
--node-type t3.xlarge \
--nodes 2 \
--nodes-min 1 \
--nodes-max 3 \
--node-ami auto
eksctl delete cluster --name=deploy-to-me --region=us-east-1
Looking Forward
At the end of the video, I decided to fire up a rapid Harness Workflow and directly execute the Workflow in our Harness Community Edition. I am a big fan of what Jenkins has done for the DevOps movement and was excited to get my hands on Jenkins X. With any new tool complexity will be there as the practice and paradigm continues to evolve around GitOps. When looking at a new paradigm such as GitOps, fighting the learning curve on a tool and methodology is a double whammy which makes learning even more difficult.
Watching a JavaZone video and reading through a DZone Article around Jenkin X’s canary approach felt limited to the stack and the confidence I had in my Jenkins X installation was not all there to attempt. At Harness, we take a wide swath of approaches e,g on and off of the GitOps maturity model to bring Continous Delivery to you no matter where you are in your journey. You do not have to be leveraging the latest CNCF stack to gain value from Harness. Simplify your delivery level of effort with the Harness Software Delivery Platform and sign up today!
Cheers,
-Ravi