Docker – integraler Bestandteil unseres DevOps-Workflows

17 Jul 2015
by Tristan Rippel
Comments are closed
docker whale moby logo

Docker – integraler Bestandteil unseres DevOps-Workflows

Ein elementarer Bestandteil unseres DevOps-Workflows ist Docker. Dies ist eine Open Source Plattform zum Containerisieren von Anwendungen. Dabei handelt es sich um eine Virtualisierung auf Betriebssystem-Ebene, bei der einem oder mehreren Programmen eine komplette Laufzeitumgebung virtuell innerhalb eines geschlossenen „Containers“ zur Verfügung gestellt wird.
Beim Containern wird aber kein weiteres Betriebssystem gestartet; die OS-Container stellen nur eine Teilmenge des Host-OS dar. Es wird also im Gegensatz zur Hardwarevirtualisierung wie beispielsweise bei KVM (Kernel-based Virtual Machine) nicht ein komplettes Gastsystem emuliert, sondern es werden lediglich Komponenten des Betriebssystems virtualisiert.

An dieser Stelle soll eine Serie von Blogbeiträgen entstehen, in welchen wir unseren Entwicklungsprozess, unsere Verfahren beim Deployment, und welche Rolle Docker hierbei spielt, erklären werden. Den Beitrag werden wir um entsprechende Verlinkungen ergänzen.

Warum überhaupt Virtualisieren?

Der Einsatz von Virtualisierungstechniken ermöglicht uns eine effektivere Auslastung der verfügbaren Hardware. Während Anwendungsserver im Bare Metal Betrieb nur selten Volllast erreichen, können wir durch virtuelle Maschinen eine höhere Anwendungsdichte gewährleisten. Durch das Anlegen von Vorlagen für ganze Umgebungen – wie zum Beispiel mit Hilfe von Vagrant – und den Einsatz von Tools zur Orchestration wie zum Beispiel Ansible, ist es uns möglich, unsere verfügbaren Ressourcen flexibel zu verteilen und ganze Umgebungen innerhalb kurzer Zeitspannen zu migrieren.
Überdies wird die Arbeit unserer Entwickler und unser Deployment-Prozess erheblich vereinfacht. Durch die lokale Nachbildung komplexer Umgebungen sowohl beim Entwickler als auch innerhalb unserer Stagingsysteme, die sich von den späteren Produktivsystem jeweils nur unwesentlich unterscheiden, kommt es zu weniger Problemen im Rahmen der Auslieferung.

Warum Container?

Der Einsatz von Containern verringert den für die Virtualisierung notwendigen Overhead abermals, so dass wir die Anwendungsdichte weiter erhöhen können, was zu einer gesteigerten Auslastung unserer Systeme und einer damit verbundenen erhöhten Kosteneffizienz führt. Des Weiteren sinken die Anforderungen an die Systeme unserer Entwickler und unsere Testumgebung.
Durch den Einsatz einer privaten Docker Registry, Compose, Swarm und Docker Machine können selbst hochkomplexe Umgebungen beliebig repliziert werden. Darüber hinaus können wir gewährleisten, dass sich die lokale von der Production-Umgebung faktisch nicht unterscheidet, was eine weitere Vereinfachung unseres Deployment-Prozesses bedeutet.
Außerdem wird es bequem möglich Single-Threaded-Applikationen, wie es beispielsweise bei Node.js der Fall ist, durch den Einsatz mehrerer identischer Applikationscontainer und eines Load-Balancing-Containers auf mehrere Kerne des Hostsystems zu verteilen.

Was spricht gegen Container?

Wenn es wichtig ist die betriebenen Applikationen aus Erwägungen der Sicherheit bestmöglich voneinander abzugrenzen, ist der Einsatz von Docker nicht unbedingt angezeigt. Obwohl Red Hat durch die Unterstützung von SELinux viel für die Sicherheit tut, ist die logische Trennung in Form von Hardwarevirtualisierern bei sicherheitskritischeren Anwendungen auch weiterhin erste Wahl.

EWU Software GmbH © 2018