Definition

Containerisierung (Software)

Was ist Containerisierung?

Containerisierung ist eine Virtualisierungstechnologie, die auf der Ebene des Betriebssystems (OS) arbeitet. Sie dient dazu, verteilte Anwendungen in ihren eigenen isolierten Umgebungen bereitzustellen und auszuführen, ohne dass virtuelle Maschinen (VMs) verwendet werden müssen. IT-Teams können mehrere Container auf demselben Server hosten, in denen jeweils eine Anwendung oder ein Dienst ausgeführt wird. Die Container greifen auf denselben Betriebssystem-Kernel zu und nutzen dieselben physischen Ressourcen. Container können auf Bare-Metal-Servern, virtuellen Maschinen oder Cloud-Plattformen ausgeführt werden. Die meisten Container laufen auf Linux-Servern, sie können aber auch auf ausgewählten Windows- und macOS-Computern ausgeführt werden.

Vor- und Nachteile der Containerisierung

Unternehmen aller Größenordnungen haben sich der Containerisierung zugewandt, da sie viele Vorteile gegenüber herkömmlichen Anwendungsimplementierungen auf Bare Metal oder innerhalb von VMs bietet. Im Folgenden werden einige der oft genannten Vorteile aufgelistet:

  • Effizienz: Container teilen sich den Kernel und die Ressourcen des Hosts, was zu sehr schlanken Containerinstanzen führt. Infolgedessen benötigen Container weniger CPU-, Memory- und Storage-Ressourcen als herkömmliche Anwendungsimplementierungen. Dank des geringeren Overheads kann dieselbe zugrunde liegende Infrastruktur viel mehr Container unterstützen.
  • Portabilität: Wenn das Betriebssystem in allen Umgebungen dasselbe ist, kann ein Anwendungscontainer auf jedem System oder jeder Cloud-Computing-Plattform ausgeführt werden, ohne dass Codeänderungen erforderlich sind. Es sind keine Umgebungsvariablen des Gastbetriebssystems oder Bibliotheksabhängigkeiten zu verwalten.
  • Agilität: Container sind leichtgewichtig, portabel und einfach zu replizieren, wodurch sie sich gut für Automatisierung und DevOps-Methoden eignen. Während des gesamten Lebenszyklus der Anwendung – von der Codeerstellung über den Test bis zur Produktion – bleiben die Dateisysteme, Binärdateien und andere Informationen gleich. Alle Entwicklungsartefakte werden in einem einzigen Container-Image konsolidiert. Die Versionskontrolle auf Image-Ebene ersetzt das Konfigurationsmanagement auf Systemebene.
  • Skalierbarkeit: Nachdem ein Entwicklungsteam seine Container-Images erstellt hat, kann es mit Hilfe von Automatisierungs- und Orchestrierungswerkzeugen Containerinstanzen erzeugen. Auf diese Weise können sie Anwendungen auf der Grundlage der aktuellen Arbeitslastanforderungen bereitstellen und gleichzeitig künftige Schwankungen in der Anwendungslast ausgleichen.
  • Isolierung: Container laufen isoliert voneinander. Wenn in einem Container ein Problem auftritt, hat das keine Auswirkungen auf einen anderen Container oder das Host-System selbst. In manchen Fällen erstreckt sich eine Anwendung über mehrere Container, wie bei Microservices. Wenn in einem dieser Container ein Problem auftritt, können sich die Entwickler auf die Behebung des Problems konzentrieren, ohne dass der Rest der Anwendung beeinträchtigt wird.
  • Schnelligkeit: Da Container so leichtgewichtig sind, können sie in kürzester Zeit erstellt und gestartet werden, viel schneller als virtuelle Maschinen. Sie stützen sich auf den Kernel des Hosts, so dass kein Betriebssystem hochgefahren werden muss, und sie enthalten alle Abhängigkeiten, die für die Ausführung der Anwendung erforderlich sind. Auf diese Weise können sie bei Bedarf sofort und überall bereitgestellt werden, wobei ein Großteil des Prozesses automatisiert ist.

