Docker Einsatz will sorgfältig geprüft sein

Seit seiner Einführung 2013 war Docker der heisse Shice im Infrastruktur Management. Wie bei neuen Technologien üblich, wurde Docker für alles verwendet: Entwicklung, Tests, Betrieb, Systeme. Prinzip: Wenn ich nur einen Hammer besitze, schaut jedes Problem aus wie ein Nagel. Heute sehen wir das deutlich ruhiger. Wann ist der Einsatz geboten?

Docker ist eine Variante von Containern, die ursprünglich auf Linux-Systemen verfügbar waren und technisch auf zwei Kernfunktionen von Linux beruhen: CGroups (Control Groups) und Namespaces. Diese beiden Funktionen zum Kontrollieren und Auditieren von Prozessgruppen waren schon 2008 zum Standard-Kernel hinzugefügt worden. In den folgenden Jahren entwickelten sich eine Reihe von Tools, die darauf aufbauen. Beispielhaft sind das

  • Docker
  • LXC (Linux Container)
  • OpenVZ (Virtuozzo)

Während die beiden letzten ganze Betriebssysteme incl Rootzugriff virtualisieren, kapselt Docker Anwendungen mit all ihren Abhängigkeiten wie Bibliotheken und Daten. Trotzdem werden die Begriffe oft synonym verwendet, und Docker kommt auch dann zum Einsatz, wenn der Anwendungszweck eigentlich ein ganzes Betriebssystem erfordern würde.

Atari 7800 with cartridge and controller
Bessere Analogie: Single-App Cartridge einer Spielekonsole

Um es klar zu sagen: Docker ist eine Paketierung von lauffähigen Anwendungen, nicht von ganzen Betriebssystemen. Das hat eine Reihe von Konsequenzen:

  • Einen Docker Container laufen zu lassen bedeutet, eine Anwendung laufen zu lassen. Mehrere Anwendungen bedeuten mehrere Container, die aufwändig orchestriert werden wollen.
  • Da das starten eines Containers unter Linux weitgehende Rechte erfordert, benötigt jeder Nutzer von Containern diese Rechte. Dies kann ein Sicherheitsrisiko sein.
  • Container laufen kooperativ, das Grundmodell lautet “Vertrauen”.

Als Architekt oder Administrator muss man sich dieser Eigenschaften bewusst sein. Nicht jeder Anwendungsfall eignet sich. Was spricht also für die Verwendung von Docker, was dagegen?

Indizien “pro Docker”

  • Hochstandardisierte Infrastruktur ist vorhanden: Mindestens Dutzende, wenn nicht hunderte identisch aufgebauter Server werden verwendet.
  • Massiv parallele Verwendung gleicher Instanzen: Betrieb von dutzenden Knoten der gleichen Anwendungsversion
  • Hohe Bandbreite zwischen Entwicklung und Betrieb: Lokales Gigabit Backbone oder schneller, keine WAN Strecken im Deployment
  • Verwendung eigener Basis-Images: Inhalt und Aufbau der Images ist unter eigener Kontrolle
  • Eigene Leistungserbringung: Organisation betreibt ihr eigenes Produkt, nicht Inhalte von anderen oder für andere (zB Hosting)

Indizien “contra Docker”

  • Unbekannte Image-Inhalte: Verwendung externer Images ist ein Risiko, da man fremden Code ungeprüft zur Ausführung bringt
  • Trennung in Mandanten kaum möglich: Alle Docker-Prozesse auf einem Host beginnen zunächst mit Root-Rechten, wirksame Trennung in Umgebungen, Mandanten etc ist nicht gewährleistet.
  • Hohe Zahl unterschiedlicher Anwendungen, geringe Wiederverwendung: Images spielen ihren Vorteil erst dann aus, wenn sie zahlreich wieder verwendet werden. “1 neues Image pro Deployment” verlangsamt den Prozess erheblich.
  • Geringe Bandbreite im WAN: Hohes Transfervolumen aufgrund Gigabyte großer Images reduziert die Deployment-Geschwindigkeit
  • Supplier-Betriebsmodell: Verantwortungsübergang bei Verwendung fremder Binaries faktisch nicht möglich

Gerade in Situationen, in denen die IT wie bei einem Shared-Datacenter oder Webhoster Inhalte verschiedener Mandanten gegeneinander absichern muss, muss Docker stets in Verbindung mit Virtualisierung von Betriebssystemen eingesetzt werden. Der Grad der Wiederverwendung entscheidet dann darüber, ob der zusätzliche Aufwand die Mühe wert ist: Die virtuellen Maschinen müssen in jedem Fall provisioniert werden, das kann mit Tools wie Ansible, Chef oder Puppet leicht auch benötigte Dienste wie Datenbanken mit einschließen. Lohnt das Verpacken zB einer Java-Anwendung in ein Docker Image dann noch? Das resultierende Image ist leicht mehrere Gigabyte gross, auch wenn das darin eingepackte WAR-File der Anwendung um Größenordnungen kleiner ist.

Docker in der Cloud

Wird die Leistungserbringung der IT konsequent in die Cloud ausgelagert, ist mit Anbietern wie Microsoft Azure oder Amazon AWS auch ein Betrieb von Anwendungen als Docker-Image möglich. Die Anbieter kümmern sich dann um die bereits erwähnten Probleme, garantieren die Trennung von Mandanten und Umgebungen. Dafür haben die Anbieter massiv in Technik und Prozesse investiert.

Ob die Entscheidung “pro Cloud” jedoch für eine Organisation richtig ist, steht auf einem anderen Blatt. Wer zB eigene Kundendaten schützen muss, kann diese nicht ohne weiteres in internationalen Datacentern speichern. Ich habe auch volles Verständnis dafür, gewisse höchst private Daten (Quelltexte, Produktinformationen, interne Kommunikation…) prinzipiell nicht “außer Haus” geben zu wollen.

Entscheidet man sich dafür, eine geteilte IT “intern vs extern” zu betreiben, bedingt der externe Einsatz von Docker in der Cloud zumeist mehr Mühe, als das Ergebnis am Ende rechtfertigt. Hier sollten alternative Verfahren wie die Provisionierung von VMs geprüft werden.