GitOps-Workflows mit GitHub-Aktionen bei Vonage

Vor kurzem haben wir eine wichtige Build- und Deployment-Pipeline für unsere Vonage Contact Center-Plattform neu gestaltet. Wir haben die Gelegenheit genutzt, diese Pipeline auf ein sicherheitskonformes GitOps-Design umzustellen. In diesem Blogbeitrag erkläre ich, was mit GitOps gemeint ist und wie unsere Pipeline umgestaltet wurde, um von diesem Konzept zu profitieren.

Gitops-Konzepte: Was ist GitOps überhaupt?

Im Großen und Ganzen ist GitOps eine Zusammenarbeit der besten Praktiken von DevOps und Sicherheit. Der Hauptunterschied zwischen DevOps und GitOps ist der Zusatz von IaC (Infrastructure as Code), der neben dem Projektcode in SCM (Source Code Management), in der Regel Git, gespeichert wird.

GitOps ist eher ein Rahmenwerk als ein einzelnes Softwarepaket oder Werkzeug. Meiner Meinung nach ist dies eine seiner Stärken. Mit GitOps haben Sie die Freiheit und Flexibilität, die Implementierung so anzupassen, dass sie am besten zu Ihrem Unternehmen passt und Ihre Prozesse verbessert.

GitOps setzt sich aus drei verschiedenen Konzepten zusammen:

1. Infrastruktur als Code (IaC)

IaC-Tools ermöglichen es, die Infrastruktur einmal zu entwerfen und zu konfigurieren und sie dann wiederholbar zu implementieren. Nach der Definition können diese Konfigurationsdaten unter Quellcodekontrolle gehalten werden, so dass eine einzige Quelle der Wahrheit für die Infrastruktur (sowie die zugehörigen Berechtigungen und Sicherheitsrichtlinien) beibehalten werden kann.

Darüber hinaus lassen sich mit einer gut konzipierten Repository-Struktur die Sicherheitskonzepte der geringsten Privilegien und der Trennung der Zuständigkeiten für diese Daten leicht umsetzen.

2. Pull Requests (PRs)

Alle Codeänderungen sollten durch PRs kontrolliert werden. Dieser Schutz gilt sowohl für den Anwendungscode als auch für den IaC-Code, der die unterstützende Infrastruktur beschreibt.

Entwickler sollten die Erlaubnis haben, Code über PRs in das Anwendungs-Repository einzubringen, aber sie sollten keine direkte Erlaubnis haben, Aktualisierungen an der GitOps-Pipeline oder den Infrastruktur-Repositories vorzunehmen.

3. Kontinuierliche Integration/kontinuierliche Bereitstellung (CI/CD)

GitOps automatisiert die CI/CD-Prozesse durch kontinuierliche Integration und Bereitstellung. CI wird durch einen Push auf den Hauptzweig ausgelöst. Die Bereitstellung wird entweder manuell oder automatisch nach dem erfolgreichen Abschluss von Qualitätsprüfungen ausgelöst.

Sicherheitstests können mit GitOps viel einfacher in den SDLC (Software Development Life Cycle) integriert werden. Da der Iterationszyklus viel schneller ist, bedeutet dies außerdem mehr Leichtigkeit und weniger Reibung bei der Einführung von Sicherheit. Dies fördert die Konzentration auf Prävention statt auf Entdeckung, was gemeinhin als "shifting left" bezeichnet wird.

Wie wir GitOps eingeführt haben

Kontext

Unser Ziel war es, eine GitOps CI/CD-Pipeline für die Bereitstellung von Micro-FrontEnd-Komponenten in den von Vonage Contact Centre gehosteten Cloud-Umgebungen zu entwickeln. Die Pipeline ist ein Ersatz für eine frühere Version. Daher war ein Design erforderlich, das die Reibung bei der Entwicklung und die Bereitstellungszeiten deutlich reduziert, die Sicherheit verbessert und infolgedessen die DevEx (Developer Experience) verbessert.

Forschung und Anforderungen

