Configuring a GitLab CI Runner with Docker for Continuous Integration Pipelines. Like previously mentioned, there are many different methods towards installing and configuring a GitLab Runner. In our example we’re going to install the GitLab Runner on the host and have it create Docker containers every time it needs to operate.
To see how quickly you can annoy your developers you just need to bring your Gitlab down.
Hi, you’ll need to create your own image which is based on CentOS 7 then. This can be used in the docker-compose setup then as different image entry. Since the Docker image recommended in the docs is officially supported and tested, I would suggest to keep using it, instead of going your own route. GitLab Community Edition docker image based on the Omnibus package. Pulls 100M+ Overview Tags. GitLab Docker images. We don't monitor the comments here, if you need he. GitLab is a refined open source alternative to GitHub. Take control of your code by self-hosting your own GitLab server! In about 15 minutes you’ll have a GitLab server running with Docker, SSL certificates, outgoing email, automatic backups and nightly updates. If you’ve got your own server already — whether.
If you did that already, you know how sensitive your build environment is and you should do everything you can to make it healthy and stable. Unfortunately, that sometimes means that you might think twice before deciding to upgrade your Gitlab configuration, or before upgrading your CI server.
However, when using Docker those troubles basically go away. In this article we are going to show you step by step how can you migrate your current Gitlab infrastructure into Docker.
Docker 101
If you have been around in the last couple of years you probably already heard of Docker. Docker is basically a Linux Container management toolset. Linux Containers provide resource limitation and prioritization (CPU, memory, block I/O, network) and application isolation in terms of the execution environment (filesystem, process trees, networking, user IDs). This has obvious benefits in terms of security, but an equally important benefit is making the management of your CI infrastructure much more enjoyable and less painful.
Docker containers are not persistent because they are based on images that are immutable. If you restart a container, you’ll restart all the processes running inside it and all changes made in previous executions will be lost because the container is created from the same original image.
To persist data you need to separate the state (configuration files you want to be able to edit frequently, databases, logs, etc) from the rest (system and static application files). The static parts should live inside the docker container and the state should be moved out to host volume folders that you can mount into your containers. This way, your state will be safe across multiple executions of the container.
Creating the initial state
Assuming that you already installed Docker in your server, the first step is selecting a Docker image that suits our needs. It’s always best to choose an official image as those are well structured and tend to be more up to date. For this post we selected the Gitlab Community Edition Docker image, which is based on the Omnibus package.
Before running the container we need to create the host volumes and set up the default configuration files that we’ll need in the first execution. There are three host volume folders that we will use:
| Host Volume | Container location | Usage |
| /docker/gitlab/data | /var/opt/gitlab | Application data |
| /docker/gitlab/data | /var/log/gitlab | Logs |
| /docker/gitlab/data | /etc/gitlab | GitLab configuration files |
To set our default configuration first create Gitlab’s configuration file /docker/gitlab/gitlab.rb. Let’s start with something simple:
For security purposes, we should enable SSL by default. This gitlab image will look for the ssl certificate in the
Now enter these commands:
And that’s it! Access https://gitlab.yourcompany.com, login with your user and make sure everything is in there!
Backups
To automate backups it’s just a matter of running an instance of the docker machine
Install it in the host’s cron (say everyday at 4am) using a more generic grep regex to avoid the need to change this cron job when you upgrade the version.
This will only backup your database, so remember to backup your configuration files as well (/docker/gitlab/conf) and the logs in (/docker/gitlab/logs), in case you want to keep them.
Upgrading your Gitlab
First stop your current docker instance:
Delete the container:
To upgrade you need to edit your Dockerfile and docker-compose.yml files. You only need to edit the tag, e.g. from 8.5.7-ce.0 to 8.5.8-ce.0.
Build it again:
And then start it:
If all went well, you should now have a new version up and running. Please keep in mind that new versions might break stuff sometimes. So test it before deploying it and it can’t hurt to run gitlab-rake gitlab:check SANITIZE=true to check for issues.
Wrapping up
Migrating your Gitlab to Docker is the first step into turning your CI more manageable. You can easily move it to another server if you need and you can easily upgrade to newer versions without running the risk of breaking things. Gitlab is the core of your team’s development infrastructure and you’ll want it to run smoothly. Docker can help you achieve just that.
Of course, if you want even more stability, you need a High-availability (HA) containers setup (e.g. with HAProxy) or to setup live-migration of containers and data. Those are advanced topics that we may explore on a future blog post.
Further reading & Resources:
Gitlab has several methods to update to newer version depending on the type of the original installation and the Gitlab version. This post will show you the way for docker version of Gitlab, which is the simplest among others.
This post will follow the official doc for updating docker version of Gitlab.
If you installed the Gitlab with docker compose, please follow this official procedure.
And hereunder some docs for the non docker version update if you are interested:
We must backup the Gitlab before everything. I’ve already written a post on how to backup up Gitlab docker version.
The update procedure will remove the current Gitlab container, so the data must be kept somewhere to be reused by the update. As I wrote in a previous post on how to install Gitlab in docker, we used the docker run --volume to mount the docker host volumes to Gitlab container. So even the Gitlab container is removed, the data are still kept in the docker host.
To verify the mounted volumes:
Install Gitlab Ce Docker Windows 10
Ok, I see there’re three volumes mounted in the Gitlab container, it’s good.
Exactly the same procedure as the official one. I will update the current gitlab-ce:10.8.3-ce.0 to gitlab-ce:latest
Install Gitlab Ce Docker Free
Pull the new image:
To pull other version, change the
lastestby the tag name which can be found from the docker hub.- Stop the running container called gitlab:
- Remove existing container:
- Create the container once again with previously specified options:
That’s all, go to take a coffee, GitLab will reconfigure and update itself, the procedure is pretty simple.
Install Gitlab Ce Docker Compose
If you take a look at the procedure for Gitlab installed from the source, you will thank yourself for choosing to install Gitlab in docker, because you chose the zen.