NETWAYS Blog

Wer GitLab CE produktiv im Einsatz hat und mit den zusätzlichen Features der EE Version liebäugelt, der wird sich beim Umstieg zwangsläufig mit den Migrationsschritten auseinandersetzen, sofern der GitLab Server nicht von einem Hoster betreut wird. In diesem Post zeige ich, wie der Wechsel inklusive Migration auf einen anderen Server gelingen kann und beziehe mich dabei auf die Omnibus Version basierend auf Ubuntu 18.04. Der Ablauf ist gar nicht so kompliziert. Bügelt man die EE-Version einfach über die aktuelle CE Version, dann hat man nur zwei Schritte zu beachten. Wenn man allerdings einen EE Server parallel hochzieht, um dann auf diesen zu migrieren, so kommen ein paar mehr Schritte hinzu.
Deshalb zeige ich im Folgenden wie man per Backup und Restore auch zum Ziel kommt. Die ersten Schritte sind ziemlich identisch mit dem, was GitLab vorgibt.

1. Zuerst erstellt man sich ein Backup:

   gitlab-rake gitlab:backup:create STRATEGY=copy

   Einfach um sich den aktuellen Stand vor der Migration zu sichern.
   Hier kann nicht viel schief gehen. Man sollte aber darauf achten, dass genügend Speicherplatz unter /var/opt/gitlab/backups zur Verfügung steht. Es sollten mindestens noch zwei Drittel des Speicherplatzes frei sein. Das resultierende Tar-Archiv sollte man sich anschließend weg kopieren, da im weiteren Verlauf ein weitere Backup erstellt wird.

2.  Nun führt man das Script von GitLab aus, das die apt-Sourcen hinzufügt und ein paar benötigte Pakete vorinstalliert:

   curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash

3. Jetzt checkt man noch kurz welche Versionsnummer von GitLab CE momentan installiert ist:

   dpkg -l |grep gitlab-ce

4. Danach installiert man die GitLab EE Version. Dabei wird die CE Version gelöscht und eine Migration durchgeführt. Um den Versionsstand kompatibel zu halten, verwendet man die gleiche Versionsnummer wie aus dem vorherigen Schritt. Lediglich der teil ‚ce‘ wird zu ‚ee‘ abgeändert:

   apt-get update && sudo apt-get install gitlab-ee=12.1.6-ee.0

5. Nun erstellt man erneut ein Backup:

   gitlab-rake gitlab:backup:create STRATEGY=copy

6. Das neu erstellte Backup transferiert man einschließlich der Dateien /etc/gitlab/gitlab-secrets.json und /etc/gitlab/gitlab.rb auf den EE Server. Das lässt sich z.B. per scp bewerkstelligen:

   scp /var/opt/gitlab/backups/*ee_gitlab_backup.tar ziel-server:./
   scp /etc/gitlab/gitlab-secrets.json ziel-server:./
   scp /etc/gitlab/gitlab.rb ziel-server:./

7. Auf dem Zielserver sollte man natürlich GitLab EE in der entsprechenden Version installieren. Hier hält man sich am besten an die offizielle Anleitung. Nicht vergessen bei der Installation die Versionsnummer anzugeben.
8. Jetzt verschiebt man die Dateien die man per scp transferiert hat und setzt die Dateiberechtigungen:

   mv ~/*ee_gitlab_backup.tar /var/opt/gitlab/backups
   mv ~/gitlab-secrets.json ~/gitlab.rb /etc/gitlab/
   chown root:root /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb
   chown git:git /var/opt/gitlab/backups/*ee_gitlab_backup.tar

9. Dann startet man den Restore:

   gitlab-rake gitlab:backup:restore

   Man quittiert die einzelnen Abfragen mit ‚yes‘. Hat sich die URL für den neuen EE Server geändert, dann sollte man das in der /etc/gitlab.rb anpassen. In diesem Fall sind auch Änderungen an den GitLab Runnern vorzunehmen. Es reicht dann allerdings wenn man auf dem jeweiligen Runner in der Datei config.toml die URL in der [[runners]] Sektion anpasst, da der Token gleich bleibt.

Troubleshooting:

Es ist allerdings auch möglich, dass es zu Problemen mit den Runnern kommt. Dies zeigt sich z.B. dadurch, dass der Runner in seinen Logs 500er-Fehler beim Verbindungsversuch zum GitLab meldet. In diesem Fall sollte man zuerst versuchen den Runner neu zu registrieren. Falls die Fehler bestehen bleiben, ist es möglich, dass diese durch einen CI-Job verursacht werden, der während der Migration noch lief. So war es zumindest bei mir der Fall. Mit Hilfe der Anleitung zum Troubleshooting und den Infos aus diesem Issue kam ich dann zum Ziel:

gitlab-rails dbconsole
UPDATE ci_builds SET token_encrypted = NULL WHERE status in ('created', 'pending');

Wenn man sich das alles sparen möchte, dann lohnt es sich einen Blick auf unsere GitLab EE Angebote der NETWAYS Web Services zu werfen.

Gabriel Hartmann

Senior Systems Engineer

---

Gabriel hat 2016 als Auszubildender Fachinformatiker für Systemintegrator bei NETWAYS angefangen und 2019 die Ausbildung abgeschlossen. Als Mitglied des Web Services Teams kümmert er sich seither um viele technische Themen, die mit den NETWAYS Web Services und der Weiterentwicklung der Plattform zu tun haben. Aber auch im Support engagiert er sich, um den Kunden von NWS bei Fragen und Problemen zur Seite zu stehen.

Lies mehr von Gabriel und triff unser Team