Bis zu einem gewissen Grad kann Containerisierung die Sicherheit verbessern, da die Anwendungen besser isoliert sind, als wenn sie auf einem Bare-Metal-Server laufen. Container sind außerdem durch Richtlinien geschützt, die ihre Berechtigungsstufen vorgeben. Dennoch bleibt die Sicherheit eines der Hauptprobleme der Containerisierung.

Container sind nicht vom Kernbetriebssystem isoliert, so dass sie anfällig für Bedrohungen des zugrunde liegenden Systems sein können. Wird ein Container angegriffen, kann der Angreifer auch in das Host-System eindringen. Im Allgemeinen sind Sicherheitsscanner und Überwachungs-Tools besser in der Lage, einen Hypervisor oder ein Betriebssystem zu schützen, als das bei Containern der Fall ist.

Eine weitere Herausforderung besteht darin, dass es sich bei Containerisierung um eine neue Technologie handelt, die sich noch schnell weiterentwickelt. Obwohl die Technologie in den letzten Jahren gereift ist, ist sie für einige IT- und Entwicklungsteams immer noch ein relativ neues Konzept. Ihnen fehlen möglicherweise die Kenntnisse und Fähigkeiten, die eine effiziente und sichere Implementierung von Containern erforderlich sind.

Dieses Problem kann sich noch verschärfen, wenn versucht wird, Container in mehreren Umgebungen oder sogar auf mehreren Host-Betriebssystemen zu implementieren. Die IT-Abteilung muss sich nicht nur mit der komplexen Orchestrierung von Containern in verschiedenen Umgebungen auseinandersetzen, sondern möglicherweise auch zusätzliche Abstraktionsebenen einrichten.

Wenn sie beispielsweise ihre Linux-Container auf Windows-Maschinen ausführen möchten, müssen sie möglicherweise eine oder mehrere virtuelle Maschinen einrichten, auf denen Linux läuft. Diese zusätzlichen Ebenen machen die Implementierung komplexer und erschweren die Bereitstellung, Sicherung und Überwachung der Container, wodurch einige der Vorteile von Containern untergraben werden.

Wie funktioniert Containerisierung?

Die Architektur einer containerisierten Umgebung basiert auf mehreren Komponenten, die zusammenarbeiten, um Container zu erstellen, zu starten, zu stoppen und zu entfernen. Abbildung 1 zeigt einen Überblick über die Kernarchitektur, wobei die Container an der Spitze des Stacks stehen und die Infrastruktur am unteren Ende, die als Grundlage für das gesamte System dient.

Abbildung 1: Container kapseln den Anwendungscode, haben aber einen gemeinsamen Betriebssystemkern.
Abbildung 1: Container kapseln den Anwendungscode, haben aber einen gemeinsamen Betriebssystemkern.

Die folgenden Komponenten bilden den Kern der Architektur einer containerisierten Umgebung:

  • Infrastruktur: Wie in den meisten Computerumgebungen ist eine Hardwareschicht für die Ausführung des Host-Betriebssystems erforderlich, das die übrigen Komponenten unterstützt. Die Infrastruktur besteht häufig aus handelsüblicher Hardware.
  • Host-Betriebssystem: Das Betriebssystem läuft auf der Hardwareinfrastruktur und bietet eine Betriebsumgebung für die anderen Komponenten. Die Container sind für die Ausführung ihrer Anwendungen auf den Betriebssystemkern angewiesen. Die meisten containerisierten Umgebungen verwenden Linux als Betriebssystem.
  • Container-Engine: Die Container-Engine ist ein Softwareprogramm, das auf dem Host-Betriebssystem läuft und dessen Kernel für die Containerinstanzen nutzt. Die Container-Engine bietet eine Laufzeitumgebung für die Container. Außerdem verwaltet sie die Container und stellt die Ressourcen bereit, die sie zur Ausführung ihrer Anwendungen benötigen. Docker ist die beliebteste Container-Engine, die heute verwendet wird.
  • Container: Ein Container ist eine Instanz eines Container-Images. Er enthält die Komponenten, die für die Ausführung der Anwendung oder des Dienstes des Containers erforderlich sind. Zu den Komponenten können Binärdateien und Bibliotheken (bins/libs) sowie Umgebungsvariablen und andere Dateien gehören.

