Ara Pulido: Ich denke, diese Frage hat zwei Seiten und es ist die Verbindung beider Aspekte, die Container so erfolgreich macht. Aus der Sicht der Entwickler ermöglichen es Container, eine Software zusammen mit all ihren Abhängigkeiten einfach zu verpacken und sicherzustellen, dass für die Anwendung und ihre Abhängigkeiten derselbe Versionssatz vorliegt, unabhängig von der Umgebung, in der diese Container ausgeführt werden. Aus betrieblicher Sicht sind Container eine vereinfachte Version einer virtuellen Maschine. Alle Container teilen sich den Kernel des Hosts, auf dem sie laufen. Dadurch lassen sie sich viel leichter bedienen als eine VM und eignen sich damit für die Bereitstellung von Microservices. Außerdem können Linux-Container auf verschiedenen Linux-Distributionen oder Clouds ohne Modifikation laufen, was sie ideal für Multicloudumgebungen macht.

Vor einigen Jahren herrschte die allgemeine Überzeugung, dass Container besser für die Ausführung zustandsloser Workloads geeignet sind. Da Container in den meisten Fällen nur eine kurze Zeit "leben", war es sinnvoll, Workloads auszuführen, die bei einem Absturz, einer Skalierung oder einer Umplanung problemlos neu starten können. Aber dank der Weiterentwicklung der verschiedenen Container-Orchestratoren und der von den verschiedenen Clouds bereitgestellten Speicherschnittstellen führen immer mehr Unternehmen auch erfolgreich zustandsabhängige Workloads in Containern aus. Wahrscheinlich sehen wir auch in Zukunft immer mehr unterschiedliche Workloads als Container laufen.

Es gibt in der DevOps-Welt eine berühmte Analogie für Infrastruktur und Workloads als Haustiere oder als Vieh. Als Infrastruktur und Anwendungen noch die Haustiere der Betreiber waren, wurden sie über Jahre hinweg sorgfältig und von Hand gepflegt. Es war schwierig, sie zu ändern, und das wirkte sich auf die Agilität der Entwickler bei der Bereitstellung von Änderungen und neuen Anwendungen aus. Heute wird die Infrastruktur eher als Vieh betrachtet, was bedeutet, dass Betreiber dank Dingen wie Infrastructure-as-Code oder Configuration- as-Code in Sekundenschnelle ein Stück Infrastruktur gegen ein anderes austauschen können. Das hat viele Vorteile: Es gibt Entwicklern mehr Flexibilität, Änderungen vorzunehmen und eine neue, passende Infrastruktur für den Betrieb ihrer Anwendungen zu wählen. Außerdem haben IT-Verantwortliche so die Möglichkeit, ihre Umgebungen in verschiedenen Regionen oder für Notfallwiederherstellungen einfach zu replizieren.

Ich glaube nicht, dass die Container-Sicherheit hinterherhinkt, aber es stimmt, dass sich das Container-Sicherheitsmodell von dem der traditionellen IT unterscheidet. Wie bei allem Neuen besteht auch bei der Containersicherheit eine Lernkurve. Wenn sie richtig konfiguriert sind, können containerisierte Umgebungen sicherer sein als traditionelle Umgebungen. Zudem gibt es immer mehr Sicherheitslösungen, die auf containerisierte Umgebungen und deren Ausführungsumgebungen ausgerichtet sind. Genau wie in klassischen Umgebungen besteht auch beim Einsatz von Containern die Sorge um das Abhängigkeitsproblem: Woher weiß ich, dass die von mir ausgeführten Container keine bekannten Sicherheitslücken haben? Glücklicherweise setzen Unternehmen Tools zum Scannen von Container-Images in ihren Deployment- Pipelines ein, sodass sie sicher sein können, dass ihre verwendeten Container keine hochriskanten Schwachstellen aufweisen.

