Managed Services & Apps GitLab Migration: Typische Fehler und wie ihr sie vermeidet

Einleitung

Moderne, kollaborative Softwareentwicklung ohne eine der großen DevOps- oder Entwicklungsplattformen ist heute selten anzutreffen – und das aus gutem Grund. Neben GitHub und Bitbucket hat sich in den letzten Jahren vor allem GitLab hervorgetan, das sich durch seine vollständig integrierte DevOps-Umgebung mit starken CI/CD-Features auszeichnet. Für viele Unternehmen ist GitLab nicht zuletzt aufgrund seines Open-Source-Ansatzes interessant, der es ermöglicht, den GitLab-Server selbst zu betreiben.

Für den Self-Hosted Betrieb auf dem eigenen Server sprechen beispielsweise die fehlende Begrenzung der Nutzer und die volle Kontrolle über die Datenhaltung, was einen Betrieb auf GitLab.com für manche Unternehmen aufgrund von Compliance- und Datenschutzanforderungen unmöglich macht. Doch wo Licht ist, da ist auch Schatten, und vielleicht gehört auch euer Unternehmen zu denen, die festgestellt haben, dass der Self-Hosted Betrieb nicht nur Zeit und Ressourcen verschlingt, sondern auch spezielles Know-how erfordert. Von der Konfiguration über den täglichen Betrieb bis hin zu den regelmäßigen Updates, die mindestens einmal im Monat durchgeführt werden sollten – all diese Aufgaben sind komplex und zeitaufwendig.

Deshalb bieten wir GitLab als Managed Service an. Unsere Kunden profitieren davon, dass wir GitLab vollständig in unserer eigenen Cloud-Umgebung betreiben – ausschließlich in deutschen Rechenzentren. Die Nachfrage nach sicherer und lokaler Datenhaltung wächst stetig, und viele Unternehmen erkennen die Vorteile dieser Lösung. So konnten wir in den letzten Jahren umfangreiche Erfahrungen bei der Migration von GitLab-Servern sammeln und möchten an dieser Stelle einige davon mit euch teilen.

Wie läuft eine GitLab Migration ab?

Eine GitLab-Migration erfordert ein sorgfältiges Vorgehen, um sicherzustellen, dass alle Daten und Konfigurationen reibungslos in die neue Umgebung übertragen werden. Der Prozess beginnt mit einer gründlichen Vorbereitung, bei der alle notwendigen Informationen und Daten gesammelt werden. Der Kunde spielt hierbei eine entscheidende Rolle, indem er die erforderlichen Details bereitstellt.

Zu den wichtigsten Informationen gehört die aktuelle GitLab-Version. Diese muss bekannt sein, um sicherzustellen, dass die Migrationsumgebung kompatibel ist. Verschiedene Versionen von GitLab haben unterschiedliche Anforderungen, weshalb eine genaue Kenntnis der Version unerlässlich ist. Wenn es größere Unterschiede zwischen der aktuellen Version und der Zielversion gibt, bedeutet das, dass zusätzliche Zeit für die Migration eingeplant werden muss. Solche Unterschiede können komplexere Anpassungen und umfassendere Tests erfordern, um sicherzustellen, dass alle Funktionen und Daten korrekt übertragen werden und reibungslos in der neuen Umgebung funktionieren.Außerdem wird ein vollständiges GitLab-Backup benötigt, das alle Datenbanken und Konfigurationen umfasst. Dieses Backup bildet die Grundlage für die Wiederherstellung der Instanz in der neuen Umgebung und dient als Sicherungskopie für den Fall, dass während der Migration Probleme auftreten.

Ein weiterer kritischer Punkt sind die GitLab Secret Files. Diese Dateien enthalten wichtige Informationen wie API-Schlüssel und Zertifikate, die für den Betrieb der Instanz notwendig sind. Ohne diese Dateien könnte die wiederhergestellte Instanz nicht ordnungsgemäß funktionieren. Schließlich müssen auch die gewünschten Hostnamen für Git und Registry bekannt sein. Diese Informationen sind notwendig, um die Netzwerk- und DNS-Einstellungen in der neuen Umgebung korrekt zu konfigurieren, damit die Benutzer nahtlos weiterarbeiten können.

Nachdem alle notwendigen Daten gesammelt wurden, wird eine dedizierte Migrations-Instanz in der neuen Umgebung eingerichtet. Diese Instanz wird zunächst so konfiguriert, dass sie exakt der aktuellen Version der GitLab-Instanz des Kunden entspricht. Das Backup des Kunden wird anschließend auf diese Instanz eingespielt, wodurch alle Projekte, Benutzer und Einstellungen wiederhergestellt werden.

Im nächsten Schritt wird die Migrations-Instanz schrittweise auf die gewünschte Zielversion aktualisiert. Diese stufenweisen Upgrades gewährleisten, dass alle Funktionen und Daten korrekt übertragen und mit der neuen Umgebung kompatibel sind. Während dieses Prozesses werden notwendige Anpassungen vorgenommen, um die optimale Leistung der Instanz sicherzustellen.

Nach Abschluss der Upgrades und Anpassungen werden Tests durchgeführt, um die Funktionalität und Datenintegrität zu überprüfen. Diese Validierungsschritte sind entscheidend, um sicherzustellen, dass nach der Migration keine Unterbrechungen oder Probleme auftreten.

Schließlich wird die Instanz in die Produktionsumgebung überführt, wobei alle Netzwerkeinstellungen korrekt konfiguriert werden. Sobald die Instanz unter den gewünschten Hostnamen erreichbar ist, wird sie vollständig in Betrieb genommen. Dieser Abschluss markiert den erfolgreichen Abschluss der Migration, wobei jeder Schritt sorgfältig durchgeführt wurde, um einen nahtlosen Übergang für die Benutzer zu gewährleisten.