Ein Container ist eine Instanz eines Container-Images, das zur Laufzeit erstellt wird. Ein Container-Image dient als Vorlage für die Erstellung einer oder mehrerer Containerinstanzen, wenn diese benötigt werden. Das Image ist ein in sich geschlossenes Paket, das den gesamten Code, alle Dateien und Abhängigkeiten enthält, die für die Ausführung der containerisierten Anwendung erforderlich sind. Die Images werden häufig in einem Repository verwaltet, auf das die Container-Engine während der Laufzeit zugreifen kann.

Heutzutage basieren die meisten Container-Images auf der Open Container Initiative, die eine Reihe von Standards für Containerformate und -laufzeiten definiert. Bei der Vorbereitung der Ausführung einer Anwendung ruft die Container-Engine eine Kopie des Container-Images ab und verwendet sie zur Instanziierung eines oder mehrerer Container. Um eine Anwendung zu aktualisieren, ändert ein Entwickler das Container-Image der Anwendung und stellt es dann neu bereit, damit es für die Instanziierung neuer Container verwendet werden kann.

Die meisten containerisierten Umgebungen stützen sich auf eine Orchestrierungsplattform wie Kubernetes, um Containerbereitstellungen zu verwalten. Orchestrierungsplattformen machen es einfacher und effizienter, containerisierter Umgebungen bereitzustellen, zu verwalten und zu skalieren. Sie sind besonders wichtig für groß angelegte Bereitstellungen, die Tausende von Containern umfassen können. Orchestrierungsplattformen ermöglichen es, viele der Vorgänge zu automatisieren, die für die Implementierung und Wartung von containerisierten Anwendungen erforderlich sind.

Containerisierung wird häufig für Microservices und verteilte Anwendungen eingesetzt. Das ist möglich, weil jeder Container unabhängig von den anderen arbeitet und nur minimale Ressourcen des Hosts beansprucht. Die Microservices kommunizieren über Programmierschnittstellen (APIs) miteinander. Ein Orchestrierungswerkzeug kann die Container automatisch skalieren, um die steigende Nachfrage nach Anwendungskomponenten zu befriedigen und gleichzeitig die Arbeitslast zu verteilen, um den Anwendungsverkehr auszugleichen.

Anwendungscontainer und virtuelle Maschinen im Vergleich

Anwendungscontainer werden oft mit VMs verglichen. Beide sind eine Form der Virtualisierung, die isolierte Umgebung für die Ausführung von Anwendungen bietet, während die zugrunde liegenden physischen Ressourcen besser genutzt werden.

Eine virtuelle Maschine ist jedoch nicht schlank wie ein Container, da sie ihr eigenes Gastbetriebssystem ausführt. Tatsächlich sieht eine VM von außen betrachtet wie ein physischer Computer aus. Virtuelle Maschinen ermöglichen es, verschiedene Betriebsumgebungen auf ein und demselben physischen Rechner zu hosten. So kann ein Unternehmen beispielsweise eine Linux-VM neben einer Windows-VM auf demselben Server betreiben. Aufgrund des Gastbetriebssystems ist die VM jedoch auf mit einem wesentlich höheren Overhead verbunden als ein Anwendungscontainer.

Abbildung 2: VMs benötigen mehr Speicherplatz, da sie ein Gastbetriebssystem benötigen, um ausgeführt werden zu können. Container verbrauchen nicht so viel Speicherplatz, da jeder Container das Betriebssystem des Hosts mitbenutzt.
Abbildung 2: VMs benötigen mehr Speicherplatz, da sie ein Gastbetriebssystem benötigen, um ausgeführt werden zu können. Container verbrauchen nicht so viel Speicherplatz, da jeder Container das Betriebssystem des Hosts mitbenutzt.

