Continuous Delivery für den Container – Teil 1

Der erste Teil dieser Blog-Serie thematisiert das Erstellen von Containern mit einer Continuous Delivery Pipeline.

Autor:  Christian Sanabria

Continuous Delivery ist in der Schweiz angekommen und viele Unternehmen haben inzwischen eine mehr oder weniger ausgeprägte Continuous Delivery Pipeline. Ebenfalls ist Cloud, bzw. sind Container, bei immer mehr Firmen ein heiss diskutiertes Thema. Diese beiden Gebiete zusammenzuführen liegt dabei auf der Hand. Produkte wie OpenShift von Red Hat unterstützen mit praktischen Features und Tool-Integrationen den Aufbau einer container-basierten Continuous Delivery Pipeline für flexible Entwicklung und schnelleres Time-to-Market.

Der Container als Fundament

Um überhaupt mit Continuous Delivery in der Cloud beginnen zu können, braucht es passende Base-Images. Dabei gibt es viele Möglichkeiten wie man zu solchen Base-Images gelangt, um daraus eigene Images für Applikationen erstellen zu können. Für OpenShift bietet z.B. Red Hat eine grosse Anzahl eigener Images an. Auch Öffentliche, wie aus Docker Hub, sind zur Verwendung möglich. Als weitere Alternative können Base-Images selbst entwickelt werden. Der erste Teil der Blog-Reihe «Continuous Delivery für den Container» geht auf eben diesen Entwicklungsprozess ein.

Bausteine eines Containers

Container sind Instanziierungen von Images. Das Erstellen von Images geschieht dabei z.B. bei Docker über sogenannte Dockerfiles. Diese bestehen aus einer Reihe von Anweisungen welche, meist auf Basis eines Base-Images, Builds und Konfigurationen ausführen. Die Base-Images selbst werden auf dieselbe Weise entwickelt.

Continuous-Delivery-1.png
Abb. 1: Anatomie eines Images

Base-Images stellen meist ein minimales OS sowie grundlegende Konfigurationen, wie Netzwerk, DNS oder NTP zur Verfügung. Ausserdem sind Referenzen zu Software-Repositories mit freigegebenen Paketen sowie Artefakt-Repositories vorkonfiguriert.

Fliessbandarbeit

Dockerfiles funktionieren wie Source Codes und der Build eines Images unterliegt denselben Regeln wie der Build einer Applikation. Das heisst, dass Images zu testen sind, bevor sie für den produktiven Betrieb freigeben werden. Und wie bei jeder Applikation geschieht dies über eine Continuous Delivery Pipeline.

Continuous-Delivery-2.png
Abb. 2: Allgemeine Continuous Delivery Pipeline

Alle Schritte innerhalb der Pipeline laufen vollautomatisch ab und werden idealerweise auch durch einen automatisierten Trigger angestossen, z.B. durch Pull-Requests auf ein Code-Repository.
In der Verify-Phase findet eine automatisierte statische Code-Analyse, z.B. mit Sonar, statt, um problematische Anweisungen im Dockerfile zu finden. In der Test-Phase werden automatisierte Tests auf Betriebssystem-Ebene durchgeführt, wofür beispielsweise ServerSpec verwendet werden kann.

Qualitätskontrolle

Da Images auch OS und Systemkonfigurationen beinhalten, gilt vor allem in der Verify- und Test-Phase besondere Aufmerksamkeit bezüglich der Compliance. Images unterliegen den selben Anforderungen wie produktive Server oder VMs. Produktiv deshalb, da Container von der Entwicklungsumgebung bis in die Produktion aus demselben Image instanziiert werden.

Compliance beinhaltet z.B. die Sicherstellung von Security-Einstellungen, Konfigurationen und anderen Policies bezüglich Infrastruktur. Mögliche Tests beziehen sich auf die Kontrolle, ob das sudo-Kommando nicht aufgerufen werden kann, ob bestimmte Dienste laufen oder ob sensitive Verzeichnisse / Dateien mit den entsprechenden Dateisystemberechtigungen versehen sind. Dafür kann beispielsweise InSpec verwendet werden.

Einzug in den Container

Sobald ein Base-Image in das Image-Repository deployed wurde, kann es auf verschiedenste Varianten verwendet werden. Produkte wie CA DevTest können darauf installiert werden, um eine On-Demand Testumgebung aufzubauen, was im zweiten Teil «Verwendung von Containern für eine Continuous Delivery Pipeline» dieser Blog-Reihe aufgezeigt wird. Oder es können Builder-Images (Source-to-Image, S2I) darauf aufsetzen, um Eigenentwicklungen in einer stabilen Umgebung bauen und deployen zu können, was im dritten Teil «Deployen von Containern in einer Continuous Delivery Pipeline» der Blog-Reihe erläutert wird. Beides geschieht ebenfalls über Dockerfiles und kann über dieselbe Pipeline wie die Base-Images automatisiert deployed werden, wobei sich natürlich die Anforderungen an die Tests entsprechend ändern.

Wartung

Mit einer Container-Orchestrierung wie OpenShift kann nun die Wartung solcher Container-Landschaften massiv vereinfacht und fast vollständig automatisiert werden.
Im Falle eines Security-Issues, wie z.B. beim Heartbleed-Bug in OpenSSL, kann nun einfach ein neues Base-Image mit der abgesicherten Version der Bibliothek erstellt und deployed werden. OpenShift erkennt eine neue Version des Base-Images und kann alle darauf aufbauenden Images ebenfalls neu bauen, bis alle Container mit der korrigierten Software laufen.

Continuous-Delivery-pipeline.gif
Abb. 3: Container in der Continuous Delivery Pipeline

Durch die Continuous Delivery Pipeline und den entsprechenden Tests ist zu jedem Zeitpunkt sichergestellt, dass Compliance eingehalten wird und alle Anwendungen weiterhin wie erwartet funktionieren.

Und jetzt?

Mit der Continuous Delivery Pipeline für Images sind nun die Grundlagen für das eigentliche Applikations-Deployment gelegt. Es ist jederzeit sichergestellt, dass alle Compliance-Vorgaben für die Container eingehalten werden und dass sicherheitsrelevante Korrekturen kontrolliert und vor allem automatisiert verteilt werden, was bei physischen Servern oder VMs nicht ohne weiteres möglich ist.

Weitere Reihen der Blogserie Continuous Delivery für den Container folgen im Laufe der restlichen Woche. Mit Teil 2 (Verwendung von Containern für eine Continuous Delivery Pipeline) und Teil 3 (Deployen von Containern in einer Continuous Delivery Pipeline) dieser Blog-Reihe wird auf weitere Stärken von Container in Bezug auf Continuous Delivery eingegangen werden.