Sie haben Webmasterkram erfolgreich abonniert.
Toll! Schließen Sie als Nächstes die Prüfung ab, um vollen Zugriff auf Webmasterkram zu erhalten.
Willkommen zurück! Sie haben sich erfolgreich angemeldet.
Erfolg! Ihr Konto ist vollständig aktiviert, Sie haben nun Zugriff auf alle Inhalte.

Anleitungen, Tipps und weiterer Web Krempel, den ich sonst wieder vergessen würde.

Gitlab unter Plesk 17+ nutzen

Gitlab unter Plesk 17+ nutzen

Als ich damals™, als Github noch für private Repos sehr teuer und public Repositorys keine Alternative waren, nach einer Lösung für meinen GIT Austausch war, bin ich auf Gitlab gestoßen. Gitlab existiert seit 2012 und wird mit monatlichen Releases weiterentwickelt. Die Versionsferwaltung gibt es dabei in einer Managed Variante unter gitlab.com sowie in einer selbst gehosteten Variante für den eigenen Server. Das wieder hat mein interesse geweckt, da ich persönlich sehr gerne self-hosted-Lösungen einsetze.

Was muss beachtet werden?

Die Installation von Gitlab ist erstaunlich einfach. Für die einfache konfiguration auf dem eigenen Server bietet Gitlab direkt eine so genannte Omnibus Installation.  Mit diesem Installer könnt ihr ganz einfach und mit wenigen Schritten, die Installation starten.
Um eine Omnibus Installation auf eurem Server zu starten, kann ich euch die offizielle Dokumentation empfehlen. Hier ist sehr übersichtlich und einfach beschrieben, mit welchen Schritten ihr die aktuelle Version installieren könnt.

Download and install GitLab
Learn about the various GitLab installation packages and downloads for Ubuntu, Debian, Docker, Google Cloud, and many more.

Konfiguration unter Plesk

Jetzt haben wir zunächst einmal eine Gitlab Installation. Diese müssen wir nun im optimalfall noch im Plesk an eine Domain durchleiten.
Dafür gehen wir nach dem Anlegen der gewünschten Domain in die Apache & nginx Einstellungen. Dort müssen wir in den Apache directives die folgenden Kommandos hinterlegen:

Additional directives for HTTP:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{REQUEST_URI} !^/.well-known/.*
RewriteRule  ^/(.*)  https://%{HTTP_HOST}/$1  [last,redirect=301]

Diese Einstellungen dienen nur dazu, dass wir später Let's Encrypt verwenden können und sagt, dass alle Verbindungen auf SSL umgeleitet werden, außer die .well-known für z.B. Anfragen für Zertifikate.

Additional directives for HTTPS:

ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:8181/ nocanon
# Stellt sicher, dass kodierte Schrägstriche nicht dekodiert, sondern im kodierten Zustand belassen werden.
# http://doc.gitlab.com/ce/api/projects.html#get-single-project
AllowEncodedSlashes NoDecode
<Location />
	# Weiterleitung an gitlab-workhorse erlauben
	ProxyPassReverse /
	Require all granted
</Location>
# Apache-Äquivalent zu nginx try-Dateien
# http://serverfault.com/questions/290784/what-is-apaches-equivalent-of-nginxs-try-files
# http://stackoverflow.com/questions/10954516/apache2-proxypass-for-rails-app-gitlab
#RewriteEngine on
# Leitet  alle Anfragen an gitlab-workhorse weiter, mit Ausnahme bestehender Dateien wie Fehlerdokumente oder Dateien
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_URI} ^/uploads/.*
RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]
RequestHeader set X_FORWARDED_PROTO 'https'
RequestHeader set X-Forwarded-Ssl on
# Für das Herunterladen von Anhängen benötigt
DocumentRoot /opt/gitlab/embedded/service/gitlab-rails/public
# Einrichten von Apache-Fehlerdokumenten, wenn das Backend ausfällt (d.h. 503 Fehler), wird eine Wartungs-/Einsatzseite aufgeworfen.
ErrorDocument 404 /404.html
ErrorDocument 422 /422.html
ErrorDocument 500 /500.html
ErrorDocument 502 /502.html
ErrorDocument 503 /503.html
# Es wird angenommen, dass sich das Log-Verzeichnis in /var/log/httpd befindet.
# Für Debian-Distributionen sollten Sie dies vielleicht auf
# /var/log/apache2.
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b" common_forwarded
ErrorLog /var/log/apache2/gitlab_error.log
CustomLog /var/log/apache2/gitlab_forwarded.log common_forwarded
CustomLog /var/log/apache2/gitlab_access.log combined env=!dontlog
CustomLog /var/log/apache2/gitlab.log combined

Eventuell müssen noch Parameter wie Port (8181) für eure Installation angepasst werden. Ansonsten sollten so alle Funktionen der Gitlab Installation von Plesk weitergeleitet werden.

Wichtig ist nun noch, dass ihr bei den nginx Einstellung den Smart static den proxy mode aktiviert lasst und files processing deaktiviert.

Die restliche Konfiguration kann nun in der Gitlab Config übernommen werden.
Jetzt sollte nur noch im Plesk ein Zertifikat erstellt werden und damit wäre die Konfiguration abgeschlossen.
Der Vorteil bei aktuellen Plesk installationen ist, dass mit der Omnibus Installation und bei aktivierten Auto-Updates, Gitlab auch automatisch mit upgedated werden kann. So erspart ihr euch einige Arbeit, da die Devs bei Gitlab scheinbar nicht schlafen.

Eigentlich alles relativ einfach, aber als ich die erste Einrichtung damals versucht habe, hatte ich mehrfach Probleme mit RAW Darstellung vom Code und Download von Anhängen in Issues.

Aktuell läuft meine Installation auf Gitlab 12.8.