Virtuelle Maschinen werden auf Servervirtualisierungsplattformen gehostet. Das Herzstück dieser Plattform ist der Hypervisor, der auf dem Host-Betriebssystem aufsetzt oder in das Betriebssystem integriert ist. Er abstrahiert die zugrunde liegende Hardware. Die VMs sind nicht wie Container mit dem Host-Kernel verbunden. Vielmehr arbeiten sie isoliert vom zugrunde liegenden System. Der Vorteil ist, dass VMs eine größere Sicherheit bieten als Container. Allerdings verbrauchen sie auch mehr Ressourcen und erfordern mehr Betriebssystemlizenzen als ein containerisiertes Setup.

Anwendungscontainer verbrauchen weniger Ressourcen als eine vergleichbare Bereitstellung auf virtuellen Maschinen. Container teilen sich Ressourcen, ohne dass jeder Anwendung ein komplettes Betriebssystem zugrunde liegt. Container nutzen nicht nur die Ressourcen effizienter, sondern ermöglichen auch die Ausführung von mehr Anwendungen auf einem einzigen Server als mit VMs. Allerdings sind diese Vorteile auch mit größeren Sicherheitsrisiken verbunden.

Aus diesem Grund stellen viele IT-Teams und Cloud-Anbieter ihre Container innerhalb von VMs bereit. Das bedeutet, dass ein einziger Server mehrere VMs hosten kann, auf denen vielleicht unterschiedliche Betriebssysteme laufen, wobei jede VM mehrere Container unterstützt. Trotz dieser zusätzlichen Schichten teilen sich die Container jedoch immer noch dieselben physischen Ressourcen, sind aber auf den Gast-Kernel der VM angewiesen. Dieser Ansatz bietet aufgrund der zusätzlichen Isolierung durch die VMs einen besseren Schutz, ist jedoch auch mit mehr Komplexität und Overhead verbunden.

Was ist ein Systemcontainer?

Eine andere Art von Container ist der Systemcontainer. Der Systemcontainer erfüllt eine ähnliche Funktion wie virtuelle Maschinen, jedoch ohne Hardwarevirtualisierung. Ein Systemcontainer, auch Infrastrukturcontainer genannt, führt sein eigenes Gastbetriebssystem aus. Er enthält seine eigenen Anwendungsbibliotheken und Ausführungscodes. Systemcontainer können Anwendungscontainer hosten.

Obwohl Systemcontainer ebenfalls auf Images basieren, sind die Container-Instanzen in der Regel dauerhaft und nicht wie Anwendungscontainer nur vorübergehend. Ein Administrator aktualisiert und ändert Systemcontainer mit Hilfe von Konfigurationsmanagement-Tools, anstatt Images zu löschen und neu zu erstellen, wenn eine Änderung eintritt. Canonical Ltd., das Entwicklerunternehmen des Ubuntu-Linux-Betriebssystems, leitet das LXD- oder Linux-Container-Hypervisor-Projekt für Systemcontainer. Eine weitere Option für Systemcontainer ist OpenVZ.

Arten der Containerisierungstechnologie

Die häufigsten Anwendungscontainer basieren auf Docker, insbesondere auf der Open-Source-Docker-Engine und Containern, die auf der universellen RunC-Laufzeitumgebung basieren. Es gibt jedoch auch eine Reihe von Docker-Alternativen, darunter Podman, Containerd und Linux LCD. Für die Orchestrierung von Containern verwenden IT-Teams häufig Tools wie Kubernetes, Docker Swarm oder Red Hat OpenShift, obwohl auch eine wachsende Zahl anderer Orchestrierungs-Tools auf dem Markt verfügbar ist.

