Kubernetes-Operatoren: den Release-Prozess automatisieren

Snyk unterstützt unsere Kunden dabei, Sicherheit in ihre CI/CD-Pipelines zu integrieren. Deshalb beschäftigen wir uns intensiv mit Automatisierung. Wenn es um die Veröffentlichung unserer eigenen Software geht, orientieren wir uns stets an Best Practices für Tests und Releases.

In diesem Blogbeitrag erläutere ich den Release-Prozess für unseren Kubernetes-Operator und zeige, wie wir die Bereitstellung des Releases über mehrere Repository-Ziele hinweg automatisiert haben.

Was ist ein Kubernetes-Operator?

Ein Operator ist eine „… Methode zum Paketieren, Bereitstellen und Verwalten einer Kubernetes-Anwendung …“. Operatoren kapseln im Grunde Aktionen über den Lebenszyklus einer Anwendung in Code und ermöglichen es uns, sie über die native Kubernetes-API zu steuern.

Warum sind Kubernetes-Operatoren wichtig?

Das Operator-Muster bietet uns die Möglichkeit, Anwendungen nach ihrem Start mithilfe der Kubernetes-APIs zu steuern. Wenn unsere Anwendungen mehr können müssen, als nur zu starten oder zu stoppen, können wir sie damit auch während des Betriebs auf dieselbe deklarative Weise steuern, mit der wir alle anderen Kubernetes-Ressourcen verwalten.

Was ist die Automatisierung von Application-Releases?

Mit dem Aufkommen von Online-Katalogen, in denen wir unsere Software zur Nutzung durch unsere Anwender bereitstellen, kann der Prozess zur Verteilung einer veröffentlichten Softwareversion sehr komplex werden. Möglicherweise müssen zahlreiche Schritte ausgeführt werden, um unsere Artefakte in verschiedenen Repositories bereitzustellen. Außerdem müssen wir unter Umständen unterschiedliche Metadatentypen bereitstellen, damit unsere Anwendung auf verschiedene Weise genutzt werden kann. Die Automatisierung dieser Prozesse ist entscheidend, damit jedes Release fehlerfrei verteilt wird und unsere Anwender neue Versionen sofort nach ihrer Verfügbarkeit nutzen können.

Schauen wir uns das genauer an

Vor einigen Monaten hat das Team hinter Container Scanning den Snyk Operator veröffentlicht. Dieser Operator für Snyk Controller erleichtert die Bereitstellung sowohl in nativen Kubernetes-Clustern als auch in OpenShift-Clustern.

Snyk Controller ist eine Snyk-Anwendung, die im Cluster des Nutzers bereitgestellt wird und Images von Containern scannt, die im Cluster ausgeführt werden. Hier erfahren Sie mehr über dieses großartige Tool und hier, wie es Ihnen dabei helfen kann, Schwachstellen in Ihren Images und Anwendungen zu erkennen.

Es gibt viele verschiedene Möglichkeiten, Operatoren für Kubernetes zu erstellen. Eine der gängigsten ist das Operator Framework, das bei CoreOS entstand und inzwischen ein CNCF-Projekt ist. Das Operator Framework bietet nicht nur ein SDK für die Entwicklung von Operatoren, sondern auch ein Repository für von der Community entwickelte Operatoren.

Der Snyk Operator wurde mit diesem Framework erstellt. Bei jedem Release stellen wir ihn in den Upstream-Repositories bereit. Wenn wir eine neue Version des Operators veröffentlichen, müssen viele Schritte ausgeführt werden, bei denen es bei einer manuellen Durchführung leicht zu Fehlern kommen kann.

Zunächst sehen wir uns an, wie der Release-Prozess für Snyk Controller abläuft und wie wir den Build des Operators darin integrieren.

Sobald ein Pull Request von einem der Mitwirkenden an unserem Snyk Controller-Repository zusammengeführt wurde, wird unsere Continuous-Integration- und Continuous-Deployment-Pipeline gestartet. Sie erstellt den Operator und sein Image und führt Unit-Tests, Systemtests und Integrationstests aus, um den Operator in verschiedenen Umgebungen zu testen.

Wir müssen eine Vielzahl verschiedener Umgebungen testen, darunter unterschiedliche Versionen von OpenShift und des Upstream-Kubernetes. In all diesen Umgebungen testen wir mit dem Operator Lifecycle Manager, der zum Operator Framework gehört und Kubernetes erweitert. So bietet er eine deklarative Möglichkeit, Operatoren und ihre Abhängigkeiten in einem Cluster zu installieren, zu verwalten und zu aktualisieren.

