CI/CD with Jenkins-x on your existing (GKE) cluster — ruby on rails application

Introduction

Jenkins X is a CI/CD platform for Kubernetes. This post is a practical approach to get Jenkins-X working on an existing Google Kubernetes Engine cluster.

Jenkins-X is based on helm. Its better to ensure helm and jx works from your shell. In case if you don’t, just get them installed from their respective github pages releases section. Also, ensure that helm works on your cluster before setting up Jenkins-x.

This post assumes that you have a running GKE cluster and does not cover creating a fresh Jenkins-X kubernetes cluster. If you don’t have one, create one on a free tier account, just a few clicks away.

Install Jenkins-X on your cluster (jx install)

If you already have a Jenkins-X cluster setup on GKE, ensure you have atleast 3 nodes (6 vCPUs) and skip this section.

Note: You should have atleast 3nodes (6 vCPUs) in your GKE cluster.

Runjx install and select the relevant options to get the Jenkins-X initialised on your kubernetes cluster.

This step does the following things:

1. Deploys tiller , an ingress controller with external loadbalancer.
2. Installs jenkins-x-platform to your kubernetes cluster helm repo which brings a ton of resources configMaps , deployments , services etc.
3. Creates two repositories each for staging and production in git and creates pipelines for each of those in jenkins.

Now we have the setup ready to perform CI/CD for any project with our jenkins-x cluster.

Prepare the rails project

Get the rails application which you want to perform CI/CD. This does not even have to be rails, it can be any web application. You can either clone your existing application or generate a new one from scratch with rails new <app>. For the sake of simplicity, I will create a new application.

Import your project into Jenkins-X

Run jx import <path to app> command to get your project imported.

This step does the following:

1. Copies the needed Helm charts, Jenkinsfile, Dockerfile from templates if they do not exist in the repository.
2. Creates Jenkins projects and pipelines for master branch and creates web-hook which triggers the jenkins job.
3. Creates a pull request PR-1, runs checks, merges and creates the first release 0.0.1 to master.
4. This is then promoted to staging and you can view how staging environment looks.

The command exists leaving things to run in the background. One can follow the activities, logs etc. from the commands above. E.g. jx get activity looks like this:

Check the status of the application with jx get app .

Grab the url of the staging environment and take a look. Mine looks like this:

Looks good, now its time to promote it to production, do it with jx promote <app> .

Repeat the jx get app and check if the production url works. Great! Now its time to make a change and see how that fits our GitOps work flow.

Update and publish our welcome page

Lets get to the application and create a welcome branch and create a welcome controller

Lets make a welcome message with user name and make it as default page. Modifying controller, view and routes.

Test it locally with rails server command on your shell. If it looks good, then git push the welcome branch.

And then create a pull request from the ui . Mine was github and hence I will click this button.

Now a new PR pipeline kicks in and validates the changes and creates a preview environment which you can see from the pull request from the ui . From the pull request, you can see this.

On clicking that link,

Alright, looks good, I would like to merge this PR, which takes this to staging . The activities and logs can all the time be followed with jx get build logs and jx get activity . After the logs and activity ends successfully, check the app status again.

Check the staging env and then promote it to production with jx promote like before if it looks okay and refresh the production url and voila !

Now we deployed a change from desktop to staging to production with few commands. And all the configs saved in version control. Thats GitOps for you !

Quick recap

1. Installed jenkins-x to an existing GKE cluster with jx install
2. Imported a project into our jenkins-x cluster with jx import
3. Promoted the project to production with jx promote
4. Made a change, tested it locally, pushed the change as a branch, created pull request, Jenkins-X automatically created preview environment for previewing.
5. Accepted the PR to get that automatically to staging for testing.
6. Ran a jx promote to promote our new version from staging to production.

Usual errors

Click to visit the gist to see the resolution (embedding limitation)

Platform versions

Acknowledgements

Excellent support from James Strachen and James Rawlings and other jx community members. I got round the clock (24x7) support from these expert in Slack #jenkins-x-user and #jenkins-x-dev channels. Hats-off for those guys !

References

1. Installing helm on GKE cluster, a quick hands-on — https://medium.com/@maniankara/helm-on-gke-cluster-quick-hands-on-guide-ecffad94b0
2. Jenkins documentation — https://jenkins-x.io/documentation/
3. https://jenkins-x.io/articles/