Recently I have been deepening my learning of DevOps methodolgies, specifically around the vRealize Automation and Orchestrator platforms. I have been producing code for both in my development environment for a while and promoting it manually to test, staging and production. However, this is a very error-prone and laborious process that fails to take advantage of
modern technologies to eliminate problems – such as syntax and formatting issues. It is clear to me that code produced in development, once committed, should be promoted to test in an automated way. This automated process should also perform initial testing and linting before manual testing and OAT is done in staging. Ideally, committed code should also be self-documenting, enabling easier code review by your peers.
To automate our code promotion we need to choose a CI/CD tool. I have chosen GitLab, as all my internal code is stored here.
The CI/CD functionality of GitLab is performed by the GitLab Runner, and the configuration is stored in a YAML file. Before we can get to that, we need to install the runner.
Whilst it is possible (and in some instances highly likely) that you can use a standard virtual machine as a runner, I am drawn to the ephemeral nature of containers for my workloads. With this in mind, I have decided to use Kubernetes as my container management platform, specifically, VMware’s Enterprise PKS.
Getting Started
In the following example, I have provisioned a PKS cluster called gb-srt-d-pks-01.uk.mdb-lab.com consisting of one master and three worker nodes.
To begin, get the credentials of your cluster using:
pks get-credentials <insert PKS cluster name here>
Once you have these, verify you can see the Kubernetes nodes using:
kubectl get nodes -o wide
Install Helm
To bring GitLab Runner into our environment, we need to use a solution to define and install our application. For this, we will use Helm.
Please note: this is only for Helm 2.0. If you’re using 3.0, then you can skip this bit and go straight to Install GitLab Runner on PKS.
To get started, define a service account for Helm to use in our PKS cluster. Create a YAML file called tiller-service-account.yaml consisting of the following:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| apiVersion: v1 | |
| kind: ServiceAccount | |
| metadata: | |
| name: tiller | |
| namespace: kube-system | |
| — | |
| apiVersion: rbac.authorization.k8s.io/v1beta1 | |
| kind: ClusterRoleBinding | |
| metadata: | |
| name: tiller | |
| roleRef: | |
| apiGroup: rbac.authorization.k8s.io | |
| kind: ClusterRole | |
| name: cluster-admin | |
| subjects: | |
| – kind: ServiceAccount | |
| name: tiller | |
| namespace: kube-system |
Apply this file to your Kubernetes cluster using:
kubectl create -f tiller-service-account.yaml
Initialize Helm using:
helm init --service-account tiller
Finally, add the GitLab repo to your Helm installation:
helm repo add gitlab https://charts.gitlab.io
Install GitLab Runner on PKS
Now Helm is up and running we can install GitLab. First, we’ll create a namespace. Whilst this isn’t normally necessary, we need it for the next step.
Create the following JSON called gitlab-runner-namespace.json:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| { | |
| "apiVersion": "v1", | |
| "kind": "Namespace", | |
| "metadata": { | |
| "name": "gitlab-runner", | |
| "labels": { | |
| "name": "gitlab-runner" | |
| } | |
| } | |
| } |
Apply it:
kubectl create -f gitlab-runner-namespace.json
GitLab Runner needs to trust the SSL certificate of the installation it will connect to. To enable this, we create a Kubernetes secret based on that cert.
Locate the certificate, and create the secret using (substitute accordingly):
kubectl --namespace gitlab-runner create secret generic gitlab-domain-cert --from-file=nl-utc-p-git-01.nl.mdb-lab.com.crt
Please note: the name of the certificate file (that you supply) must match that of the FQDN of the GitLab server (eg. nl-utc-p-git-01.nl.mdb-lab.com).
Confirm the secret exists as expected using:
kubectl describe secret -n gitlab-runner gitlab-domain-cert
The size in bytes should also be the same as the original certificate:
It’s alive!
To authenticate the runner with GitLab, we need a token. To do this, go into GitLab and click CI/CD.
Expand the Runners section, and take a note of the registration token in red:
Make a note of the stuff in red…
Now we need to define our yaml file for our application, GitLab Runner. Create a values.yaml file containing the following (substitute accordingly):
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| ## GitLab Runner Image | |
| imagePullPolicy: IfNotPresent | |
| gitlabUrl: https://<insert GitLab server name here> | |
| runnerRegistrationToken: <insert registration token here> | |
| unregisterRunners: true | |
| terminationGracePeriodSeconds: 3600 | |
| certsSecretName: gitlab-domain-cert | |
| concurrent: 10 | |
| checkInterval: 30 | |
| ## For RBAC support: | |
| rbac: | |
| create: true | |
| clusterWideAccess: false | |
| metrics: | |
| enabled: false | |
| runners: | |
| image: ubuntu:18.04 | |
| privileged: false |
Substitute the gitlabUrl and runnerRegistrationToken values accordingly.
Finally, install the application using:
helm install --namespace gitlab-runner --name gitlab-runner -f values.yaml gitlab/gitlab-runner
Please note: if using Helm 3.0, use the following:
helm install gitlab-runner gitlab/gitlab-runner --namespace gitlab-runner -f values.yaml
Wait a few minutes, then list the pods to verify it was successful:
kubectl get pods -n gitlab-runner -o wide
Take a note of the pod name and then review the logs using (substitute accordingly):
kubectl logs <insert pod name here> -n gitlab-runner
If everything has gone well, you should see something like:
Looking good
In GitLab you should see a runner with a green circle next to it:
Success!
That’s it! GitLab Runner is now installed in your VMware Enterprise PKS cluster.
virtualhobbit 
Pingback: Using Continuous Deployment to Provision VDI Desktops | virtualhobbit