kalafoto - Fotolia

Die größten Probleme bei der App-Portabilität in Container-Umgebungen

Container gelten als bestes Mittel zur Erreichung einer hohen App-Portabilität. Gerade in Cloud-Umgebungen gibt es aber noch viele Hindernisse.

Container werden als bessere Alternative zu virtuellen Maschinen betrachtet, wenn es um das Verwalten und Abschotten von Anwendungen auf geteilter Infrastruktur geht. Container helfen dabei, bei kleinerem Ressourcenverbrauch mehr Leistung aus Applikationen herauszuholen und können zudem die App-Portabilität erleichtern. Die Daten und Services rund um die eigentlichen Container, die verschiedenen Abhängigkeiten einer Anwendung also, sind dabei aber meist weit weniger portabel als der Container selbst.

Container kommen anfangs meist in lokalen IT-Umgebungen zum Einsatz, wo die App-Portabilität durch einen homogenen Container-Stack weitgehend sichergestellt ist. Produktive Container-Umgebungen befinden sich aufgrund der besseren Skalierbarkeit aber oft in der Public Cloud, wo Cloud-Services wie AWS Elastic Container Service (ECS), Microsoft Azure Container Service oder Google Container Engine (GKE) zur Verfügung stehen.

Nun nutzen zwar alle der hier genannten Container-as-a-Service-Anbieter (CaaS) als Container-Image das Docker-Format, die anderen Services innerhalb eines Container-Ökosystems sind aber meist nicht miteinander kompatibel, also beispielsweise Image-Registry, Cluster-Manager, Discovery-Service oder persistenter Storage.

Die folgenden Hürden gilt es daher, auf dem Weg zur tatsächlichen App-Portabilität in Container-Umgebungen zu überwinden.

Container und die Notwendigkeit für persistenten Storage

Anwendungs-Container sind per Design zustandslose Module, die schnell und immer wieder bereitgestellt werden können. Die meisten Applikationen sind aber eben nicht zustandslos wie Cloud-Apps, sondern benötigen vielmehr Zugang zu persistentem Storage abseits des Containers. Dabei gibt es unterschiedliche Wege, wie Storage in Container-Umgebungen bereitgestellt werden kann, am häufigsten wird lokaler Storage auf einem Container-Cluster bereitgestellt, indem ein Storage-Plug-in im Container-Image platziert wird. Als Plug-ins kommen dabei EMC libStorage oder Flocker von ClusterHQ infrage, wobei ClusterHQ seit Ende 2016 seinen Geschäftsbetrieb eingestellt hat.

Die Nutzung einer Public Cloud macht es dabei paradoxerweise sogar schwerer, auf persistente Daten zuzugreifen, weil jede Container-Plattform unterschiedliche Storage-Services unterstützt. Microsoft Azure beispielsweise unterstützt das Docker Volume Plug-in zur Anbindung an den Azure File Storage Service. In ähnlicher Weise bietet AWS ECS Support für die Speicherung von Container-Konfigurationsdaten in Amazon S3 (Simple Storage Service). Bei der Container-Ausführung können diese Daten allerdings zwar gelesen werden, aber nicht geändert. AWS ECS ermöglicht aber auch die Nutzung von persistenten Datenlaufwerken, wenn ECS Task Definitions erstellt werden.

Googles Container-Service bietet demgegenüber einen wesentlich flexibleren Weg, um mit persistentem Storage zu interagieren. Hierfür nutzt Google den eigenen Cluster-Manager Kubernetes, um Laufwerks-Abstraktionen zu erstellen, die über mehrere Container in einem Kubernetes-Pod geteilt werden können und auch Container-Neustarts überleben. Als Pod werden dabei anwendungsspezifische Hosts für einen oder mehrere Container bezeichnet. Das Problem mit diesen drei Vorgehensweisen liegt nicht nur in ihrer Inkompatibilität, sondern vor allem in der Festlegung auf einen spezifischen Cloud-Service. Wenn eine Container-Anwendung migriert werden soll, führt dies zwangsläufig zu größeren Problemen.

Auch die Unterstützung für Windows-Container hat das Potenzial, zur App-Portabilität in Cloud-Umgebungen zu führen. Auch wenn Docker ursprünglich auf und für Linux entwickelt wurde, steht die Engine inzwischen auch für Windows zur Verfügung und kann dort auch Windows-Container ausführen. Da erscheint es nur logisch, dass die Unterstützung für Windows-Container für Microsoft Azure angekündigt wurde, derzeit aber lediglich als Preview verfügbar ist.

Genauso unterstützt auch AWS Windows-Container derzeit nur als Beta. In der Google Cloud können IT-Abteilungen Instanzen der Google Compute Engine selbst für die Unterstützung von Windows-Containern konfigurieren, der von Google verwaltete GKE-Service unterstützt diese aber nicht. Auch hier machen es aber Unterschiede bei Funktionsumfang und Implementierungsstatus schwierig, Windows-Container von einer Plattform auf die andere zu migrieren.

Probleme beim Container-Management

