© John-Francis Bourke, 123RF

Devops und Container tauchen oft gemeinsam auf. Hat man das eine, kommt das andere automatisch dazu. Aber ganz so einfach ist es nicht, wie das folgende Plädoyer für Vernunft zeigt.

Docker[1] hat nachhaltigen Einfluss auf die jüngere Informationstechnologie, das steht außer Frage, und es finden sich auch ausreichend viele Erfolgsgeschichten. So entsteht der Eindruck, dass die Einführung und der Betrieb eine einfache Sache sei. Dieser Artikel möchte zeigen, dass dem nicht so ist.

Alter Wein in neuen Schläuchen?

Es gibt mehrere Möglichkeiten, Container zu beschreiben: Für die einen ist es eine neue, zusätzliche Form der Virtualisierung, also eine natürliche Fortsetzung von KVM [2], Xen [3], VMware [4], Hyper-V [5] oder des Zonen-Konzepts in Solaris [6]. Für andere sind Container die Nachfolger der Laufzeitumgebung in Java [7].

Manche sehen in der Technologie ein neues Paketierungsformat für Applikationen. Damit sind Container so etwas wie eine aufgebohrte Version von Deb [8], RPM [9] oder gar Tar-Archiven [10]. Eine andere Sichtweise ordnet die Technologie einfach als eine Reihe von zusätzlichen Prozessen und Konfigurationen ein, die eine geschicktere Ressourcenverwaltung erlauben. Wer erfolgreich virtualisiert hat, kann jedenfalls scheinbar einfach mit Containerisierung weitermachen. Neben Apt [11], Yum/Dnf ([12], [13]) kommen nun eben noch Docker [14] oder RKT [15] dazu.

Tatsächlich funktioniert es aber doch nicht ganz so, und der Teufel steckt nicht nur im Detail. Drei große Themen tauchen immer wieder als Herausforderungen auf: die IT-Sicherheit, der Betrieb und die Menschen dahinter.

Sicherheit

Die Sicherheit in der Containerwelt ist zum gegenwärtigen Zeitpunkt gleich mit einer Reihe von Fragezeichen zu versehen. Typische Fragen des IT-Sicherheitsbeauftragten sind: Wo sind die Containerabbilder gespeichert? Wie sind sie gegen Manipulation geschützt? Wie lassen sich Sicherheitslücken erkennen und wie schließt man sie? Wie sichert man sensitive Daten davor, ausspioniert oder unerwünscht verändert zu werden? Wie steht es um die Mandantenfähigkeit? Welche Vorkehrungen sichern die Laufzeitumgebung ab?

Das Auflisten der Fragen ließe sich nahezu beliebig fortsetzen. Fast immer zeigt die Suche nach den Antworten, dass die Containertechnologie eben doch noch recht frisch ist. Auf manche der Fragen haben junge Projekte eine Antwort, manchmal gibt es Ideen oder Diskussionen – leider fehlt aber auch oft eine befriedigende Lösung.

Angestammte Virtualisierer sind da in einer deutlich besseren Position. Bei ihnen lassen sich viele Prozesse aus der physikalischen Welt übertragen. So kann man bei ihnen die Software scannen, um Sicherheitslöcher zu finden und zu schließen, es gibt ein Patchmanagement und die Laufzeitumgebung lässt sich absichern. Legt man bei der konventionellen Virtualisierung Abbilder ab, dann sind erprobte Konzept für die sichere Datenverwaltung benutzbar.

Dagegen kennen verschiedene Industriestandards wie PCI-DSS (Payment Card Industry – Data Security Standard, [16]), SSA-16 (Standards for Attestation Engagements No. 16, [17]) oder ISO-27001 [18] die Containertechnologie nicht. Es fehlen daher Hinweise und Richtlinien für die Sicherheit von Docker & Co., wie sie in anderen Bereichen der Informationstechnologie üblich sind.

Das fordert sowohl die IT-Verantwortlichen als auch die Auditoren heraus. Das Resultat sind oft Insellösungen für die jeweilige Containerlandschaft. Die Macher sind gezwungen, das Rad neu zu erfinden. Ein gutes Beispiel ist das Aufspüren von Sicherheitslücken in Containerabbildern. Erst seit dem Herbst 2015 gibt es hier entsprechende Projekte (Clair [19], Nautilus [20], Abbildung 1).

