Before a while I had the idea to setup my own Gitlab instance to manage my git repositories on my own server. In order to install Gitlab, I ran into a few problems, because I’m already using ISPConfig as administration panel for my root server. Hence I am slightly going to migrate my whole hosting infrastructure to a docker based solution, I wanted Gitlab to run as an independent docker stack using Docker Compose on the same physical machine.
Reasons for using Gitlab
There are many reasons to run your own Gitlab. The most important one is, that Gitlab is somewhat of an all-in-one solution. It combines a very intuitive user interface for git and a complete bugtracking solution including a strongly customizable issue board (Scrum Board). Additionally every Gitlab repository has a build in wiki. The wiki supports Markdown for content creation. Furthermore you can use the included composer repository feature to organize the code of complex PHP applications. Moreover Gitlab ships with an complete CI / CD stack, that – for example – let you run pipelines depending on trigger events on your repository. Finally the integrated code snippet collection feature definitely have to mentioned. And best of it all: All of this is include in the free open source community edition of Gitlab.
For a complete list of all features, have a look at this feature overview.
So these where the key requirements for the resulting solution I imposed to my own :
- Gitlab should run as an independent Docker-Compose stack
- I wanted Gitlab to run under a separate domain on my ISPConfig managed root server
- Gitlab should be available via HTTPS / SSL via an self extending Let’s Encrypt certificate
Challenges when running Gitlab behind ISPConfig
I had to master the following challenges before I could get Gitlab run behind ISPConfig as a proxy.
- ISPConfig already uses the port 80 (Apache / HTTP), 8080 (ISPConfig Webinterface) and 443 (Apache / HTTPS)
- Let’s Encrypt already used by ISPConfig to create valid SSL certificates for the websites managed by ISPConfig and the panel itself.
Gitlab docker compose stack
I used this Gitlab Docker Compose stack to run Gitlab behind ISPConfig:
unicorn['worker_timeout'] = 120
unicorn['worker_processes'] = 2
letsencrypt['enable'] = false
nginx['listen_port'] = 80
nginx['listen_https'] = false
The corresponding environment file looks like that:
Use ISPConfg as a proxy (the solution)
To get ISPConfig working as a proxy for the Gitlab Docker stack I took the following steps:
- Create a new website for Gitlab in ISPConfig with the domain Gitlab is going to run under
- Enable SSL and Enable Let’s Encrypt SSL in the Website configuration:
- Add the following Apache Directive under the websites options:
Apache12345678910111213ProxyPreserveHost OnProxyRequests OffSSLProxyEngine onSSLEngine onSSLHonorCipherOrder on<Location />RequestHeader unset Accept-EncodingRequestHeader set Host "gitlab.root-server.com"RequestHeader add X-Forwarded-Ssl onRequestHeader set X-Forwarded-Proto "https"Order allow,denyAllow from all</Location>
These links can be useful if you struggle upon problems when setting up Gitlab behind ISPConfig:
- Official Gitlab webiste: https://about.gitlab.com/
- Feature Comparison Gitlab Editions: GitLab.com Feature Comparison | GitLab
- Gitlab Proxy Settings: https://docs.gitlab.com/omnibus/settings/nginx.html#supporting-proxied-ssl
- Gitlab HTTPS-settings: https://docs.gitlab.com/omnibus/settings/nginx.html#manually-configuring-https
- A guy who had similar problems to run Gitlab behind a proxy: https://www.itsfullofstars.de/2019/06/gitlab-behind-a-reverse-proxy/
- My Docker category
- My blog posts regarding GIT