Automatisierung des GitLab-Betriebs in Kubernetes-Umgebungen GitLab Operator mit OpenShift-Unterstützung

Wer GitLab auf Basis von Kubernetes in einer OpenShift-Umgebung bereitstellen und betreiben möchte, profitiert vom sogenannten GitLab Operator. Bereits seit Anfang des Jahres ist das Tool als Beta in die DevOps-Umgebung integriert, nun ist es generell verfügbar.

Firmen zum Thema

ConSol Consulting & Solutions Software GmbH

PresseBox - unn | UNITED NEWS NETWORK GmbH

OutSystems

Anfang dieses Jahres wurde GitLab 13.1 zusammen mit der Beta-Version des GitLab-Operator veröffentlicht. In den vergangenen sechs Monaten hat GitLab eng mit dem Team von Red Hat zusammengearbeitet, um technische Details zu besprechen und ein Höchstmaß an Kompatibilität zu gewährleisten.

GitLab Operator und das Cloud Native Helm Chart werden gemeinsam als Bereitstellungslösungen für Cloud-Native-Umgebungen angeboten. Hinter den Kulissen nutzt der Operator das Helm Chart, um den IT-Betrieb nachzubilden. Der Operator bietet erweiterte Funktionen über das Cloud Native Helm Chart hinaus und bietet Produktionsunterstützung für OpenShift und Kubernetes, während das Helm Chart nur Vanilla Kubernetes unterstützt.

Anregungen für den eigenen Operator hat sich GitLab beim gleichnamigen CoreOS-Äquivalent geholt. Das Ziel eines Operators ist es, das betriebliche Wissen eines Administrators abzubilden und zu automatisieren, wobei die Software innerhalb des Clusters läuft. Initialaufgaben wie Installation und Konfiguration sowie Folgeaufgaben, wie zum Beispiel Patches und Upgrades mit minimierter Ausfallzeit, werden integriert.

Für die Zukunft plant GitLab native Upgrades ohne Ausfallzeiten, automatisches Backup-Management und Metriken-basierte Leistungsempfehlungen. In der Dokumentation zum GitLab Operator finden Sie weitere Informationen zu bekannten Einschränkungen und Voraussetzungen sowie eine vollständige Installationsanleitung.

(ID:47741496)