Best Practices für Continuous Integration und Continuous Delivery an Google Kubernetes Engine

In diesem Leitfaden werden Best Practices für Continuous Integration und Continuous Delivery (CI/CD) in Google Kubernetes Engine (GKE) beschrieben. Diese Methoden behandeln eine breite Palette von Themen, von der Versionsverwaltung bis hin zu Bereitstellungsstrategien. Diese Best Practices gelten speziell für GKE und die allgemeinen Best Practices für CI/CD gelten weiterhin. Weitere Informationen finden Sie unter DevOps-Technologie: Continuous Integration und DevOps Tech: Continuous Delivery.

Continuous Integration

Continuous Integration (CI) ist eine Methode, bei der Entwickler alle Codeänderungen so häufig wie möglich wieder in einen Hauptzweig integrieren. Es soll schnellere Fehler ermöglichen, weil Probleme so früh wie möglich im Prozess erkannt werden. CI-Pipelines werden normalerweise durch Entwickler ausgelöst, die Änderungen am Code vornehmen. Die Pipeline umfasst Schritte zum Prüfen dieser Änderungen wie Linting, Tests und Erstellung. Eine CI-Pipeline erzeugt in der Regel ein Artefakt, das Sie in späteren Phasen des Bereitstellungsprozesses bereitstellen können.

Pipelines erstellen, die eine schnelle Iteration ermöglichen

Die Zeitspanne zwischen dem Zeitpunkt, an dem ein Entwickler eine Codeänderung vornimmt, und dem Zeitpunkt, zu dem Sie eine ausgeführte Version der Anwendung haben, sollte so kurz wie möglich sein. Diese Geschwindigkeit ist besonders wichtig bei der Entwicklung von Feature-Branches, die eine schnelle Iteration durch Entwickler beinhalten. Idealerweise sollten Ihre CI-Pipelines in weniger als 10 Minuten ausgeführt werden. Wenn dies nicht möglich ist, erstellen Sie zwei Arten von CI-Pipelines:

  • Schnelle Pipelines: Diese Pipelines werden in der Regel innerhalb von zehn Minuten oder weniger ausgeführt. Diese Pipelines sind für Feature-Branches vorgesehen und nicht vollständig. Schnelle Pipelines können zu instabilen Artefakten führen.

  • Vollständige Pipelines: Die Ausführung dieser Pipelines kann länger als zehn Minuten dauern. Außerdem führen sie umfangreichere Tests und Prüfungen durch. Vollständige Pipelines werden für Zusammenführungs- oder Pull-Anfragen ausgeführt und Commits werden zum Haupt-Branch durchgeführt.

Container-Images testen

Achten Sie als Teil Ihrer CI-Pipelines darauf, alle erforderlichen Tests an Ihrem Code auszuführen und Artefakte zu erstellen. Diese Tests sollten Einheiten-, Funktions-, Integrations- und Lasttests oder Leistungstests umfassen.

Außerdem ist es wichtig, die Struktur Ihrer erstellten Container-Images zu testen. Durch das Testen der Struktur wird sichergestellt, dass alle Befehle in Ihrem Container erwartungsgemäß ausgeführt werden. Außerdem können Sie mithilfe von Tests prüfen, ob sich bestimmte Dateien am richtigen Speicherort befinden und den richtigen Inhalt haben.

Zum Testen der Container-Images können Sie das Containerstruktur-Test-Framework verwenden.

Sicherheit in Pipelines frühzeitig einrichten

Sorgen Sie dafür, dass Sicherheitsüberprüfungen und -stände im Entwicklungszyklus so früh wie möglich berücksichtigt werden. Wenn Sie Sicherheitsrisiken ermitteln, bevor Sie Artefakte oder Bereitstellungen erstellen, können Sie den Zeitaufwand und die Kosten reduzieren, um diese Risiken einzugehen.