Abbildung 1: Projekte wie Clair oder Nautilus schließen großen Lücken in der Containerwelt.

Wer Linux-Container schon vorher sicher betreiben wollte, musste sich selbst etwas ausdenken. Zudem stellt sich die Frage, wie aufwändig und komplex eine Migration von der Heim- auf die Community-Lösung ist.

Ein analoges Beispiel ist das Signieren von Abbildern [21]. In der Docker-Welt gibt es das ebenfalls erst seit 2015 mit Notary [22]. Für manchen Container-Sicherheitsexperten kommt dieses Projekt spät, wenn nicht zu spät. Auf der Rocket-Seite (15, 21) ist man schon etwas länger vorbereitet. Doch ist der verwendete Mechanismus ein anderer als bei Docker und nicht kompatibel. Das erleichtert es nicht, Abbilder zu signieren.

Welches Format setzt sich durch? Wohin soll man migrieren und wann? Hilft die Open Container Initiative [23] oder verlangsamt sie nur? Das Thema Sicherheit im Container-Universum ist nicht zu unterschätzen – insbesondere im produktiven Betrieb (Abbildung 2).

Abbildung 2: Nicht weniger als vier Projekte buhlen um die Vorherrschaft bei der Container-Orchestrierung.

Der Betrieb im Alltag

Der Einsatz der Containertechnologie im harten produktiven Alltag ist insbesondere in traditionellen oder gewachsenen IT-Landschaften nicht unbedingt eine leichte Übung. Da wäre beispielsweise die Frage der Zuständigkeit und Verantwortlichkeit für die verschiedenen Bestandteile. Technisch gesehen liegt die Containertechnik zwischen den unteren Betriebssystem-Ebenen und der Anwendungsschicht. Oft genug fühlen sich die Infrastruktur-Teams oder auch die Systemadministratoren gar nicht oder nur teilweise zuständig.

Insbesondere den Inhalt der jeweils laufenden Instanz oder das zugrunde liegende Abbild schieben sie gerne den Applikationsverwaltern zu. Die sind aber mit Aufgaben wie der Pflege und Wartung Betriebssystem-naher Software oder der harmonischen Integration in tiefer liegende Infrastruktur nicht vertraut.

Der klassische IT-Betrieb sieht oft eine klare Trennung der verschiedenen Schichten beziehungsweise Komponenten vor. Die Containerwelt erlaubt aber keine einfache 1:1-Abbildung dieses Ansatzes. Für den erfolgreichen Einsatz ist daher eine Umstrukturierung der Organisation unausweichlich. Wer aber denkt schon beim Einsatz einer Technologie an den Umbau der Verwaltungsstruktur der Firma? Enthusiasten könnten an dieser Stelle erstmals das Stichwort “Devops” einwerfen.

Neben technischen Funktionen spielen Aspekte wie kommerzieller Support, Integration in die vorhandenen Softwarelandschaft und der Abgleich mit Dienstleistern eine große Rolle. Im Mittelpunkt steht die Frage nach dem richtigen Werkzeug zur Konfigurationsverwaltung. Puppet [24], Ansible [25] und auch Chef [26] sind die üblichen Verdächtigen in diesem Zusammenhang.

Sogar ein Blick auf die Tools aus dem Hause Docker selbst zeigt, dass der Betrieb erst seit Kurzem im Fokus steht. Hilfsmittel wie Trusted Registry (DTR, [27]) oder Universal Control Plane (DUCP, [28]) stehen deshalb erst seit Mitte oder gar Ende letzten Jahres bereit, andere Werkzeuge fehlen nach wie vor.

Menschen im Mittelpunkt

Das Schlüsselwort Devops taucht nun öfter im Zusammenhang mit dem Container-Thema auf, womit auch eine nötige Umstrukturierung bereits angesprochen ist. Die ist aber leichter gesagt als getan. So fangen die meisten IT-Abteilungen nicht auf der grünen Wiese an. Nicht selten haben letztendlich auch die Kunden einen maßgeblichen Einfluss auf den Aufbau und die Funkionsweise der bestehenden Prozesse, Prozeduren und Protokolle. Somit kann der Dienstleister nicht isoliert etwas verändern.

