Continuous Delivery für den Container – Teil 3

In diesem Teil wird eine Strategie dargelegt, wie Container in einer Continuous Delivery Pipeline deployed und über mehrere Stages gebracht werden können.

Deployen von Containern in einer Continuous Delivery Pipeline

Autor:  Christian Sanabria

In den ersten beiden Teilen dieser Blog-Reihe wurde aufgezeigt, wie Images für die Instanziierung von Containern mittels einer Continuous Delivery Pipeline entwickelt und wie Container für den Aufbau eben dieser Pipeline zu verwenden sind. In diesem dritten und letzten Teil wird nun eine Strategie dargelegt, wie Container in einer Continuous Delivery Pipeline deployed und über mehrere Stages, von der Entwicklung bis zur Produktion, gebracht werden können.

Images als neue Artefakte

Gegenüber dem klassischen Staging, bei dem Anwendungs-Artefakte auf jeder Zielumgebung installiert oder aktualisiert werden, bietet ein Staging mit Images mehrere Vorteile:

  • Das Bestellen, Bereitstellen und Konfigurieren von Zielumgebungen ist nicht mehr nötig, sondern passiert ad-hoc mit der Instanziierung des Containers.
  • Die Umgebungskonfigurationen sind auf allen Zielumgebungen immer gleich, da sie zusammen mit dem Instanziieren des Containers aufgebaut werden.
  • Der Installations- oder Updateprozess wurde bereits bei der Image-Erstellung ausgeführt, getestet und braucht keine Wiederholung.
  • Unterbruchfreies Deployment einer Anwendung kann durch parallelen Betrieb mehrerer Container-Versionen und gezieltem Load-Balancing einfacher erreicht werden.

Vom Source zum Image

Für Eigenentwicklungen gibt es prinzipiell zwei Wege, wie man zu einem Image kommt:

  • Der klassische Weg führt über ein Dockerfile, mit dem ein vorpaketiertes Artefakt aus einem Artefakt-Repository auf ein Base-Image installiert wird.
  • Der moderne Weg führt über das Source-to-Image (S2I) Prinzip, das auf sogenannten Builder-Images basiert.

Builder-Images nehmen die URL eines Code-Repositories als Input und enthalten alle Build-Werkzeuge, um aus dem Source Code die Anwendung zu bauen. Für den Build wird aus dem Image ein Container instanziiert und der Build-Prozess gestartet. Nach erfolgreichem Abschluss wird innerhalb des Containers ein Startskript für das neu erstellte Artefakt kreiert. Als letzter Schritt wird aus dem Container ein Anwendungs-Image zu erzeugt, welches für den weiteren Staging-Prozess verwendet werden kann.

Diese ganze Pipeline kann vollkommen automatisiert ablaufen, wobei die PaaS-Lösung die Orchestrierung abhandelt.

Ab in die Pipeline

Ab diesem Zeitpunkt kann das Anwendungs-Image mittels einer Continuous Delivery Pipeline von Stage zu Stage gebracht werden, wie dies der erste Teil dieser Blog-Reihe Continuous Delivery für den Container – Teil 1  erläuterte. Dazu wird die Verwendung einer Container-Orchestrierung wie OpenShift empfohlen. Eine solche Platform-as-a-Service (PaaS)-Lösung enthält bereits alle Funktionen und Prozesse, um eine Pipeline mit Images und Containern aufzubauen. Ein solches Produkt kann über Trigger, z.B. einen neuen Commit auf das Code-Repository oder Änderungen am Base-Image, den Build eines neuen Anwendungs-Images anstossen. Dieses neue Image wird instanziiert und der Container, inklusive der darin laufenden Anwendung, getestet. Bei Erfolg instanziiert die PaaS-Lösung aus dem Image in der nächsten Zielumgebung einen neuen Container, dies parallel zum allfällig laufenden Container, mit der alten Version der Anwendung. Erst wenn auch dieses Quality-Gate erfolgreich durchlaufen wurde, wird der alte Container abgebaut und der Load-Balancer umgehängt (Blue/Green-Deployment). Das Spiel beginnt dann wieder in der nächsten Zielumgebung von Neuem, bis in die Produktion.

Am Türsteher vorbei

In einer solchen vollautomatisierten Continuous Delivery Pipeline kommt vor allem den Quality-Gates eine hohe Bedeutung zu. An diesen Gates werden alle für diesen Stage benötigten Tests automatisiert durchgeführt. D.h. die Tests müssen eine hohe Qualität und Abdeckung aufweisen. Diese Tests können mit Hilfe von Test-Werkzeugen wie CA DevTest durchgeführt werden. Dabei werden auch diese Tools von der PaaS-Lösung bei Bedarf automatisch als Container hochgefahren und initialisiert, wie dies im zweiten Teil «Verwendung von Containern für eine Continuous Delivery Pipeline» dieser Blog-Reihe gezeigt wurde. Falls benötigt, kann man sogar so weit gehen, dass für die Tests ein eigener DB-Container mit geklonten Daten aus der Zielumgebung gestartet wird und erst nach erfolgreichen Tests wird der Anwendungs-Container auf den ‘echten’ DB-Container umgebogen. Auch dieser Prozess wird durch die PaaS-Lösung automatisiert.

Willkommen im Club

Mit dem Abschluss dieser Blog-Reihe sind nun alle Bausteine für eine erfolgreiche Continuous Delivery Pipeline aus Containern für Container beisammen.

Im ersten Teil «Erstellen von Containern mit einer Continuous Delivery Pipeline» wurde gezeigt, wie man Container mittels einer Continuous Delivery Pipeline entwickelt. Im zweiten Teil «Verwendung von Containern für eine Continuous Delivery Pipeline» wurde erläutert, wie man für eine solche Continuous Delivery Pipeline Container einsetzten kann. Dieser letzte Teil demonstrierte, wie man Container mit Hilfe einer Continuous Delivery Pipeline in die Produktion bringt.

Der nächste Schritt ist nun, diese Bausteine im eigenen Unternehmen einzusetzen. Dabei kann Sie ipt in allen Phasen unterstützen: angefangen bei der Erarbeitung einer optimal zugeschnittenen Container-Umgebung, über die Containerisierung von Anwendungen, bis hin zum kompletten Aufbau einer PaaS-Lösung für die Umsetzung der eigenen Cloud Strategie.