AWS Fargate: Container-Orchestrierung ohne Cluster

Inhaltsverzeichnis

Jeder, der sich mit Cloud-nativen Anwendungen, DevOps und Microservices beschäftigt, kommt an zwei Hype-Technologien nicht vorbei: Container-Orchestrierung und Serverless-Architekturen. Bisher gab es zwischen diesen Ansätzen wenig Überschneidungen. Mit AWS Fargate hat Amazon Web Services nun einen Hybrid vorgestellt, der Eigenschaften beider Verfahren zusammenbringt. Dieser Artikel befasst sich mit der grundlegenden Idee hinter Fargate, stellt Vergleiche zu den Alternativen her und zeigt, wie sich Fargate über CloudFormation und die AWS CLI bedienen lässt. Hierzu wird als Anwendungsbeispiel ein einfacher Container per Skript gestartet, der als Bastion Host fungieren kann.

Schon wieder eine neue Container-Orchestrierung?

Von allen Ankündigungen der im Dezember stattgefundenen AWS-Hausmesse Invent ist AWS Fargate eine der spannendsten. Fargate basiert zum jetzigen Zeitpunkt im Kern auf ECS (Elastic Container Service) und ist somit technisch gesehen ein Aufsatz für eine Container-Orchestrierung. ECS ermöglicht es, die eigenen in Docker Images verpackten Services auf einem Cluster in der Cloud zu betreiben. Hierbei profitiert man von den üblichen Vorteilen einer Container-Orchestrierung wie Selbstheilung, horizontale Skalierung, automatisches Bin-Packing der Container auf die Instanzen, einer Service Discovery und vom automatischen Routen des Netzwerkverkehrs zwischen den Containern.

Die Besonderheit von AWS Fargate tritt erst durch die Verbindung mit typischen Features von Serverless-Architekturen zu Tage. Diese zeichnen sich durch den geringeren operativen Aufwand aus, da hier keine virtuellen Maschinen gepflegt werden müssen. Zusätzlich skalieren diese Architekturen schnell und automatisch. Darüber hinaus charakterisiert sie ein nutzungsbasiertes Preismodell, das eine bessere Auslastung der bezahlten Ressourcen ermöglicht. Ein Beispiel: AWS Lambda ist ein Service, der es ermöglicht, eine beliebige Anzahl Events massiv parallel abzuarbeiten, wobei die Kosten auf der Bearbeitungsdauer in 100 ms Zeiteinheiten basiert. Für jedes Event wird hierfür potenziell eine eigene Lambda-Funktion instanziiert, um auch sehr hohen Traffic extrem schnell und parallel abzuarbeiten. Wird die Lambda-Funktion im nächsten Augenblick mal nicht benutzt, entstehen wiederum keine Kosten.

Ein typischer Nachteil von beispielsweise AWS Lambda gegenüber Container-basierten Ansätzen ist die maximale Ausführungsdauer von fünf Minuten und die kleine Anzahl von vorgegeben Laufzeitumgebungen. Aktuell unterstützt Lambda nur Node.js, Java, Python, .NET Core und Go. Ein Nachteil von Container-Orchestrierungen wiederum ist der operative Aufwand der zugrunde liegenden Maschinen und das von diesen vorgegebene Preismodell. Bei ECS beispielsweise müssen die EC2-Maschinen (Elastic Compute Cloud), aus denen das Cluster besteht, vollständig selbst verwaltet werden. Die Infrastrukturkosten für diese Maschinen berechnen sich nach den EC2-Kosten und nicht nach der aktuellen Ressourcenverwendung beziehungsweise der laufenden Container.

Cluster-as-a-Service

Fargate ist nun die Verbindung der Vorteile von Container-Orchestrierung und Serverless-Architekturen ohne die genannten Nachteile. Dies wird ermöglicht, indem AWS Fargate ECS-Ressourcen erstellt, dessen Maschinen automatisch und für den Nutzer unsichtbar bereitgestellt werden. Alle operativen Tätigkeiten wie Updates und Skalierung entfallen und werden in Fargate übernommen. Darüber hinaus entstehen bei Fargate keine Kosten für das Cluster, stattdessen wird jeder darauf laufende Container auf Basis seines zugewiesenen Prozessor- und Arbeitsspeicheranteils in Zeiteinheiten von Sekunden fakturiert.

