Docker und DevOps | Von Continuous Integration zu Continuous Delivery

Ein Ziel von DevOps ist die weitestgehende Automatisierung aller beteiligten technischen und damit auch die Vereinfachung und Unterstützung der organisatorischen Prozesse. Hierbei kommen seitens der Entwicklung „Continuous Integration Plattformen“ und seitens des Betriebs „Provisioning- und Deployment-Tools“ zum Einsatz. Docker ermöglicht es, diese beiden Stränge der Automatisierung effektiv miteinander zu verbinden und Continuous Delivery zu erreichen.

Auf Seiten der Entwicklung kommen Continuous Integration (CI) Plattformen zum Einsatz – eine meist webbasierte „Steuerzentrale“ zur Automatisierung der Build- und Test-Prozesse. Hier werden bei Änderungen am Programmcode Software-Builds automatisiert angestoßen, welche statische Code-Analysen sowie Unit- und Integrations-Tests ausführen und installierbare Pakete bereitstellen. Außerdem werden wiederkehrende Aufgaben wie Security-Tests, Lasttests, User Acceptance Tests sowie Deployments auf Test-Systeme automatisiert und für alle sichtbar gebündelt. Change- und Patch-Management, welches zuvor in der Live-Umgebung realisiert wurde, wird ebenfalls Teil des Continuous Integration Prozesses.

Auf Seiten des Betriebs werden mit Hilfe von Werkzeugen wie Puppet, Ansible, Chef oder anderen alternativen Tools sämtliche Provisioning- und Deployment-Aufgaben automatisiert. Bei den genannten Aufgaben in der Continuous-Integration (CI) werden von Anfang an Docker-Images als Ergänzung bzw. Ersatz für die erwähnten Software-Pakete erzeugt. Diese Images bilden dann sowohl die Grundlage für die Test-Automatisierung als auch für das Deployment bis hin zur Live-Stage.

Der Software-Build in der CI erzeugt mittels der aus dem Betrieb bekannten Werkzeuge automatisiert Docker Images, welche auf Test-Umgebungen deployed werden. Hier werden die resultierenden, installierten Container als Grundlage für alle nötigen Tests genutzt. Die selben Images werden, wenn sie erfolgreich alle Tests durchlaufen haben, bis hin zur Live-Umgebung für das Deployment genutzt.

Auf diese Art und Weise werden neben der Software auch alle Deployment-Automatismen, Daten-Migrationen und Konfigurations-Änderungen im Continuous-Integration System “mitgetestet”. Die CI-Plattform dient somit zusammen mit dem
Einsatz von Docker als Kernstück der gesamten Automatisierungskette für die Implementierung von Continuous Delivery.

DevOps verkürzt den Softwareentwicklungsprozess durch die zielgerichtete, direkte Zusammenarbeit von Entwicklung (Dev) und Betrieb (Ops) mit dem Ziel der schnellen Auslieferung neuer Features und von Bug-Fixes in hoher Qualität. In der “klassischen” Softwareentwicklung durchläuft eine Software von der Implementierung eines Features bis zum Deployment auf dem Live-System viele Prozessschritte. Dabei gibt es eine technische und organisatorische Grenze zwischen Entwicklung und Betrieb. Zur Überwindung dieser Grenze soll durch Test- und Abnahme-Prozesse ein hoher Reifegrad der Software für den Betrieb sichergestellt werden. Danach sind Störungen im Betrieb Ausnahmen und werden im Rahmen eines Incident-Management behandelt.

Durch diese Art der Organisation ist der Weg von einer “Störung” bis hin zur Behebung des zugrunde liegenden Problems in der Software weit.

Mit DevOps rücken die Entwicklung und die dort genutzten Deployment-Methoden für Entwicklungs- und Test-Systeme näher an den Live-Betrieb heran. Die Zeit zur Behebung von Störungen bzw. der Impact durch Rollouts wird dadurch minimiert, dass der Reifegrad der Software schon während der Entwicklung durch die Benutzung der gleichen Werkzeuge und Techniken inhärent erreicht wird.

