Was sind Container

Als Container-Image wird ein eigenständiges, ausführbares Softwarepaket bezeichnet, dass alle seine Abhängigkeiten (mit Ausnahme des Betriebssystems) mitbringt. Wird ein Image instanziiert, so wird ein Container erzeugt, der entsprechend der ihm enthaltenen Software arbeitet. Ein Image kann beliebig oft instanziiert und somit können beliebig viele Container erzeugt werden.

Die wesentlichen Vorteile von Containern sind die Abstraktion vom Betriebssystem ohne jedoch einen viel langsameren Hypervisor einzufügen, beispielsweise wie bei Hyper-V oder VMWare. Und durch ihre Portabilität und geringe Größe, können schnell Containerinstanzen erzeugt werden und so große Cloud-Native-Anwendungen mit vielen Microservices entsprechend skalieren.

Unterstützung von Linux und Windows Containern bei AWS und Azure

Die oben gezeigte Grafik stellt verschiedene Dienste bei AWS und Azure dar. Hierbei wurde geprüft, ob die Dienste Windows – (links), Linux (rechts) oder beide Container (Mitte) unterstützen. Zusätzlich floss ein, ob die Dienste manueller Konfiguration und Wartung bedürfen (unten) oder ob es sich um full managed Services handelt (oben).

Eine kurze Einordnung, welche Dienste hierbei untersucht wurden, gibt die folgende Tabelle:

Erläuterung

A, B, C: Azure Container Services sind ein Dienst, um Infrastruktur für verschiedene Docker-Orchestrator aufzusetzen. Sie unterstützen dabei DC/OS, Docker Swarm und Kubernetes. Hierbei wird Kubernetes mit Linux und Windows Containern angeboten. Das Managen des Clusters und patchen des Betriebssystems muss dabei manuell erfolgen. Auch wird das automatische Skalieren der Worker-Nodes des Clusters noch nicht überall unterstützt.

D: Service Fabric ist ein gemanagter Dienst zum Hosten und Skalieren von Microservices und Containern. Es handelt sich um eine full managed Infrastruktur, die für die .NET Entwicklung erstellt wurde. Viele Azure Services basieren intern auf dieser Implementierung.

Er bietet eine automatische Installation, Continous Deployment und automatische Skalierungsmöglichkeiten. Es ist nicht nötig, unterliegende Infrastruktur zu konfigurieren oder zu patchen.

Beim Aufsetzen eines Service Fabric Clusters in Azure kann zwischen Windows Server oder Ubuntu Server gewählt werden, wodurch die unterstützte Containertechnologie vorgegeben wird. Aus historischen Gründen ist die Unterstützung für Windows etwas umfangreicher, als für Linux. Eine On-Premise Installation für Windows oder Linux ist ebenfalls möglich, falls der Cluster in der private Cloud betrieben werden soll.

E: Docker bildet die Grundlage für die Containertechnologie. Der Swarm Mode erweitert das Docker-System um einen Orchestrator, der das Zusammenspiel und die Replikation verschiedener Container steuert und überwacht. Eine herkömmliche Docker-Installation liefert den Swarm Mode direkt mit aus und muss lediglich aktiviert werden.

Da Docker auf Windows und Linux Systemen arbeitet, kann auch der Swarm Mode auf Windows und Linux genutzt werden. Die Docker-Webseiten bieten diverse Skripte und Anleitungen zur Installation auf Windows oder Linux VMs in Azure.

F, I: Kubernetes ist einer der bekanntesten Container Orchestrator für den produktiven Einsatz und für die Entwicklung. Aufgrund seiner Verbreitung wird er in vielen Cloud-Providern unterstützt und von ihnen in den letzten Wochen mehr und mehr als full managed Service angeboten.

Die Kubernetes Dokumentation hält Skripte für die Installation von Kubernetes auf Linux Systemen bereit. Dabei wird sowohl Linux VMs in Azure als auch Linux EC2 Instanzen in AWS unterstützt. Aus historischen Gründen ist die Unterstützung hier für EC2 ein wenig umfangreicher.