Es gibt eine Vielzahl von Containerisierungsprodukten und -diensten auf dem Markt, darunter auch von den führenden Cloud-Service-Anbietern:

  • Apache Mesos: Mesos ist ein Open-Source-Cluster-Manager, der Arbeitslasten in einer verteilten Umgebung durch dynamische gemeinsame Nutzung und Isolierung von Ressourcen verwaltet. Er eignet sich für die Bereitstellung und Verwaltung von Anwendungen in groß angelegten Cluster-Umgebungen. Die Plattform bietet native Unterstützung für das Starten von Containern mit Docker- und AppC-Images.
  • Google Kubernetes Engine: Kubernetes Engine ist eine verwaltete, produktionsbereite Umgebung für die Bereitstellung von containerisierten Anwendungen. Sie ermöglicht eine schnelle App-Entwicklung und -Iteration, indem sie die Bereitstellung, Aktualisierung und Verwaltung von Anwendungen und Diensten erleichtert.
  • Amazon Elastic Container Registry (ECR): Dieses Produkt von Amazon Web Services speichert, verwaltet und stellt Docker-Images bereit. Amazon ECR hostet Images in einer hochverfügbaren und skalierbaren Architektur, die es Entwicklern ermöglicht, Container für ihre Anwendungen zuverlässig bereitzustellen.
  • Azure Kubernetes Services (AKS): AKS ist ein verwalteter Containerorchestrierungsdienst, der auf dem Open-Source-System Kubernetes basiert. AKS ist in der Public Cloud von Microsoft Azure verfügbar. Entwickler können AKS nutzen, um Docker-Container und containerbasierte Anwendungen in einem Cluster von Container-Hosts bereitzustellen, zu skalieren und zu verwalten.

Wie Sie eine Plattform für die Containerisierung auswählen

Bei der Auswahl einer Plattform für die Containerisierung sollten Entwicklungsteams mehrere wichtige Faktoren berücksichtigen:

  • Anwendungsarchitektur: Der Schwerpunkt sollte auf den zu treffenden Entscheidungen zur Anwendungsarchitektur liegen, zum Beispiel ob die Anwendungen monolithisch oder Microservices sind und ob sie zustandslos oder zustandsabhängig sind.
  • Workflow und Zusammenarbeit: Berücksichtigen Sie die Änderungen an den Arbeitsabläufen und ob die Plattform eine einfache Zusammenarbeit zwischen den Beteiligten ermöglicht.
  • DevOps: Berücksichtigen Sie die Anforderungen für die Verwendung der Self-Service-Schnittstelle zur Bereitstellung von Anwendungen durch die DevOps-Pipeline.
  • Packaging: Berücksichtigen Sie das Format und die Tools zur Verwendung des Anwendungscodes, der Abhängigkeiten, der Container und der Containerabhängigkeiten.
  • Monitoring und Protokollierung: Stellen Sie sicher, dass die verfügbaren Überwachungs- und Protokollierungsoptionen den Anforderungen entsprechen und mit den aktuellen Entwicklungsabläufen funktionieren.

Die Bereitstellung von containerisierten Anwendungen kann auch Auswirkungen auf IT-Teams haben, insbesondere auf diejenigen, die an DevOps-Initiativen beteiligt sind. Aus diesem Grund sollten die Teams mehrere wichtige Faktoren berücksichtigen, bevor sie ihre containerisierten Anwendungen bereitstellen:

  • Architektonische Anforderungen der Anwendungen: Vergewissern Sie sich, dass die Plattform die architektonischen Anforderungen der Anwendung sowie die Anforderungen an den Storage für zustandsabhängige Anwendungen erfüllt.
  • Migration von Legacy-Anwendungen: Die Plattform und die sie umgebenden Werkzeuge müssen alle Altanwendungen unterstützen, die migriert werden müssen.
  • Anwendungsaktualisierungen und Rollback-Strategien: Arbeiten Sie mit den Entwicklern zusammen, um Anwendungsaktualisierungen und Rollbacks zu definieren, damit die Service Level Agreements eingehalten werden.
  • Überwachung und Protokollierung: Planen Sie den Einsatz der richtigen Infrastruktur- und Anwendungsüberwachungs- und Protokollierungs-Tools, um eine Vielzahl von Metriken zu erfassen.
  • Storage und Netzwerk: Stellen Sie sicher, dass die notwendigen Storage-Cluster, Netzwerkidentitäten und Automatisierungen vorhanden sind, um die Anforderungen aller zustandsabhängigen Anwendungen zu erfüllen.

