Technische und organisatorische Stolpersteine 5 häufige Fehler bei Container-Deployments

Anbieter zum Thema

DAXTEN GmbH

EPS Rechenzentrum Infrastruktur GmbH

STACKIT GmbH & Co. KG

Je mehr Container in der Softwareentwicklung und -bereitstellung Verwendung finden, desto häufiger macht die Technik dahinter zwangsläufig Probleme. Hier sind die häufigsten fünf Fehler, die es zu vermeiden gilt.

Container sind bei Unternehmen angesagt, die im Zuge der digitalen Transformation die Softwareentwicklung beschleunigen und das Infrastrukturmanagement effizienter gestalten wollen. Laut einer Studie von 451 Research verwendet etwa die Hälfte der Unternehmen entweder schon jetzt Container oder plant dies in den kommenden zwei Jahren. Diese Zahl wird wahrscheinlich weiter anwachsen.

Warum auch nicht? Container paketieren und isolieren Einzelteile, die für die Ausführung einer Anwendung nötig sind und unabhängig von der Laufzeitumgebung einheitlich funktionieren. Dies erhöht die Portabilität zwischen Public Clouds, Hybrid Clouds und On-Premises-Infrastrukturen, reduziert die Kosten und fördert eine agile DevOps-Kultur.

Kubernetes, eine Open-Source-Software, die die Bereitstellung, Orchestrierung und Verwaltung von containerisierten Anwendungen automatisiert und bei weitem das beliebteste Tool seiner Art ist, unterstützt die Einführung von Containern in großem Maßstab.

Dabei kann eine Menge schief gehen, wenn man nicht vorsichtig ist. Doch was sind die häufigsten Container-Fehler – und wie lassen sie sich vermeiden?

1. Fehlkonfigurierte Container oder containerisierte Anwendungen

Beim Wechsel von der traditionellen Bewältigung der Arbeitslast (Workload) hin zur Ausführung auf Containern ändern sich mehrere Faktoren: die IP-Adressen, die Berechtigungsstufe und eine Reihe anderer Dinge. Der Anwendungsbetreuer muss sich über all diese Änderungen im Klaren sein.

Andernfalls kann es zu Fehlkonfigurationen kommen, die zu unerwarteten Ergebnissen wie Anwendungsfehlern, Leistungseinbußen, Sicherheitslücken usw. führen können. Um eine Fehlkonfiguration zu vermeiden, sollten sich die Anwendungsbetreuer eingehend mit Container-Orchestrierungsplattform vertraut machen und alle notwendigen Maßnahmen ergreifen, um die Anwendungen für die Migration vorzubereiten.

2. Übermäßige Bindung und mangelnde Überwachung von Ressourcen

Obwohl Container in der Regel weniger Ressourcen verbrauchen als herkömmliche virtuelle Maschinen, bedeutet dies nicht, dass Nutzer Tausende von Containern auf einem einzigen physischen Server erstellen können. Planung ist auch hier das halbe Leben.

Ressourcenmanagement und Kapazitätsüberwachung sollten bei der Umsetzung der Containerstrategie dementsprechend immer berücksichtigt werden. Andernfalls können die verfügbaren physischen Ressourcen relativ leicht überbeansprucht werden.

Glücklicherweise bieten führende Container-Orchestrierungsplattformen wie Kubernetes Ressourcenmanagement-Funktionen. Damit lassen sich beispielsweise jedem Container spezifische Werte für CPU und RAM zuweisen. Im Gegenzug können verschiedene Open-Source-Tools zur Kapazitätsüberwachung eingesetzt werden.

3. Mangelnde Berücksichtigung von betrieblichen Abläufen

Einige Anwender denken nicht über den Tag 1 hinaus und bereiten sich nicht richtig auf den Container-Betrieb nach der Inbetriebnahme vor. Sie stolpern über Aufgaben wie Patching, Upgrades, Skalierung und die Integration von IaaS, sprich Infrastructure-as-a-Service.

