GitLab auf eigenem Server einrichten

von

In diesem Beitrag befasse ich mich mit der Einrichtung eines GitLab-Servers unter Ubuntu. Dabei wird eine Instanz auf einem eigenen Server aufgesetzt, etwa im Heimnetzwerk, oder auch auf einem angemieteten Root-, oder V-Server. Wichtig hierbei ist, dass man Root-Rechte auf der jeweiligen Maschine besitzt.

Systemvoraussetzungen

Zunächst sollte sichergestellt werden, dass genügend Leistung bereitsteht, um einen GitLab-Server zu betreiben. GitLab ist nicht besonders „hungrig“, aber wenn auf dem Server weitere Dienste laufen, kann beispielsweise der Arbeitsspeicher an seine Grenzen kommen (ist mir beim zusätzlichen Installieren einer „Jenkins“-Instanz passiert).

Laut gitlab.com sollten folgenden Bedingungen etwa zutreffen:

  • ca. 8GB RAM (inkl. SWAP)
  • Prozessor mit mindestens 2 Kernen

Die Instanz, welche ich aufgesetzt habe läuft allerdings einwandfrei auch mit weit weniger Ressourcen. Man muss allerdings dazu sagen, dass hier keine 100 Benutzer unterwegs sind, sondern lediglich einer.

Vorschalten eines Apache-Webservers

GitLab bringt einen eigenen NGINX-Webserver mit und ist auch nur noch in dieser Standalone-Variante verfügbar. Ich betreibe auf der gleichen Maschine allerdings bereits einen Apache-Webserver. Dieser soll auch weiterhin alle Anfragen beantworten und die Anfragen an GitLab dann einfach forwarden. Aus Performance-Sicht ist dies nicht wirklich sinnvoll, da ein NGINX Webserver performanter arbeitet als ein Apache. In meinem Fall möchte ich dieses Setting allerdings so beibehalten, bzw. erweitern.

Weiterhin soll das ganze natürlich auch per SSL abgesichert werden. Ich werde in GitLab zwar keine wichtigen / kritischen Daten / Code laden, aber wer gibt schon gerne Benutzername und Passwort in ein Webformular ein, wenn dieses nicht verschlüsselt übertragen wird?

Die Weiterleitung des Apache an GitLab muss intern nicht wirklich verschlüsselt sein, weshalb hier auf SSL-Forwarding verzichtet wird.

Daraus ergibt sich folgendes Setting:

Vorgehensweise

Um dies nun umzusetzen, gehen wir wie folgt vor:

  • Downloaden und Installieren von GitLab
  • Erstellen eines Zertifikates mit Let’s Encrypt
  • Einrichten der Virtual Hosts für den Apache
  • Blockieren des Direktzugriffs auf GitLab

Downloaden und Installieren von GitLab

Wir möchten GitLab auf einer eigenen Maschine installieren und keine Cloud-Lösung verwenden, also laden wir GitLab zunächst runter. Sollte ‚curl‘ noch nicht installiert sein, so wird dies vorher erledigt. Folgende Befehle stammen hierbei von der offiziellen GitLab-Website.

apt-get update
apt-get install curl
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash
sudo EXTERNAL_URL="http://gitlab.example.com"
apt-get install gitlab-ee

GitLab wird nun vollständig installiert. Anschließend müssen noch einige Einstellungen angepasst werden, wie etwa der Port, welcher per Default auf 80 eingestellt ist und somit mit dem Apache kollidieren würde. Dazu muss folgende Datei bearbeitet werden:

nano /etc/gitlab/gitlab.rb 
# in deser Datei dann die entsprechenden Werte anpassen: 
external_url 'gitlab.example.de' 
nginx['listen_address']= 'localhost' 
nginx['listen_port']= 85 

# anschließende die GitLab-Config neu laden: 
gitlab-ctl reconfigure

Hinweis: GitLab bringt eine PostgreSQL-Datenbank mit. Eine separate Datenbank kann zwar ebenfalls eingerichtet werden, ist aber kein muss.