G: Die Kubernetes Dokumentation stellt auch Anleitungen für das Aufsetzen von Kubernetes auf Windows Maschinen bereit. Dabei wird sowohl auf Azure VMs als auch auf AWS EC2 Instanzen eingegangen. Die Anleitung ist jedoch recht umfänglich und erfordert viele manuelle Schritte.

H: Amazon Web Services bieten mit den Elastic Container Services (ECS) einen selbstentwickelten Orchestrator für Container an. Hierbei werden sowohl Linux Container als auch Windows Container unterstützt. Die darunterliegende Infrastruktur besteht aus EC2 Instanzen, die zwar automatisch angelegt, jedoch manuell gepatcht und gewartet werden müssen.

J: Ähnlich wie E bietet die Docker Dokumentation und viele andere Anbieter automatisierte Installationsskripte für die Installation von Linux auf EC2. Linux und EC2 sind die älteste Kombination und daher sicherlich auch am meisten diskutiert, dokumentiert und geskriptet. Jedoch gilt auch hier, wie für E, dass das patchen des Betriebssystems und das Networking aller Knoten manuell (bzw. durch Skripte) eingerichtet werden muss.

K: Die Unterstützung zur Installation von Docker im Swarm Mode auf Windows Servern auf EC2 Instanzen ist kaum vorhanden. Dementsprechend erfordert dieses Szenario maximalen manuellen Aufwand und unterstützt keine Automatisierung bei der Installation und der Wartung der EC2 Instanzen.

L: Seit kurzer Zeit bietet Azure einen managed Kubernetes Cluster (AKS) an. Hierbei kann automatisch auf eine neue Kubernetes Version upgegradet werden und es ist kein Patching des Betriebssystems nötig. Neue Knoten können ebenfalls leicht hinzugefügt werden.

Der neue Dienst unterstützt lediglich Linux Container.

M: Seit der Connect() 2017 gibt es in einigen Azure Regionen auch Docker Swarm als full managed Service in der Preview. Wie bei L wird hier ebenfalls die automatische Installation und das Upgrade auf eine neuer Version unterstützt. Das Patchen des Betriebssystems der Knoten entfällt ebenfalls.

Auch hier werden lediglich Linux Container unterstützt.

N: Mit Container Instances bietet Azure einen weiteren serveless Dienst, der es erlaubt, Container direkt zu instanziieren und zu nutzen. Hierbei läuft jeder Container einzeln, ohne dass es sich um einen Cluster oder eine Gesamtanwendung mit vielen Containern handelt. Die Containerinstanzen können beispielsweise für Build oder Deploymentprozesse genutzt werden oder auch als Worker einem Kubernetes Cluster hinzugefügt werden.

O: Seit dem re:Invent 2017 bietet Amazon ebenfalls einen managed Kubernetes Cluster (EKS) in der Preview an. Hierbei ist lediglich der Master-Knoten full managed, die Workernodes müssen weiterhin manuell gepatcht werden. Dieser neue Dienst nutzt ebenfalls EC2 Instanzen als Infrastruktur und kann derzeit nur mit Linux Containern genutzt werden.

P: Ebenfalls beim re:Invent 2017 vorgestellt wurde Fargate. Hierbei handelt es sich um eine gemanagte Infrastruktur für ECS (H). Dadurch wird ECS von den darunterliegenden EC2 Instanzen entkoppelt und arbeitet direkt mit den Containern. Fargate unterstützt derzeit nur Linux Container. Als nächste Weiterentwicklung ist die Unterstützung von Kubernetes Clustern (O) geplant.

Ergebnis

