The DevOps 2.4 Toolkit

Viktor Farcic

• Publisher: Packt Publishing
• Year: 2019
• ISBN:
  9781838648787
• Edition: 1
• Topic: Computer Science
• Subtopic: Software Development
• Index: Computer Science

An exploration of continuous deployment to a Kubernetes cluster, using a wide range of Kubernetes platforms with instructions on how to develop a pipeline on a few of the most commonly used CI/CD platforms.Key Features• The fifth book of DevOps expert Viktor Farcic's bestselling DevOps Toolkit series, with a discussion of the difference between continuous delivery vs. continuous deployment, and which is best for the user• Guides readers through the continuous deployment process using Jenkins in a Kubernetes cluster• Provides an overview of the best practices for building, testing, and deploying applications through fully automated pipelines.Book DescriptionBuilding on The DevOps 2.3 Toolkit: Kubernetes, Viktor Farcic brings his latest exploration of the Docker technology as he records his journey to continuously deploying applications with Jenkins into a Kubernetes cluster.The DevOps 2.4 Toolkit: Continuously Deploying Applications with Jenkins to a Kubernetes Cluster is the latest book in Viktor Farcic's series that helps you build a full DevOps Toolkit. This book guides readers through the process of building, testing, and deploying applications through fully automated pipelines.Within this book, Viktor will cover a wide-range of emerging topics, including an exploration of continuous delivery and deployment in Kubernetes using Jenkins. It also shows readers how to perform continuous integration inside these clusters, and discusses the distribution of Kubernetes applications, as well as installing and setting up Jenkins.Work with Viktor and dive into the creation of self-adaptive and self-healing systems within Docker.What you will learn• Gain an understanding of continuous deployment• Learn how to build, test, and deploy applications into Kubernetes• Execute continuous integration inside containersWho this book is forReaders with an intermediate level understanding of Kubernetes and hands-on experience.

Installing and Setting Up Jenkins

When used by engineers, UIs are evil. They sidetrack us from repeatability and automation.

UIs do have their purpose. They are supposed to provide enough colors and random graphs for CIO, CTO, and other C-level executives and mid-level managers. Management works in multi-color, while engineers should be limited to dual-color terminals, mixed with a slightly increased color pallet of IDEs and editors we use to code. We produce commits, while managers fake interest by looking at UIs.

The preceding phrase is a bit exaggerated. It's not true that UIs are useful only to managers nor that they fake interest. At least, that's not true for all of them. UIs do provide a lot of value but, unfortunately, they are often abused to the level of even postponing or even preventing automation. We'll try to make an additional effort to remove Jenkins UI for any setup related tasks. We'll try to automate everything.

We already improved a lot our ability to install Jenkins. A mere switch from custom-made YAML files to Helm Charts is a considerable step forward from the operational perspective. The addition of ServiceAccounts bound to Roles improved security. But, there's still one big thing left only partly explored. We did not yet reach the point where we can install and fully setup Jenkins from a command line. So far, there were always a few things we had to do manually from its UI. We'll try to get rid of those steps in the hope that the only command we'll need to execute is helm install.

As it often goes, we cannot hope to fully automate the setup without going through manual steps first. So, we'll start by exploring different use-cases. If we hit a road-block, we'll try to figure out how to overcome it. The chances are that another one will be waiting for us after the first, and another one after that.

We're yet to see which obstacles we'll encounter and which steps are missing until we make Jenkins fully operational and, at the same time, reasonably secure. We'll try to automate the process only once we're confident in the way we set up Jenkins manually.

Creating a Cluster and retrieving its IP

You already know what the first steps are. Create a new cluster or reuse the one you dedicated to the exercises.

We'll start by going to the local copy of the vfarcic/k8s-specs repository and making sure that we have the latest revision.

