Lesezeit: 3 Minuten

CI-Ops vs. GitOps: Vergleich und Auswahl des richtigen Ansatzes

Die kontinuierliche Integration und Auslieferung (Continuous Integration/Continuous Deployment, CI/CD) hat sich in der Softwareentwicklung als unverzichtbarer Bestandteil etabliert. Dabei werden verschiedene Ansätze verwendet, um den Entwicklungsprozess zu automatisieren und effizienter zu gestalten. Zwei populäre Ansätze sind CI-Ops und GitOps. Während CI-Ops traditionell in der Softwareentwicklung eingesetzt wird, hat sich GitOps als bevorzugter Ansatz für die Infrastrukturautomatisierung etabliert. In diesem Blogartikel werden wir die typischen Anwendungsbereiche der beiden Ansätze vergleichen und diskutieren, warum CI/CD auch mit dem GitOps-Ansatz in der Softwareentwicklung möglich ist.

Erfahrungsbericht

In meinen Kundenprojekten konnte ich erfolgreich den GitOps-Ansatz zur automatisierten Einrichtung der Infrastruktur verwenden. Durch die Verwaltung der Infrastrukturkonfiguration als Code in einem Git-Repository war es möglich, effizientere Prozesse und eine robuste Infrastruktur zu schaffen. Die Umstellung auf GitOps führte zu schnelleren Bereitstellungen, hoher Flexibilität und positivem Kundenfeedback.

Gegenüberstellung

CI-Ops konzentriert sich auf die kontinuierliche Integration und den Betrieb. Es automatisiert den Integrationsprozess von Codeänderungen und ermöglicht eine schnelle und effiziente Bereitstellung von Anwendungen. Der Einsatz von Tools wie Jenkins unterstützt die Automatisierung von Build-, Test- und Bereitstellungsprozessen.

GitOps hingegen nutzt das Git-Repository als zentrale Steuerungseinheit für den Bereitstellungsprozess. Mit Tools wie ArgoCD und Tekton ermöglicht GitOps eine deklarative Bereitstellung, bei der der gewünschte Zustand der Infrastruktur im Git-Repository definiert wird. Änderungen im Repository lösen automatisch Bereitstellungsaktionen aus.

Die Gegenüberstellung der beiden Ansätze zeigt Unterschiede und Vorteile:

1. CI-Ops:

• Fokus auf Integration und Deployment
• Automatisierung von Build-, Test- und Bereitstellungsprozessen
• Verbesserte Zusammenarbeit zwischen Entwicklungs- und Betriebsteams
• Geeignet für Projekte mit häufigen Codeänderungen und Anforderungen an schnelle Bereitstellung

2. GitOps:

• Verwendung des Git-Repositories als zentrale Steuerungseinheit
• Deklarative Bereitstellung und automatische Aktualisierung der Infrastruktur
• Bessere Nachvollziehbarkeit und Konsistenz der Bereitstellung
• Geeignet für Projekte, die auf stabile und reproduzierbare Infrastruktur setzen
   

Entscheidungsfindung

Die Entscheidung, welcher Ansatz gewählt wird, hängt von den spezifischen Anforderungen und Zielen des Projekts ab.

Für Projekte mit häufigen Codeänderungen und der Notwendigkeit einer schnellen Bereitstellung kann CI-Ops die richtige Wahl sein. Die Automatisierung von Build-, Test- und Bereitstellungsprozessen mit Jenkins ermöglicht eine effiziente Entwicklung und Bereitstellung.

Für Projekte, die auf stabile und reproduzierbare Infrastruktur setzen und eine bessere Nachvollziehbarkeit der Bereitstellung benötigen, ist GitOps mit ArgoCD und Tekton eine gute Option. Die Verwendung des Git-Repositories als Steuerungseinheit bietet eine klare Sicht auf den gewünschten Zustand der Infrastruktur und ermöglicht eine automatische Aktualisierung.

Für Projekte auf der OpenShift-Plattform bietet RedHat Operatoren für Tekton (OpenShift Pipelines) und ArgoCD (OpenShift GitOps) an. Diese installieren Custom Resource Definitions und nach Wunsch sogar vollständige Instanzen auf dem Cluster. Unsere Experten können je nach Projektanforderungen maßgeschneiderte Instanzen auf Ihren Clustern einrichten, unter Berücksichtigung der bewährten Best Practices von RedHat.