Beim Betrachten des Diagrammes fällt sofort auf, wie schlechte die Unterstützung für Windows Container derzeit noch ist. Der rechte Bereich (Linux) ist gut gefüllt und die Automatisierung ist dort sehr hoch. Wohingegen auf der linken Seite (Windows) gähnende Leere klafft, aber es zumindest einige Hypridentwicklungen in der Mitte gibt. Da historisch alles mit Linux begann und dort die bestehenden Technologien nach und nach um Windows Container erweitert werden, ist diese Verteilung auch wenig verwunderlich.

Auch alle neuen managed Services von Amazon AWS wie Fargate (P) und EKS (O) oder auch die neuen Services von Microsoft Azure wie AKS (L) und ACS mit DockerCE (M) zielen auf einen höheren Automatisierungsgrad ab. Jedoch wird bei keinem Service eine zusätzliche Unterstützung für Windows Container berücksichtigt.

Es lässt sich also festhalten, dass Windows Container noch lange nicht zu den First-Class-Citizens gehören, denn die Entwicklung geht erst einmal in die weitere Automatisierung der bestehenden (Linux) Technologien und erst dann in die Breite zur Unterstützung von Windows.

Was sollen .NET Entwickler tun, wenn sie Container brauchen?

Nun stehen die .NET Entwickler ein wenig verlassen und einsam vor der schönen neuen Containerwelt. Doch welche Wege gibt es nun, um .NET Anwendungen mit Containern zu nutzen?

Windows Container

Microsoft hat es verschlafen mit seinen Serverprodukten kleine leichtgewichtige Images anzubieten. Ein Windows Server Core mit 5GB Speicherplatz ist keine gute Grundlage für einen Container. Doch vor ein paar Jahren kam der Nanoserver mit rund 400MB ins Docker-Hub. Die neueste Version (Tag 1709) spart noch einmal 80% Speicherplatz und liegt derzeit bei 99MB. Damit ist der Nanoserver als Container äußerst attraktiv geworden. Nun fehlen nur noch die zusätzlichen Dienste. Hier gibt es mit ACS Kubernetes eine Unterstützung für Windows Container und mit Service Fabric sogar einen managed Service.

.NET Core

Mit .NETCore 2.0 ist der Umfang an Funktionalität deutlich gestiegen. Es wird von 70% des .NET Frameworks gesprochen. Mit .NET Core kann die Anwendung auch in Linux Containern laufen und so gelingt die Entkoppelung von Windows Containern und alle Dienste aus der oberen rechten Ecke des Diagrammes werden nutzbar.

Mit dem Roslyn API Analyzer bietet Microsoft ein zusätzliches Analysetool für .NET Core Projekte. Dabei werden nicht nur die verwendeten APIs auf Aktualität geprüft, sondern es enthält einen Plattform-Kompatibilitäts-Prüfer. Bei jeder Funktion wird gemeldet, falls diese unter MacOS oder Linux nicht unterstützt wird. Das erleichtert zusätzlich die Entwicklung für Linux Container bzw. ist sehr Hilfreich bei der Migration von bestehenden Anwendungen zu .NET Core.

Serverless ohne Container

Bei serverless Architektur handelt es sich um Nutzung von Diensten, ohne sich um die darunterliegende Infrastruktur zu kümmern. Einige der genannten Dienste sind schon serverless. Doch evtl. kann bei der Entwicklung noch ein Schritt weitergegangen werden und anstatt Microservices in Container zu verpacken, kann der C#-Code direkt in Azure Functions oder AWS Lambdas entwickelt/deployt werden. Beide Mechanismen bieten fast grenzenlose Skalierung und sekundengenaue Abrechnung bei Benutzung.

Auch wenn die Containerangebote für Linux sehr umfänglich sind, gibt es auch für Windows Container einige Möglichkeiten. Der detaillierte Vergleich fällt aber weiterhin ganz klar zu Gunsten von Linux aus. Und überall dort, wo die Windows Container Unterstützung noch nicht ausreichend ist, gibt es mit .NET Core und serverless Ansätzen interessante Alternativen.