Erstellen eines Zertifikates mit Let’s Encrypt

Mit Let’s Encrypt bekommt man glücklicherweise (ein Danke an dieser Stelle 🙂 ) mittlerweile an kostenlose SSL-Zertifikate heran. Und dies zusätzlich auch erstaunlich einfach. So kann man seine Verbindungen mit wenigen Klicks (bzw. eigentlich eher Befehlseingaben) verschlüsseln.

Auf meinem Server ist hierbei das Hilfsprogramm ‚certbot‘ bereits installiert. Sollte dies noch nicht vorhanden sein, kann man dies schnell nachholen:

apt-get update
apt-get install software-properties-common
add-apt-repository ppa:certbot/certbot
apt-get update
apt-get install python-certbot-apache

Anschließend wird mit folgenden Befehlen ein neues Zertifikat erstellt. Eine passende VirtualHost-Datei wird hierbei direkt im passenden Verzeichnis des Apache erstellt. Dies kann man dann noch nach seinen eigenen Wünschen anpassen.

certbot --apache certonly

Eine ausführliche Dokumentation findet man auf der Website der Projektes certbot.

Einrichten der Virtual Hosts für den Apache

Wir haben nun eine VirtualHost-Datei und passen diese noch etwas an:

<VirtualHost *:443>
ServerName gitlab.example.de 
ServerAlias www.gitlab.example.de

ServerAdmin admin@example.de

DocumentRoot /var/www/html/gitlab.example.de /

# enable proxy to GitLab
ProxyPreserveHost On
ProxyRequests Off
ProxyVia Off
ProxyPass / http://127.0.0.1:85/
ProxyPassReverse / http://127.0.0.1:85/

# SSL: LetsEncrypt
SSLCertificateFile /etc/letsencrypt/live/gitlab.example.de/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/gitlab.example.de/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

Anschließend teilen wir dem Apache mit, dass er die neuen Konfigurationen laden soll:

service apache2 reload

Nun sollte man über SSL direkt auf GitLab weitergeleitet werden, etwa mit der URL

https://gitlab.example.de

Blockieren des Direktzugriffs auf GitLab

Zuletzt blockieren wir noch die Anfragen, welche direkt an den Port des Nginx ankommen, mit einem Paketfilter. Dies ist nicht unbedingt notwendig, wenn man GitLab nur selbst verwendet und immer brav über die mit SSL verschlüsselte Verbindung über den Apache zugreift. Dennoch ist dies natürlich eine Sicherheitslücke, welche man mit wenig Aufwand schließen kann.

Also weisen wir alle Anfragen an den Port 85 ab, welche direkt an den Nginx Webserver geleitet werden. Somit darf ein Anwender nur noch über den Apache intern an die GitLab-Instanz ran. Das Blockieren des Ports nehmen wir über den Paketfilter ‚iptables‘ vor. Folgende Befehle sind hierzu relevant:

# Ausgabe der eingetragenen Filterregeln
iptables -t filter -L
# Löschen einer Filterregel (Kette und Position in der Liste)
iptables -D INPUT 3

# Zunächst über das Loopback Interface die Anfragen weiterhin erlauben:
iptables -A INPUT -i lo --protocol tcp --dport 85 -j ACCEPT
# Alle anderen Anfragen von außerhalb verwerfen (die Netzwerkschnittstelle entsprechend eintragen)
iptables -A INPUT -i <ext. interface> --protocol tcp --dport 85 -j DROP

Nun kann noch einmal versuchen, auf den Port 85 zuzugreifen. Wenn alles funktioniert hat, wird man nicht mehr auf die Seite von GitLab weitergeleitet. Wird die entsprechende URL verwendet, welche über den Apache weiterleitet, so sollte GitLab weiterhin zu erreichen sein – per SSL verschlüsselt.

Verweise / Quellen

Schreibe einen Kommentar