Ein Beispiel: Ein Container mit einem virtuellen CPU-Kern und 2 GB RAM kostet in der Sekunde 0,00002112 US-Dollar (0,076032 US-Dollar pro Stunde). Ein neu gestarteter Container wird mit mindestens einer Minute berechnet. Die vergleichende preisliche Bewertung zu Alternativen wie AWS Lambda und AWS EC2 ist komplex, da sich die technischen Unterschiede und Preismodelle nicht gut miteinander vergleichen lassen. Dennoch lässt sich eine grobe Abschätzung vornehmen: Ein Fargate-Container ist etwa dreimal teurer als eine vergleichbare EC2-Instanz und ungefähr ein Drittel günstiger als eine vergleichbare dauerhaft laufende Lambda-Funktion.

Durch die Eigenschaften von Fargate bieten sich neue Möglichkeiten der Nutzung von Cloud-Ressourcen an, beispielsweise für aufwendige Tests in einer Continuous-Delivery-Pipeline. Ein Selenium Grid kann End-To-End-Tests einer Frontend-Anwendung auf Fargate starten. Mehrere Container testen dann die Weboberfläche und melden dem CI-Server die Ergebnisse.

Ein anderer Anwendungsfall wäre ein sogenannter Bastion Host. Dies ist ein Server, der als SSH-Gateway fungiert, um sich auf seine Cloud-Instanzen zu verbinden, ohne diese öffentlich zugänglich machen zu müssen. Fargate kann dieses Einfallstor für die Cloud in kurzer Zeit und beliebig oft erstellen und nach der Verwendung einfach wieder herunterfahren. Die Kurzlebigkeit des Bastion Host erhöht hiermit sogar die Sicherheit der Infrastruktur, da dieser Angriffspunkt nur kurz zur Verfügung steht. Ebenso ist Fargate auch einfach eine wartungsarme Alternative zu Plattformen wie Heroku, frei nach dem Motto "bring deinen Container mit, Fargate macht den Rest".

Less Ops

AWS Fargate schließt somit nicht nur eine Lücke zwischen den sehr schnell ausführbaren Function-as-a-Service-Ansätzen (AWS Lambda) und virtuellen Maschinen (AWS EC2), sondern bietet durch seine AWS-Nativität vergleichsweise mehr als eine selbstbetriebene Container-Orchestrierung.

Die Integration in bestehende AWS-Paradigmen und -Services wie Software Defined Networking, Lastverteilung, Authentifizierung und Autorisierung, Log- und Metrik-Aggregation bieten einen geringeren Betriebsaufwand als eigens konzipierte Varianten. Bei diesen müssen alternative Werkzeuge Cluster-übergreifende Aspekte wie Log-Aggregation integrieren. Auch die Selbst-Heilung oder der Austausch der virtuellen Maschinen mit AWS-Paradigmen wie AutoScaling wird bei Verzicht auf Fargate notwendig, um die Verfügbarkeit der eigenen Services zu garantieren. Fargate selbst bietet im Kontrast hierzu einen SLA mit 99,99 Prozent Verfügbarkeit für die Cluster-Infrastruktur und nimmt dem Betrieb diese Verantwortung ab.

ECS – Das braucht man, noch ...

Zur Zeit unterstützt AWS Fargate nur ECS zur Container-Orchestrierung, was impliziert, das grundlegende ECS-Konzepte und Vokabeln verstanden sein müssen, um Fargate zu benutzen. Dies soll jedoch nicht so bleiben, denn AWS hat für dieses Jahr den Elastic Container Service for Kubernetes (EKS) angekündigt, eine Alternative zu ECS. Fargate wird EKS integrieren und ermöglicht somit die Migration bestehender Kubernetes-Anwendungen auf Fargate.

Zum jetzigen Zeitpunkt muss man sich jedoch mit ECS begnügen. Das muss für eingefleischte Kubernetes-Fans jedoch nicht abschreckend wirken. Wer Kubernetes bereits in Teilen kennt, dem werden einige ECS-Konstrukte bekannt vorkommen. Ein Task ist die kleinste ausführbare Einheit eines ECS-Clusters und beschreibt eine Menge an Containern, die zusammen auf einem Knoten ausgeführt werden sollen. Sie ähneln hiermit den in Kubernetes bekannten Pods. Im Folgenden wird dieses Konzept genauer anhand eines praxisnahen Beispiels dargestellt: einer Fargate Bastion.