There are two basic flavors of prebuilt Docker containers available (Ubuntu-based and Alpine-based). The big difference between them is that the Alpine one is much smaller and has a better security track. You can find it here: https://gitlab.com/gitlaborg/gitlabrunner/blob/master/dockerfiles/alpine/Dockerfile.

You can run the container with arguments that will be passed through to the GitLab Runner binary that is started inside the container. This also enables easier runtime registration of the Runner with a GitLab instance. Remember from the Creating your own Dockerized GitLab Runner section that we baked the registration of the Runner inside the image. You can find the appropriate images on Docker Hub: https://hub.docker.com/r/gitlab/gitlab-runner/tags.

Just start a container using the following command. It will automatically download the right image:

$ mkdir /Users/shared/gitlab-runner && mkdir /Users/shared/gitlab-runner/config
 $ docker run -d --name gitlab-runner -v /Users/shared/gitlab-runner/config:/etc/gitlab-runner 
    -v /var/run/docker.sock:/var/run/docker.sock 
    gitlab/gitlab-runner:latest

You can check the logs of the running container with the following command:

$ dockers logs -f gitlab-runner
 ERROR: Failed to load config stat /etc/gitlab-runner/config.toml: no such file or directory  builds=0

The preceding output means that the gitlab-runner software is running inside the container, but it isn't registered yet.

The next step is to register it and save the configuration file in the container (in the configuration volume you specified with -v):

docker run --rm -v /User/shared/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register 
   --non-interactive 
   --executor "docker" 
   --docker-image python:3.7-alpine 
   --url "https://gitlab-ee.joustie.nl/" 
   --run-untagged="true" 
   --registration-token "xxx" 
   --description "docker-runner" 
   --tag-list "eventmanager" 
   --locked="false"

If you examine the container logs (maybe you left the window open) after this, a message should appear:

...
 Configuration loaded                                builds=0

This means that the Runner now has a valid configuration and is online with GitLab.

If we try to trigger the pipeline for the eventmanager-documentation project again, a job will be run:

Checking for jobs... received                       job=660 repo_url=https://gitlab-ee.joustie.nl/marketing/eventmanager-documentation.git runner=8cX8wWCr

In GitLab, you will see this job running:

In the log file of the container, a message will appear if the job succeeds:

Job succeeded                                       duration=1m17.7055922s job=660 project=10 runner=8cX8wWCr

This is also visible in the job log in GitLab:

This concludes the two ways of running Docker locally with relatively simple containers:

• Building your own container
• Using a prebuilt image

How can you manage this if you have massive amounts of build jobs? You can use an orchestration system such as Kubernetes, which is the subject of the next section.