Über diese Aspekte nachzudenken, noch bevor man Container verwendet, ist unerlässlich. Jede Maschine ist im Grunde genommen ein Betriebssystem mit eigenen Bibliotheken und Binärdateien. Mit der Zeit können sie anfällig für Sicherheitslücken und andere Bugs werden, die mit den spezifischen Softwareteilen, die in jedem Container laufen, zusammenhängen.

Die meisten Container-Runtimes teilen sich nur den Kernel zwischen den einzelnen Containern, was nur eine begrenzte Isolierung ermöglicht. Anders gesagt: Wenn ein Container kompromittiert wird, zieht das mit hoher Wahrscheinlichkeit andere Container und den zugrunde liegenden Host in Mitleidenschaft. Darum ist es so wichtig, dass auch Container regelmäßig Updates und Patches erhalten.

Welche Möglichkeiten gibt es, diese Herausforderung zu bewältigen? Da sind zunächst einmal CI/CD-Pipelines, mit denen die Anwendungen mit den neuesten Patches automatisiert erstellt, getestet und bereitgestellt werden können. Darüber hinaus ermöglichen Container-Laufzeiten wie die Open-Source-Lösung Kata eine bessere Isolierung von Containern, indem sie die Funktionalität der zugrunde liegenden Hardware, z.B. die Anweisungen zur CPU-Virtualisierung nutzen. Drittanbieter-Lösungen können die Sicherheit nicht nur während der Bereitstellung, sondern auch in der Entwicklungsphase überprüfen.

4. Der Versuch, ungeeignete Workloads auf Container zu portieren

Sehr häufig treffen Organisationen Entscheidungen zur Container-Migration und ignorieren dabei völlig, dass ihre bestehenden Workloads nicht für die Migration bereit sind. Versuche, monolithische Legacy-Anwendungen in Container zu packen, enden in der Regel nicht sehr gut.

Die Migration zu Containern sollte eine strategische Unternehmensentscheidung sein und sowohl die Infrastruktur als auch die Anwendungen umfassen. Vor der Migration zu Containern sollten die bestehenden Workloads auf Grundlage der Micro Services-Architektur neugestaltet werden.

Darüber hinaus sind einige Anwendungen einfach weder für Container noch für die Microservices-Architektur geeignet. Beispiele für solche Anwendungen beinhalten Dienste, die bestimmte Hardware-Erweiterungen (z.B. Virtualisierung) erfordern, oder zustandsabhängige Dienste, die Daten lokal speichern.

5. Potenzielle Container-Inkompatibilitäten werden unterschätzt

Trotz der Portabilität von Containern kann es unter Umständen Inkompatibilitäten zwischen einem Container und dem zugrunde liegenden Betriebssystem oder der Plattform as a Service (PaaS) geben, die ein Unternehmen verwendet. So kommt es vor, dass eine Anwendung zum Beispiel innerhalb des Containers eine Kernel-Funktionalität aufruft oder sich auf diese verlässt, diese im Kernel des zugrunde liegenden Host-Betriebssystem oder PaaS aber noch nicht verfügbar ist.

Außerdem stellen manche Anbieter proprietäre CLI-Tools und Erweiterungen für offene APIs, wie z.B. die von Kubernetes bereit. Das macht das Verschieben von Workloads von einer PaaS zu einer anderen schwierig. Es erschwert auch das Einrichten von Multi-Cloud-Umgebungen, wenn eine PaaS-Lösung nur in einer einzigen Cloud verwendet werden kann.

Hier empfiehlt es sich, die Prinzipien der Twelve Factor App zu befolgen, einer Methodik zum Erstellen moderner Software-as-a-Service-Anwendungen. Plattformen wie Kubernetes sind um diese Architekturen herum konzipiert, daher sollte man sich mit diesen Architekturen gut vertraut machen.

Container sind die Zukunft und zunehmend schon auch die Gegenwart der Anwendungsentwicklung. Es ist wichtig, eine Reihe von Best Practices zu entwickeln und Container-Fehler zu vermeiden, damit jedes Unternehmen von den besonderen Vorteilen der Technologie profitieren kann.

* Stephan Fabel ist Director of Product bei Canonical. Als Autor bereichert er regelmäßig unser Ubuntu- und Open-Source-Special von Canonical mit neuen Beiträgen.

(ID:46462275)