Deploying GitLab Runner to VMware Enterprise PKS

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.

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:

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 yaml called gitlab-runner-namespace.json:

{
  "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):

## GitLab Runner Image
imagePullPolicy: IfNotPresent
gitlabUrl: https://<<em>insert GitLab server URL here</em>>/
runnerRegistrationToken: "<<em>insert registration token here</em>>"
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

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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.