Da dies unser erster praktischer Kontakt mit GitOps war, haben wir erste Nachforschungen über das GitOps-Framework angestellt und einen Spike durchgeführt, um einige verschiedene Ansätze zu testen. Angesichts der Art unserer Anforderungen und der unvermeidlichen Einschränkungen bei der Arbeit haben wir uns für das ereignisgesteuerte Modell von GitHub Actions mit einer Kombination aus Cloud-nativen CLI-Tools entschieden, um Aktualisierungen in der in der Cloud gehosteten Infrastruktur (in diesem Fall CDNs, serverlose Codefunktionen und eine NoSQL-DB) steuern zu können. In unserer GitOps-Architektur benötigen wir nur ein Ereignis. Die Bereitstellung der Anwendung wird durch ein GitHub repository_dispatch Ereignis ausgelöst, das aus dem Anwendungs-Repository stammt und auf das GitOps-Repository abzielt, wo es die Bereitstellung automatisch auslöst.

Als wir überzeugt waren, dass GitOps eine praktikable Lösung war, haben wir unsere Anforderungen verfeinert:

• Verbesserung der Sicherheitslage durch Einhaltung der Grundsätze des geringstmöglichen Privilegs und der Trennung der Zuständigkeiten

• Rechtzeitiges Feedback an die Entwickler

• Reduzieren Sie die Reibungsverluste bei der Bereitstellung und verbessern Sie dadurch die Bereitstellungszeiten und DevEx

• Unterstützung von Einsatzmetriken

• Verwendung wartbarer GitOps CI/CD-Pipelines

• Horizontale Skalierbarkeit (nahtlose Integration neuer Anwendungen in die GitOps-Pipeline)

• Nutzung und Verbesserung interner Tools, wo dies sinnvoll ist

GitOps Architektur

Infrastruktur-Repositorien

Terraform war das Tool unserer Wahl für den Rollout und die Verwaltung der Cloud-Infrastruktur, auf der die MFE-Komponenten gehostet werden sollten. Dieser IaC-Ansatz ist nützlich für die Kontrolle von Infrastrukturen, die sich nicht oft ändern.

Jede der Ressourcen, die für das Hosting der MFE-Komponenten erforderlich sind, wurde in Terraform-Modulen erfasst, zusammen mit den erforderlichen unterstützenden Sicherheits- und Berechtigungsobjekten. Eine bereits existierende Terraform CI/CD-Pipeline wird für die Wartung dieser Komponenten verwendet.

Anwendungs-Repositories

Entwickler (und das MFE-Anwendungsrepository selbst) haben nur eingeschränkte Berechtigungen für Entwicklungswerkzeuge und -systeme. Daher kümmert sich ein CI-Workflow, der mit Github Actions definiert wurde, um diese Verantwortlichkeiten und bietet klassische Build- und Qualitätsfunktionen in einem automatisierten Prozess mit Vorlagen. Die durch diesen Prozess erzeugten Build-Artefakte werden in ein Paket-Repository (jFrog Artifactory) übertragen.

Application CI Workflow

Ein CD-Workflow im selben Repository bietet dem Entwickler die Möglichkeit, die Anwendung bereitzustellen. Konkret bedeutet dies, dass ein GitHub repository_dispatch Ereignis, das an das Ziel-Repository von GitOps gesendet wird, gefolgt von einem Schritt des Wartens auf die Fertigstellung.

Beispiel für eine GitHub-Aktion, die eine Anwendungsbereitstellung auslöst:

- name: Deploy MFE ${{ env.MFE_NAME }} version ${{ env.MFE_VERSION }} to ${{ env.MFE_ENVIRONMENT }}
  uses: peter-evans/repository-dispatch@11ba7d3f32dc7cc919d1c43f1fec1c05260c26b5 # v2.0.0
  with:
    token: ${{ secrets.GITOPS_GITHUB_TOKEN }}
    repository: ${{ env.GITOPS_REPOSITORY }}
    event-type: deploy-mfe-trigger
    client-payload: '{
                        "type": "deploy-mfe-trigger",
                        "timestamp": "${{ env.DATEANDTIME }}",
                        "user": "${{ github.actor }}",
                        "mfe": "${{ env.MFE_NAME }}",
                        "version": "${{ env.MFE_VERSION }}",
                        "environment": "${{ env.ENVIRONMENT }}",
                        "cache_invalidation_keys": "${{ env.CACHE_INVALIDATION_KEYS }}",
                        "repository": "${{ github.repository }}",
                        "ref": "${{ github.ref }}",
                        "sha": "${{ github.sha }}"
                    }'

Application CD GitOps Workflow

GitOps IaC-Repository

Dieses Repository bildet die Grundlage für unser GitOps-Framework. Es verfügt über die erforderlichen Berechtigungen für die Bereitstellung bei einem bestimmten Cloud-Anbieter. Beachten Sie, dass es von den MFE-Anwendungs-Repositories getrennt ist, wodurch die Sicherheitsprinzipien der geringsten Privilegien und der Aufgabentrennung (sowie der Verlagerung der Sicherheit nach links) eingehalten werden.

