Today I installed the GitLab Community Edition on Docker. It takes me some time to figure out how to get it done in an reasonable way. On the GitLab pages there is an installation guide for Docker. And the Docker images for GitLab are very well maintained on DockerHub. In the following I will expalin how to run GitLab with Docker-Compose and separate Database Containers.
If you follow the install guide you can start a GitLab Container from the command line or with Docker compose. However, the examples are not representative of how you may run GitLab in your production environment. GitLab comes with a so called all-on-one Docker container. The image contains beside the GitLab applicaton also a Redis and a PostgreSQL database. This is convenient for a first look but not the best setup for docker.
If you were going to run it in a docker environment like Imixs-Cloud, you’d may want to use external data services for PostgreSQL and Redis, as well as store the GitLab filesystem somewhere that will persist. Thankfully, the GitLab CE Docker image makes it easy to do these things. In the following example I show how you can setup GitLab with Docker Compose. This example can also be adapted to Docker Swarm. In the docker-compose file I split the Redis and PostgreSQL database into separate containers. There for you need to deactivate the internal databases. All configuration settings can be done in the environment variable named ‘GITLAB_OMNIBUS_CONFIG.
postgresql['enable'] = false
gitlab_rails['db_username'] = "gitlab"
gitlab_rails['db_password'] = "gitlab"
gitlab_rails['db_host'] = "postgresql"
gitlab_rails['db_database'] = "gitlabhq_production"
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'utf8'
redis['enable'] = false
gitlab_rails['redis_host'] = 'redis'
gitlab_rails['redis_port'] = '6379'
Note: The ‘external_url’ is optional and not necessary for local testing.
During my first tests I run into some strange behavior when the Docker-Container wont start any more. To solve such a situation its best to remove the existing containers and start again. Especially the configuration data located in /etc/gitlab can be a cause for a problem.
The Admin Account
After the first launch you will be asked to create the admin password. You can later login with the userid ‘root’ and you admin password to administrate your environment
You can run GitLab also in combination with Traefik reverse-proxy. In case you use Traefik with HTTPS and self-signed certificates you need to disable this feature in GitLab. Set the following GITLAB_OMNIBUS_CONFIG entry:
letsencrypt['enabled'] = false
In addition you may not set the parameter ‘external_url’, so just uncomment. Also it is necessary to add the Hostname into your service description. Otherwise the Repository URLs generated by GitLab will show the correct external address. Here is the complete configuration example in case of traefik:
web: image: gitlab/gitlab-ce:11.11.2-ce.0 .... ....... hostname: gitlab.foo.com environment: GITLAB_OMNIBUS_CONFIG: | letsencrypt['enabled'] = false # Disable external_url "https://gitlab.foo.com" ...... networks: - proxy-net - backend
For some reasons the GitLab Image includes not only the database server but also a Prometheus installation. I do not understand why this is possible. It takes much resources. To disable it add the following GITLAB_OMNIBUS_CONFIG entry:
prometheus['enable'] = false
How to Create Backups
You can easily backup your GitLab data with the build in backup tool:
docker exec -it gitlabtest_web_1 gitlab-rake gitlab:backup:create
The backups will be stored at:
Note: The backup does not include the configuration files or SSL certificates. So it is necessary to backup also the folder: