GitLab Managed Apps war eine Funktion der Kubernetes-Integration der Plattform Dies ermöglichte die Installation gängiger Cluster-Apps mit einem Klick. Diese Iteration der Funktion wurde während des Veröffentlichungszyklus von GitLab 13 eingestellt und in der Version 14.0 vom Juni vollständig entfernt. So migrieren Sie Ihre verwalteten Apps zu einem unterstützten Bereitstellungsmodell.
Von verwalteten Apps wegbewegen
Verwaltet Apps wurden entwickelt, um die Inbetriebnahme eines neuen Kubernetes-Clusters zu vereinfachen. GitLab hat Vorlagen für Anwendungen wie NGINX Ingress, Cert Manager und Prometheus bereitgestellt.
Es wurden zwei verschiedene Installationsmethoden angeboten: One-Click und CI/CD. Die Ein-Klick-Methode stellte eine Benutzeroberfläche in GitLab bereit, die verfügbare Apps auflistete und Sie zum Installieren anklicken ließen. Einige Apps haben auch grundlegende Konfigurationseinstellungen verfügbar gemacht. Die CI/CD-Methode bot eine GitLab-CI-Vorlage zum Hinzufügen von Apps zu einem Cluster als Teil einer Pipeline.
Installationen mit einem Klick sind jetzt vollständig weg. Die CI-Methode bleibt funktionsfähig, ist jedoch veraltet und wird in GitLab 15.0 entfernt. Obwohl Managed Apps die Installation drastisch vereinfachten, deckten sie nur diese Phase des Lebenszyklus des Clusters ab. Apps wurden entweder installiert oder deinstalliert, sodass Sie schnell zu den regulären Kubernetes-Verwaltungstools wechseln müssen, um Wartungen und Anpassungen durchzuführen.
Trotz der Entfernung der Funktion werden vorhandene Installationen verwalteter Apps in GitLab 14.0 weiterhin funktionieren. Sie können GitLab sicher aktualisieren, ohne sich über Ausfallzeiten in Ihrem Cluster Gedanken machen zu müssen. Durch das Upgrade wird jedoch die Benutzeroberfläche für verwaltete Apps entfernt, sodass Sie Apps in GitLab nicht anzeigen oder deinstallieren können.
Übernehmen Sie die Kontrolle über Ihre Apps
Die Migration von Managed Apps erfordert nicht unbedingt eine sofortige Aktion Ihrerseits. Da Ihre Apps weiterhin betriebsbereit bleiben, können Sie sie unverändert lassen, wenn Sie damit zufrieden sind, dass sie im Namespace gitlab-managed-apps bleiben.
Werbung
Da die Apps einfach Helm simply sind Bereitstellungen in Ihrem Cluster können Sie diese mit den Befehlszeilenbinärdateien kubectl und Helm verwalten. Sie werden als normale Kubernetes-Ressourcen angezeigt.
Mit diesem Kubectl-Befehl können Sie Clusterressourcen auflisten, die von GitLab installiert wurden:
kubectl get all -n gitlab-managed-apps
Auf diese Weise können Sie überprüfen, was in Ihrem Cluster ausgeführt wird, wenn GitLabs alte “Anwendungen” Seite.
Bei alten installierten Apps können Probleme auftreten GitLab-Versionen. Diese wurden möglicherweise mit Helm v2 hinzugefügt, das nicht mit modernen Helm v3-Clients kompatibel ist. Wenn Sie nicht sicher sind, ob Sie v2-Apps installiert haben, verwenden Sie den folgenden Befehl, um dies zu überprüfen:
kubectl get all -n gitlab-managed-apps | grep 'helm.sh/release'
Apps, die in der Ausgabe dieses Befehls angezeigt werden, wurden von Helm v3 installiert. Vergleichen Sie die Liste mit dem früheren Befehl get all, um von Helm v2 hinzugefügte Apps zu identifizieren.
Werbung
Wenn sich herausstellt, dass Ihre Apps Helm v2 verwenden, müssen Sie den Helm-Migrationsleitfaden manuell durchgehen, um sie auf den neuesten Stand zu bringen. Es wird empfohlen, zu Helm v3 zu wechseln, wenn Sie die Apps langfristig behalten möchten. Alternativ können Sie durch die Installation von Helm v2 auf Ihrem Computer mit den Apps interagieren, um sofortige Fehlerbehebungen und Wartungen durchzuführen.
Upgrade auf Das neue Cluster-Apps-Modell von GitLab
Das übergeordnete Ziel von Managed Apps – Vereinfachen der Cluster-Einrichtung – wurde von GitLab nicht vollständig verworfen. GitLab 14.0 konzentriert sich auf Cluster-“Managementprojekte” als neues Bereitstellungsmodell für die Clusterbereitstellung.
GitLab bietet eine Projektvorlage, mit der Sie Apps in Kubernetes-Clustern installieren können. Dadurch werden die ursprünglichen Probleme mit Managed Apps behoben, indem sichergestellt wird, dass Sie die volle Kontrolle über die bereitgestellten Helm-Diagramme haben. Sie klonen die Vorlage, verbinden das Projekt mit Ihrem Cluster und bearbeiten und löschen dann die einzelnen App-Diagramme nach Bedarf. Durch das Ausführen einer CI-Pipeline werden die ausgewählten Apps in Ihrem Cluster bereitgestellt.
Sie können vorhandene verwaltete Apps in das Verwaltungsprojektformat migrieren. Auf diese Weise können Sie sie mit einem von GitLab unterstützten Ansatz weiter betreiben. Wir gehen davon aus, dass Sie aufgrund Ihrer vorhandenen Bereitstellungen bereits einen Kubernetes-Cluster mit Ihrer GitLab-Instanz verbunden haben.
Beginnen Sie mit dem Erstellen eines neuen GitLab-Projekts mit dem Plus-Button oben rechts. Klicken Sie auf “Aus Vorlage erstellen” und scrollen Sie dann nach unten zum “GitLab Cluster Management” Schablone. Klicken Sie auf die Schaltfläche “Vorlage verwenden” Taste. Geben Sie auf dem nächsten Bildschirm Ihrem Projekt einen Namen und klicken Sie auf “Projekt erstellen.”
Die Vorlage enthält eine Reihe von Helm-Diagrammen zum Bereitstellen von Apps in Ihrem Cluster. Die einzelnen App-Charts werden im Anwendungsverzeichnis gespeichert. Jede App bekommt ihr eigenes Unterverzeichnis.#
Werbung
Beginnen Sie mit der Bearbeitung von helmfile.yaml im Stammverzeichnis Ihres Projekts, entweder in der GitLab-Web-IDE oder indem Sie das Repository mit Git klonen. Diese Datei verweist auf die einzelnen Anwendungsvorlagen. Aktivieren Sie die von Ihnen verwendeten Anwendungen, indem Sie die entsprechenden Zeilen auskommentieren. In diesem Beispiel haben wir Ingress und Cert Manager zuvor als von GitLab verwaltete Apps installiert, sodass wir sie im Cluster-Management-Projekt aktivieren.
Als Nächstes müssen Sie herausfinden, welche Diagrammversion bereits in Ihrem Cluster bereitgestellt ist. Dieser Schritt ist wichtig, damit Sie Ihre App nicht versehentlich durch eine andere Version ersetzen.
Sie können die Version einer App abrufen, indem Sie helm ls -n gitlab-managed-apps ausführen. Suchen Sie in der Ausgabetabelle nach der App und notieren Sie die in der Spalte CHART angezeigte Version. Dies nimmt das Format App-Name-X.Y.Z an; Sie benötigen nur den X.Y.Z-Teil.
Kehren Sie zu Ihrem neuen GitLab-Projekt zurück und öffnen Sie die mit der Anwendung verknüpfte helmfile.yaml, z. B. applications/ingress/helmfile.yaml. Ändern Sie das Versionsfeld so, dass es der notierten Version entspricht.
Ersetzen Sie schließlich die default values.yaml durch Ihren vorhandenen Satz von Helm-Werten. Verwenden Sie Helm, um die YAML-Darstellung der Wertedatei Ihrer App zu laden:
helm get values ingress -n gitlab-managed-apps -a –output yaml
Ersetzen Sie eingehenden Traffic durch den Namen der Bereitstellung Ihrer App. Kopieren Sie die gesamte YAML-Ausgabe und verwenden Sie sie, um die Datei applications/ingress/values.yaml zu überschreiben. Stellen Sie sicher, dass Sie den Dateipfad an Ihre App anpassen. Jetzt können Sie die Bereitstellung des Clusterverwaltungsprojekts ausführen.
Werbung
Eine Bereitstellungspipeline wird automatisch gestartet, wenn Sie Ihre Änderungen im Standardzweig zusammenführen (was normalerweise für neue Projekte in GitLab 14.0) wichtig ist. Verwenden Sie Git, um Ihre Änderungen zu übernehmen und zusammenzuführen in:
git checkout -b my-branch git add . git commit -m “Bestehende GitLab Managed Apps migrieren” git checkout main git merge my-branch git push -u origin main
Die Pipeline wird ausgeführt. Wenn die Vorlagenänderungen korrekt waren, sollte dies keine Auswirkungen auf Ihre laufenden Anwendungen haben. Einige harmlose Metadaten können geändert werden, wenn sich der Bereitstellungsmechanismus ändert.
Sie können jetzt das Clusterverwaltungsprojekt für die laufende Wartung Ihrer Apps verwenden. Sie können beispielsweise auf eine neue Version einer App aktualisieren, indem Sie das Versionsfeld in der Datei helmfile.yaml bearbeiten. Das Zusammenführen der Änderung in main würde Helm dazu veranlassen, die Änderungen in Ihrem Cluster anzuwenden.
Schlussfolgerung
GitLab Managed Apps halfen vielen Benutzern, ihre ersten Schritte mit Kubernetes zu machen. Die Einfachheit der Funktion erwies sich jedoch letztendlich als zu einschränkend, sodass sie jetzt in einem mehrstufigen Prozess entfernt wird.
Glücklicherweise ist es ziemlich einfach, die Migration abzuschließen von verwalteten Apps. Sie haben nichts Besonderes – Es handelt sich lediglich um reguläre Helm-Bereitstellungen, die sich zufällig im Namespace gitlab-managed-apps Ihres Clusters befinden. Dies bedeutet, dass Ihre Workloads auch nach einem Upgrade auf GitLab 14.0 verfügbar bleiben, sodass Sie in Ihrem eigenen Tempo umsteigen können.
In Zukunft sind Cluster-Management-Projekte der bevorzugte Ansatz, um mit GitLab beliebte Apps zu installieren Kubernetes. Dieses Modell ist zwar technisch etwas anspruchsvoller, bietet Ihnen jedoch viel mehr Kontrolle und hilft Ihnen, Ihre Infrastruktur als Code zu verwalten.