tippapatt - stock.adobe.com
So evaluieren Sie das GitOps-Modell für Ihr Unternehmen
Für viele Firmen führt GitOps zur optimierten Softwarebereitstellung, für andere ist DevOps oder NetOps besser geeignet. Erfahren Sie, welche Faktoren Sie berücksichtigen sollten.
Für langjährige Entwickler, Softwarearchitekten und Entwicklungsmanager sind die modernen Praktiken eine wahre Fundgrube an Möglichkeiten. Wir sind von weitgehend unsystematischen Praktiken zu mehreren Systemen übergegangen, oft mit leicht unterschiedlichen Zielen.
Obwohl GitOps derzeit sehr populär und bekannt ist, ist es nur ein Beispiel für ein aufkommendes Entwicklungsmodell, und es ist kaum der einzige Ansatz für die Softwarebereitstellung. Wie bei vielen Dingen in der IT ist es wichtig, dass man nicht auf einen Trend aufspringt.
Neue Tools erhalten in der Regel viel Aufmerksamkeit, aber es besteht die Gefahr, dass Sie einen Schritt rückgängig machen müssen, wenn Sie das GitOps-Modell übernehmen, ohne sicherzustellen, dass es den Anforderungen Ihres Unternehmens entspricht. Um festzustellen, ob GitOps das Richtige für Ihr Unternehmen ist, sollten Sie es mit anderen Entwicklungsansätzen vergleichen und die folgenden Faktoren berücksichtigen.
Vergleich von GitOps mit anderen Entwicklungsansätzen
Alles, was mit dem Suffix Ops bezeichnet wird, bezieht sich auf den Betrieb, einschließlich der Integration von IT-Operationen in die Entwicklung.
DevOps ist hier das zukunftsträchtige Konzept. Der DevOps-Ansatz basiert auf der Idee, dass eine Kombination von Praktiken und Tools die effektive Umwandlung eines neuen Softwareprojekts oder einer Änderung in eine Bereitstellung unterstützen kann, die den Anforderungen eines Unternehmens entspricht.
Der Vorteil von GitOps liegt in seiner Einzigartigkeit. Unternehmen, die bereits Git als Versionskontrollsystem für die Softwareentwicklung verwenden, können das GitOps-Modell problemlos übernehmen. Die Frage, mit der sich Unternehmen konfrontiert sehen, ist, ob dieser Vorteil GitOps im Vergleich zu den verschiedenen anderen Entwicklungs- und Bereitstellungsmodellen wirklich an die Spitze bringt.
GitOps vs. DevOps
In der Praxis ist DevOps sehr umfangreich und nicht genau definiert, und es gibt so viele Unterschiede in der Umsetzung, dass es für Unternehmen schwierig sein kann, es zu verstehen. DevOps ist auch in Bezug auf den Entwicklungsbereich sehr kurz, was bedeutet, dass der Schwerpunkt eher auf der operativen Seite liegt.
GitOps verwirklicht das DevOps-Ziel der Betriebsintegration, indem es viele der Prinzipien von Infrastructure as Code(IaC) anwendet. Das GitOps-Modell verwendet Repository-Pull-Requests, die Änderungen an der Software signalisieren, um Infrastrukturänderungen und die Beziehungen zwischen Software und Infrastruktur zu berücksichtigen.
Im Gegensatz zu GitOps schreibt DevOps kein bestimmtes Repository-Verfahren oder Bereitstellungsmodell vor. Obwohl es möglich ist, mit GitOps nicht-containerisierte Anwendungen zu erstellen, verwenden die meisten GitOps-Organisationen Container, die die Konfigurationsdeklarationen mit den Images transportieren. Im Gegensatz dazu verwenden DevOps-Bereitstellungen eher Ansible, Chef oder Puppet statt eines Container-Orchestrators wie Kubernetes.
GitOps vs. NetOps
Ein weiterer Bereich, der sowohl zu DevOps als auch zu GitOps gehört, ist NetOps: die Prozesse im Zusammenhang mit der Netzwerkkonfiguration und -verbindung, die für eine Anwendung erforderlich sind.
Theoretisch könnten Teams, die einen NetOps-Ansatz verfolgen, auch Deklarationen aus einem Git-Repository abrufen. Heutzutage ist es jedoch unüblich, die Netzwerkkonfiguration in die Anwendungsbereitstellung und die Einrichtung der Infrastruktur zu integrieren, da die Netzwerkkonnektivität normalerweise statisch eingestellt wird, um eine einheitliche Konnektivität zu gewährleisten.
Wie wirkt sich GitOps auf CI/CD-Pipelines aus?
Die beste Strategie für den Vergleich von GitOps- und DevOps-Modellen besteht darin, mit der Standard-CI/CD-Pipeline zu beginnen.
Eine herkömmliche CI/CD-Pipeline zieht neuen Code aus einem Repository, erstellt ein Bereitstellungs-Image und aktualisiert dann die Bereitstellung und Orchestrierung mit dem neuen Code. Der Nachteil dieses Ansatzes besteht darin, dass die Konfiguration und Parametrisierung, die auf der Bereitstellungsebene erforderlich sind, vom Code getrennt sind, so dass es keine einzige Quelle der Wahrheit (Single Source of Truth, SSOT) gibt.
Bei GitOps besteht die einzige Änderung im Prozess darin, dass die für die Bereitstellung erforderlichen Deklarationen ebenfalls im Repository gespeichert und mit Git abgerufen werden, um den Zustand der Infrastruktur zu steuern. Im allgemeinen CI/CD-Modell sind diese Erklärungen (Declaratives) getrennt, wobei der Schwerpunkt auf der Entwicklung und dem Testen des Codes im Repository liegt.
Wann ist GitOps die richtige Wahl?
Wann ist es sinnvoll, das GitOps-Modell zu übernehmen? Es gibt sowohl positive als auch negative Anzeichen, auf die ein Unternehmen achten kann.
Wann sollte das GitOps-Modell eingesetzt werden?
Ein Anzeichen dafür, dass GitOps geeignet ist, ist die Konzentration auf Container für das Hosting. Die Mehrheit der zufriedenen GitOps-Benutzer arbeitet mit Containern und Kubernetes. Wenn Ihr Unternehmen weder Container verwendet noch in Erwägung zieht, ist GitOps möglicherweise nicht die richtige Lösung.
Ein weiterer positiver Indikator ist die Bedeutung von IaC in Ihrem Betrieb. Wenn Ihre Anwendungsänderungen regelmäßig Änderungen an den Bereitstellungserklärungen erfordern, wird GitOps wahrscheinlich hilfreich sein. Wenn jedoch die meisten Anwendungsänderungen keine Infrastrukturkonfiguration erfordern, ist der Nutzen von GitOps begrenzt.
Wann man das GitOps-Modell nicht verwenden sollte
Ein negativer GitOps-Indikator ist ein starker Fokus auf die Bereitstellung von Microservices und eine umfassende Komponentisierung. Unternehmen, die Cloud-Anwendungen aus Microservices und zustandslosem (stateless) Betrieb aufbauen, neigen dazu, die Bereitstellungsanforderungen zu standardisieren, um Ressourcen möglichst effizient zu nutzen. In solchen Fällen ist GitOps weniger nützlich.
Ein zweites negatives Signal für GitOps ist die strikte Anforderung, ein anderes Repository-Modell für den Entwicklungsteil der Anwendungspipeline zu unterstützen. Mehrere Repositorys in einem Prozess zu haben, der einen reibungslosen Übergang von der Entwicklung zur Bereitstellung gewährleisten soll, ist fast immer ein Fehler. Wenn es keine praktische Möglichkeit gibt, Ihre Repository-Strategie auf Git umzustellen, sollten Sie sich andere IaC-Optionen ansehen.
Tipps für eine erfolgreiche Einführung von GitOps
Selbst wenn GitOps ein guter Ansatz ist, ist die Übernahme des Modells wahrscheinlich nicht der einzige Schritt, der erforderlich ist, um die Integration von Entwicklung und Betrieb sicherzustellen.
Im Gegensatz zu DevOps, das eine Entwicklungskomponente enthält, konzentriert sich GitOps auf Bereitstellungsdeklarativen. Es sollte durch entwicklungsseitige CI/CD-Tools ergänzt werden, um eine vollständige Pipeline für Softwareänderungen und deren Übergang zur Bereitstellung zu schaffen. Einige GitOps-Toolkits enthalten einige oder alle dieser verwandten Elemente der Entwicklungsebene, aber das ist keine Garantie.
Wenn Sie sich dafür entscheiden, dass GitOps das Richtige für Ihr Unternehmen ist, müssen Sie sich noch entscheiden, ob Sie es in einem Push- oder Pull-Modell verwenden möchten:
Bei der Push-Variante des GitOps-Modells werden Entwicklungsänderungen bei ihrer Freigabe an die Cluster weitergeleitet.
Bei der Pull-Variante des Modells werden die Modelle in Abhängigkeit von den Anwendungszeitplänen in die Cluster gezogen, sobald die Änderungen verfügbar sind.
Es gibt viele Diskussionen darüber, welcher Ansatz der Beste ist, aber der allgemeine Konsens ist, dass der Pull-Ansatz den Produktionsbedingungen den Vorrang gibt und den Zugriff auf das Repository in der Pipeline einschränkt.
Die Auswahl der richtigen GitOps-Tools
Die erfolgreiche Einführung von GitOps hängt von der Auswahl der besten Tools ab. Im Allgemeinen ist es am besten, wenn Sie Ihre Tool-Überprüfung mit den vollständigen Git-basierten CI/CD-Angeboten beginnen und sich dann auf gezieltere Tools konzentrieren, wenn diese breiteren Tool-Sets nicht den Anforderungen Ihrer Pipeline entsprechen.
GitLab bietet Tools in Form einer vollständigen Bereitstellungsplattform, die auch den CI/CD-Entwicklungsteil der Pipeline abdeckt, und es ist oft eine gute Idee, diese zuerst zu prüfen. Harness ist ein weiteres beliebtes kommerzielles Bereitstellungs-Tool für die gesamte Pipeline.
Viele Kubernetes-Benutzer bevorzugen Tools wie Argo und Flux zur Integration von GitOps mit Kubernetes. Codefresh bietet ein Argo-basiertes SaaS-Tool an, und der GitOps-Service von Rafay ist eine weitere SaaS-Option zur Verwaltung des GitOps-Kubernetes-Prozesses.
