Container-Orchestrierung im Vergleich (2)

AWS hat mit Elastic Container Service (ECS) und Amazon Elastic Kubernetes Service (EKS) gleich zwei verwaltete Container-Cluster-Manager zum Betrieb cloudnativer Apps im Portfolio. Da ECS zwar der ältere, im Vergleich mit EKS aber besser mit dem AWS-Portfolio integrierte Cluster-Manager ist und wir Kubernetes in der Cloud bereits anhand von Google Kubernetes Engine gewürdigt haben, widmet sich dieser Beitrag dem Elastic Container Service.

Bei ECS handelt es sich um einen voll verwalteten Compute-Service für das hochverfügbare Betreiben von Anwendungscontainern über mehrere Availability Zones (AZ) innerhalb einer Region hinweg. Im Gegensatz zu Kubernetes wurde der Cluster-Manager von ECS von AWS selbst entwickelt. Anwender können einen ECS-Cluster wahlweise in einer neuen oder bestehenden Virtual Private Cloud (VPC) erstellen.

Danach können Sie auf Basis sogenannter Task-Definitionen wahlweise einfache Single-Tasks oder komplette Services definieren, wobei sowohl in Tasks als auch in Services festgelegt ist, welche Docker-Container-Images Grundlage des Cluster-Dienstes sind. Container-Images werden per Default in der Amazon-Container-Registry (ECR) abgelegt beziehungsweise daraus abgerufen. Die Registry kann sich aber bei Bedarf auch außerhalb der AWS-Infrastruktur (Custom Repo oder Docker Hub) befinden.

Tasks vs. Service bei ECS

Die atomare Deployment-Einheit in ECS ist ein Task. Tasks bestehen aus einem oder mehreren eng miteinander gekoppelten Containern, die jeweils explizit vom "ECS Task Scheduler" verwaltet, das heißt platziert, verschoben, gelöscht oder neu gestartet werden. Ein Task kann entweder genau einmal ablaufen oder in Intervallen. Der ECS Task Scheduler eignet sich optimal für Batch-Jobs und ist nicht für lang laufende Services gedacht.

Daneben stellt der ECS-Cluster-Manager mit dem "ECS Service Scheduler" einen zweiten Scheduler

Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.