Sie können die folgenden Sicherheitsmaßnahmen in Ihre Pipelines implementieren, um eine frühzeitige Erkennung zu ermöglichen:

  • Achten Sie darauf, dass Fachleute auf Code zugreifen können, der in Ihr Produktions-Repository eingebunden ist.

  • Frühzeitige Implementierung der Lint- und statischen Code-Analyse in der Pipeline Mit diesen Tests können Sie Schwachstellen erkennen, z. B. das Umschreiben von Eingaben, das Akzeptieren von Rohdaten für SQL-Abfragen oder Sicherheitslücken in Ihrem Code.

  • Scannen Sie Ihr erstelltes Container-Image auf Sicherheitslücken mit einem Scan auf Sicherheitslücken.

  • Verhindern Sie mithilfe der Binärautorisierung, dass Images, die Sicherheitslücken enthalten, in Ihren Clustern bereitgestellt werden. Für die Binärautorisierung ist ein GKE Enterprise-Abo erforderlich. Für eine höhere Zuverlässigkeit für die generierten Images können Sie mit der Binärautorisierung auch Attestierungen von verschiedenen Entitäten oder Systemen anfordern. Diese Attestierungen könnten Folgendes enthalten:

    • Scan auf Sicherheitslücken bestanden
    • QA-Tests bestanden
    • Vom Produkteigentümer abmelden

Continuous Delivery

Mit Continuous Delivery (CD) können Sie jederzeit Code freigeben. CD arbeitet auf dem von CI-Pipelines erzeugten Artefakt. CD-Pipelines können deutlich länger als CI-Pipelines ausgeführt werden, insbesondere wenn Sie umfangreichere Bereitstellungsstrategien wie Blau/Grün-Bereitstellungen verwenden.

GitOps-Methode verwenden

GitOps ist das Konzept der deklarativen Infrastruktur, die in Git-Repositories und den CI/CD-Tools gespeichert ist, um diese Infrastruktur in Ihrer Umgebung bereitzustellen. Mit einer GitOps-Methode sorgen Sie dafür, dass alle Änderungen an Ihren Anwendungen und Clustern in Quell-Repositories gespeichert werden und immer zugänglich sind.

Die Verwendung von GitOps-Methoden bietet folgende Vorteile:

  • Sie können Änderungen prüfen, bevor sie über Zusammenführungs- oder Pull-Anfragen bereitgestellt werden.
  • Sie haben einen einzigen Standort, mit dem Sie jederzeit auf den Zustand Ihrer Anwendungen und Cluster zurückgreifen können.
  • Snapshots Ihrer Cluster und Anwendungen erleichtern die Wiederherstellung nach Fehlern.

Weitere Informationen zur GitOps-Methode und den verschiedenen Mustern, die Sie in Ihren Quell-Repositories verwenden können, finden Sie unter GitOps-Konzepte.

Gängige Tools für die deklarative Infrastruktur sind Terraform von HashiCorp und Config Connector von Google Cloud. Als praktische Anleitung zur Verwaltung von Infrastruktur mit GitOps und anderen Tools können Sie die Anleitung Infrastruktur als Code verwalten mit Terraform, Cloud Build und GitOps aus. Mehr zum Verwalten von Anwendungen im GitOps-Stil finden Sie unter Continuous Delivery gemäß GitOps mit Cloud Build.

Container-Images hochstufen und neu erstellen

Container-Images sollten nicht neu erstellt werden, da sie die verschiedenen Phasen einer CI-/CD-Pipeline durchlaufen. Die Neuerstellung kann geringfügige Unterschiede in den Code-Branchen zur Folge haben. Diese Unterschiede können dazu führen, dass Ihre Anwendung in der Produktion fehlschlägt oder dass der Code des Produktionscontainers versehentlich nicht getesteten Code enthält. Damit das getestete Container-Image das bereitgestellte Container-Image ist, sollten Sie es einmal erstellen und in Ihren Umgebungen bewerben. Dabei wird davon ausgegangen, dass Sie die umgebungsspezifische Konfiguration von Paketen getrennt halten.

Verwenden Sie komplexere Bereitstellungs- und Testmuster.

Mit GKE können Sie Ihre Anwendungen mithilfe verschiedener Muster flexibel bereitstellen und testen. Welches Bereitstellungsmuster Sie wählen, hängt weitgehend von Ihren Unternehmenszielen ab. Sie müssen beispielsweise Änderungen ohne Ausfallzeiten bereitstellen oder Änderungen in einer Umgebung oder einer Teilmenge von Nutzern vornehmen, bevor Sie ein Feature allgemein verfügbar machen.