All the commands from this chapter are available in the 06-jenkins-setup.sh (https://gist.github.com/vfarcic/4ea447d106c96cb088bc8d616719f6e8) Gist.

 1 cd k8s-specs
 2 3 git pull

We'll need a few files from the go-demo-3 repository you cloned in one of the previous chapters. To be on the safe side, please merge it the upstream. If you forgot the commands, they are available in the go-demo-3-merge.sh gist (https://gist.github.com/vfarcic/171172b69bb75903016f0676a8fe9388).

The requirements are the same as those from the previous chapters. The only difference is that I will assume that you'll store the IP of the cluster or the external load balancer as the environment variable LB_IP.

For your convenience, the Gists and the specs are available as follows. Please note that they are the same as those we used in the previous chapter with the addition of the export LB_IP command.

• docker4mac-ip.sh: Docker for Mac with 3 CPUs, 3 GB RAM, with nginx Ingress, with tiller, and with LB_IP variable set to 127.0.0.1 (https://gist.github.com/vfarcic/66842a54ef167219dc18b03991c26edb).
• minikube-ip.sh: minikube with 3 CPUs, 3 GB RAM, with ingress, storage-provisioner, and default-storageclass addons enabled, with tiller, and with LB_IP variable set to the VM created by minikube (https://gist.github.com/vfarcic/df5518b24bc39a8b8cca95cc37617221).
• kops-ip.sh: kops in AWS with 3 t2.small masters and 2 t2.medium nodes spread in three availability zones, with nginx Ingress, with tiller, and with LB_IP variable set to the IP retrieved by pinging ELB's hostname. The Gist assumes that the prerequisites are set through Appendix B (https://gist.github.com/vfarcic/7ee11f4dd8a130b51407582505c817cb).
• minishift-ip.sh: minishift with 3 CPUs, 3 GB RAM, with version 1.16+, with tiller, and with LB_IP variable set to the VM created by minishift (https://gist.github.com/vfarcic/fa902cc2e2f43dcbe88a60138dd20932).
• gke-ip.sh: Google Kubernetes Engine (GKE) with 3 n1-highcpu-2 (2 CPUs, 1.8 GB RAM) nodes (one in each zone), and with nginx Ingress controller running on top of the "standard" one that comes with GKE, with tiller, and with LB_IP variable set to the IP of the external load balancer created when installing nginx Ingress. We'll use nginx Ingress for compatibility with other platforms. Feel free to modify the YAML files and Helm Charts if you prefer NOT to install nginx Ingress (https://gist.github.com/vfarcic/3e53def041591f3c0f61569d49ffd879).
• eks-ip.sh: Elastic Kubernetes Service (EKS) with 2 t2.medium nodes, with nginx Ingress controller, with a default StorageClass, with tiller, and with LB_IP variable set to the IP retrieved by pinging ELB's hostname (https://gist.github.com/vfarcic/f7f3956cd39c3bc55638529cfeb2ff12).

Now we're ready to install Jenkins.

Running Jenkins

We'll need a domain which we'll use to set Ingress' hostname and through which we'll be able to open Jenkins UI. We'll continue using nip.io service to generate domains. Just as before, remember that this is only a temporary solution and that you should use "real" domains with the IP of your external load balancer instead.

 1 JENKINS_ADDR="jenkins.$LB_IP.nip.io"
 2 3 echo $JENKINS_ADDR

The output of the latter command should provide a visual confirmation that the address we'll use for Jenkins looks OK. In my case, it is jenkins.52.15.140.221.nip.io.

A note to minishift users
Helm will try to install Jenkins Chart with the process in a container running as user 0. By default, that is not allowed in OpenShift. We'll skip discussing the best approach to correct the issue, and I'll assume you already know how to set the permissions on the per-Pod basis. Instead, we'll do the most straightforward fix. Please execute the command that follows to allow the creation of restricted Pods to run as any user.
oc patch scc restricted -p '{"runAsUser":{"type": "RunAsAny"}}'

We'll start exploring the steps we'll need to run Jenkins in a Kubernetes cluster by executing the same helm install command we used in the previous chapters. It won't provide everything we need, but it will be a good start. We'll improve the process throughout the rest of the chapter with the objective of having a fully automated Jenkins installation process. We might not be able to accomplish our goal 100%. Or, we might conclude that full automation is not worth the trouble. Nevertheless, we'll use the installation from the Chapter 4, Packaging Kubernetes Applications as the base and see how far we can go in our quest for full automation.

 1 helm install stable/jenkins \ 2  --name jenkins \ 3 --namespace jenkins \ 4 --values helm/jenkins-values.yml \ 5 --set master.hostName=$JENKINS_ADDR

Next, we'll confirm that Jenkins is rolled out.

 1 kubectl -n jenkins \ 2  rollout status deployment jenkins

The latter command will wait until jenkins deployment rolls out. Its output is as follows.

Waiting for rollout to finish: 0 of 1 updated replicas are available... deployment "jenkins" successfully rolled out

A note to minishift users
OpenShift requires Routes to make services accessible outside the cluster. To make things more complicat...