Continuous Delivery in Kubernetesland
This repository contains all code related to the training Continuous Delivery in Dockerland by Nicolas Byl. In this session we will provide a step-by-step demo how to build a continuous delivery pipeline running on kubernetes.
Lab 0: Prerequisites
To have this running on your machine, you will need the following tools:
You will also need a virtualization that is supported by minikube. This tutorial has been tested on VirtualBox
Lab 1: Setup
Kubernetes
First of all initialize your kubernetes cluster with minikube:
minikube addons enable dashboard
minikube addons enable ingress
minikube start --memory 4096
Maybe, you will have to select your VM driver using --vm-driver
. To see your available options, please refer to minikube start --help
.
After the cluster has been started, verify your installation with:
kubectl cluster-info
The ip of your minikube VM can be found using:
minikube ip
Update: If you want to download the docker images on high-speed connection now, you can issue the following command:
minikube ssh 'gcr.io/kubernetes-helm/tiller:v2.8.1 nbyl/jenkins-slave-docker-image-build:3.10-2 java:8 postgres:9.5.4 jenkins/jenkins:lts jenkins/jnlp-slave:3.10-1; do docker pull $i; done'
Helm
Initialize helm using it's init command:
helm init
When the server component tiller is ready, you can view a list of your (not yet existing) applications with:
helm list
Jenkins
Now that helm and kubernetes are ready, we can install Jenkins using the a helm command:
helm install stable/jenkins --set Agent.Memory=1024Mi,Persistence.StorageClass=standard --name=cd
To open jenkins in your brower simply use minikube:
minikube service cd-jenkins
The user to login is admin
and the password can be found the command given by the output of helm install ...
earlier.
Lab 2: Continuous Integration
Lab 2.1: Create your first build pipeline
Create a new pipeline job for our project:
- Click on "New Item" and enter the name of the project "confy"
- As a type select "Pipeline" and click on "OK"
- Configure the following job options:
- "Build Triggers" → "Poll SCM" → "* * * * *"
- "Pipeline"
- "Definition": "Pipeline from SCM"
- "SCM": "Git"
- "Repository URL": "https://github.com/nbyl/cd-workshop-demo.git"
Afterwards you can click on "Save" and "Build Now" to start your first pipeline run. Congratulations, your pipeline is setup now.
Lab 2.2: Cache your dependencies
Everytime a build is now started, gradle will redownload all dependencies mentioned in the build.gradle. To save us some time, we will create a persistent volume to cache these.
First create a persistent volume:
kubectl apply -f minikube/gradle-cache.yml
Now configure Jenkins to use it when spawning a new build pod:
- "Manage Jenkins"
- "Configure System"
- Search for "Kubernetes Pod Template"
- "Add Volume" → "Persistent Volume Claim"
- "Claim Name": gradle-cache
- "Mount path": /home/jenkins/.gradle
- "Add Volume" → "Persistent Volume Claim"
Now restart the build. It will most likely fail, because minikubes hostPath provisioner will only allow root access to our filesystem. You can correct the rights using:
minikube ssh 'sudo chmod -R 777 /tmp/hostpath_pv'
Warning: You should not do this on a production system.
Now run your build again twice. You should notice a speedup on the second run.
Lab 3: Publish docker container
First we need to enable the build pod to build docker images. Configure Jenkins to mount the corresponding socket:
- "Manage Jenkins"
- "Configure System"
- Search for "Kubernetes Pod Template"
- Change "Docker Image" to "nbyl/jenkins-slave-docker-image-build:3.10-2"
- "Add Volume" → "Host Path Volume"
- "Host Path": /run/docker.sock
- "Mount path": /run/docker.sock
- "Add Volume" → "Host Path Volume"
- "Host Path": /var/run/docker.sock
- "Mount path": /var/run/docker.sock
After saving run the pipeline again. It will call another gradle task that builds a docker container. Publishing is currently disabled as we are on a minikube system and the image will always be present. But why don't you implement this as an exercise?
Lab 4: Integration Testing
There is nothing to change for this lab. But to check out the helm chart, look at the helm/confy
directory. The deployment is described here as a set of templates for the kubernetes resources. The application is installed using a deployment of the pod to run. The database for the application is configured using environment variables. The instances of the application are combined using a kubernetes service.
Lab 5: User Acceptance Testing
There is nothing to change for this lab. If you look at the helm/confy
chart, you will find an ingress resource to access the application. It will available after deployment at http:///confy-uat
Lab 6: Production Deployment
There is nothing to change for this lab. After the confirmation the application will be available at http:///confy