Hier einige der verschiedenen verfügbaren Bereitstellungsmuster:

  • Bereitstellung neu erstellen: Sie skalieren die vorhandene Anwendungsversion vollständig herunter, bevor Sie die neue Anwendungsversion hochskalieren.

  • Rolling Update-Bereitstellung: Sie aktualisieren eine Teilmenge der ausgeführten Anwendungsinstanzen, statt alle ausgeführten Anwendungsinstanzen gleichzeitig zu aktualisieren. Anschließend aktualisieren Sie kontinuierlich mehr laufende Anwendungsinstanzen, bis alle aktualisiert sind.

  • Blau/Grün-Deployment: Sie stellen in einer vorhandenen Produktionsversion eine zusätzliche parallele Gruppe von Instanzen für die aktualisierte Version Ihrer Anwendung bereit. Sie wechseln den Traffic an die neuen Instanzen, wenn Sie für die Bereitstellung bereit sind.

Cluster für verschiedene Umgebungen trennen

Die Trennung von Umgebungen ist wichtig für jedes Bereitstellungsziel. Idealerweise sollten Sie separate Cluster für jede der folgenden Umgebungen haben:

  • Entwicklungsumgebung: In dieser Umgebung stellen Ihre Entwickler Anwendungen zum Testen und Experimentieren bereit. Diese Deployments erfordern die Einbindung in andere Teile der Anwendung oder des Systems (z. B. eine Datenbank). Die Cluster für diese Umgebung haben normalerweise weniger Tore, und Entwickler haben mehr Kontrolle über ihre Clusterkonfiguration.

  • Vorproduktionsumgebungen (Staging oder QA): Diese Umgebungen sollten der Produktionsumgebung möglichst ähnlich sein. Sie werden für umfangreiche Tests von Änderungen wie Integration, Last, Leistung oder Regressionstests verwendet.

  • Produktionsumgebung: In dieser Umgebung werden Ihre Arbeitslasten und an Nutzer gerichtete Anwendungen und Dienste ausgeführt.

Weitere Informationen zu diesen Umgebungen finden Sie im Abschnitt „Umgebungen“ in Kubernetes und den Herausforderungen der kontinuierlichen Softwarebereitstellung.

Produktionsumgebungen sollten sich in der Nähe der Produktion befinden

Im Wesentlichen sind Cluster vor der Produktionsumgebung mit Produktionsclustern identisch. Die Kosten für Vorproduktionscluster können jedoch zu Kosten reduziert werden. Wenn Sie die Cluster ähnlich halten, werden alle Tests mit denselben oder ähnlichen Bedingungen in der Produktion durchgeführt. Durch die Parität zwischen Vorproduktions- und Produktionsclustern wird außerdem die Wahrscheinlichkeit von unerwarteten Fehlern aufgrund von Umgebungsunterschieden bei der Bereitstellung in der Produktion verringert.

Eine deklarative Infrastruktur und GitOps unterstützen Sie dabei, eine genauere Gleichheit Ihrer Umgebungen zu erreichen, da Sie die Konfiguration des zugrunde liegenden Clusters einfacher duplizieren können. Damit Ihre Umgebungen ähnliche Bedingungen für Richtlinien und Konfigurationen haben, können Sie auch Tools wie Config Sync verwenden.

Auf Fehler in der Produktion vorbereiten

Viele Tests können das ordnungsgemäße Verhalten Ihrer Anwendung in der Produktion nicht sicherstellen. Fehler können durch Grenzfälle mit Daten verursacht werden, die von den nicht getesteten Nutzern nicht berücksichtigt wurden oder Zugriffsmuster haben. Es ist wichtig, dass Sie die Anwendung in der Produktion überwachen und automatisierte Rollback- und Bereitstellungsmechanismen implementieren, damit Sie schnell auf Programmfehler oder Ausfälle reagieren können. Durch die Verwendung robuster Bereitstellungsstrategien können Sie die Auswirkungen von Problemen reduzieren und weniger Ihrer Endbenutzer zu beeinträchtigen, wenn Probleme in der Produktion auftreten.

Zusammenfassung der Checkliste

In der folgenden Tabelle sind die Aufgaben zusammengefasst, die wir für die Verwendung einer CI/CD-Pipeline in GKE empfehlen:

Gebiet Aufgaben
Continuous Integration
Continuous Delivery

Nächste Schritte