Wie AWS Fargate das Container-Management entlastet

ComputerWeekly.com/de

https://www.computerweekly.com/de/tipp/Wie-AWS-Fargate-das-Container-Management-entlastet

Wie AWS Fargate das Container-Management entlastet

von Kurt Marko

Zunehmend betreiben Entwicklungs- und IT-Ops-Teams in Unternehmen Container auf Pools von Cloud-VMs, sogenannten Clustern, anstatt auf einzelnen Compute-Instanzen wie in EC2. Dieser Ansatz bietet zwar einerseits mehr Flexibilität, schafft andererseits aber auch Mehrarbeit für Anwender. Sie müssen zwei Umgebungen konfigurieren und verwalten: Amazon EC2 und die Container-Infrastruktur.

Orchestrierungsdienste wie der Amazon EC2 Container Service (ECS) bieten Cluster-Management und Container-Steuerung als Managed-Service. Dadurch wird ein Teil dieses Overheads vermieden. Allerdings müssen die Benutzer die zugrunde liegenden Instanzen, die den Cluster bilden, noch konfigurieren und verwalten.

Um dies zu ändern, veröffentlichte Amazon AWS Fargate. Fargate ergänzt ECS und ECS for Kubernetes (EKS) und löst den zweiten Teil des Container-Bereitstellungs-Puzzles: das Instanz-Management.

Container einrichten

Ähnlich wie Azure Container Instances verwandelt AWS Fargate einzelne Container in konsumierbare Cloud-Ressourcen. Bei Fargate muss ein Entwickler nur die Parameter für eine Container-Instanz angeben und AWS stellt sie auf seiner Hardware bereit.

Die grundlegenden Elemente einer Fargate-Bereitstellung sind Compute, Networking, Storage, Zugriffsrechte, Logging und Debugging-Konfiguration sowie das Runtime-Image – die alle in Task-Definitionen gekapselt sind.

Entwickler können diese unveränderlichen, versionierten Dokumente – nahezu identisch mit ECS-Task-Definitionen – in JSON- oder YAML-Syntax schreiben. Multiple Container werden durch einen Task-Lauf auf einem von ECS verwalteten Container-Cluster beschrieben, wobei Kubernetes Ende 2018 via EKS unterstützt werden soll.

Die Tasks umfassen folgende Elemente:

Ein eindeutiger Family Name und eine Versionsnummer für die Definition des Tasks;
Die benötigten CPU-Ressourcen, die sich alle Container teilen, die in der Aufgabe definiert wurden, stehen in fünf virtuellen CPU-Größen (vCPU) – von 0,25 bis 4 – zur Verfügung;
Der gesamte Memory für die Aufgabe, wie er durch die vCPU-Zuweisung vorgegeben ist. Zum Beispiel können 0,5-vCPU-Tasks 0,5, 1 oder 2 GB auswählen, während 4-vCPU-Tasks einen beliebigen Wert zwischen 8 und 30 GB in Schritten von 1 GB wählen können;
Eine Liste von bis zu zehn Container-Definitionen, die einen Namen und eine Image-URL aus der Amazon Elastic Container Registry (ECR) oder der Public Registry des Docker Hub enthalten. Sie legen die Eigenschaften jedes Containers fest, der demselben Host zugeordnet ist;
Ein optionaler CPU- und Memory-Sharing-Parameter, der einen bestimmten Anteil der gesamten vCPU und des Speichers für eine bestimmte Container-Instanz reserviert. Wenn Sie beispielsweise eine zusammengesetzte, auf Microservices basierende Anwendung haben, die für jeden Dienst separate Container verwendet, können Sie eine bestimmte Menge an vCPU für Frontend-Webserver garantieren;
Der Netzwerkmodus, der jeder Aufgabendefinition eine Private Elastic Netzwerkschnittstelle zu einer Amazon Virtual Private Cloud, einer primären private IP-Adresse und einen internen Host-Namen des Domain Name Systems (DNS) zur Verfügung stellt. Sie können einer Aufgabe auch öffentliche IPs zuweisen, um externen Traffic zuzulassen;
Die Task-Level Load-Balancing-Konfiguration mit Support für Network Load Balancer oder Application Load Balancer, wobei letzterer mindestens zwei Subnetze in unterschiedlichen Verfügbarkeitszonen benötigt;
Port Mappings für jeden Container in der Aufgabendefinition, die es Container-Instanzen ermöglichen, Daten über bestimmte Netzwerk-Ports zu senden und zu empfangen;
Storage-Konfiguration, die sowohl persistenten als auch ephemeralen Docker-Layer Storage unterstützt. Dabei ist letzterer bis zu zehn GB pro Task konfigurierbar und kann von allen Containern gemeinsam genutzt werden. Layer Storage erlaubt es anderen Containern nicht, die Daten zu sehen, während die persistente Speicherung diese Sichtbarkeit zwischen den Containern ermöglicht, solange sie sich innerhalb derselben Sitzung befindet. Die Sichtbarkeit ist beispielsweise verschwunden, wenn die Aufgabe beendet wird. Entwickler können bis zu vier GB eines Elastic Block Store Volumes pro Task-Definition verwenden und die zugehörigen Mount-Punkte und den Volume-Source-Pfad konfigurieren;
Drei Stufen von Zugriffsberechtigungen. Dazu gehören Cluster-Berechtigungen, die Aufgaben starten oder beschreiben können; Anwendungsberechtigungen, die den Container-Zugriff auf externe AWS-Ressourcen definieren; und Housekeeping-Berechtigungen, die den Zugriff auf verschiedene administrative Tasks ermöglichen;
CloudWatch Log-Konfiguration, um Parameter für den awslogs-Treiber zu definieren. Dieser sendet Anwendungsdaten an CloudWatch;
Benutzerdefinierte Kontrollbefehle, wie das Überwachungsintervall, der Timeout-Wert und die Wiederholungsgrenze, um nach gestoppten Tasks zu suchen.

