Continuous Delivery in der Cloud, Teil 2 6 Gründe für Spinnaker bei Cloud-Deployments

Die Open-Source-Software Spinnaker ergänzt gängige CI-, sprich Continuous-Integration-Tools um Komponenten zur Umsetzung von Continuous Delivery (CD) in Multi-Cloud-Umgebungen. Es gibt viele gute Gründe für den Einsatz von Spinnaker, hier die sechs wichtigsten.

Anbieter zum Thema

Insider Research

OutSystems

Fastly GmbH

Pivotal

1. Nahtlose Integration mit Cloud Foundry

Cloud Foundry ist eine Open Source Application Development Platform (PaaS), mit der sich Enterprise-Anwendungen entwickeln und über ihren gesamten Lebenszyklus hinweg managen lassen. Die PaaS unterstützt eine Vielzahl von Entwicklungswerkzeugen, so dass Developer ihr bevorzugtes Werkzeug-Set nutzen können. Pivotal, einer der Hauptunterstützer von Cloud Foundry, sorgt mit einem Adapter für eine tiefe Integration mit Spinnaker.

Da CI-Werkzeuge oder Build Server wie Concourse und Jenkins Multi-Cloud-Abstraktionen nicht nativ unterstützen, übernimmt der in Cloud Foundry integrierbare Adapter nun diese Aufgabe. Die in den CI-Tools implementierten Jobs und Workflows können an Spinnaker übergeben, dort um die notwendigen Multi-Cloud CD-Prozesse und Pipelines erweitert und schließlich automatisiert durchgeführt und überwacht werden.

2. Optimierung für Multi-Cloud-Strukturen

Spinnaker entkoppelt die Release-Pipeline von der direkten Kopplung an Public Cloud Provider. Denn Spinnaker nutzt ein agnostisches Deployment-Modell, welches die unterschiedlichen Konfigurationsanforderungen der verschiedenen Ziel-Clouds verallgemeinert. Das heißt, Anwendungen lassen sich so auf die gleiche Weise auf mehreren Clouds und Plattforminstanzen verteilen.

Eine wichtige Voraussetzung, um die Bereitstellung von Anwendungen über mehrere Phasen und Teams hinweg zu standardisieren. Jedes Mal, wenn eine Anwendung geändert wurde, kann sie schnell und ohne weiteren Aufwand vollautomatisch in mehrere Public Clouds gleichzeitig deployt werden.

3. Zero Downtime Deployments

Dabei unterstützt Spinnaker auch komplexere Bereitstellungsprozesse. Dazu zählen beispielsweise Blue/Green-Deployments: Um valide Testergebnisse abzuwarten, wird die Anwendung praktisch in realer Produktivumgebung getestet. Dafür müssen zwei identische Umgebungen ausgerollt werden, damit eine als Testfeld dienen kann.

Ein weiteres Szenario sind Canary-Deployments: Hierbei werden ebenfalls zwei identische Produktivsysteme ausgerollt, wobei eines aktualisiert und mit einem zuvor festgelegten Anteil an realem Traffic getestet wird. Spinnaker ermöglicht die Automatisierung solcher Prozesse.

Läuft alles nach Plan, werden die Änderungen nach den Tests in die zweite Umgebung übernommen. Gibt es Abweichungen vom erwarteten Ergebnis, kann ein Rollback erfolgen. Außerdem unterstützt Spinnaker progressives Deployment, etwa wenn verschiedene Zeitzonen entsprechend versetzt mit den neuen Features versorgt werden sollen.

4. Inventarisierung der Anwendungen

CD mag die Bereitstellung beschleunigen, aber man verliert doch schnell den Überblick über schon ausgespielte, getestete oder zurückgerollte Änderungen, erst recht, wenn mehrere Public Clouds im Spiel sind, oder die Anwendung aus mehreren untereinander abhängigen Komponenten besteht, die über mehrere Clouds verteilt wurden um die Abarbeitung von Anfragen zu optimieren.