Sobald eine Version des Snyk Operators getestet wurde, müssen wir das finale Release bereitstellen. Derzeit veröffentlichen wir den Snyk Operator im Operator Hub. Damit können Nutzer den Snyk Operator in jedem Kubernetes-Cluster installieren, auf dem der Operator Lifecycle Manager ausgeführt wird. Außerdem veröffentlichen wir ihn im OpenShift-Katalog.

Dieser Release-Prozess umfasst zwei separate Pull Requests. Bei einer manuellen Durchführung wäre das mit erheblichem Mehraufwand verbunden: Einer fügt den Snyk Operator zum Ordner community-operators hinzu, der andere zum Ordner upstream-community-operators. Mit dem ersten wird der Snyk Operator auf OperatorHub.io veröffentlicht, mit dem zweiten im OpenShift-Katalog.

Um den Aufwand für diese Schritte zu verringern, möchten wir den Release-Prozess für beide Repositories vollständig automatisieren. Daher haben wir all diese Schritte in unserer CircleCI-Pipeline skriptgesteuert.

Zunächst kopieren wir alle benötigten Dateien in den Ordner snyk-operator und ersetzen dabei die Anwendungsversion durch die neueste Version. Wir laden das Tool operator-sdk herunter und verwenden es, um das Image des Snyk Operators zu erstellen. Anschließend übertragen wir das Image in unsere öffentliche Registry auf Docker Hubs.

Quelle: GitHub

Mit diesem Image können wir die Integrationstests in der Pipeline ausführen und sicherstellen, dass das Release in OpenShift-Clustern der Versionen 3.x und 4.x sowie in Kubernetes-Clustern mit OLM funktioniert. Dabei nutzen wir einen Trick, um die Integrationstests auszuführen. Wir übertragen das Operator-Image in die Quay-Registry, erstellen eine operator-source.yaml und installieren den Operator anschließend im Cluster, indem wir diese install.yaml anwenden.

Damit möchten wir denselben Prozess nachbilden, den Nutzer durchlaufen, wenn sie den Operator über die Benutzeroberfläche installieren. Wir betrachten ihn als Blackbox und führen einige der Schritte aus, die OpenShift ausführen würde, wenn ein Nutzer in der Benutzeroberfläche auf „Installieren“ klickt.

Quelle: GitHub

Quelle: GitHub

Quelle: GitHub

Wenn alle Tests erfolgreich sind, können wir schließlich mit der Veröffentlichung des Snyk Operators fortfahren. Dazu müssen wir zusätzliche Metadaten erstellen. Diese umfassen die ClusterServiceVersion und die CustomerResource Definitions. Sie füllen die Seite von Snyk Controller im Operator Hub und ermöglichen die Integration mit dem Operator Lifecycle Manager. Mit OLM können Nutzer einen Operator abonnieren. So werden Installation und Updates in einem einzigen Schritt zusammengefasst.

Da sich diese Metadaten nicht häufig ändern, verwenden wir Templates und passen lediglich die Version an die neueste Version des Snyk Operators an.

Quelle: GitHub

Nachdem wir alle diese Schritte abgeschlossen haben, können wir unsere Commits erstellen: einen, um die neuen Operator-Metadaten in den Ordner community-operators aufzunehmen, und einen für den Ordner upstream-community-operators. Für jeden Commit erstellen wir einen Pull Request im Community-Operators-Repository und fügen die gewünschte Nachricht in den Pull Request ein.

Quelle: GitHub

Beispiele für diese automatisierten PRs finden Sie hier und hier.

Nach der Erstellung der PRs werden automatisierte Tests in OperatorHub und OpenShift ausgeführt. Schließlich führen die Maintainer dieser Repositories unsere neue Version zusammen.

Fazit

Durch die vollständige Automatisierung des Release-Prozesses für unseren Operator sparen wir unserem Engineering-Team viel Zeit und Ressourcen. Gleichzeitig können wir weiterhin so schnell und effizient wie möglich neue Versionen unserer Software bereitstellen.

Snyk Controller integriert Snyk-Scans in Ihre Kubernetes-Cluster. So können Sie Ihre laufenden Workloads importieren und testen sowie Schwachstellen in den zugehörigen Images und Konfigurationen erkennen, die die Sicherheit dieser Workloads beeinträchtigen könnten. Hier erfahren Sie mehr. Registrieren Sie sich für ein kostenloses Konto und nutzen Sie Snyk.