That's it. We explored (soon to be) Jenkinsfile that contains our Continuous Delivery Pipeline and KubernetesPod.yaml that contains the Pod definition that will be used to create Jenkins agents. There are a few other things we need to do but, before we discuss them, we'll change the address and the Docker Hub user in Jenkinsfile.orig, store the output as Jenkinsfile and push the changes to the forked GitHub repository.
We'll use a slightly modified version of Jenkins file. Just as in the previous chapter, we'll add the ocCreateEdgeRouteBuild step that will accomplish the same results as if we'd have NGINX Ingress controller. Please use Jenkinsfile.oc instead of Jenkinsfile.orig in the command that follows.
1 cat Jenkinsfile.orig
2 | sed -e "[email protected]@$ADDR@g"
3 | sed -e "s@vfarcic@$DH_USER@g"
4 | tee Jenkinsfile
5
6 git add .
7
8 git commit -m "Jenkinsfile"
9
10 git push
Since we are into running Git commands, we might just as well merge your jenkins-shared-libraries fork with the upstream/master.
That will ensure that you have the latest version that includes potential changes I might have made since the time you forked the repository.
1 cd ..
2 3 git clone https://github.com/$GH_USER/jenkins-shared-libraries.git
4 5 cd jenkins-shared-libraries
6 7 git remote add upstream 8 https://github.com/vfarcic/jenkins-shared-libraries.git
9 10 git fetch upstream
11 12 git checkout master
13 14 git merge upstream/master
15 16 cd ../go-demo-5
We're almost ready to create a Jenkins pipeline for go-demo-5. The only thing missing is to create a new Kubernetes Cloud configuration.
For now, we have only one Kubernetes Cloud configured in Jenkins. Its name is kubernetes. However, the pipeline we just explored uses a cloud named go-demo-5-build. So, we should create a new one before we create jobs tied to the go-demo-5 repository.
1 open "http://$JENKINS_ADDR/configure"
Please scroll to the bottom of the page, expand the Add a new cloud list, and select Kubernetes. A new set of fields will appear.
Type go-demo-5-build as the Name. It matches the cloud entry inside kubernetes block of our pipeline.
Next, type go-demo-5-build as the Kubernetes Namespace.
Just as with the other Kubernetes Cloud that was already defined in our Jenkins instance, the value of the Jenkins URL should be http://prod-jenkins.prod:8080, and the Jenkins tunnel should be set to prod-jenkins-agent.prod:50000.
Don't forget to click the Save button to persist the changes.
Right now, we have two Kubernetes Clouds configured in our Jenkins instance. One is called kubernetes, and it uses the prod Namespace, while the other (the new one) is called go-demo-5-build and it can be used for all the builds that should be performed in the go-demo-5-build Namespace.
Even though we have two Kubernetes Clouds, their configurations are almost the same. Besides having different names, the only substantial difference is in the Namespace they use. I wanted to keep it simple and demonstrate that multiple clouds are possible, and often useful. In the "real world" situations, you'll probably use more fields and differentiate them even further. As an example, we could have defined the default set of containers that will be used with those clouds.
Now we're ready to create a job that will be tied to the go-demo-5 repository and validate whether the Pipeline defined in the Jenkinsfile works as expected.
We'll create our job from the BlueOcean home screen.
1 open "http://$JENKINS_ADDR/blue/organizations/jenkins/"
Please click the Create a New Pipeline button and select GitHub as the repository type. Type Your GitHub access token and click the Connect button. A moment later, you'll see the list of organizations that token belongs to. Select the one where you forked the applications. The list of repositories will appear. Select go-demo-5 and click the Create Pipeline button.
Jenkins will create jobs for each branch of the go-demo-5 repository. There is only one (master), so there will be one job in total. We already explored in the previous chapter how Jenkins handles multiple repositories by creating a job for each, so I thought that there is no need to demonstrate the same feature again. Right now, master job/branch should be more than enough.
Please wait until the build is finished.
Since the build was executed against the master branch, the when condition inside the release stage evaluated to true so the production-ready image was pushed to Docker Hub and the Helm Chart with the updated tag was pushed to ChartMuseum. We'll check the latter by retrieving the list of all the Charts.
1 curl "http://cm.$ADDR/index.yaml"
The output is as follows.
apiVersion: v1 entries: go-demo-5: - apiVersion: v1 created: "2018-08-08T20:47:34.322943263Z" description: A silly demo based on API written in Go and MongoDB digest: a30aa7921b890b1f919286113e4a8193a2d4d3137e8865b958acd1a2bfd97c7e home: http://www.devopstoolkitseries.com/ keywords: - api - backend - go - database - mongodb maintainers: - email: [email protected] name: Viktor Farcic name: go-demo-5 sources: - https://github.com/vfarcic/go-demo-5 urls: - charts/go-demo-5-0.0.1.tgz version: 0.0.1 generated: "2018-08-08T21:03:01Z"
We can see that we have only one chart (so far). It is the go-demo-5 chart. The important thing to note is the version of the chart. In that output, it's 0.0.1. However, I might have bumped it later since I wrote this text, so your version might be different. We'll need that version soon, so let's put it into an environment variable.
1 VERSION=[...]
Please make sure to change [...] with the version you obtained earlier from index.yaml.
Among other things, the build modified the Chart before pushing it to ChartMuseum. It changed the image tag to the new release.
We'll add ChartMuseum as a repository in our local Helm client so that we can inspect the Chart and confirm that image.tag value is indeed correct.
1 helm repo add chartmuseum 2 http://cm.$ADDR
3
4 helm repo list
The output of the latter command is as follows.
NAME URL stable https://kubernetes-charts.storage.googleapis.com local http://127.0.0.1:8879/charts chartmuseum http://cm.18.219.191.38.nip.io
You might have additional repositories configured in your local Helm client. That's not of importance. What matters right now is that the output showed chartmuseum as one of the repositories.
Now that we added the new repository, we should update local cache.
1 helm repo update
Finally, we can inspect the chart Jenkins pushed to ChartMuseum.
1 helm inspect chartmuseum/go-demo-5 2 --version $VERSION
The output, limited to relevant parts, is as follows.
... version: 0.0.1 ... image: tag: 18.08.08-3 ...
We can see that the build modified the image.tag before it packaged the Chart and pushed it to ChartMuseum.
The first build of our continuous delivery pipeline was successful. However, the whole process is still not finished. We are yet to design the process that will allow us to choose which release to deploy to production. Even though our goal is to let Jenkins handle deployments to production, we'll leave it aside for a while and first explore how we could do it manually from a terminal.
Did I mention that we'll introduce GitOps to the process?