Eine weitere Komponente, die die App-Portabilität in Container-Umgebungen behindert, ist das Software-Ökosystem zum Container-Management. Also beispielsweise was Orchestrierung und Cluster-Management oder Container-Registries betrifft. Derzeit gibt es unterschiedliche konkurrierende Tools zum Cluster-Management, die die Container-Platzierung, das Skalieren der Instanzen und auch Software-Updates automatisieren. Allerdings verwenden die meisten von ihnen unterschiedliche Semantiken.

Sowohl Docker Compose/Swarm als auch Kubernetes nutzen YAML-Dateien für Deployment-Beschreibungen. Aber selbst hierbei unterscheiden sich Syntax und Funktionsumfang. Mesos Marathon wiederum nutzt JSON-Dateien, um containerisierte Anwendungen zu beschreiben.

Eine Container-Registry besteht typischerweise aus einem Image-Repository und einer Möglichkeit zum Suchen von Images oder ganzen Microservices. Das Bereitstellen von Prozessen und Automatisierungs-Skripten rund um Container-Management-Tools macht den Container-Einsatz effizienter, sorgt gleichzeitig aber auch für Probleme bei der Migration auf eine andere Container-Plattform. Es ist vergleichsweise einfach, Workloads und Images zu migrieren. Bei den dazugehörigen Prozessen und Abhängigkeiten wird die Migration schon wesentlich schwieriger.

Bei der Container-Bereitstellung in Cloud-Umgebungen geht die Tendenz inzwischen klar in Richtung Cloud-agnostischer Container-Images mit Cloud-spezifischen Services. Wenn Unternehmen beispielsweise AWS ECS zur Bereitstellung einer Instanz nutzt, müssen hierfür AWS-spezifische ECS-Hooks verwendet werden. Das treibt IT-Abteilungen immer weiter in spezifische AWS-Services, die meist nicht außerhalb der jeweiligen Plattform unterstützt werden.

Unzureichende Container-Sicherheit

Vor allem in hybriden Cloud-Umgebungen ist es schwierig, konsistente Security-Policies aufrechtzuerhalten. Auch Container-Umgebungen machen hierbei keinen Unterschied.

Wie jede virtuelle Umgebung sind auch Container-Infrastrukturen an darunterliegende Anwender- oder Gruppenverzeichnisse sowie an Identity-Management-Systeme gebunden, die Zugriffskontrolle und Nutzungsrichtlinien ermöglichen. Wenn es sich dabei um lokale Verzeichnisdienste wie Active Directory oder LDAP (Lightweight Directory Access Protocol) zusammen mit Cloud-Verzeichnissen wie Google Cloud Identity and Access Management handelt, wird die Integration unterschiedlicher Identitäts- und Sicherheitsregeln über Plattformen hinweg meist schwierig.

Best Practices für eine bessere App-Portabilität

Probleme mit App-Images verhindern nur selten die App-Portabilität über Container-Umgebungen hinweg, vor allem weil alle großen Software- und Cloud-Anbieter die Spezifikation der Open Container Initiative (OCI) unterstützen. Allerdings betont die OCI, dass die Spezifikation nicht an ein höher liegendes Konstrukt gebunden ist, etwa an einen Client oder Software-Stack. Die OCI-Spezifikation liegt auch noch nicht final vor, somit fehlen derzeit auch Funktionen wie eine konsistente Namenskonvention.

Um die Container-Portabilität zu erhöhen empfiehlt sich ein Cloud-agnostisches, hybrides Design, bei dem das Management- und Orchestrierungssystem lokal bereitgestellt wird, während Container-Images, Registry und Automatisierung zentralisiert in der Cloud ablaufen. Diese Systeme lassen sich dann auf unterschiedlichsten Cloud- oder On-Premises-Infrastrukturen ausführen, etwa auf lokalen Docker-Installationen oder auf ECS und GKE. Kurz gesagt sollten IT-Abteilungen die Cloud für die Container-Runtime, aber nicht für Entwicklungs- und Management-Systeme nutzen.

Auch wenn es um die benötigten Daten geht empfiehlt sich ein hybrider Ansatz, bei dem persistente Daten zentral gespeichert und von verschiedenen Runtime-Services synchronisiert werden können. Komplexe hybride IT-Umgebungen erfordern das Aufteilen von Anwendungsfunktionen auf verschiedene Clouds. Manche Komponenten, etwa Web-Front-end, Middleware oder Big-Data-Engine, werden so beispielsweise in der Public Cloud ausgeführt, während andere auf eigener Infrastruktur ablaufen.

Container sollten in der Cloud genau dafür eingesetzt werden, wofür sie sich am besten eignen – für das enge Verknüpfen von Anwendungen oder Microservices, ohne hierfür Daten oder Security-Policies einbinden zu müssen. Dafür gilt es, die Anwendungslogik strikt von Management und Automatisierung der Infrastruktur zu trennen und sicherzustellen, dass das Container-Management so unabhängig wie möglich von unterschiedlichen Clouds und Plattformen ist.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!

Artikel wurde zuletzt im Mai 2017 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Cloud-Anwendungen

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

Close