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. Ths is a test.
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.
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
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.
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:
– kind: ServiceAccount
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 yaml called gitlab-runner-namespace.json:
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:
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:
Now we need to define our yaml file for our application, GitLab Runner. Create a values.yaml file containing the following (substitute accordingly):
## GitLab Runner Image
gitlabUrl: https://<<em>insert GitLab server URL here</em>>/
runnerRegistrationToken: "<<em>insert registration token here</em>>"
## For RBAC support:
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
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:
In GitLab you should see a runner with a green circle next to it:
That’s it! GitLab Runner is now installed in your VMware Enterprise PKS cluster.