Container on Azure – Teil 1: Basics

In diesem Beitrag möchte ich auf die grundlegenden Begriffe zum Thema Container eingehen. Dies dient als Vorbereitung auf den weiterführenden Beitrag, indem es dann konkret um das Service Angebot von Azure zum Thema Container geht.

Containerisierung und Docker

Ein oft gehörtes Buzzword hierzu ist die Containerisierung. Unter dieser versteht sich im Allgemeinen die „Virtualisierung der Virtualisierung“. Dies bedeutet, dass Anwendungen von ihrer Laufzeitumgebung abstrahiert werden und so Container entstehen. Ein Container ist somit eine isolierte Umgebung, welche alle Abhängigkeiten und die eigentliche Softwareanwendung wie Binaries, Runtime, System Tools und Libraries in einem Image zusammenfasst.

Analog zur objektorientierten Programmierung, bei der ein Objekt die Laufzeitinstanz einer Klasse darstellt, ist ein Container die Laufzeitinstanz eines Images. Die Docker-Images werden an einem zentralen Ort gespeichert, der sogenannten Container Registry. Eine Container Registry bietet einen schnellen Zugriff auf die Images, hohe Verfügbarkeit und eine detailgetreue Zugriffskontrolle.

Wird heutzutage von Container gesprochen, ist in der in der Regel die Rede von Docker. Dabei handelt es sich um eine Open-Source-Softwarelösung, die uns beim Erstellen und Ausführen von Containern hilft. Der Kern von Docker ist der Docker Daemon. Die Funktionen der Engine werden über einer REST API zur Verfügung gestellt. Ein Benutzer kommuniziert aber in der Regel nicht direkt mit der REST API sondern nutzt das Docker Command Line Interface (CLI).

Aber wieso eigentlich dieser Hype um Container?

Nun diese Frage lässt sich durch die Nennung eingier Vorteile selbiger beantworten. Zum einen gewinnt man Skalierbarkeit, da Container sehr leichtgewichtig sind, können sie schnell gestartet oder gestoppt werden. Auch sind sie sehr leicht portierbar. Normalerweise gilt das Prinzip Any App, Any Language, Any Stack was ein einfaches Deployment auf verschiedenen Umgebungen zur Folge hat. Auch können unterschiedliche Container parallel auf einer Maschine laufen, dies spart Lizenzkosten und Ressourcen (Density). Zuletzt lassen sich Container leicht modular updaten oder austauschen und so flexible Softwaregebilde bauen.

Unterschied von Container und VM

Oft werden Container mit VMs verglichen. Der prinzipielle Unterschied ist, dass eine virtuelle Maschine immer eine feste Ressourcenanzahl zugewiesen bekommt. Ein Hypervisor schafft die Möglichkeit, dass verschiedene Gastsysteme auf einem Host parallel laufen können. Bei Containern ist weder ein gastsystem, noch ein Hypervisor nötig. Wie schon erwähnt, teilen sich Container den Kernel des Hostsystems. Daher ist nur eine sog. Container Runtime nötig, damit alles reibungslos funktioniert.

Eine weitere wichtige Komponente in der Containerwelt stellt der Orchestrator dar. Dieser automatisiert die Verwaltung von Containern (Supend, Shutdown, Spin, Clone..) und bietet eine Schnittstelle nach außen. Auch betreibt er Load Balancing und steuert den Zugriff auf Ressourcen. Der Orchestrator entscheidet welcher Container auf welchem Node in einem Cluster läuft und wie sie verteilt werden.

Einer der bekanntesten, welcher auch für Azure wichtig ist, heißt Kubernetes. Hier werden genu die Aufgaben übernommen, die oben beschrieben werden. Kurz beschrieben gibt es ein Master Node in einem Kubernetes Cluster. Diesem werden ein Container Image und weitere Informationen übergeben. Das Master Node entscheidet dann auf welcher Instanz der Container entstehen soll. Es wird ein sog. Deployment erstellt, welches alle relevanten Informationen wie nötiger RAM, Speicher, CPU, Storage und Skalierung enthält.

Kubernetes nutzt sogenannte Pods. Hierbei handelt es sich um Gruppen von mindestens bzw. meistens genau einem Containern. Jeder Pod hat eine eindeutige ID und ermöglicht einen Zugriff von außen über einen Adressraum. Container innerhalb eines Pods sind über localhost untereinander erreichbar, teilen sich den Speicher und die Port Range.

Hier geht es zu Teil 2