Diese drei Dinge solltet ihr vor einer GitLab Migration bedenken

Wie so oft liegt der Teufel im Detail – und das gilt auch für die Migration von GitLab-Servern. Eine vollständige Auflistung aller potenziellen Fehlerquellen würde den Rahmen sprengen und wäre weder hilfreich noch besonders spannend. Stattdessen haben wir für euch drei typische Stolpersteine herausgefiltert, die uns in der Praxis immer wieder begegnen. Diese Probleme teilen eine Gemeinsamkeit: Sie können den Migrationsprozess erheblich verlängern oder verkomplizieren, sind jedoch mit der richtigen Vorbereitung problemlos vermeidbar.

1. Die Version eurer GitLab Instanz ist veraltet

Wenn die GitLab-Versionen zwischen der Quell- und der Zielumgebung nicht übereinstimmen, kann es zu Kompatibilitätsproblemen kommen, die die Migration erschweren oder unmöglich machen.

• Versionen abgleichen: Stellt sicher, dass die GitLab-Version auf der Zielumgebung exakt mit der Version auf der Quellumgebung übereinstimmt. Ihr könnt die aktuelle Version mit folgendem Befehl überprüfen:

gitlab-rake gitlab:env:info

• Update-Strategie: Wenn ein Upgrade erforderlich ist, führt es schrittweise durch und haltet euch strikt an die offiziellen GitLab-Release-Hinweise. Dies minimiert das Risiko von Problemen und gewährleistet, dass die Migration reibungslos verläuft.

2. Ihr habt eure GitLab Instanz lange nicht aufgeräumt

Ein schlankes Backup ist natürlich leichter zu migrieren, aber in der Praxis lässt sich das nicht immer umsetzen. Was jedoch fast immer möglich ist, ist ein gründliches Aufräumen – und das kann manchmal wahre Wunder bewirken.

Ein Beispiel aus der Praxis: Angenommen, ihr habt eure GitLab-Instanz bisher mit lokalem Speicher betrieben und wechselt nun zu einem Anbieter, der Object Storage verwendet. In solchen Fällen kann eine große Anzahl von Objekten – bei GitLab sind das häufig Artifacts – zu einem echten Problem werden. Das Verschieben dieser Objekte kann in Extremfällen mehrere Tage dauern. Hier zahlt es sich aus, im Vorfeld aufzuräumen. Oft werden viele dieser Artifacts gar nicht mehr benötigt. Durch ein gezieltes Entfernen überflüssiger Dateien könnt ihr die Ausfallzeiten während der Migration deutlich reduzieren.

• Regelmäßige Bereinigung: Implementiert eine regelmäßige Bereinigungsstrategie für nicht mehr benötigte Artefakte, temporäre Dateien und alte Backups.

• Automatisierung: Nutzt Skripte oder integrierte GitLab-Funktionen, um diese Bereinigung zu automatisieren. Das Einrichten von Lebenszyklus-Richtlinien für Artefakte ist hier ein gutes Beispiel, um diesen Prozess effizient zu gestalten.

3. Fehlende Konfigurationsdateien und Anpassungen

Wichtige Konfigurationsdateien werden bei Migrationen häufig übersehen, was zu Fehlkonfigurationen und Funktionsstörungen führen kann. Ebenso werden spezifische Anpassungen und Integrationen, die im Laufe der Zeit implementiert wurden, oft nicht ausreichend dokumentiert oder korrekt übertragen.

Ein Praxisbeispiel: Wenn im Zuge der Migration auch die Domain gewechselt wird, müssen die Konfigurationsdateien der GitLab Runner entsprechend angepasst werden. Diese Anpassungen müssen manuell auf den Maschinen vorgenommen werden, auf denen die Runner laufen, um sicherzustellen, dass sie weiterhin korrekt mit der neuen GitLab-Instanz kommunizieren können.

• Vergleiche und Anpassungen: Vergleicht die Konfigurationsdateien der Quell- und Zielumgebung und passt sie an, um sicherzustellen, dass alle Einstellungen korrekt übernommen werden. Dies umfasst sämtliche Anpassungen, die im Laufe der Zeit vorgenommen wurden.

• Anpassen der Runner-Konfiguration: Wenn die Domain geändert wird, müssen die Konfigurationsdateien der Runner manuell angepasst werden. Besonders relevant ist hier die Datei config.toml, die sich standardmäßig im Verzeichnis /etc/gitlab-runner/ befindet. Hier ein Beispiel, wie die URL angepasst werden kann:

sudo nano /etc/gitlab-runner/config.toml

Ändert die URL in der Datei von:

[[runners]]
name = "my-runner"
url = "https://old-domain.com/"
token = "YOUR_RUNNER_TOKEN"
executor = "shell"

zu:

[[runners]]
name = "my-runner"
url = "https://new-domain.com/"
token = "YOUR_RUNNER_TOKEN"
executor = "shell"

Speichert die Datei und startet den Runner neu, damit die Änderungen wirksam werden:

sudo gitlab-runner restart

Fazit

Eine GitLab-Migration erfordert sorgfältige Planung und präzise Durchführung, um Datenverlust und Ausfallzeiten zu vermeiden. Durch das Beachten der beschriebenen Schritte und das frühzeitige Erkennen potenzieller Stolpersteine können viele Probleme von vornherein vermieden werden. Ob es darum geht, Versionen abzugleichen, ungenutzte Artefakte zu bereinigen oder Konfigurationsdateien sorgfältig zu überprüfen – jedes Detail zählt. Mit der richtigen Vorbereitung und einer strukturierten Vorgehensweise kann der Migrationsprozess reibungslos verlaufen und eure GitLab-Instanz in der neuen Umgebung optimal funktionieren.