Geschichte der Containerisierung

Die Containertechnologie wurde erstmals 1979 mit der Unix-Version 7 und dem Chroot-System eingeführt. Chroot leitete den Beginn der Prozessisolierung im Containerstil ein, indem es den Dateizugriff einer Anwendung auf ein bestimmtes Verzeichnis – das Root-Verzeichnis – und dessen Unterverzeichnisse beschränkte. Ein wesentlicher Vorteil der Chroot-Trennung war die verbesserte Systemsicherheit. Eine isolierte Umgebung konnte keine externen Systeme kompromittieren, wenn eine interne Sicherheitslücke ausgenutzt wurde.

FreeBSD führte im März 2000 den Jail-Befehl in sein Betriebssystem ein. Der Jail-Befehl war dem Chroot-Befehl ähnlich. Er enthielt jedoch zusätzliche Funktionen, um Dateisysteme, Netzwerke und Benutzer zu isolieren. FreeBSD jail bot die Möglichkeit, eine IP-Adresse zuzuweisen, eigene Softwareinstallationen zu konfigurieren und Änderungen an jeder Jail vorzunehmen. Die Anwendungen innerhalb der Jail hatten jedoch nur begrenzte Möglichkeiten.

Mit den Solaris-Containern, die 2004 auf den Markt kamen, wurden über Solaris Zones vollständige Anwendungsumgebungen geschaffen. Mit Zones kann ein Entwickler einer Anwendung vollen Benutzer-, Prozess- und Dateisystemplatz sowie Zugriff auf die Systemhardware geben. Die Anwendung konnte jedoch nur sehen, was sich innerhalb ihrer eigenen Zone befand.

Im Jahr 2006 führte Google Prozesscontainer ein, um die Ressourcennutzung eines Prozesses zu isolieren und zu begrenzen. Die Prozesscontainer wurden 2007 in Kontrollgruppen (cgroups) umbenannt, um nicht mit dem Wort Container verwechselt zu werden.

Im Jahr 2008 wurden die cgroups dann in den Linux-Kernel 2.6.24 integriert. Das führte zur Gründung des heutigen LXC-Projekts (Linux-Container). LXC ermöglichte die Virtualisierung auf Betriebssystemebene, indem mehrere isolierte Linux-Container auf einem gemeinsamen Linux-Kernel ausgeführt werden konnten. Jeder dieser Container hatte seine eigenen Prozess- und Netzwerkbereich.

Google änderte Container erneut im Jahr 2013, als es seinen Container-Stack als Projekt mit dem Namen Let Me Contain That For You (LMCTFY) zur Verfügung stellte. Mit LMCTFY konnten Entwickler containerfähige Anwendungen schreiben. Das bedeutete, dass sie so programmiert werden konnten, dass sie ihre eigenen Sub-Container erstellen und verwalten konnten. Im Jahr 2015 stellte Google die Arbeit an LMCTFY ein und beschloss stattdessen, die Kernkonzepte von LMCTFY in das Docker-Projekt Libcontainer einzubringen.

Docker wurde im Jahr 2013 als Open-Source-Projekt veröffentlicht. Mit Docker konnten Container so verpackt werden, dass sie von einer Umgebung in eine andere verschoben werden konnten. Ursprünglich basierte Docker auf der LXC-Technologie. Im Jahr 2014 wurde LXC jedoch durch Libcontainer ersetzt. Dadurch konnten Container mit Linux-Namensräumen, Libcontainer-Kontrollgruppen, AppArmor-Sicherheitsprofilen, Netzwerkschnittstellen, Firewall-Regeln und anderen Linux-Funktionen arbeiten.

2017 stellten Unternehmen wie Pivotal, Rancher, AWS und sogar Docker auf die Unterstützung des Open-Source-Container-Schedulers und Orchestrierungs-Tools Kubernetes um.

Diese Definition wurde zuletzt im Februar 2025 aktualisiert

Erfahren Sie mehr über Server- und Desktop-Virtualisierung