Ich möchte hier kurz einen Erfahrungsbericht zum aktualisieren von Gitlab (Community Edition) - hier als docker-Container installiert - über mehrere Major-Releases wiedergeben. In meiner Umgebung habe ich gitlab als Docker-Installation übergeben bekommen, die mittels docker-compose eingerichtet ist.
Das hier ist die docker-compose.yml:
Code: Alles auswählen
version: "2"
services:
gitlab:
image: 'gitlab/gitlab-ce:14.8.6-ce.0'
restart: "no"
container_name: gitlab
hostname: 'git.xxx.de'
ports:
- '127.0.0.1:7080:80'
- '127.0.0.1:7081:81'
- '127.0.0.1:7082:82'
- '22:22'
volumes:
- '/srv/gitlab/config:/etc/gitlab'
- '/srv/gitlab/logs:/var/log/gitlab'
- '/srv/gitlab/data:/var/opt/gitlab'
privileged: true
Datensicherung
Vor dem Upgrade habe ich erst einmal eine Sicherung gemacht. Der Einfachheit halber habe ich den Docker-Container beendet und mit tar (tar --preserve-permissions --numeric-owner) das Datenverzeichnis (hier ~20 GB) gesichert. Alternativ ginge das auch mit:
Code: Alles auswählen
docker exec gitlab gitlab-rake gitlab:backup:create
# restore: docker exec -it gitlab gitlab-rake gitlab:backup:restore RAILS_ENV=production BACKUP=timestamp_of_backup
Dokumentation zum Upgrade
Upgradepfad beachten
Wichtig ist bei mehreren Upgrade zunächst, dass der Upgrade Pfad eingehalten wird, gemäß hier:
https://docs.gitlab.com/ee/update/#upgrade-paths
Meine Vorversion war 14.8.6 und ich wollte hoch bis zur aktuellen Version 16.x. Unter obigem Link stand dann auch die Zeile:
Code: Alles auswählen
GitLab 15: 15.0.5 > 15.1.6 (for GitLab instances with multiple web nodes) > 15.4.6 > 15.11.x
DB-Migrationen im Hintergrund müssen durchlaufen
Manche Anpassungen an der Datenbankstruktur, auch Migrationen genannt, laufen im Hintergrund. Diese müssen jeweils komplett durchlaufen, bevor das nächste Release eingespielt werden kann.
Dazu liefert die in der Doku verlinkte Seite:
https://docs.gitlab.com/ee/update/backg ... tions.html
entsprechende Befehle, die die aktuellen Jobs anzeigen. Welche ich in Schleife in ein Script gepackt habe, um den aktuellen Status zu sehen:
Code: Alles auswählen
#!/bin/bash
while :;do
echo "$(date) : new run..."
echo "$(date) : background jobs remaining $(docker exec -ti gitlab gitlab-rails runner -e production 'puts Gitlab::BackgroundMigration.remaining')"
echo "$(date) : background jobs queued $(docker exec -ti gitlab gitlab-rails runner -e production 'puts Gitlab::Database::BackgroundMigration::BatchedMigration.queued.count')"
# the following only for version 14.0 - 14.9
#echo "$(date) : failed migrations $(docker exec -ti gitlab gitlab-rails runner -e production 'puts Gitlab::Database::BackgroundMigration::BatchedMigration.failed.count')"
# the following only for version >= 14.10
echo "$(date) : failed migrations $(docker exec -ti gitlab gitlab-rails runner -e production 'puts Gitlab::Database::BackgroundMigration::BatchedMigration.with_status(:failed).count')"
sleep 1
done
Diese einzelnen gitlab-rails-Kommandozeilenbefehle haben eine Ausführungszeit von ca. 1-2 Minuten (!!!). Bei mir waren vor dem Upgrade direkt fehlerhafte Migrationen vorhanden. Man kann im gitlab-Webinterface unter Admin -> Monitoring -> Background Migrations diese Migrationen nochmal anstarten, falls es fehlerhafte Migrationen gab. Es dauert teilweise 10-60 Minuten bis bei einem Release-Upgrade diese Migrationen abgeschlossen sind.
Die Dokumentation beschreibt außerdem, was man bei erweiterten Setups noch zusätzlich beachten hat, z. B. wenn man Elasticsearch integriert hat.
Grundsätzliche auftretende Fehler
gitlab reconfigure bricht ab
Ab und an ist der Docker-Startprozess inkl. der Chef-Scripte einfach mal abgebrochen und der Container war gestoppt. In dem Fall kann man den Container einfach erneut starten (docker restart gitlab) und es läuft an der Stelle weiter, wo es brach. Ich vermute, da stimmt in der Chef-Logik bzw. Reihenfolge etwas nicht und beim nächsten Start war dann die Voraussetzung einfach da. Da die Chef-Scripte von den Programmierern ja hoffentlich "idempotent" ausgelegt sind, d. h. bei mehrfachem Ausführen immer das gleiche Ergebnis liefern, sollte das in Ordnung sein.
Datenbankmigrationen schlagen fehl
Im Anfangszustand waren bei mir bereits fehlgeschlagene Migrationen vorhanden, die ich nicht nochmal erfolgreich durchführen konnte. Im Verlauf des Updateprozesses habe ich neu auftretende fehlgeschlagene Migrationen erfolgreich über das Webinterface neu angestartet und durchgeführt.
Durchführung der Upgrades
Gemäß des Upgradepfades suche ich mir also vom Docker-Hub das neueste Docker-Tag / Minor Release von gitlab/gitlab-ce. (Docker-Hub ist aber eigentlich nicht notwendig. Die Releases hiessen alle, so wie im Upgrad-Pfad angegeben, mit angehängtem Literal "-ce.0". Aber sicherheitshalber würde ich trotzdem nochmal nachschauen, vielleicht gibt's da dann doch nochmal ein anderes Tag. Einen Kommandozeilenbefehl, mit dem ich mir alle Tags für gitlab/gitlab-ce holen kann, habe ich auch nicht gefunden, bzw. die API Nutzung nicht richtig verstanden.)
Anschließend gehe ich dann in das Verzeichnis, in dem meine docker-compose.yml liegt und setze das neue Tag ein.
Vor dem Upgrade sah meine docker-compose.yml so aus:
Code: Alles auswählen
...
gitlab:
image: 'gitlab/gitlab-ce:14.8.6-ce.0'
...
Code: Alles auswählen
...
gitlab:
image: 'gitlab/gitlab-ce:14.9.5-ce.0'
...
Code: Alles auswählen
docker-compose pull # holt ggf. das erforderliche neue Image
docker-compose up -d # Erstellt den Container neu und startet diesen
Code: Alles auswählen
docker logs gitlab -f
Sobald die Backgroundmigrationen alle erfolgreich durchgelaufen sind, gehe ich zum nächsten Release. Sind Migrationen fehlgeschlagen, versuche ich die gemäß obiger Verfahrensweise im WebUI nochmal anzustarten.
Teilweise habe ich zwischendurch noch zusätzliche Datensicherungen durchgeführt. Könnte sein, dass ein Update-Schritt fehlschlägt und dann müsste ich mit Zwischenbackup nur an der Stelle des letzten Backups fortfahren und nicht nochmal komplett von vorne beginnen.
Der Upgradevorgang für 6 neue Major-Versionen hat ca. 6 Zeitstunden gedauert (Mit notwendigem Restore zwischendurch).
Nachtrag 12:13
Als gitlab-version einfach gitlab/gitlab-ce:latest zu nehmen hatte ich kurzzeitig so, ist recht schnell gebrochen.