Die Bereitstellungsereignisse werden vom CD-Workflow der Anwendung empfangen und automatisch verarbeitet. Der GitOps-Prozess besteht im Wesentlichen aus drei verschiedenen Schritten:

1. GitHub verarbeiten repository_dispatch Ereignisse

   1. annehmen/ablehnen

   2. IaC-Konfiguration auf der Grundlage von Ereignis-Metadaten aktualisieren

   3. PR betreiben

2. PR automatisch zusammenführen

   1. Qualitätsprüfungen durchführen

   2. PR zusammenführen, wenn die Qualitätsprüfungen bestanden sind

3. Anwendung bereitstellen

   1. Kopieren des Artefakts in den Cloud-Speicher

   2. DB-Tabelle aktualisieren

   3. CDN-Cache ungültig machen

GitOps Operations Deployment Workflow

Werkzeug zur Bereitstellung von Cloud-Infrastrukturen

Wir haben ein CLI-Tool entwickelt, das eine Schnittstelle zu unserem Cloud-Anbieter bildet und die nahtlose Bereitstellung von Anwendungen ermöglicht.

Durch die Abstrahierung der Bereitstellungslogik in dieses neue CLI-Projekt konnten wir die feinkörnigen Details der Bereitstellungslogik verwalten und gleichzeitig sicherstellen, dass neue Funktionen vor der Freigabe für die Produktionspipeline getestet werden.

Micro-FrontEnd-Projektrahmen CLI

Dies ist ein internes Tool, das ein CI/CD-Framework für die Entwicklung in mehreren Sprachen bietet. Wir verwenden dieses Tool, um den Aufwand für die Erstellung und Aktualisierung unserer Software-Projekte zu verringern. Es bietet unter anderem Skelett-Komponentencode, allgemeine Konfigurationsoptionen und CI/CD-Pipeline-Vorlagen. Es unterstützt eine Vielzahl von Sprach-Laufzeiten und Komponententypen.

Wir haben uns frühzeitig entschieden, das Tool zu verbessern, um das neue GitOps-Framework für MFEs zu unterstützen, die Erfahrung der Entwickler bei der Erstellung neuer MFEs zu verbessern und auch die Migration bestehender MFE-Komponenten in die neue CI/CD-Pipeline zu unterstützen. Unsere Änderungen an diesem Tool bedeuten, dass es automatisch die erforderlichen CI/CD-GitOps-Workflows für Micro-FrontEnd-Projekte erstellen wird.

Um die GitOps-Pipeline in ein neues oder bereits bestehendes Projekt zu übernehmen, müssen Sie das Projekt mit dem CLI-Tool rendern.

Wohin würden wir als nächstes gehen?

Dieses Projekt hat uns eine großartige Gelegenheit gegeben, die GitOps-Konzepte in den Griff zu bekommen und einen Einblick in die Bereiche zu erhalten, in denen wir uns weiter verbessern können. Hier sind einige der Dinge, die wir als nächstes angehen könnten:

• Arbeiten Sie eng mit den Sicherheitsteams von Vonage zusammen, um die Anforderungen an die Sicherheitskonformität als Konfiguration zu definieren (YAML, Terraform, ...). Wenn dies Teil des SDLC ist (und zu den kontinuierlichen Überprüfungs-/Verfeinerungszyklen gehört), sind Sie sicher, dass Sie die Compliance einhalten und den Nachweis dafür erbringen können.

• Erwägen Sie die Nutzung von GitHub-Aktionen für selbst gehostete Läufer, um uns mehr Kontrolle über Skalierung, Konfiguration und Kosten zu geben. Dieser Schritt muss sorgfältig abgewogen werden, da er einen Kompromiss zwischen der Sicherheit der Runner, den Kosten und der Wartbarkeit darstellt.

• Erstellen/übernehmen Sie eine GitOps GitHub App, ähnlich den für K8s verfügbaren Operationen.

Abschließende Überlegungen

Ich hoffe, dieser Blog war informativ und hat einige der Vorteile der Einführung von GitOps in Ihre Entwicklungspipeline aufgezeigt.

Folgen Sie uns auch auf Twitter und treten Sie unserem Slack-Kanal für weitere Informationen.

Vielen Dank fürs Lesen!