Continuous Delivery in der Cloud, Teil 1 Das Deployment-Tool Spinnaker unter Cloud Foundry
Was nützt es agil zu sein, wenn fertig entwickelte und den Integrationstest erfolgreich absolvierte Code-Änderungen nicht schnell genug ausgeliefert werden können? Das Open-Source-Tool Spinnaker ist dabei eine wertvolle Unterstützung.
Anbieter zum Thema

Die Zeiten der großen halb- oder vierteljährlichen Software-Releases sind längst vorbei. Agile Entwicklungsmethoden liefern Änderungen an den Anwendungen – wie neue Features, Bugfixes und ähnliches – in kleineren Häppchen, die schnelle Integration und Umsetzung immer im Blick.
Die Umsetzung von Continuous Delivery bedeutet aber weit mehr, als Continuous-Integration-Prozesse um einen Deployment-Schritt zu erweitern. Zusätzlich zur Bereitstellung von Anwendungen auf zumeist Cloud-basierten Infrastrukturen geht es darum, Security, Skalierbarkeit und Nachvollziehbarkeit sicherzustellen.
Auf gewisse Standards darf bei all der gewünschten Agilität und Geschwindigkeit also nicht verzichtet werden: Vor allem das Testen, was bei herkömmlicher Software-Entwicklung oft stiefmütterlich behandelt wird, sollte man entschieden verfolgen, um Fehler frühzeitig zu vermeiden. Die Art und Weise muss aber sehr wohl an die agilen Prozesse angepasst werden.
Systematisch entwickeln und integrieren
Continuous-Integration-Werkzeuge (CI) bilden oft den ersten Schritt in Richtung einer zumindest teilweisen Automatisierung der Software-Bereitstellung. In der Praxis sollen viele kleine Code-Änderungen kontinuierlich direkt in den Hauptzweig der Anwendung integriert werden. Dies verringert das Risiko, dass Fehler zu spät erkannt werden und ermöglicht ein zeitnahes Ausliefern der Software.
Während des gesamten Softwareentwicklungs- und Software-Release-Zyklus sollten geeignete Tests die Funktionsfähigkeit der Software sicherstellen. Nur so kann garantiert werden, dass jede auch noch so kleine Änderung keine Fehlfunktionen im Gesamtkontext der Anwendung produziert. Dafür müssen automatisierte Unit-, Last- und Integrations-, und Deployment-Tests aufgesetzt werden.
CI-Umgebungen wie Jenkins oder Concourse CI bringen die notwendige Systematik in den komplexen CI-Prozess. Beide Beispiele sind Open-Source-Initiativen mit einer regen Entwickler-Community und arbeiten mit mehreren Stufen. In Concourse definiert der Nutzer seine Quellressourcen – diese können ganz verschiedene sein, von Git Repositories bis Docker Images.
Tasks stellen Schritte in einem Job in der Build-Pipeline dar und dienen der Ausführung von Build-Skripten, die samt der benötigten Abhängigkeiten und Konfigurationen in einem Docker-Container gekapselt werden. Aus mehreren Tasks entstehen Jobs, die Input verarbeiten sowie Output liefern und wiederum als Ressource definiert werden.
Schließlich lässt sich alles zu einer CI-Pipeline orchestrieren. Mit dieser Verkettung – Änderungen der Input-Ressourcen lösen bestimmte Jobs aus, die neue Outputs erzeugen und dabei wieder andere Jobs auslösen – lassen sich komplexe Strukturen abbilden.
Kontinuierliche Bereitstellung in der Cloud
Nach dem Durchlauf der CI-Pipeline steht die Anwendung samt neuem Feature im Prinzip zum Deployment bereit. Die Qualität des Codes sollte nun hoch sein und die neuen Funktionen dürften sich reibungslos in die Anwendung einfügen.
Bei der Auslieferung der Änderungen in die produktive Umgebung sind jedoch weitere Punkte zu beachten: Die neue Anwendung sollte nicht nur funktionieren, sondern gleichzeitig sicher, skalierbar, rückverfolgbar sowie auf verschiedenen Infrastrukturen ausgerollt werden können.
Ein einfaches Deployment genügt deshalb nicht. Diese eher anwendungsbetrieblich bezogenen Aspekte finden bisweilen zu wenig Beachtung innerhalb der agilen Entwicklung – sie müssen aber beachtet werden, um Software kontinuierlich auszuliefern und bereit zu stellen, respektive bestehende Installationen zu aktualisieren.
Open-Source-CD-Tool: Spinnaker
Auch für die Umsetzung eines effektiven CD-Prozesses stehen hilfreiche Werkzeuge zur Verfügung. Das Continuous-Deployment-Tool Spinnaker erfährt besonders breite Unterstützung durch die Open-Source-Community und wurde ursprünglich von Netflix entwickelt, um die eigenen Software-Releases auf Cloud-Plattformen zu verteilen.
Spinnaker unterstützt die gängigsten CI-Tools, inklusive Concourse und Jenkins, und ist programmiersprachenunabhängig einsetzbar. Das Wichtigste ist jedoch das agnostische, also verallgemeinernde, Deployment-Modell: So können Anwendungen simultan auf verschiedene Cloud-Plattformen verteilt werden wie Amazon Web Services, Google Cloud Platform, Microsoft Azure und Kubernetes.
Spinnaker fungiert dabei als anwendungszentrierte Steuerungsebene. Die für die Entwickler weniger interessante Bereitstellung von Cloud-Infrastruktur wie das Provisionieren von virtuellen Maschinen, Load Balancern, Services u.Ä., werden standardisiert.
Sprich: Spinnaker organisiert Ressourcen um die Anwendung herum. Vorgaben hinsichtlich Performance oder Security werden vorab definiert und dann bei der Bereitstellung berücksichtigt. Am Ende stehen die Anwendungen auf allen verschiedenen Plattformen einheitlich und sicher bereit.
Neben diesem Application-Management-Part bietet Spinnaker zugleich Unterstützung beim Application Deployment. Der Entwickler stellt Pipelines zusammen, die aus mehreren Aktionssequenzen, sogenannten Stages, bestehen. Dabei können jeweils Parameter von Stage zu Stage übergeben werden. Die Pipeline kann sowohl manuell als auch automatisch getriggert gestartet werden.
Spinnaker und Pivotal Cloud Foundry: CD für die Cloud
Bisher war es nicht ganz einfach CI-Tools mit Spinnaker zu verbinden. CI-Systeme sind typischerweise nicht mit nativer Unterstützung für Cloud-Abstraktionsebenen ausgestattet und können keine Pipelines erschaffen, die bestimmte betriebliche Vorgaben für den Anwendungsbetrieb erfüllen sollen. Als Verbindungsebene zwischen CI und Spinnaker kommt der quelloffene Plattform-Service Cloud Foundry ins Spiel
Zum einen sorgt Cloud Foundry dafür, dass Entwicklerteams mit den gewohnten Werkzeugen Applikationen entwickeln können, die sie bevorzugen, ohne auf die Vorgaben der verschiedenen Cloud-Services achten zu müssen, da diese über die Open-Service Broker API Cloud-übergreifend durch die Plattform bereitgestellt werden. Pivotal ergänzte nun das Pivotal-Cloud-Foundry-Angebot mit einem zusätzlichen Adapter für Spinnaker.
Concourse lässt sich somit auf einfache Art und Weise mit Spinnaker integrieren: Beispielsweise können nun Deployments in Spinnaker über das Manifest gesteuert werden. Ein Manifest enthält Metadaten für eine Gruppe von Dateien und Deployments. Zudem sind nun Blue/Green-Deployments möglich, bei denen auf zwei produktive, meist identische Umgebungen deployed wird. Die verschiedenen Cloud-Services, auf denen die verschiedenen Anwendungsteile bereitgestellt werden sollen, werden nun übersichtlich dargestellt, Application-Management wie Skalierung, Enable/Disable, Rollback und ähnliches sind möglich.
Fazit
Die Integration von Spinnaker mit Pivotal Cloud Foundry ist ein wichtiger Schritt, um CI und CD für Entwicklerteams praktisch umsetzbar zu machen. „Continuous“ kann die Entwicklung und Bereitstellung vor allem auf verschiedenen Infrastrukturen nur sein, wenn der Prozess durchgängig orchestriert und gleichzeitig Sicherheits-, Performance- und andere individuelle Vorgaben berücksichtigt werden.
Dass diese Entwicklungen nachhaltig sind beweist nicht nur die aktive Community, sondern ebenso die große Anzahl der Unternehmen, die sich hier engagieren. So sollen nach und nach mehrere CI/CD-Initiativen unter dem Dach der Continuous Delivery Foundation (CDF) zusammengeführt werden.
Die gemeinnützige Stiftung agiert unter der Federführung der Linux Foundation. Die CDF will nach eigenen Angaben ein herstellerneutrales Zuhause für wichtige CI/CD-Projekte wie Jenkins und Spinnaker schaffen und die Weiterentwicklung fördern.
* 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:45950136)