Installation von Gitlab-CE

Datum

GitLab ist eine Webanwendung zur Versionsverwaltung für Softwareprojekte auf Basis von git. Sie bietet diverse Management und Bug-Tracking-Funktionalitäten sowie mit GitLab CI ein System zur kontinuierlichen Integration. GitLab ist in den Programmiersprachen Ruby und Go entwickelt.

Die GitLab Community Edition (CE) wird als Open-Source-Software unter der MIT-Lizenz entwickelt. Seit August 2013 bietet die GitLab Inc. auch eine Enterprise Edition (EE) an, die zusätzliche insbesondere für Unternehmen relevante Funktionen beinhaltet
Quelle: Wikipedia

Vor und Nachteile

Vorteile
  • private Repositories (sind auf github.com kostenpflichtig)
  • komplette Verwaltung von Benutzern und Teams
  • kostenfrei (Community Edition)
  • CI/CD kann nach belieben integriert und gesteuert werden
Nachteile
  • man benötigt eigenen Server, empfohlen sind dabei 4 GB RAM
  • man muss sich selbst um das einspielen von Aktualisierungen kümmern

Installation der der Community Edition

Vor der Installation von Gitlab sollten folgende Pakete installiert sein:
  • ca-certificates
  • curl
  • openssh-server
  • postfix

Falls das noch nicht der Fall sein sollte, kann man dies unter Debian/Ubuntu mit
sudo apt-get install ca-certificates curl openssh-server postfix
und unter Red Hat/CentOS mit:
yum -y install curl policycoreutils openssh-server openssh-clients postfix
nachholen.

Gitlab selber stellt entsprechende Installationsscripte in verschiedenen Formaten unter https://packages.gitlab.com bereit.
Aktuell für:

  • deb
  • rpm
  • node
  • python
  • gem

Dazu gibt es jeweils einen „quick install“ Oneliner, wo ein Shellscript direkt an die lokale bash-session übergeben werden kann.
Bei Systemen welche .deb verwenden sieht das z.B. wie folgt aus:
curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

Man sollte sich das entsprechende Script auch vorher einmal anschauen bevor man es blind an die bash übergibt.
Darum kann man sich das Script auch herunterladen und genauer betrachten:

$ cd /tmp
$ curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
$ less /tmp/script.deb.sh

Und anschließend ausführen: sudo bash /tmp/script.deb.sh

Im Grunde prüft das Script ob grundlegende Werzeuge (wie z.B. curl) installiert sind und installiert dann selber die GPG-Keys und Paketquellen von Gitlab.

Nachdem die Paketquellen von Gitlab im System hinterlegt sind, sollte man den Paketcache erneuern.
Bei Red Hat/CentOS: sudo yum clean all && sudo yum makecache fast
Bei Debian/Ubuntu: sudo apt-get clean && sudo apt-get update

Nun folgt die eigentliche Installation…
Hierbei kann man sowohl vorher als auch im Nachhinein angeben unter welcher URL die eigene Gitlab-Instanz erreichbar ist.
Will man dies bereits vor der Installation mitgeben, so verwendet setzt man die entsprechende Variable EXTERNAL_URL
Bsp: sudo EXTERNAL_URL="http://gitlab.example.com" apt install gitlab-ce
Alternativ führt man nur die Installation per:
sudo apt install gitlab-ce
unter Debian/Ubuntu
und sudo yum install gitlab-ce
unter Red Hat/CentOS durch.

Anmerkung: Sofern eine Firewall vorhanden ist (z.B.: ufw, iptables, etc.) sollten die Ports 80 (HTTP) und 443 (HTTPS) freigeschaltet werden.

Wenn die EXTERNAL_URL vorher angeben wurde, sollte man nun in der Lage sein die URL aufzurufen und
ein entsprechendes root-Passwort zu vergeben.

und anschließend kann man sich damit einloggen…

Konfiguration

Die Konfiguration von Gitlab befindet sich hauptsächlich in der Datei /etc/gitlab/gitlab.rb und nach jeder Anpassung muss sudo gitlab-ctl reconfigure durchgeführt werden.

external_url

In dieser Datei befindet sich fast ganz am Anfang die Variable external_url welche angibt über welche URL die Gitlab-Instanz erreichbar ist.
Bsp.: external_url 'http://gitlab.techgoat.net'

Let’s Encrypt

