GitLab Docker Major Update
Es ist soweit: Die Version 15 von GitLab wurde vor einigen Wochen veröffentlicht und ich wollte bei meinem Server-Update natürlich nicht auf das Major Update verzichten. Wer ein bisschen auf meinem Blog gelesen hat, wird wissen, dass ich alle Dienste ausschließlich mit Docker auf diesem Server betreibe. Im Grund also nur (1) Container herunterfahren, (2) neues Image ziehen und (3) Container wieder hochfahren. Wenn es doch nur so einfach gewesen wäre…
GitLab reconfigure hat ein Problem festgestellt
Bei jedem Start des Containers wird ein gitlab-ctl reconfigure ausgeführt. Dieser Prozess ist für das ordnungsgemäße Starten, Importieren der Konfiguration und Überwachen der Prozesse notwendig. Betreibt man GitLab nativ auf einem Server, nutzt man diesen Befehl meistens, wenn sich irgend ein Dienst aufgehängt hat oder Änderungen an der Konfiguration vorgenommen wurden. In meinem Fall blieb dieser Prozess an einer Stelle stehen, die sonst ohne Probleme passiert wird:
There was an error running gitlab-ctl reconfigure: rails_migration[gitlab-rails] (gitlab::database_migrations line 51) had an error: Mixlib::ShellOut::ShellCommandFailed: bash[migrate gitlab-rails database] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/resources/rails_migration.rb line 16) had an error: Mixlib::ShellOut::ShellCommandFailed: Command execution failed. STDOUT/STDERR suppressed for sensitive resource
Bei der Migration der Datenbank scheint es also zu hängen. Gerade der fragilste Teil des ganzen Konstruktes…
Ich bin nicht sicher, welche Version ich vor diesem Update betrieben habe, aber es müsste 14.9.* oder 14.10.* gewesen sein. Wie groß der Sprung zu 15.1.2 ist, kann ich nicht beurteilen, aber von vorn beginnen werde ich mit Sicherheit nicht! Eine Übersicht der bisherigen Version auf Docker Basis findet man auf der offiziellen Seite im DockerHub, man muss allerdings ganz schön suchen. In GitLabs eigenem Issue-Board fand ich dann eine mögliche Lösung: Eine manuelle Migration der Daten mittels gitlab-rake Skript.
Docker exec ohne Container
Der Lösungsvorschlag ist auf eine Cluster von Docker Containern anwendbar, jedoch nicht so ganz auf meine einzeln betriebenen Container. Ich kann also kein docker exec ... ausführen, ohne einen laufenden GitLab Container zu haben. Und der will ja aufgrund des Fehlers im Startprozess nicht so wie ich.
Die Lösung dafür war ein Downgrade: Container mit Tag 14.10.5-ce.0 herunterladen und starten. Und siehe da: der nächste Fehler…
There was an error running gitlab-ctl reconfigure:
postgresql_user[gitlab] (postgresql::enable line 196) had an error: Mixlib::ShellOut::ShellCommandFailed: execute[create gitlab postgresql user] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/postgresql/resources/user.rb line 11) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '2'
---- Begin output of /opt/gitlab/bin/gitlab-psql -d template1 -c "CREATE USER \"gitlab\"" ----
STDOUT:
STDERR: psql: FATAL: the database system is starting up
---- End output of /opt/gitlab/bin/gitlab-psql -d template1 -c "CREATE USER \"gitlab\"" ----
Ran /opt/gitlab/bin/gitlab-psql -d template1 -c "CREATE USER \"gitlab\"" returned 2
Nach etwas mehr Googlen fand ich auch dafür ein offizielles Issue von GitLab. Dieser Fehler scheint schon eine längere Zeit zu existieren und es gibt wohl mehrere Lösungen, auch auf Shell-Skript Basis. Grundsätzlich wartet hier ein Skript auf die Datenbank, um mehrere Befehle darin auszuführen. Dauert das Starten von PostgreSQL allerdings zu lange, bricht es einfach ab. Die Entwickler haben allerdings mit einer Konfiguration entgegengewirkt. Dazu muss folgendes in die gitlab.rb eingetragen werden:
postgresql['max_service_checks'] = 20 postgresql['service_check_interval'] = 5 # seconds
Nach Anpassung der Parameter war genug Zeit, um den gitlab-ctl reconfigure Befehl erfolgreich zu beenden. Jetzt konnte ich per docker exec Befehl die Migration nachholen, was mir auch mit einem „Done.“ quittiert wurde. Ein Update vom aktuellen Stand auf GitLab 15.1.2 wollte allerdings noch immer nicht funktionieren. Die Logs waren allerdings hilfreich: „Bitte vorher auf 15.0.* aktualisieren“.
Also mehrfach (1) Container herunterfahren, (2) Container mit nächster Versionsnummer ziehen, (2) Starten und „rekonfigurieren“ lassen und (4) wieder mit der 1 beginnen, bis man beim aktuellsten Stand ist. Nach ein paar Stunden hat dann endlich wieder alles auf der neusten Major-Version funktioniert.
Das nächste Update wird hoffentlich etwas Admin-freundlicher.