If you haven’t used Gitlab’s Auto Devops product yet, and you’re in the DevOps or CI/CD space, you’re really missing out on the convenience that the Review App can bring. In order to get started, you’ll need a few things:

1. A Digital Ocean Account.
2. A little bit of working Knowledge about Digital Ocean’s Dashboard.
3. Be a Site Admin for GitLab
4. Some UNIX chops.

I’m going to assume that you have a GitLab instance up and running already. Setting this up is probably a bit outside of this article, but, I highly recommend the Omnibus installer for your sanity (and mine, honestly). Fortunately, you won’t need SSH access to your Gitlab instance, but you will need to be able to open a shell and do UNIX like things. I haven’t tested this on Windows, so, you’re on your own there.

GitLab things:

The two things that I’ll highly recommend is that you have Let’s Encrypt enabled, and that you have the container registry enabled. We’ll start by looking at the /etc/gitlab/gitlab.rb file, and ensuring that the following lines are there:

Next, we’ll need to create a Digital Ocean Kubernetes Cluster. The engineers and software developers at Digital Ocean made it super simple to create a Kubernetes cluster without a lot of manual steps. It’s as easy as:

• Go to the Dashboard
• Create a Kubernetes Cluster
• Download the YAML file that’s at the bottom of the page of your managed dashboard and keep it somewhere other than the default download location on your hard drive.

You’ll also need to get kubectl installed – snap worked on my ubuntu 18.04 box to install it, and brew managed to install it on OSX without issue. From there, copy the contents of the YAML file from eariler into the ~/.kube directory on your system.

Configure Service Accounts in your Kubernetes Cluster

In order for GitLab to authenticate with your Kubernetes Cluster we need to create a Service Account. Open a new terminal session and let’s start creating a Service Account!

First off we need to create a new namespace for GitLab.

kubectl create namespace gitlab-namespace

Let’s set our context to the newly created namespace so we don’t have to consistently add the --namespace=gitlab-namespace option to the commands.

kubectl config set-context $(kubectl config current-context) --namespace=gitlab-namespace

kubectl create -f service-account.yml

Next up is setting the correct permissions for the gitlab-user in the gitlab-namespace.

kubectl create clusterrolebinding gitlab-cluster-admin-binding --clusterrole=cluster-admin --serviceaccount=gitlab-namespace:gitlab-user

And

kubectl create clusterrolebinding permissive-binding --clusterrole=cluster-admin --user=admin --user=kubelet --group=system:serviceaccounts

GitLab Kubernetes Integration

To use your newly created or existing Kubernetes Cluster in GitLab you will need connect it to your system. You’ll need to go to the Site Admin -> Kubernetes -> Add Kubernetes Cluster.

You will see a panel with 2 tabs; Create new Cluster on Google Cloud Engine and Add existing cluster. You should go to Add existing cluster since we created ours on DigitalOcean.

Now it is time to enter your existing Kubernetes Cluster details. You can retrieve this information by performing the following steps in your terminal.

Get Service Account definition

Execute the following command kubectl describe serviceAccounts gitlab-user to get information about the service-account we created earlier. The things that are important here are the Mountable secrets and Tokens.

Get secret definition

Execute the following command kubectl describe secret [the token from the output from describe serviceAccounts] to get the token. We’re more interested in the token’s certificate than anything else:

kubectl get secret [gitlab-user-token-b468q] -o jsonpath="{['data']['ca\.crt']}" | base64 --decode

In the terminal you see the certificate starting with -----BEGIN CERTIFICATE-----. Copy everything including -----END CERTIFICATE----- to your the file your are using to keep track of the details.

Get your Kubernetes Cluster API URL

You can find the API URL by executing the following command kubectl config view, in the Clusters, server: yaml. You should see a URL that matches your cluster name from DO in the server field, and you’ll copy that as your Kubernetes Cluster API URL.

Enter details in GitLab

Now that you have all the details we can start entering them in GitLab. Go back to GitLab and you should see a form with the following input fields (Some may not be visible to you).

Kubernetes Cluster name

The name you wish to give the cluster.

Environment scope

The default environment scope is *, which means all jobs, regardless of their environment, will use that cluster. Each scope can only be used by a single cluster in a project, and a validation error will occur if otherwise. Also, jobs that don’t have an environment keyword set will not be able to access any cluster.

API URL

It’s the URL that GitLab uses to access the Kubernetes API. Kubernetes exposes several APIs, we want the “base” URL that is common to all of them, e.g., https://kubernetes.example.com rather than [https://kubernetes.example.com/api/v1](https://kubernetes.example.com/api/v1). We got the URL from the kubectl config view command we did earlier.

CA Certificate

If the API is using a self-signed TLS certificate, you’ll also need to include the ca.crt contents here. We decoded this from the token.

Token

GitLab authenticates against Kubernetes using service tokens, which are scoped to a particular namespace. Enter the base64 encoded token here.

Project namespace (optional, unique)

You don’t have to fill it in; by leaving it blank, GitLab will create one for you.

RBAC-enabled cluster

Enable it, your cluster is role-based this was done earlier.

Once you filled in all the fields with the correct values. You can add the Kubernetes Cluster and you will be redirected to the Kubernetes Cluster page in Gitlab. Next step is to install some Helm Charts.