Spinnaker übernimmt die Inventarisierung und vermerkt die IaaS-Bereiche und Runtimes der Anwendungen und ihrer Instanzen. Dafür werden die Cloud-Ressourcen regelmäßig abgefragt und zwar auch nach Anwendungen, die gar nicht über Spinnaker deployt wurden.

Diese Kontrollinstanz zeigt den Zustand der Anwendungen an, mögliche Fehler werden aufgedeckt und Korrekturmaßnahmen, wie etwa ein Neustart oder ein Rollback, können eingeleitet werden. Auch andere Werkzeuge können diese Inventur-Übersicht nutzen, um beispielsweise Sicherheitsschwachstellen im Code zu finden oder anderen Unregelmäßigkeiten im produktiven System auf den Grund zu gehen.

5. Compliance und Auditierbarkeit der Pipeline

Über die Inventarisierung hinaus pflegt Spinnaker einen Audit-Trail über alle Änderungen an Anwendungen und Infrastrukturen. Im Prinzip können Entwickler, der IT Betrieb und Auditoren erkennen, wer, was, wann und warum geändert hat.

Das System unterstützt rollenbasierte Zugriffskontrollen und bietet mehrere Authentifizierungs- und Authorisierungsoptionen, wie beispielsweise OAuth, SAML, LDAP, GitHub-Teams, Azure und Google Groups an. Wenn gewünscht, lassen sich sogar manuelle Änderungen oder sogenannte Approval Gates tracken, an denen der Workflow auf eine manuelle Eingabe wartet, um seine Arbeit fortsetzen zu können.

6. Erweiterbarkeit und breites Ökosystem

Neben der bereits erwähnten Integration mit CI- und Build Tools wie Concourse, Jenkins, Wrecker oder Travis CI – nun vereinfacht durch den Adapter für Pivotal Cloud Foundry – arbeitet Spinnaker mit zahlreichen anderen Anwendungen aus verschiedenen Bereichen zusammen.

So lassen sich beispielsweise Nachrichten über Slack, HipChat oder E-Mail senden und Application Monitoring Tools wie Datadog, Prometheus integrieren. Durch Spinnakers Cloud-Provider-Unabhängigkeit wird es durch diese breite Unterstützung vieler Tools möglich, den eigenen, bewährten Technology Stack weiterzuverwenden.

Fazit: Spinnaker vereinfacht Continuous Delivery

CD wurde als Fortsetzung und Erweiterung agiler Development-Methoden entwickelt. Spinnaker setzt dort an, wo CI-Tools aufhören und ermöglicht komplexe, regelbasierte, Cloud-Provider-integrierte, automatisierte Application Deployments. Spinnaker kombiniert dafür zwei wichtige Komponenten im CD-Prozess: Zum einen lassen sich komplexe CD-Pipelines auf der Basis von CI-Workflows erstellen. Zum anderen ist Spinnaker in der Lage, dies unabhängig vom Public-Cloud-Provider auszurollen.

Jürgen Hoffmann

Praktisch relevant für Entwickler ist Spinnaker, weil sie dank des breiten Ökosystems die Entwicklungs-, Testing-, CI- und Monitoring-Tools nutzen können, die sie mögen. Und weil sich bereits eine große Community etabliert hat – angeführt von namhaften Unternehmen wie Netflix, Google, Microsoft, Veritas und Kenzan – die die Weiterentwicklung forcieren.

* Jürgen Hoffmann ist Senior Manager Platform Architecture bei Pivotal. Das Unternehmen beschleunigt die Entwicklung von innovativer Software vieler der weltweit größten Marken. Damit unterstützt Pivotal Unternehmen, nach dem Vorbild des Silicon Valleys die passenden Lösungen zu bauen, die sie im Rahmen der digitalen Transformation benötigen.

Hoffmann hält ein Diplom in Wirtschaftsinformatik der Technischen Universität Darmstadt und verfügt über mehr als 25 Jahre IT-Erfahrung mit einem besonderen Fokus auf Java-basierter Software und Linux-basierter Infrastruktur. Vor Pivotal war er sieben Jahre lang in verschiedenen Management-Positionen bei Red Hat tätig.

(ID:45987508)