Microservices

Doch wie sehen Anwendungen in Containern eigentlich aus? Im Zusammenhang mit Containern ist häufig von Micro­services die Rede. Darunter versteht man Dienste, die jeweils eine kleine Aufgabe erfüllen. Die Microservices lassen sich über Schnittstellen so miteinander verbinden, dass sich daraus eine beliebig komplexe Software ergibt. Darüber hinaus sind die einzelnen Funktionsblöcke je nach Nutzung und Auslastung unabhängig voneinander skalierbar. Die beiden Haupteigenschaften von Microservices sind dabei Spezialisierung und Eigenständigkeit. So beschränkt sich jeder Dienst auf die Lösung eines bestimmten Problems – und arbeitet eigenständig: Jeder dieser kleinen Dienste lässt sich bereitstellen, betreiben und skalieren, ohne die Funktionsfähigkeit anderer Services zu beeinträchtigen.

Aus technischer Sicht besteht aber zwischen Micro­services und Containern kein direkter Zusammenhang. So lassen sich auch komplette monolithische Applikationen mittels Container betreiben. Doch gerade in Anbetracht ­einer möglichen Skalierung bzw. einer effizienten Nutzung der IT-Infrastruktur ist das manchmal nicht unbedingt ­sinnvoll.

Ähnlich sieht es Wolfgang Kurz, CEO beim IT-Dienstleister Indevis: «Natürlich kann man auch grössere Blöcke in Container packen. Allerdings verfehlt man dann etwas den ursprünglichen Gedanken, für jeden Task einen Container zu haben, der dann im Idealfall ‹state­less› ist und im Bedarfsfall einfach häufiger gestartet wird.» Wolle man beispielsweise eine grosse SQL-Datenbank in einem Container betreiben, dann stelle sich die Frage, warum sie in

einem Container laufen sollte. «In klassischen Infrastrukturen hat man das Thema des persistenten hochverfüg­baren Storage mit hohem I/O, funktionierendem Cluster und Backup-Konzept seit vielen Jahren im Einsatz.» Wenn man so etwas in einem Container machen wolle, dann sei man schnell im experimentellen Bereich oder müsse sehr viel Know-how selbst aufbauen. Das sei nur für sehr grosse Firmen oder Cloud-Anbieter sinnvoll.

In einigen Fällen kann es dennoch ratsam sein, auch ganze Applikationen in Container zu packen. Laut Fleischer von Consol hat es sich insbesondere während der Entwicklungsphase bewährt, lokale Dienste wie etwa Datenbanken oder Queue-Server in Containern zu starten, «da auf diese Weise sehr einfach identische Umgebungen für alle Kollegen im Entwicklungsteam erstellt werden können».

Trotz aller Vorteile – Unternehmen treibt beim Einsatz von Containern vor allem das Thema Sicherheit um. Laut der eingangs erwähnten Studie gaben 38 Prozent der IT-Verantwortlichen an, dass Sicherheitsbedenken ein Grund dafür sind, keine Container im Unternehmen ein­zusetzen. Und die Bedenken haben auch ihre Berechtigung: Denn der sichere Betrieb von Container-Workloads ist alles andere als ­trivial.

In den Anfangszeiten der Containerisierung liefen diese oft mit Root-Rechten. Dadurch konnte ein Angreifer, der die Sicherheitsmechanismen des Host-Betriebssystems überwand und Zugriff auf die Hardware hatte, gegebenenfalls auch auf die Container zugreifen. Heutzutage liegen laut Kleff von NetApp die Hürden hingegen deutlich höher, da viele Lösungen auf den Root-Zugriff verzichten – «System und Container bleiben getrennt, obwohl diese Trennung nicht so weit wie bei einer Server-Virtualisierung reicht.» Im Allgemeinen gilt gemäss Kleff: «Wo aus Sicherheitsgründen eine dedizierte Hardware-Trennung ein­geführt wurde, wird man diese jetzt nicht durch einen Mischbetrieb mehrerer Container auf einem Host ersetzen.»

Dass die Sicherheit ein grosses Thema ist, das noch längst nicht gelöst ist, betont auch Wolfgang Kurz von Indevis. Ein gängiges Problem sei etwa der Übergriff in Speicherbereiche des Nachbarn. Das gelte auch für Teile des Betriebs­systems. «Durch den Einsatz von Containern wird es also keinesfalls sicherer, zumal viele Technologien zum Schutz von Containern noch in den Kinderschuhen stecken.»

Auch wenn alle etablierten Firmen Angebote zum Schutz von Container-Lösungen im Angebot hätten, so seien das oft aus der Virtual-Machine-Welt übertragene Ansätze, die nur teilweise funktionierten. Daher seine Warnung: «Viele Online-Repositories, von denen viele Anwender ihre Container beziehen, sind veraltet und haben eklatante bekannte Sicherheitslücken. Hier muss man im Grunde täglich die Container neu bauen. Solch eine Build Pipeline hat aber nicht jeder im Einsatz, auch wenn sie notwendig wäre.»