fbpx
5 Minuten Lesezeit (1023 Worte)

Das Potential von DevOps mit Docker Containern entfalten

Mit dem heutige Blogbeitrag möchten wir ein Verständnis dafür zu schaffen, ab wann Docker oder allg. Containerisierung als Tooling im Unternehmen bei DevOps-Prozessen lohnenswert ist. Dieser Beitrag erläutert nicht die grundlegende Funktionsweise von Containerisierung und den Unterschied zu VMs oder Ähnlichem. Es soll basierend auf Erfahrungswerten gezeigt werden, welche internen Prozesse bestehen müssen, um das Potential von DevOps via Docker entfalten zu können. Da die Zeit gezeigt hat, dass das Verständnis und die Definitionen von DevOps eine Vielzahl sind, soll auf die hier gestützte Definition gegeben werden:

„DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality" (Bass et al. DevOps: A Software Architect´s Perspective (ISBN: 9780134049878)).


Der erste Gedanke zum Erreichen dieser Ziele sollte die Optimierung und Automatisierung der internen Prozesse ausgehend vom Arbeitsplatz des Entwicklers bis hin zur Integration des entwickelten Codes sein. Das Schlüsselwort hierfür ist Continuous Integration (CI). CI greift bei jedem Commit eines Entwicklers, indem nach dem Commit vordefinierte Applikations- und Integrationstests ausgeführt werden. Dies hat eine höhere Qualität, sowie eine schnellere Entwicklung zur Folge. Unbeabsichtigte logische, sowie semantische Fehler werden über die eben genannten Tests gefiltert und das verbreiten des Codes verhindert. So ist zu jeder Zeit gewährleistet, dass der vorliegende Code zum einen kompilierbar ist und zum anderen die Funktionsweise der Applikation nicht verändert worden ist. CI kann grade in größeren Teams eine entscheidende Rolle sein.

Der nächste Gedanke, nachdem CI erfolgreich umgesetzt wurde, sollte Continuous Delivery (CD) bzw. das erweiterte Continuous Deployment sein. CD setzt auf CI auf und erweitert dieses um Akzeptanztests. Das Continuous Deployment erweitert das CD um den Schritt des automatischen Deployments in Ihre Umgebungen u. a. in die Produktionsumgebung. Mit dem Continuous Deployment besteht somit eine Pipeline vom Entwickler bis hin in die Produktionsumgebung, die komplett automatisch durchgeführt wird. Folgendes Szenario soll das eben erwähnte kurz verdeutlichen. Mehrere Entwickler entwickeln an einer und derselben Applikation. In idealerweise kurzen Zeitabständen übertragen die Entwickler ihren Code in die bestehende Code-Verwaltung (beispielsweise GIT). Durch jeden Commit wird eine Pipeline gestartet, die verschiedenste Tests zur Überprüfung der Richtigkeit und Funktionalität durchführt. Anschließend wird automatisch die Applikation in verschiedenen Umgebungen bereitgestellt. Hier drunter ist ebenfalls eine kleine Gruppe von Endanwendern, welche durch die Nutzung der Software den Akzeptanztest durchführen. Nach Abschluss des Akzeptanztests wird automatisch die neue oder geänderte Applikation auf der Produktionsumgebung bereitgestellt.


Um bis hierhin Ihren Prozess zu optimieren, müssen für Ihre Applikation Tests geschrieben, Pipelines zur automatischen Ausführung dieser und verschiedenste Umgebungen (Dev, QA, Staging, Production) aufgesetzt worden sein. Das allerwichtigste hierbei ist, dass jeder einzelne diesen Prozess lebt. Ein Entwickler, der beispielsweise wochenlang an einer Änderung arbeitet und ggf. mehrere Änderungen auf einmal durchführt ohne diese mit anderen zu teilen, arbeitet gegen diesen Prozess. 

DevOps ist jedoch keine Einbahnstraße für Entwickler. Zu der Optimierung Ihrer Prozesse und damit dem erfolgreichen Leben von DevOps gehört ebenfalls, das reagieren auf Bugs, Ausfälle und Änderungen von Anforderungen. Hierzu zählt ein sauber gepflegtes Monitoring Ihrer Anwendung bzw. Umgebunden sowie eine Möglichkeit, dass Endnutzer schnell auf Fehler etc. aufmerksam machen können. Der Nutzen aus der Kombination mehrerer DevOps Praktiken, führt in Ihrem Unternehmen zu folgenden Benefits:

  • Schnellere Entwicklungszeiten und damit mehr Releases in kürzere Zeit
  • Verkürzte Time-to-Market Zeiten
  • Höhere Qualität durch Beständigkeit Ihrer zu vor definierten Tests
  • Geringere Kosten auf Grund von Automatisierung und Optimierung
  • Wahrscheinlich höhere Akzeptanz beim Endkunden durch schnellere Reaktionszeiten

