pattilabelle - Fotolia
AWS Container-Services entwickeln sich, haben aber Lücken
Auf der re:Invent 2017 hat AWS sein Container-Service-Portfolio erweitert. Sein Container-Orchestrierungsdienst, Amazon ECS, ärgert aber immer noch Entwicklerteams.
Amazon Web Services (AWS) war einer der ersten Cloud-Anbieter, der einen Managed-Containerservice mit einer modernen Containerisierung anbot, dem nur Google zuvorgekommen ist. Insgesamt sind die AWS-Containerdienste aber noch Arbeit.
AWS hat den Amazon EC2 Container Service (ECS) vor über drei Jahren eingeführt. Seine Komplexität hat allerdings – mit Ausnahme der anspruchsvollsten Benutzer – alle abgeschreckt. Dass sich AWS um seinen Service nicht ausreichend kümmert, kann man nicht sagen: Seit seinem Debüt sorgt AWS für einen stetigen Strom von Verbesserungen – was es allerdings nicht einfacher macht.
Mit ECS müssen Benutzer einen Cluster von EC2-Instanzen (Elastic Compute Cloud) hinter den Kulissen ausführen, überwachen, neu starten und aktualisieren. ECS verwendet EC2-Instanzen, um einen virtuellen Server-Pool für die Docker-Laufzeit und andere Komponenten zu erstellen. Aber es automatisiert nicht den Betrieb der zugrunde liegenden AWS-Ressourcen.
Das IT-Team muss andere Services nutzen, um Aufgaben zu automatisieren, darunter CloudFormation für Ressource Deployment Templates, CloudWatch für die Ressourcenüberwachung und Application Load Balancer für das Traffic Routing. Elastic Beanstalk kann den größten Teil der Bereitstellung, Konfiguration und laufenden Überwachung verwalten. Das erhöht allerdings die Komplexität weiter.
Amazon ECS-Probleme
Anwender stehen mit Amazon ECS vor einer ganzen Reihe von Herausforderungen – das Cluster-Management ist nur eine. Wenn Sie variable Workloads bewältigen müssen, kann insbesondere die Cluster-Skalierung problematisch sein. Da ECS diese Aufgabe nicht übernimmt, müssen Benutzer EC2-Instanzen in einer Auto-Scaling-Gruppe ausführen.
Auch Health Checks können Probleme verursachen. Der Service startet automatisch Aufgaben, bis er die konfigurierte Kapazität erreicht hat. Dienste, die fehlschlagen, werden erneut gestartet. Zur Bewältigung dieser Aufgabe muss sich der EC2-Cluster mit einem Load Balancer abstimmen.
Einige Anwendungen können allerdings einen Zustand erreichen, in dem ein Container startet, aber aufgrund einer fehlenden Abhängigkeit nicht ausgeführt werden kann. Dies kann zum Beispiel eine Datenbank sein, die nicht online ist. Da ECS versucht, einen Dienst immer wieder zu stoppen und neu zu starten, kann dieses Problem zu einer Endlosschleife innerhalb von ECS führen. Entwickler müssen daher die Health-Check-Parameter sorgfältig konfigurieren, um kaskadierende Neustarts zu vermeiden.
Auch wenn Sie das Container- und Instance Management entkoppeln, schließen die resultierenden Protokolldaten häufig den Kontext aus. Beispielsweise zeichnet das Protokoll nicht auf, dass ein Container infolge eines Host-Ausfalls und eines ECS-Neustarts neu gestartet wurde. Entwickler sind hier gefordert, um aussagekräftige Telemetrie in Anwendungsprotokollen bereitzustellen.
ECS verwendet ein Rolling-Deployment-Modell. Bei diesem läuft eine minimale Anzahl von Containern – standardmäßig 50 Prozent – weiter, während andere stoppen und sich mit neuem Code aktualisieren. Diese Technik eliminiert zwar Ausfallzeiten, es gibt aber eine Lücke, wenn zwei Versionen einer Anwendung oder eines Microservices gleichzeitig laufen. Dies könnte ein Problem für andere Anwendungen sein, wenn Sie APIs und I/O-Formate aktualisieren müssen.
Eine der wesentlichen technischen Errungenschaften von ECS ist seine Zustandsverwaltung (State Management) und seine Konsistenz über ein verteiltes System. Dies stellt sicher, dass gleichzeitige Änderungen an verschiedenen Containern im Cluster keine Konflikte verursachen. Das Feature kann zum Beispiel verhindern, dass vor einem vorherigen Festschreiben (Commit) in die gleiche Datenbank geschrieben wird. Dennoch kann das State-Management-System Probleme verursachen, wenn Container-Instanzen den Kontakt zur Management Engine verlieren.
Ein weiteres Problem von Amazon ECS besteht schließlich noch darin, dass es keinen vollständigen Anwendungs-Stack aufbaut. ECS benötigt andere Komponenten, um eine komplette containerisierte, servicebasierte Anwendung zu erstellen. Um Docker-Images zu speichern und zu verwalten, brauchen Entwickler analog der Amazon Elastic Container Registry eine Service-Registry.
Neueste ECS-Verbesserungen
Die Containerisierung ist nach wie vor einer der heißesten Bereiche im Cloud Computing. Kein Wunder also, dass sich die AWS Container-Services, einschließlich ECS, ständig weiterentwickeln. Zu den jüngsten Verbesserungen gehören:
- Cloud-natives Networking für ECS ermöglicht es Containern, elastische Netzwerkschnittstellen für EC2-Instanzen innerhalb einer Amazon Virtual Private Cloud (VPC) zu verwenden.
- Erweiterte Auto-Scaling-Fähigkeiten innerhalb von ECS. Verwenden Sie CloudWatch Alerts, um Skalierungsrichtlinien festzulegen, die neue Dienste in einem Container-Cluster auslösen. Diese Richtlinien gelten allerdings nur für die Container-Aufgaben, nicht für Cluster-Instanzen. Letztere müssen immer noch eine EC2 Auto-Scaling-Gruppe und einen Load Balancer verwenden, um mehr Kapazität zu erzeugen.
- ECS-Erkennung über das Domain Name System (DNS). Dieser Prozess verwendet einen Agenten in den Container-Instanzen, um Dienste für den DNS-Dienst Route 53 zu registrieren. Der Agent überwacht Docker-Ereignisse und registriert den Servicenamen und für jede Aufgabe die Metadaten – wie IP-Adresse und Ports – in einer privaten gehosteten Zone von Route 53. Mit ECS können Sie auch Agenten aktualisieren, die auf EC2-Cluster-Instanzen laufen und nicht mehr benötigte Task-Definitionen abmelden oder auf veraltete Revisionen verweisen.
- Verbesserungen an der ECS-Konsole. Zu diesen Verbesserungen gehören eine einfachere Erstkonfiguration und eine bessere Fehlerprotokollierung von Docker-Ereignissen. Diese enthalten nun auch die Start- und Stoppzeit von Tasks sowie eine kurze Beschreibung der Fehlerursache, zum Beispiel einen fehlgeschlagenen Elastic Load Balancing Health Check.
AWS hat auf der re:Invent auch Fargate eingeführt. Der Service soll den Einsatz und das Management von EC2-Clustern überflüssig machen. Fargate ähnelt dem neuen Azure Container Instance Service. Der Service nimmt ein Container-Image sowie die Anforderungen an die Bereitstellung von CPU-, Speicher-, Netzwerk- und Identity and Access Management (IAM)-Richtlinien und stellt automatisch Instances auf einem von AWS verwalteten Cluster bereit. Fargate unterstützt ECS Primitive und APIs und integriert sich in VPCs. Der Dienst unterstützt außerdem elastische Netzwerkschnittstellen, IAM, CloudWatch und Load Balancer.
Managed Kubernetes versus ECS
Auf der re:Invent 2017 hat AWS auch über den neuen Elastic Container Service for Kubernetes (EKS) den nativen Kubernetes-Support freigegeben. Dieser Service erspart den größten Teil der manuellen Arbeit, die für den Betrieb von Kubernetes auf einem EC2-Cluster erforderlich ist, zum Beispiel Deployment, Upgrades und Patches.
Kubernetes kümmert sich um die physische Bereitstellung und Skalierung von Server-Instanzen in einem Cluster, der als Pod bezeichnet wird. Dadurch entfällt bei EKS ein Großteil der zusätzlichen Arbeit, die mit der Verwendung von ECS verbunden ist. Dazu gehört auch die automatische Replikation von Kubernetes-Mastern über drei Verfügbarkeitszonen, was die Zuverlässigkeit erhöht. Außerdem basiert EKS auf Open-Source-Kubernetes, so dass Anwender Applikationen, die auf privaten Kubernetes-Clustern laufen, ohne Code-Änderung auf EKS migrieren können.
Das Release von EKS ist das stillschweigende Eingeständnis, dass Kubernetes der De-facto-Standard für das Container-Cluster-Management ist und das 2016 eingeführte AWS Blox überflüssig macht. AWS Blox ist daher praktisch von der AWS-Website verschwunden, abgesehen von einer Handvoll Referenzen, die sich noch darauf berufen.
Die Zukunft der AWS Container-Services
Die neuen Features und Services, die auf der re:Invent 2017 bekanntgegeben wurden, verändern die AWS Container-Roadmap erheblich. In Zukunft dürfte ECS nur eine untergeordnete Rolle spielen.
Neue Container-Anwender und erfahrene Entwickler, die die Größe und Kontrollmöglichkeiten von Kubernetes nicht benötigen, dürften Fargate ECS vorziehen. Vor allem, da Fargate viele Probleme beseitigt.
Erfahrene Container-Anwender, insbesondere solche, die eine massive Skalierbarkeit benötigen und Anwendungen in einer Microservices-Architektur einsetzen, werden sich wahrscheinlich für Amazon EKS interessieren. Der einfache Grund ist, dass es eine Orchestrierungs-Engine verwendet, die vielen Entwicklern vertraut ist.
EKS ermöglicht eine einfache Anwendungs- und Aufgabenmigration zwischen AWS und anderen Cloud- oder On-Premises-Infrastrukturen.
Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!