Kundenanforderungen können auf diese Weise schneller umgesetzt werden. Gleichzeitig sinkt die Zahl der Incidents und damit der Ressourceneinsatz. Die verbleibenden Incidents lassen sich aufgrund des hohen Automatisierungsgrades leichter nachvollziehen und reproduzieren. Eine Menge Gründe, die dafür sprechen, den bisherigen Softwareentwicklungsprozess zu überdenken.

Unabdingbar für die Einführung von DevOps ist die Bereitschaft aller Beteiligten, bestehende Prozesse und Strukturen verändern zu wollen. Gegenseitiges Vertrauen und die gemeinsame Übernahme der Verantwortung für alle Prozesse durch Dev und Ops sind Grundvoraussetzungen für den erfolgreichen Transformationsprozess von klassischen hin zu agilen Prozessen.

“Grass Roots”-Bewegungen sind in diesem Bereich deutlich weniger erfolgreich als die Einführung von DevOps „von oben“. Insofern ist es notwendig, dass das Management hinter der DevOps Einführung steht, plant und forciert:

1. Das erste DevOps-Projekt sollte dedizierte Ressourcen zugewiesen bekommen und das Team ausreichend Zeit für die Umsetzung.

2. Bestehende Tasks, Bug-Fixes und Rollouts sollten die Einführung von DevOps nicht ausbremsen. Schließlich sollen durch den neuen Ansatz genau diese Tasks schneller und einfacher umgesetzt werden. Eine Priorisierung sollte also im Zweifel in Richtung DevOps-Umsetzung vorgenommen werden.

3. Wie jede Änderung braucht auch ein neuer Deployment-Ansatz Unterstützung von anderen Abteilungen. Je mehr Rückendeckung und Zustimmung im Unternehmen existiert, desto besser. Das kann man aber nur durch gute Kommunikation erreichen.

4. Das Projekt sollte schrittweise geplant und angegangen werden. Kleine Erfolge sollten über das Team hinaus kommuniziert werden, um das gemeinsame Verständnis und den Know-how Transfer sicherzustellen.

Im vorliegenden Szenario verpacken wir die Anwendungen in sog. Docker Container, wodurch die Anwendungen separiert und vom Betriebssystem isoliert werden. Jedoch ist Docker nicht in der Lage die IP-Adressen interdependenter Dienste selbständig aufzulösen und zu aktualisieren. Aber genau das wäre nötig, wenn ein Service ausfällt oder neu gestartet wird. Unser Ziel sind Container, die bei jedem Start und im laufenden Betrieb die IPs aller abhängigen Anwendungen und Dienste automatisiert aktualisieren. Hierfür setzen wir Consul ein.

Alle verfügbaren Dienste in einer bestimmten Umgebung werden von der Consul Service Registry verwaltet, die selbst ebenfalls in einen Container gepackt ist und sich problemlos in jeder Umgebung starten lässt. Die übrigen Container in der Umgebung enthalten jeweils einen sog. “Consul Agent”, die sich beim Start mit der Consul Registry verbinden. Durch Abfrage der Consul API können sich unsere Dienste nun gegenseitig finden. Hierbei setzen wir Consul als voll funktionsfähigen DNS-Server ein, um eine vollständige Kontrolle über die Auflösung aller Dienste zu haben.

Alle verfügbaren Dienste in einer bestimmten Umgebung werden von der Consul Service Registry verwaltet, die selbst ebenfalls in einen Container gepackt ist und sich problemlos in jeder Umgebung starten lässt. Die übrigen Container in der Umgebung enthalten jeweils einen sog. “Consul Agent”, die sich beim Start mit der Consul Registry verbinden. Durch Abfrage der Consul API können sich unsere Dienste nun gegenseitig finden. Hierbei setzen wir Consul als voll funktionsfähigen DNS-Server ein, um eine vollständige Kontrolle über die Auflösung aller Dienste zu haben.

Veröffentlichung am 14. Oktober 2015, aktualisiert am 18. Oktober 2020