Setting up a Docker-based Gitlab Runner on Alibaba Cloud ECS

Gitlab offers a couple of amazing features, one of which is its Continous Integration/Delivery tool using GitlabCI. By default, your builds are run on gitlab’s servers for free and capped at 2000 minutes across private projects, after which you either pay for an upgraded plan or use your own server.
In this guide, we will set up a private gitlab runner on our Alibaba Cloud ECS instance while hosting our project on gitlab.

Getting Started

To kickstart, let’s create an Alibaba Cloud ECS instance (if there’s none already) with at least 1GB of RAM and either of Debian, CentOS or Ubuntu as our base OS. For this guide, we will be using Ubuntu version 16.04. If you’re totally new here, the Alibaba Cloud documentation has an excellent guide to creating your first ECS instance.
The rest of this guide will be mostly CLI-based so a pretty lack-of-fear-of-the-command-line would be welcomed :smile: .

Hello Docker

Our next step is to install docker on our ECS instance. Since we are using Ubuntu for our guide, installing docker is as simple as running:
apt install docker.io.
Note: We are installing docker.io instead of docker since the later will only install the system tray package on our system.
You can confirm the installation by running docker info which should print out your container information to the terminal.

Installing the Gitlab Runner

Once docker is installed, we will use the runner installation script provided by Gitlab. Currently, it supports Ubuntu, CentOS and Debian (See why we needed one of those OSs now?). So go ahead and type:
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash to download the script and then proceed with the installation by running:
sudo apt install gitlab-runner
As confirmation, you can run: gitlab-runner --help to display the help information on your terminal.

There is a runner installed on our ECS instance, now what?

As you might know, the runners are used to build and deploy our code from a gitlab project/repository which means, we will have to bind the same runner to our project on gitlab by registering it.

Registering a Gitlab Runner

The gitlab-runner we installed earlier comes with interactive CLI tool to be used for registration but to get the required info, we will need to visit our target gitlab project i.e, the project we are looking to build on our ECS instance. So visit your project’s CI settings page which should live at https://gitlab.com/{gitlab-username}/{project-name}/settings/ci_cd (We are assuming it is hosted on gitlab.com) and expand the “Runners” section. Take note of the URL and the registration token on the page (shown in the expansion below) as we’ll be using that shortly.

Back to our SSH connection, run:
sudo gitlab-runner register and you’ll be presented with a couple of prompts and here is a little break down of each prompt:

Co-ordinator URL: This is the URL as shown in the image. It refers to where our gitlab instance is hosted and for our case, it’s https://gitlab.com/.
Runner Token: The registration token on the page, it’s used to uniquely identify projects so you will have to copy it from the page and paste on your terminal.
Runner description: Helps to identify the specific runner in cases where we have multiple runners working together, it defaults to our hostname.
Runner tags: Comma-separated values that we can use to delegate jobs from our CI configuration file i.e our gitlab-ci.yml. We’ll leave ours blank.
Executor: This is the method used to run our jobs and the options are laid out for us. We will be using docker here.
Docker Image: The default image used when none is specified in our gitlab-ci.yml. Gitlab advises you use a general image and get more specific if required in the CI config file. In the spirit of keeping our image as small as possible, we will use Alpine Linux - a really minimal Linux distro that is designed to be simple and resource efficient, so go ahead and type alpine:latest on the prompt.

An important thing to note here is that our configurations are stored in /etc/gitlab-runner/config.toml so you can always edit the file directly and reload in case you somehow, need to update any of the provided information.

Going back to our project’s CI/CD settings page, we should see our shiny new runner added and we can safely disable the shared runners now.

Conclusion

So there! We have configured our Alibaba Cloud ECS instance to handle our CI builds for our gitlab project and you may also want to register more runners for different projects using same steps as above or optimize the runner you just created to improve your build times.