Diese verschachtelten Aufgaben- und Container-Einstellungen bieten alles, was Fargate benötigt, um mehrere Container auf einem Host bereitzustellen. Darüber hinaus können Entwickler mit ECS Fargate-Workloads auf einem virtuellen Cluster verwalten, für den Fall, dass mehrere Aufgaben gemeinsam bereitgestellt werden sollen.

Die Zukunft von Fargate

AWS Fargate Version 1.1 enthält Erweiterungen des Dienstes, einschließlich der Unterstützung von Task-Metadaten-Endpoints, Container Health Checks und ECS Service Discovery. Metadaten-Endpoints ermöglichen die Erfassung von Fargate-Metriken durch Monitoring-Tools von Drittanbietern wie Datadog. Health Checks identifizieren fehlgeschlagene Tasks und generieren einen automatischen Neustart von fehlgeschlagenen oder aufgehangenen Tasks. ECS Service Discovery erleichtert schließlich die Verbindung zwischen containerisierten Diensten, die in verschiedenen Tasks laufen.

AWS Fargate kann ein Segen für Unternehmen sein, die Container-Implementierungen als Ärgernis betrachten. Schließlich macht der Dienst das Management von EC2-Instanzen überflüssig. Wenn IT-Teams Erfahrungen mit der Ausführung von containerisierten Anwendungen sammeln, können sie Fargate-Bereitstellungen auf ECS - und eventuell auch auf EKS - für das Cluster-Management ausdehnen. Sie haben dabei den Komfort, dass sie die Task-Konfigurationen wiederverwenden können und erhalten so mehr Ressourcenoptionen und mehr Kontrollmöglichkeiten.

Preismodelle: AWS Fargate versus Google Kubernetes Engine

Preise direkt zwischen Fargate und Google Kubernetes Engine (GKE) zu vergleichen, ist schwierig, da die Knotengrößen nicht direkt vergleichbar sind. Sie können jedoch für jede Dienstleistung eine grobe Schätzung der Kosten vornehmen.

Das Preismodell von Fargate basiert auf einer Kombination aus Ressourcennutzung, wie zum Beispiel vCPU und Speicherzuweisung, und Ausführungszeit in Schritten von einer Sekunde mit einem Minimum von einer Minute. AWS lässt Benutzer zahlen, sobald ein Container-Image aus einem Repository heruntergeladen wird und stoppt, wenn die Aufgabe beendet wird. Wenn Sie also eine Anwendung mit zehn Tasks haben, die jeweils 0,25 vCPU und ein GB Arbeitsspeicher verwenden, und wenn diese Anwendung eine Stunde pro Tag läuft, kostet das 7,61 US-Dollar pro Monat.

Wenn Sie bei GKE für jede der zehn oben genannten Aufgaben einen eigenen Knoten verwenden und die kleinste gemeinsame Instanz auswählen, die GKE bereitstellt – den f1-micro -– berechnet der Kostenrechner von Google, dass die Nutzung pro Stunde und Tag 2,31 US-Dollar pro Monat kosten würde; das sind etwa 30 Prozent der Kosten von Fargate. GKE erfordert jedoch gründliche Kenntnisse des Kubernetes-Managements – und verlangt außerdem einiges mehr an Setup als Fargate.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!

08 Nov. 2018