Gitlab bietet automatische Unterstützung für Let’s Encrypt-Zertifikate an. D.h. wenn Let’s Encrypt-Unterstüzung aktiviert wird, werden automatisch entsprechende Zertifikate für die unter external_url hinterlegte Domain erzeugt und diese werden auf Wunsch auch automatisch verlängert.

Um Let’s Encrypt zu aktivieren stellt man die unter external_url hinterlegte URL von http:// auf https:// um und entfernt das Kommentarzeichen (#) vor den folgenden Optionen:

letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['webmaster@techgoat.net'] # This should be an array of email addresses to add as contacts
letsencrypt['auto_renew'] = true
letsencrypt['auto_renew_hour'] = 2
letsencrypt['auto_renew_minute'] = 15 # Should be a number or cron expression, if specified.
letsencrypt['auto_renew_day_of_month'] = "*"

Nach dem anschließenden sudo gitlab-ctl reconfigure sollte die Gitlab-instanz auch per https erreichbar sein.

Backups

Anmerkung: das Tool rsync sollte installiert sein.

Gitlab kann Backups der aktuellen Instanz anfertigen.
Dafür kann man folgende Optionen anpassen:

gitlab_rails['manage_backup_path'] = true
gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"
gitlab_rails['backup_archive_permissions'] = 0644

Hierbei wird der Pfad angegeben, wo die Backups abgelegt werden.

Um die Einstellungen von Gitlab selbst zu speichern, welche unter /etc/gitlab liegen, sollte man, laut Gitlab, folgenden Befehl verwenden:
sudo sh -c 'umask 0077; tar -cf $(date "+etc-gitlab-%s.tar") -C / etc/gitlab'

Ein Backup der vorhandenen Repos wird mit dem Gitlab-eigenen Befehl gitlab-rake gitlab:backup:create erstellt:

$  gitlab-rake gitlab:backup:create
Dumping database ... 
Dumping PostgreSQL database gitlabhq_production ... [DONE]
done
Dumping repositories ...
 * rasputin/Scripte ... [DONE]
[SKIPPED] Wiki
 * rasputin/progress ... [DONE]
[SKIPPED] Wiki
 * rasputin/golang ... [DONE]
[SKIPPED] Wiki
 * rasputin/Command-line-text-processing ... [DONE]
[SKIPPED] Wiki
 * rasputin/whirlpool ... [DONE]
[SKIPPED] Wiki
 * rasputin/cryptopasta ... [DONE]
[SKIPPED] Wiki
done
Dumping uploads ... 
done
Dumping builds ... 
done
Dumping artifacts ... 
done
Dumping pages ... 
done
Dumping lfs objects ... 
done
Dumping container registry images ... 
[DISABLED]
Creating backup archive: 1535530788_2018_08_29_11.2.3_gitlab_backup.tar ... done
Uploading backup archive to remote storage  ... skipped
Deleting tmp directories ... done
done
done
done
done
done
done
done
Deleting old backups ... skipping

Das neu erstellte Backup befindet sich nun im dafür festgelegten Ordner:

$ ls -lha /var/opt/gitlab/backups
insgesamt 17M
drwx------  2 git  root 4,0K Aug 29 10:19 .
drwxr-xr-x 21 root root 4,0K Aug 29 07:37 ..
-rw-------  1 git  git   17M Aug 29 10:19 1535530788_2018_08_29_11.2.3_gitlab_backup.tar

Diese Backups lassen sich auch z.B. nach Amazon S3 hochladen, entsprechende Optionen dafür finden sich in der /etc/gitlab/gitlab.rb.
Weitere Informationen zum Backup und Restore findet man hier: docs.gitlab.com

Troubleshooting

Um zu prüfen ob die SSH-Verbindung ordnungsgemäß funktioniert verwendet man:

ssh -T git@<gitlab.domainname.tld>
Welcome to GitLab, @rasputin!

Fehler: trotz hinterlegter SSH-Keys wird für den Benutzer git ein Passwort verlangt
Lösung: usermod -p '*' git damit löscht man das Passwort für den Benutzer git. Das hat den Nachteil das man anschließend kein Passwort mehr für den Benutzer vergeben kann.
Alternativ dazu legt man in der sshd_config fest das für den Benutzer git keine Authentifizierung per Passwort erfolgen soll:

    Match User git
        PasswordAuthentication no

Autor
Kategorien Gitlab, Linux

PRTG Map