</TECH NEWS>
NEUESTES VON UNSEREN ENTWICKLERN:

25.04.2019 – von Eike Eschmann|

GitLab-Migration und Anbindung an die Google Cloud

GitLab ist ein mächtiges, vor allem aber umfangreiches Werkzeug und ist dabei, die DevOps Welt elegant zu vereinfachen.
Es bietet sowohl eine On-Premise Lösung als auch eine Managed Lösung an. Preislich sind beide Lösungen identisch, mit dem Unterschied, dass bei der Managed Lösung Updates und die Umgebung bereitgestellt wird. GitLab bringt von Haus aus eine integrierte CI/CD Unterstützung mit und harmoniert mit den Repositories und der webeigenen Oberfläche.

Auch wir, die Entwicklung der SH Telekommunikation Deutschland GmbH, haben uns dafür entschieden, GitLab als Versionsverwaltungssystem zu verwenden. Unsere Entwicklungsabteilung besteht aus mehreren Teams, welche unterschiedliche Versionsverwaltungssysteme benutzten. Alle Entwickler haben vor den jeweiligen Migrationen bereits Zeit erhalten, ihre Accounts bei GitLab.com einzurichten und einen SSH Key zu hinterlegen. Für die zusätzliche Accountsicherheit wurde Two-factor authentication für alle beteiligten Projekt Mitglieder eingeführt. Die Migration der Projekte hat jedoch auf unterschiedliche Weise statt gefunden.

GitLab-Migration

Die B2B Plattformen sind hauptsächlich in Java geschrieben und wurden bereits in einer GitLab CE Variante betrieben. Einige Projekte wurden in einem Jenkins 2 gebaut. Neuere Projekte hingegen wurden bereits mit der GitLab CI Build Pipeline erstellt und ausgeliefert. Sowohl die GitLab CE als auch die GitLab CI Runner wurden selbst gehostet und gewartet. Die Migration aller Projekte verlief reibungslos. Mit einem relativ einfachen Bash Script wurden alle Branches der Projekte auf „protected“ gesetzt, exportiert und in GitLab.com importiert. Die Entwickler auf den Projekten mussten somit nur noch die Upstream Url der lokalen Repositories auf GitLab.com setzen und konnten mit den Projekten wie gewohnt weiter arbeiten. Die bestehenden Build Pipelines des Jenkins wurden ebenfalls auf die neue GitLab Url angepasst, sodass die Build Prozesse wie gewohnt weiter laufen konnten. Eine Umstellung der Projekte auf GitLab CI Build Pipelines erfolgte dann schrittweise. Die GitLab CE Umgebung und die Runner konnten anschließend abgeschaltet werden.

Anders hingegen wurde die Plattform des Endkundenportals Sparhandy umgezogen. Für Sparhandy wurde das Versionsverwaltungstool Bitbucket von Atlassian verwendet. Den Buildprozess hatte noch ein Jenkins 1 übernommen. Für die Migration von Bitbucket nach GitLab wurde initial das Repository von Bitbucket ins GitLab importiert. Es erfolgte eine schleichende Migration des Projektes, in dem Feature und Bugfix Branches, die in den Master Branch gemerged wurden, in den Master Branch nach GitLab gesynced wurden. Der Buildprozess wurde dahin angepasst, dass der Master Branch nicht mehr im Jenkins gebaut wurde. Stattdessen werden Änderungen im Master Branch per GitLab CI gebaut und bereitgestellt. Die Abschaltung des Jenkins und Bitbucket erfolgte dann zeitgleich, als die letzten offenen Merge Requests bearbeitet wurden und in den Master nach GitLab gesynced wurden.

Jenkins und GitLab

Ähnlich wie GitLab CE und Bitbucket wurden die Jenkins Instanzen selbst verwaltet. Einige Updates liefen schwer von statten, da beispielsweise einige Plugins nicht voll kompatibel gewesen sind oder etwas an den Build Pipelines geändert werden musste. Mit der Umstellung auf die Managed GitLab Umgebung fallen diese Komponenten mit einem Schritt weg. Keine lästigen Updates mehr, keine Kompatibilitätsprobleme mit den installierten Plugins und keine Server Probleme auf die man selber reagieren muss.

Jedoch musste durch die Verwendung eines Managed GitLab auch das Setup etwas angepasst werden. Wir benutzen eigene GitLab Runner in einem separaten Kubernetes Cluster in der Google Cloud. Über eine VPN können die GitLab Runner mit dem aktuell noch im Haus gehosteten Artifactory kommunizieren und Artefakte unterschiedlichster Art abrufen oder auch ablegen. Das Deployment erfolgt dann per helm charts und über die GitLab Runner.

Mehr Flexibilität gewannen wir durch den Umfang der Features in den GitLab Build Pipelines. So konnten Aktionen ausgeführt werden, wenn es Änderungen in bestimmten Pfaden gab, oder anders herum Aktionen aussetzen, wenn bestimmte Pfade nicht geändert wurden. Artefakte konnten über die Stages hinweg verwendet werden und ohne weitere Ergänzungen auch aus dem GitLab UI heruntergeladen werden. Eine einfache Integration der Umgebungen ist ebenfalls über Environment Attribute gegeben und die ausgerollten Applikationen verlinkt. Um mal einige zu nennen. Natürlich profitieren wir von vielen weiteren Features.

Die Umstellung auf die GitLab Runner in der Cloud verlief nicht ganz ohne Probleme. Jedoch konnten alle Herausforderungen gelöst werden. Eine dieser Herausforderungen war die VPN Verbindung zwischen dem Google Cloud und dem internen Netzwerk. Trotz bestehender Verbindung zwischen beiden Netzwerken, konnten keine Packages gesendet oder empfangen werden. Hier wurde für die Phase 2 ein nicht unterstützter Cipher in der Verschlüsselung verwendet. Die Pakete wurden also trotz bestehender Vebindung einfach verworfen. Ein genauer Blick in die Dokumentation und eine Anpassung der Konfiguration halfen, das Problem zu lösen.

Was ebenfalls zu Problemen führten, war die Standard Konfiguration der GitLab Runner. Builds mit den neuen GitLab Runnern benötigten plötzlich das 4-5 fache an Zeit. Teilweise erreichten die Builds den default Timeout von einer Stunde. Mit Zuweisung von mehr Resourcen für die GitLab Runner Services wurden die Builds auch wieder schneller und erreichten auch die altbekannten Buildzeiten.

Fazit

Mit der Umstellung auf GitLab und Google Cloud haben wir unsere Infrastruktur und Buildpipelines vereinfacht und vereinheitlicht. Es müssen keine Komponenten mehr in unserer internen Infrastruktur gewartet und betrieben werden da GitLab CE, Bitbucket und beiden Jenkins Instanzen wegfallen. Die Build Prozesse als auch die Tools wurden zu einem zusammen gedampft, und können einheitlich über die Teams hinweg genutzt werden. Auch die GitLab Runner in der Cloud laufen zu lassen, ist dank der Dokumentation mit wenigen Kniffen konfiguriert. Es ist jetzt ein leichteres die Umgebungen zu erweitern, da wir durch die Cloud einiges an Flexibilität gewonnen haben. Ein Umzug des Artifactory in die Google Cloud steht noch aus und könnte die Infrastruktur noch einen weiteren Schritt vereinfachen. Sobald der Umzug stattgefunden hat, können wir von automatisierten Skalierungen weiter profitieren.



WEITERE SPANNENDE BEITRÄGE



Unternehmen Marken Team Presse Karriere Tech-Blog SH Händler-Shop