Die Erfahrung zeigt, dass es oft sogar noch schwieriger ist: Man muss die traditionellen Kunden weiterhin auf die gewohnte Art bedienen und gleichzeitig neue Prozesse und Prozeduren für andere Geschäftspartner einführen. Dieses Balancieren bedeutet eine Zerreißprobe für die IT-Abteilung und führt zu Verwirrung unter den Mitarbeitern.

Die gleichzeitige Koexistenz von traditionellen und Devops-Ansätzen innerhalb einer Firma verursacht automatisch Spannungen und Konflikte. Software wie die Containertechnologie ist dann nicht die Lösung. Im Gegenteil: Tatsächlich ist sie oft genug sogar ein Auslöser der Spannungen.

Ein gutes Beispiel ist das Thema Netzwerk. Der traditionelle Ansatz kennt Teams oder ganze Abteilungen für das Verwalten von VLANs und/oder Firewall-regeln. Es gibt Protokolle und Prozeduren, um Änderungen und Erweiterungen zu beantragen. Die Antragsteller sind beispielsweise Systemadministratoren oder Applikationsbetreuer. In der Containerwelt mit Devops sieht das anders aus. Alle Aufgabenbereiche sind einem einzigen Team zugeordnet. Damit fällt automatisch das externe Absegnen einer Firewalländerung durch die Netzwerkgruppe flach. Ein Kompetenzgerangel ist da fast programmiert.

Die traditionelle Trennung zwischen Entwicklung und Betrieb lässt sich nicht über Nacht einfach in den Papierkorb werfen. Der Admin muss Verständnis für die Bedürfnisse der Developer entwickeln und der Entwickler muss lernen, warum IT-Betrieb komplizierter ist, als es auf den ersten Blick aussieht.

An dieser Stelle lässt sich wieder das Beispiel mit der Netzwerkgruppe und dem Devops-Team aufgreifen. Erstere muss lernen einem Betriebsteam der neuen Art und seiner Arbeit zu vertrauen. Das ist keine Einbahnstraße. Auch die Devops-Leute sollten nicht einfach kopfschüttelnd die Kommunikation mit der Netzwerkgruppe abbrechen, wenn sie sich missverstanden fühlen. Wie funktioniert das? Reden und Zuhören helfen.

Das Devops-Team kann von dem Wissen und den (vielleicht jahrzehntelangen) Erfahrungen der Netzwerker lernen – jedenfalls schaden die nicht. Letztere können wiederum von den neuen Ansätze und Methoden profitieren.

Der Schlüssel zu einer Lösung ist gegenseitiger Respekt vor traditionellem wie auch vor brandneuem Wissen und den Leuten dahinter. Es ist nicht immer einfach, hier das Eis zu brechen. Der Autor hat gute Erfahrung mit externer Moderation gemacht. Extern heißt hier, außerhalb des Projekts oder des Fachgebiets – nicht notwendigerweise durch eine andere Firma. Wichtig ist, dass der Moderator von beiden Seiten als Autorität anerkannt wird.

Die praktische Erfahrung hat gezeigt, dass eine Art Pilotprojekt ein guter Indikator dafür ist, ob sich die gesamte Organisation verändern und weiterentwickeln kann. Wichtig ist, dass der Umfang klar beschränkt und deutlich getrennt vom restlichen Alltagsgeschäft ist – man könnte es auch als klassisches Laborexperiment beschreiben. Zusammengefasst: Zuerst kommen die Menschen – der Rest (etwa die Software, die Technologie) findet sich dann schon.

Fazit

Es gibt nicht genug Gründe, Container zu verdammen. Vielmehr geht es um die realistische Einschätzung der Praxistauglichkeit abseits vom Marketinggeklingel. Grundlage dieses Artikels bilden die Erfahrungen des Autors im eigenen Unternehmen und Gespräche, Diskussionen und Interviews im Rahmen der einschlägigen Fachkonferenzen und außerhalb. Es gilt, den blinden Einsatz von Containern zu vermeiden. Technologie ist nur ein Aspekt für den nachhaltigen und erfolgreichen Einsatz von Docker & Co. Prozesse, Prozeduren und nicht zuletzt die Menschen dahinter bestimmen über den Erfolg wesentlich mit.