Push- vs. Pull-basierte Architektur in GitOps

In der Anfangsphase der Entwicklung oder Implementierung von GitOps kann es entmutigend sein, über die verschiedenen Tools und Verfahren nachzudenken, die Sie benötigen könnten. Sie möchten sichergehen, dass Sie einen robusten und skalierbaren Workflow für die Verwaltung von Infrastruktur und Anwendungsbereitstellungen entwickeln. Und Sie möchten nichts einführen, was die Prozesse übermäßig verkompliziert oder es Ihrem Team erschwert, Codeänderungen zu veröffentlichen.

Eine Möglichkeit, Ihren Fokus einzugrenzen, ist die Suche nach Tools und Verfahren, die Ihre Bereitstellungspraktiken unterstützen. Die wichtigste Überlegung ist, ob Sie einen Push-basierten oder einen Pull-basierten Ansatz verwenden. Beide haben ihre Vor- und Nachteile, und je nachdem, welchen Sie verwenden, werden sich die Tools und Prozesse, die Sie in Ihre GitOps-Strategie einbeziehen, verändern.

Automatisierung von Arbeitsabläufen und Infrastruktur

Lassen Sie uns zunächst zwei zentrale DevOps-Praktiken betrachten: Infrastructure as Code (IaC) und Automatisierung mit Continuous Integration und Continuous Delivery (CI/CD). 

IaC ist eine Technik für die Bereitstellung und Verwaltung der Infrastruktur durch Code anstelle einer Reihe von manuellen Schritten oder interaktiven Prozessen. Dieser Ansatz ist nicht nur auf Infrastrukturprimitive oder verwaltete Cloud-Dienste beschränkt, sondern lässt sich auf alle verwaltbaren Aspekte wie Konfigurationsdateien, Softwareinstallationen, Netzwerk- und Sicherheitsrichtlinien usw. anwenden. Diese Art der einheitlichen Verwaltung, die auch als "X as Code" bezeichnet wird, bietet eine Vorlage und einen dokumentierten Sollzustand für Ihre Bereitstellung.

CI/CD ist eine Methodik und eine Reihe gemeinsamer Praktiken, die es Entwicklern ermöglichen, schnell und zuverlässig qualitativ hochwertige und sicher kodierte Anwendungen bereitzustellen. Die Einführung von CI/CD bedeutet eine Kultur, in der sich Entwicklungsteams durch die Implementierung von Automatisierung in den richtigen Phasen des Softwareentwicklungszyklus ganz auf die Anforderungen des Unternehmens und der Endnutzer konzentrieren können.

In der Softwareentwicklung ist die Integration der Prozess, bei dem Änderungen am Code in ein Repository übertragen werden. Bei der kontinuierlichen Integration (CI) werden die Änderungen automatisch validiert, indem der aktualisierte Anwendungscode auf zuverlässige und konsistente Weise erstellt, getestet und verpackt wird. Das Auslösen eines CI-Workflows bei jedem Push-Ereignis sorgt für einen reibungsloseren und schnelleren Entwicklungsprozess, da Fehler, Sicherheitslücken und Konflikte entdeckt werden können, bevor die Änderungen in einer Umgebung bereitgestellt werden.

Ein Continuous-Delivery-Workflow (CD-Workflow) wird nach erfolgreichem Abschluss des CI-Workflows übernommen. Dabei handelt es sich um einen automatisierten und konsistenten Prozess zur Bereitstellung des aktualisierten Anwendungscodes in einer ausgewählten Umgebung, der die Bereitstellung der Anwendung direkt auf Staging- oder Produktionsservern oder die Auslieferung einer neuen Version an eine Container-Registry oder eine mobile Verteilungsplattform ermöglicht. 