Bei neuen Projekten außerhalb des Prototyping-Bereichs ist es ratsam, den GitOps-Ansatz zu bevorzugen, da er eine bessere Transparenz, Nachvollziehbarkeit und Konsistenz bei der Bereitstellung bietet. Durch die Verwendung von Tools wie ArgoCD und Tekton kann von Anfang an eine effektive Pipeline-Orchestrierung und deklarative Bereitstellung implementiert werden.

Insgesamt hängt die Wahl des richtigen Ansatzes von den spezifischen Anforderungen und Präferenzen des Projekts ab. Sowohl CI-Ops als auch GitOps bieten Vorteile in Bezug auf Automatisierung, Zusammenarbeit und Effizienz, und die Entscheidung sollte anhand der Projektanforderungen und -ziele getroffen werden.

Beispiele

Dies sind einfache Beispiele, die den Aufbau der Pipeline-Definitionen in YAML für Jenkins (CI-Ops) und Tekton / ArgoCD (GitOps) zeigen.

In der Jenkins Pipeline werden die Stufen "Build", "Test" und "Deploy" definiert, wobei die Schritte zur Codekompilierung, Tests und Bereitstellung angegeben werden.

Im Gegensatz dazu verwendet die Tekton / ArgoCD Pipeline separate Aufgaben ("git-clone", "build-and-test", "deploy"), die jeweils auf spezifische Task-Definitionen verweisen, um die Schritte des Git-Repository-Clonens, des Build- und Testvorgangs sowie der Bereitstellung durchzuführen.

Abbildung 1: Beispiel für eine Jenkins Pipeline (CI-Ops)

Abbildung 2: Beispiel für eine Tekton Pipeline (GitOps)

In diesem Beispiel wird der Tekton Task "deploy" definiert. Der Task akzeptiert Parameter für die Image-URL, den Artifactory-Benutzernamen und das Artifactory-Passwort.

Der erste Schritt "login-to-artifactory" verwendet das Bild "docker.io/jfrog/jfrog-cli:v1.47.1" und konfiguriert die JFrog CLI mit den angegebenen Artifactory-Zugangsdaten.

Der zweite Schritt "push-to-artifactory" verwendet ebenfalls das Bild "docker.io/jfrog/jfrog-cli:v1.47.1" und verwendet die JFrog CLI, um das Image an die angegebene Image-URL in das Artifactory-Repository hochzuladen.

Der letzte Schritt "argocd-deploy" verwendet das Bild "argoproj/argocd-cli:v2.1.2" und führt den Befehl "argocd app sync my-app" aus, um das Deployment der Anwendung "my-app" über ArgoCD auszulösen.

Abbildung 3: Beispiel für einen Tekton Task um das Image in Artifactory zu pushen und ArgoCD zu triggern (GitOps)

In diesem Beispiel wird das ArgoCD App-Projekt "my-app-project" definiert. Das Projekt definiert die Konfigurationen und Berechtigungen für die Anwendungen, die diesem Projekt zugeordnet sind.

Abbildung 4: Beispiel für ein ArgoCD App Project

Die Application-Definition definiert die Details der Anwendung. Sie gibt den Server-URL von ArgoCD an, den Ziel-Namespace, das Projekt, den Repo-URL und den Pfad zur Anwendung im Repository sowie die Zielrevision. Die syncPolicy ist auf automatisiert eingestellt, was bedeutet, dass das Deployment automatisch durchgeführt wird.

Es ist wichtig anzumerken, dass die genauen Werte und Konfigurationen in den YAML-Dateien je nach den spezifischen Anforderungen und Umgebungen angepasst werden sollten.

Fazit

Die Wahl zwischen GitOps und CI-Ops hängt von den spezifischen Rahmenbedingungen ab. Aus unseren Kundenprojekten haben wir wertvolle Auswahlkriterien und Entscheidungshilfen gewonnen. Es ist wichtig, klare Ziele zu formulieren und das Vorgehen daran auszurichten. Mit einer fundierten Entscheidung und konsequentem Umsetzen steht einer erfolgreichen Auslieferungsstrategie nichts mehr im Weg. Die Automatisierung von CI/CD-Prozessen mit GitOps oder CI-Ops bietet erhebliche Vorteile für die Effizienz und Qualität der Softwareentwicklung. Die richtige Wahl des Ansatzes in Verbindung mit klaren Zielen bildet die Grundlage für erfolgreiche Projekte.