Alle bis hierhin genannten Punkte sollten erfüllt sein, um eine solide Basis für Tooling wie Docker geschaffen zu haben. Es soll an dieser Stelle ausdrücklich erwähnt werden, dass der Einsatz von Containerisierung auch vorher schon möglich ist. Viele Vorteile von Containerisierung greifen auch ohne die Optimierung der eben genannten Prozesse. Jedoch muss oftmals händisch nachgesteuert werden. Der Wunsch an einem Ende Anpassungen durchzuführen, die voll automatisch bis zum Endkunden gelangen, ist nur durch das Einsetzen von Containerisierung nicht möglich. Die Erfahrung hat gezeigt, dass oftmals Probleme ohne Optimierung der Prozesse und alleiniges Einführen von Containerisierung verlagert jedoch nicht gelöst werden.​

Der alleinige Einsatz einer Plattform für Containerisierung wie beispielsweise Docker bedarf trotz aller Vorteile die Docker mit sich bringt eine manuelle Pflege der einzelnen Images. Änderungen ohne CI im Code müssen von Hand angepasst und getestet werden. Die Pflege von den bei Docker eingesetzten Images obliegen ebenfalls dem Dev-Team. Ebenfalls späteres Patching muss von Hand ausgeführt werden. Vorteile die bei einer bestehenden CI/CD Basis greifen, knüpfen bei den zuletzt genannten Punkten an. Über CI/CD werden Container nach Änderung des Codes automatisch gebaut und gegen verschiedene Tests gefahren. Durch die Tatsache, dass Applikationen in Containern laufen, können Plattform-Tests ohne großen Aufwand umgesetzt werden. Images, welche zum Bau von Containern verwendet werden, können ebenfalls über die CI/CD Pipeline verändert und somit ohne manuelles Eingreifen bis ins Zielsystem übertragen werden. Das Patching der Laufzeitumgebung auf beispielsweise eine höhere PHP-Version wird somit automatisch übernommen, da durch den automatisierten Bau von Containern der aktualisierten Images immer die neusten Container in Ihrer Umgebung laufen. Wird die Containerisierung über ein Orchestrator, wie beispielsweise Kubernetes (K8) betrieben, sind sogenannte Rolling-Updates möglich. Dies bedeutet für Ihre Produktionsumgebung keine Downtimes mehr, um Ihre verschiedenen Laufzeitumgebungen auszutauschen oder zu aktualisieren. Ebenfalls könnten automatisch mehrere Versionen parallel dem Kunden zur Verfügung gestellt werden. Es Bedarf hier keine Auslieferung mehr von fertigen VMs oder Ähnlichem, sondern lediglich den fertig gebauten Images bzw. Containern.

DevOps & Docker Resümee:

 Zusammengefasst bedeutet dies, dass die Containerisierung Ihrer Anwendung ein Ziel mit hoher Priorität sein sollte, da hierdurch verschiedenste Vorteile entstehen, allerdings die Optimierung Ihrer internen Prozesse Ihr primäres Ziel sein muss. Erst durch die Optimierung dieser, können Sie alle Vorteile einer Containerisierung voll und ganz ausschöpfen. Sind Sie der Meinung, dass Sie internen Prozesse schon optimiert haben, sollten Sie dies an Hand der nachstehenden Fragen kurz überprüfen: Haben Sie einen bestehenden Workflow zur automatisierten Verarbeitung, Testing und Deployment Ihrer Anwendung? Liegt eine bestehende Patching-Strategie vor? Sind alle nötigen infrastrukturellen Gegebenheiten realisiert? Sind Möglichkeiten für Containerisierung in Ihrem Unternehmen und bei Ihren Kunden geschaffen? Wenn Sie all diese Fragen mit einem klaren „Ja" beantworten können, dann kann Ihr nächstes primäres Ziel die Containerisierung zur Optimierung Ihrer DevOps-Prozesse sein.

No Cloud Transformation & Digitalisation without D...
It's time for INTEGRATE 2019 - kommen Sie mit uns ...

HABEN WIR IHR INTERESSE GEWECKT?

Sprechen Sie uns an!

Funkfrequenzen

Tel.: +49 (40) 6963816–0
Tel.: +49 (151) 1176898-0
E-Mail: ahoi@datapassion.de

Heimathafen

DATA Passion GmbH
Am Sandtorkai 37
20457 HAMBURG

Data Passion drives your business smarter