ECS-kluster, uppgiftsdefinitioner och tjänster

Containrar paketerar en applikation och alla dess beroenden i en portabel, isolerad enhet som körs konsekvent i olika miljöer. Amazon ECS (Elastic Container Service) är AWS:s helt hanterade tjänst för containerorkestrering, som kör Docker-containrar utan att ni behöver hantera ett control plane. ECS har djupa integrationer med AWS-tjänster (IAM, ALB, CloudWatch och Secrets Manager) och är det rekommenderade sättet att köra containrar på AWS utan Kubernetes-komplexitet.

Ett ECS Cluster är en logisk gruppering av beräkningsresurser där era containrar körs. Ett kluster kan innehålla EC2-instanser (EC2 launch type), Fargate-kapacitet (Fargate launch type) eller båda. Ni kan ha flera tjänster och fristående tasks i ett kluster. Kluster är regionala men sträcker sig över flera Availability Zones. Ett vanligt mönster är ett kluster per miljö (dev/staging/prod) med flera tjänster i varje kluster för olika mikrotjänster.

En Task Definition är ritningen för att köra containrar i ECS – jämförbar med en Docker Compose-fil. Den anger: container images (ECR-URI:er eller Docker Hub), tilldelningar av CPU och minne, port mappings, environment variables, logging configuration, volumes och IAM task role. En task definition är versionshanterad – varje revision är oföränderlig. Ni kan definiera flera containrar per task för sidecar-mönster (huvudapplikation + loggsändare + övervakningsagent).

ECS-tasks använder två separata IAM-roller med olika syften. Task Execution Role används av ECS-agenten för att hämta container images från ECR, skicka loggar till CloudWatch och hämta secrets från Secrets Manager eller Parameter Store när tasken startas. Task Role används av programkoden som körs i containern för att anropa AWS-tjänster (S3, DynamoDB och SQS). Tilldela alltid minsta möjliga behörighet separat till varje roll – ge aldrig execution role behörigheter som applikationen inte behöver.

En ECS Service upprätthåller ett angivet antal task-instanser som körs samtidigt (det desired count). Om en task misslyckas eller stoppas startar tjänstens schemaläggare automatiskt en ersättare. Tjänster integreras även med Elastic Load Balancing för trafikfördelning och stöder rolling deployments samt blue/green deployments. Använd en tjänst för alla långvariga processer (webbserver, API-server och bakgrundsarbetare). För engångsjobb ska ni i stället köra en fristående task.

Nätverksläget awsvpc ger varje ECS-task ett eget Elastic Network Interface (ENI) och en privat IP-adress i ert VPC – precis som en EC2-instans. Detta möjliggör detaljerad styrning av security groups per task och krävs för Fargate-tasks. Nätverksläget bridge använder Dockers inbyggda virtuella nätverk på värden, med portmappning från värd till container – det delar den värdbaserade EC2-instansens ENI. För SAA-C03-provet gäller att Fargate alltid använder awsvpc, medan EC2 launch type kan använda vilket som.

Registrera er ECS-tjänst med en ALB target group för att fördela trafik mellan task-instanser. När en ny task startar registrerar ECS den automatiskt i target group; när den stoppas avregistrerar ECS den. Konfigurera en health check grace period (till exempel 60–120 sekunder) så att containrarna hinner starta innan hälsokontrollerna körs. Utan en sådan respitperiod kan ALB markera en långsamt startande container som ej frisk innan den är redo, vilket orsakar ersättningsloopar.

ECS-tjänster stöder två distributionsstrategier: Rolling Update ersätter gradvis gamla tasks med nya – konfigurerbart med minimumHealthyPercent (golv) och maximumPercent (tak). Inställningen 100/200 innebär att gamla tasks körs medan nya startas (100 % frisk kapacitet krävs, upp till 200 % kapacitet tillåts). En Blue/Green deployment (via AWS CodeDeploy) skapar en ny task set parallellt med den gamla, flyttar gradvis trafiken med viktad routning i ALB och avslutar gamla tasks efter validering. Blue/green har möjlighet till rollback utan driftstopp.

Konfigurera loggdrivrutinen awslogs i er task definition för att skicka containerns stdout/stderr direkt till CloudWatch Logs. Ange en log group, region och stream prefix. Task execution role behöver behörigheterna logs:CreateLogStream och logs:PutLogEvents. För centraliserad loggaggregering från flera tjänster kan ni överväga FireLens (en sidecar-container med Fluent Bit eller Fluentd) för att dirigera loggar till S3, OpenSearch eller loggningssystem från tredje part.

När mikrotjänster i ECS behöver kommunicera med varandra fungerar hårdkodade IP-adresser inte, eftersom tasks är kortlivade och får nya IP-adresser vid varje start. Använd AWS Cloud Map (ECS Service Discovery) för att registrera varje tasks IP-adress och port i ett DNS-namespace. Andra tjänster slår upp myservice.namespace.local för att hitta de aktuella IP-adresserna till friska tasks. ECS registrerar automatiskt nya tasks och avregistrerar sådana som har misslyckats, så att DNS-posterna hålls korrekta utan manuell hantering.

Hårdkoda aldrig autentiseringsuppgifter i task definitions. Referera i stället till secrets i Secrets Manager eller Parameter Store i er task definition – ECS injicerar dem som miljövariabler när tasken startar. Task execution role måste ha behörighet att hämta secrets. För Secrets Manager använder ni secretsmanager:GetSecretValue och för Parameter Store ssm:GetParameters. Secrets hämtas en gång när containern startar; rotering av secrets kräver att tasken ersätts för att de nya värdena ska hämtas.

I den här lektionen lärde ni er följande: ECS Clusters grupperar beräkningsresurser där tasks körs, Task Definitions definierar container images, CPU/minne, roller och loggning som versionshanterade ritningar, och ECS Services upprätthåller önskat antal tasks, integreras med ALB för trafikfördelning och stöder rolling eller blue/green deployments. Nästa ämne är en jämförelse mellan EC2 launch type och den serverlösa Fargate launch type.