Einer der Vorteile des Betriebs in der Cloud ist, dass sich zahlreiche der verwalteten Container-Services aus besagten öffentlichen Clouds einsetzen lassen. Für viele Unternehmen ist die Nutzung der Cloud nicht möglich und der lokale Betrieb eines Container-Orchestrators wie Kubernetes wird immer üblicher. Kubernetes vor Ort zu betreiben, bringt jedoch eine höhere betriebliche Komplexität mit sich, denn in den meisten Fällen müssen sich die Betreiber selbst um die verschiedenen Komponenten von Kubernetes wie etcd, den API-Server oder das Netzwerk kümmern. Der Betrieb von selbstverwaltetem Kubernetes ist komplex und ein Team muss gut verstehen, wie Kubernetes und das Ökosystem darum herum funktionieren, bevor es sich auf ein solches Projekt einlässt. Außerdem sollte das Team eine klare und tiefgreifende Beobachtungsstrategie für seine Cluster haben, um jederzeit verstehen zu können, was in jeder Kubernetes-Komponente passiert, und um potenzielle Probleme beheben zu können.

Der größte Unterschied zwischen Containern und VMs bezogen auf das Lifecycle- Management ist, dass Container in der Regel als "ephemer" betrachtet werden. Selbst wenn ein Container über einen längeren Zeitraum läuft, wird davon ausgegangen, dass er jederzeit abstürzen kann, auf einen anderen Knoten umgeplant oder im Rahmen der Skalierung der Anwendung gelöscht werden kann. Das ist auch wichtig für Entwickler, denn sie müssen sicherstellen, dass sich ihre Anwendungslogik auf den im ephemeren Speicher der Container gespeicherten Zustand verlässt.

Container und Kubernetes sind nur zwei Technologien, die Teil eines Paradigmenwechsels im IT-Bereich sind. Selbst ohne diese beiden gibt es eine Menge Best Practices und Prozesse, die ein hohes Maß an Automatisierung und Agilität beim Bereitstellen moderner Anwendungen ermöglichen können: Die Unveränderlichkeit von Anwendungs-Images bedeutet, dass Entwickler ihre Anwendung als Image bereitstellen und dieses anschließend nicht verändern, also zum Beispiel keine Pakete aktualisieren oder neue Pakete in der Produktionsumgebung installieren. Stattdessen erstellen sie ein neues Abbild und tauschen dieses gegen die alte Version. So funktionieren Container, aber dieselbe Vorgehensweise kann auch bei anderen Arten von Infrastrukturen wie VMs zum Einsatz kommen. Die Unveränderlichkeit von Images öffnet die Tür zu kontinuierlicher Bereitstellung, einfachen Rollbacks und vielem mehr. Durch Infrastructure- und Configuration-as- Code lässt sich die Replikation einer Umgebung automatisieren, ohne dass Änderungen verloren gehen. Diese Best Practices besagen, dass jede Infrastrukturoder Anwendungskonfiguration kodifiziert und in einem Versionskontrollsystem wie Git gespeichert wird. Außerdem erfolgen nötige Änderungen zuerst am Code und werden anschließend an Git übergeben, wonach sich diese Änderungen automatisch in der tatsächlichen Umgebung widerspiegeln.

Meine erste Empfehlung wäre es, zu lernen und zu verstehen, was Container aus technischer Sicht sind. Das hilft, das Sicherheitsmodell besser zu begreifen und Risiken im späteren Verlauf der Migration zu reduzieren. "Container Security", ein Buch von Liz Rice, deckt die Grundlagen der Linux-Container-Technologie ab und wie sie mit ihrem Sicherheitsmodell zusammenhängen. Das ist definitiv ein guter Ausgangspunkt. Sobald Container verstanden sind, ist es wichtig, Kubernetes, seine wichtigsten Grundfunktionen und die Komponenten der Steuerungsebene zu lernen. Die Cloud Native Computing Foundation bietet eine Zertifizierung zum "Certified Kubernetes Administrator" an und veröffentlicht regelmäßig einen kompetenzorientierten Lehrplan. Auch wenn es nicht um eine Zertifizierung geht, bietet der Lehrplan einen guten Überblick darüber, welche Konzepte unbedingt gelernt werden müssen.