Dies sind die zentralen Themen rund um die Automatisierung von Entwickler-Workflows. Ein GitOps-Ansatz stützt sich auf diese zentralen DevOps-Praktiken und setzt sie in die Praxis um. Durch die Nutzung eines Git-Repositorys als einzige Quelle der Wahrheit für IaC-Definitionsdateien und die Verwendung von Automatisierungspipelines können Sie den gewünschten Zustand Ihrer Infrastruktur effektiv versionskontrollieren. 

Hier kommen wir wieder auf Ihre Bereitstellungspraktiken zurück: Entscheiden Sie, ob Push- oder Pull-basiert die beste Lösung für Ihre Anwendung und Ihre GitOps-Strategie ist.

Vergleich zwischen Push- und Pull-basierter Architektur

Push-basiert oder agentenlos ist der traditionellere Ansatz, bei dem Änderungen durch einen externen CI/CD-Client wie Jenkins oder CircleCI in die ausgewählte Umgebung gepusht werden. Dies kann für Nicht-Kubernetes-Umgebungen oder Umgebungen mit einer Mischung aus verschiedenen Workload-Typen, die die Ausführung separater Agenten und Webhooks für jede Komponente umständlich machen würden, von Vorteil sein.

Vorteile:

• Einfachere Implementierung für mehrere Arten von Workloads in einer einzigen Umgebung.
• Standardisierung der Bereitstellungsmethodik zwischen verschiedenen Umgebungen (d. h. Cloud-Native und On-Premise).
• Tooling-Flexibilität, da die meisten CI/CD-Frameworks ein Push-basiertes Modell verwenden. 

Nachteile:

• Der CI/CD-Client verfügt nicht über eine Beobachtungsmöglichkeit, um festzustellen, ob Änderungen erfolgreich bereitgestellt wurden oder ob serverseitige Probleme aufgetreten sind.
• Möglicherweise müssen zusätzliche Tools installiert werden (z. B. kubectl, Helm, Docker, Ansible, Terraform, SSH), damit der CI/CD-Client die Änderungen bereitstellen kann.
• Der CI/CD-Client muss externen Zugriff auf die Umgebung erhalten, was das Risiko von Sicherheits- und Compliance-Problemen erhöht.

Der Pull-basierte oder Agenten-Ansatz arbeitet in die entgegengesetzte Richtung, indem er die Umgebung zum Teil der CD-Pipeline macht. Ein Agent oder Operator überwacht das Git-Repository auf Änderungen, zieht diese dann heraus und wendet sie an. Diese Aufgabe wird auch immer dann ausgeführt, wenn der Agent eine Konfigurationsabweichung von der einzigen Quelle der Wahrheit feststellt. Dieser Ansatz funktioniert besonders gut mit Kubernetes-Umgebungen.

Vorteile:

• Der Agent/Betreiber hat die Möglichkeit, den aktuellen Zustand und den Einsatzstatus der Umgebung zu beobachten.
• Bessere Sicherheit und einfachere Einhaltung von Vorschriften, da die Umgebung nur die Erlaubnis benötigt, die Quelle einzusehen.
• Schnelle Erkennung von Konfigurationsabweichungen durch manuelle Eingriffe oder andere Quellen.

Nachteile:

• Komplexer für Nicht-Kubernetes-Bereitstellungen.
• Erfordert Werkzeuge, die für die Arbeit in bestimmten Umgebungen ausgelegt sind.

Wenn Sie mit der Planung Ihrer GitOps-Strategie beginnen, sollten Sie überlegen, wie verschiedene Bereitstellungsstrategien Ihre Anwendung unterstützen werden. Sowohl Push- als auch Pull-basierte Ansätze haben ihre Vorteile und sind für verschiedene Szenarien geeignet. Es gibt viele Tools und Praktiken, die Sie in Betracht ziehen können, und mit einer gewissen Perspektive werden Sie wissen, welche Lösung für Ihr Team und Ihren Stack die richtige ist.

Sie suchen weitere Informationen? Laden Sie unser kostenloses GitOps-Strategie-Ebook herunter oder holen Sie sich ein kostenloses Beratungsgespräch mit einem Akamai Cloud Computing-Experten.