[Erfahrungsbericht] Gitlab/Docker über mehrere Major-Releases aktualisieren

[heisenberg]

Das Anliegen

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 

Grundsätzlich ist gitlab eine recht komplexe Angelegenheit. Bei jedem starten des gitlab-Containers laufen sehr komplexe Chef-Scripte ab, die das ganze Konstrukt jeweils neu konfigurieren - sofern benötigt. D. h. die Scripte laufen immer. Aber jedes einzelne Element des Skriptes prüft, ob eine Ausführung der aktuellen Anweisung notwendig ist und führt diese dann bei Bedarf aus - Genau so wie Opscode Chef eben funktioniert. Im Docker-Container läuft auch ein Service-Manager, der ein gutes Dutzend an Diensten (Postgres, Redis, Puma, Prometheus, Mattermost, ... ) betreibt.

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

Diese letztere Prozedur habe ich aber nicht getestet.

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

Als ich die Version 15.1.6 aktiviert hatte, ist das Upgrade nicht erfolgreich durchgelaufen. Irgend ein Ruby on Rails-Prozess in den Chef-Scripten ist mit Fehler abgebrochen. Mehrfaches ausführen hat immer wieder zum gleichen Fehler geführt. Also habe ich wieder die Vorversion (15.0.5) aktiviert, den Container hochgefahren und danach die 15.1.6 ausgelassen und bin direkt zur 15.4.6 gesprungen. Damit hat das funktioniert. Die 15.1.6 darf also nicht eingespielt werden bei meinem Setup. Das geht für mich aus dieser Zeile zwar nicht hervor - aber egal.

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

Das obige Script lasse ich nebenbei beim Start des Docker-Containers mitlaufen und sehe dann, wann der Container bereit ist für das nächste Upgrade.

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'
...

Für den ersten Update-Schritt habe ich die Datei geändert zu:

Code: Alles auswählen

...
gitlab:
    image: 'gitlab/gitlab-ce:14.9.5-ce.0'
...

Anschließend führe ich aus:

Code: Alles auswählen

docker-compose pull # holt ggf. das erforderliche neue Image
docker-compose up -d # Erstellt den Container neu und startet diesen

Ich beobachte gleichzeitig mit

Code: Alles auswählen

docker logs gitlab -f

den Konfigurationsprozess und auf einem anderen Terminal lasse ich das obige Script für die Beobachtung der Background-Jobs laufen.

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.

[whisper]

danke für deinen Bericht. Nahezu dasselbe habe ich auch in der Pipeline, nur noch älterer Ursprung.

[whisper]

Ich habe jetzt erfolgreich ein Gitlab von 11.10.4 bis 16.3.7 upgegradet.
Wer Interesse hat kann mein Tagebuch mal ansehen.

https://daucity.de/de/docker/gitlab
Hinweise von euch auf Fehler, bzw. Strukturierung oder weiteres nehme ich gerne entgegen.