Continuous Delivery für den Container – Teil 2

Im zweiten Teil der Blog-Reihe zeigen wir die Verwendbarkeit der Container in der Continuous Delivery Pipeline innerhalb einer Cloud-Umgebung auf.

Autor:  Christian Sanabria

Verwendung von Containern für eine Continuous Delivery Pipeline innerhalb einer Cloud-Umgebung: Hauptsächlich für die Applikationsentwicklung, aber natürlich auch für Images selbst.

Things we leave behind

Die Infrastruktur in der klassischen Softwareentwicklung sieht in etwa folgendermassen aus:

  • Entwickler haben eine Desktop-Entwicklungsumgebung auf dem eigenen Notebook oder PC, inkl. Build- und einigen Test-Werkzeugen sowie eine kleine Menge Testdaten.
  • Auf der Continuous-Integration-Umgebung sind dieselben Build- und Test-Werkzeuge sowie Testdaten, diesmal vollständig, vorhanden und werden über alle Projekte hinweg geteilt.
  • Auf allen weiteren Staging-Umgebungen sind erneut die gleichen Test-Werkzeuge und Test-Daten vorhanden, welche ebenfalls über alle Projekte geteilt werden.
  • Zusätzlich gibt es ein zentrales Code- und Artefakt-Repository sowie ein Werkzeug zur Abbildung der Pipeline.

Dieses Setup birgt einige Nachteile:

  • Die Versionen von Build- und Test-Werkzeugen müssen über alle Staging-Umgebungen synchron gehalten werden, was mit Installationsaufwand und Down-Times verbunden ist.
  • Die Continuous-Integration-Umgebung sollte immer verfügbar und auch skalierbar sein, was mit Wartungsaufwand verbunden ist.
  • Änderungen an den Test-Daten haben Seiteneffekte auf andere Projekte und müssen konsistent gehalten werden, was mit Koordinationsaufwand verbunden ist.

Brave new world

In der Welt von Containern und Container-Orchestrierung sieht die Infrastruktur in etwa folgendermassen aus:

  • Entwickler haben eine Desktop-, vielleicht aber auch eine Online-Entwicklungsumgebung zur Verfügung.
  • Alle weiteren Bestandteile der Continuous Delivery Pipeline sind als Image bereitgestellt und können bei Bedarf als Container instanziiert und mit entsprechenden Konfigurationen gestartet werden.
  • Eine Cloud-Umgebung und Container-Orchestrierung wie OpenShift steht zur Verfügung.
  • Das zentrale Code- und Artefakt-Repository sowie das Pipeline-Werkzeug existiert weiterhin.

Mit diesem Setup lassen sich die Nachteile der «klassischen» Pipeline elegant eliminieren:

  • Es muss nur noch ein Image pro Build- und Test-Werkzeug unterhalten werden, die Synchronisation über mehrere Staging-Umgebungen entfällt.
  • Test-Daten werden ebenfalls dediziert bei Bedarf in einem Container bereitgestellt, wobei Änderungen keine Seiteneffekte auf andere Projekte und die Konsistenz haben.
  • Es existiert keine Continuous-Integration-Umgebung mehr, da die benötigten Werkzeuge bei Bedarf in Containern gestartet und durch die Container-Orchestration skaliert werden.

Unbreakable

Durch die Verwendung von Containern und Container-Orchestrierung, zusammen mit einer Cloud-Umgebung, entsteht eine neue Continuous Delivery Pipeline. Diese ist für effiziente Softwareentwicklung und schnelles Time-to-Market hervorragend geeignet. Builds, Testing und Deployment ist für jedes Projekt über alle Staging-Umgebungen von anderen Anwendungen unabhängig, was Stabilität und Reproduzierbarkeit massiv erhöht. Die Koordination der Test-Daten wird vereinfacht, da nur noch ein globaler Stand gepflegt werden muss, welcher bei Bedarf instanziiert und nach den Tests wieder verworfen wird und damit jederzeit in konsistentem Zustand verfügbar ist. Der Unterhalt einer Continuous-Integration-Umgebung sowie mehrerer Instanzen von Test-Werkzeugen wird durch die Pflege von Images ersetzt und entfällt somit.

Deep Impact

Der Aufbau einer solchen Container-gestützten Continuous Delivery Pipeline ist mit mehr oder weniger hohem Initialaufwand verbunden. Vor allem die Entwicklung der Images sowie die Bereitstellung der Cloud-Umgebung ist nicht zu vernachlässigen. Wir müssen uns bei Images Gedanken machen, wie Konfigurationen oder Test-Daten beim Container-Start geladen werden können. Speziell bei Standardprodukten ist mit Mehraufwand beim Image-Design zu rechnen. Ebenso können unter Umständen Anpassungen bei Prozessen und Schnittstellen, elektronischen wie auch menschlichen, notwendig werden.

Step by Step

Jedoch muss der Initialaufwand nicht in einem Big-Bang geleistet werden, sondern jeder Baustein der Continuous Delivery Pipeline kann einzeln und nach Bedarf migriert werden. Dadurch lässt sich eine vernünftige Planung und Umsetzung ohne grosse Risiken realisieren. Dem Ziel einer DevOps Organisation kommt man mit grossen Schritten näher, da durch die dedizierten Container viel mehr Verantwortung an die Entwickler übergeben wird: Sie warten und deployen die Images für ihre Werkzeuge selber. Entsprechend wird der Betrieb entlastet und kann sich auf seine Kernaufgaben konzentrieren anstatt sich mit Entwicklungs- und Continuous-Integration-Umgebungen zu beschäftigen.

Und jetzt?

Mit der Continuous Delivery Pipeline für Images und der Bereitstellung dieser Pipeline mittels Containern fehlt nur noch das Deployment von Eigenentwicklungen in Containern über verschiedene Stages hinweg. Dies geschieht über Builder-Images (Source-to-Image, S2I). Mit Teil 3 «Deployen von Containern in einer Continuous Delivery Pipeline» werden wir auf die Stärke von Containern in Bezug auf Continuous Delivery eingehen.