Anunciando a consistência de versão de software para os serviços do Amazon ECS

Por Olly Pomeroy, Developer Advocate na Amazon Web Services.

Introdução

As tags de imagem de containers oferecem uma maneira fácil de gerenciar e acompanhar diferentes versões de imagens de containers. No entanto, elas também apresentam um risco de segurança para as organizações devido à sua natureza mutável. Sem proteções, uma tag de imagem de container pode ser alterada em um repositório de imagens de containers para apontar para uma imagem de container diferente. Isso apresenta um cenário em que a imagem do container solicitada, quando uma carga de trabalho foi definida, pode não ser aquela usada quando uma carga de trabalho é executada.

Temos o prazer de anunciar um novo recurso para o Amazon Elastic Container Service (ECS): consistência da versão do software. O Amazon ECS agora resolverá uma tag de imagem de container para seu digest de imagem de container para cada versão (implantação) de um serviço Amazon ECS. Isso garante que a mesma imagem de container seja usada em todo o ciclo de vida da implantação e aumenta a segurança e a consistência de seus aplicativos implantados como serviços do Amazon ECS.

Contexto

Os serviços do Amazon ECS são um grupo de tarefas idênticas usadas para aplicativos de longa execução, geralmente cargas de trabalho da web e de API. O Amazon ECS garante que as tarefas dentro de um serviço sejam as mesmas vinculando uma versão de um serviço a uma revisão de definição de tarefa, chamada de implantação de serviço do Amazon ECS. No entanto, quando uma tag de imagem de container é usada em uma revisão de definição de tarefa, ela pode quebrar essa consistência.

As imagens de containers são imutáveis. Depois que a imagem do container é criada, é criado um digest da imagem do container (um digest sha256). Esse digest de imagem fornece a informação autoritativa sobre os metadados dessa imagem de container, pois ela é criada a partir de uma soma de verificação do conteúdo da imagem do container. No entanto, as imagens de containers nem sempre são mencionadas por seu digest. Em vez disso, eles são mais comumente referenciadas por uma tag.

Uma tag de imagem de container não é imutável, e uma tag de imagem de container pode ser alterada. Em um momento, uma tag pode se referir a um digest da imagem do container e, posteriormente, ser atualizada para apontar para um novo digest da imagem do container. Isso é mais comum no uso de uma tag de imagem de container “latest”. É comum encontrar projetos usando uma tag de imagem de container chamada “latest” e movê-la regularmente para uma nova imagem de container toda vez que há uma nova versão do software. Registros OCI podem implementar recursos para evitar que uma tag de imagem de container seja alterada, como a imutabilidade da tag do Amazon ECR. No entanto, o uso de “latest” ainda é amplamente adotado.

Consistência da versão de software para Amazon ECS

A partir de 11/07/2024, os serviços do Amazon ECS que usam o controlador de implantação do Amazon ECS usarão o mesmo digest da imagem do container durante todo o ciclo de vida de uma implantação, mesmo que a revisão da definição de tarefa se refira às tags de imagem do container. Nós reforçamos isso, capturando o(s) digest(s) da imagem da primeira tarefa em execução de uma implantação, uma vez que as tags tenham sido resolvidas pelo runtime do container. Em seguida, usamos esses digests de imagens em todo o ciclo de vida da implantação para todas as tarefas adicionais.

O comportamento anterior do Amazon ECS era que cada runtime do container resolvesse a tag de imagem para um digest de forma independente. Portanto, se uma implantação específica aumentasse e diminuísse com frequência e uma tag de imagem de container fosse atualizada para apontar para um novo digest de imagem de container, poderiam haver versões diferentes de uma imagem de container em execução na mesma implantação do serviço Amazon ECS.

Para todas as novas implantações de um serviço do Amazon ECS, seja por meio da criação de um novo serviço ou da atualização de um serviço existente, uma tag de imagem de container agora é convertida e armazenada como um digest da imagem de container após a implantação da primeira tarefa. Um passo a passo da nova ordem de implantação dos serviços do Amazon ECS é o seguinte:

Amazon ECS Service

Serviço Amazon ECS

Um novo serviço no Amazon ECS é criado ou atualizado.
O Amazon ECS primeiro agenda uma tarefa, independentemente da contagem desejada do serviço
Depois que essa tarefa estiver em execução, o digest da imagem do container de todos os containers da tarefa é capturado e reportado ao Amazon ECS.
As tarefas subsequentes dessa implantação são então agendadas com o digest da imagem do container, em vez da tag da imagem do container. Isso garante que as tarefas dessa implantação usem a mesma imagem de container.

Observação: se uma definição de tarefa não usar tags de imagem de container e, em vez disso, se referir a cada imagem de container pelo seu digest, essa nova ordem de implantação não será seguida. O comportamento anterior do ECS, de agendar todas as tarefas ao mesmo tempo é utilizado.

Passo a passo

O recurso de consistência da versão de software dos serviços do Amazon ECS pode ser mostrado criando uma nova implantação de um serviço existente. O guia de conceitos básicos do Amazon ECS pode ajudá-lo a criar seu primeiro serviço, caso você não tenha um. Assim que tiver um serviço em execução, você pode iniciar uma nova implantação de serviço com o comando aws ecs update-service.

$ aws ecs update-service --cluster $CLUSTER --service $SERVICE --force-new-deployment

Depois que uma nova implantação for criada, você poderá verificar se as tags de imagem do container foram resolvidas, inspecionando as tarefas em execução com a chamada da API DescribeTask. Primeiro, vamos obter uma lista das tarefas em execução para um serviço:

$ TASK_ARNS=$(aws ecs list-tasks --cluster $CLUSTER --service $SERVICE --query 'taskArns[]' --output text)

Em seguida, ao descrever as tarefas e usar o parâmetro --query para analisar a saída, você verá que, para uma tarefa, as tags da imagem do container foram usadas e, em seguida, para todas as tarefas adicionais, o digest da imagem do container foi utilizado.

$ aws ecs describe-tasks --tasks $TASK_ARNS --query 'tasks[*].{taskArn:taskArn,containerName:containers[0].name,containerImage:containers[0].image}'
[
    {
        "taskArn": "arn:aws:ecs:eu-west-1:111222333444:task/default/279034d4f56b40239e72881c19acc58f",
        "containerName": "containerone",
        "containerImage": "public.ecr.aws/docker/library/nginx@sha256:ac96a05e4b3dd2c57c9ca2637012f4fa17b11d5fdd2ce856c2f937bd843f0440"
    },
    {
        "taskArn": "arn:aws:ecs:eu-west-1:111222333444:task/default/e1174f0425ab435fb5abb1a661e6fd9c",
        "containerName": "containerone",
        "containerImage": "public.ecr.aws/docker/library/nginx@sha256:ac96a05e4b3dd2c57c9ca2637012f4fa17b11d5fdd2ce856c2f937bd843f0440"
    },
    {
        "taskArn": "arn:aws:ecs:eu-west-1:111222333444:task/default/199bd6a195f645a7ab1b503e3598e5c4",
        "containerName": "containerone",
        "containerImage": "public.ecr.aws/docker/library/nginx:stable"
    }
]

Você também pode inspecionar os eventos de uma implantação usando a chamada da API DescribeService. Nessa saída, você pode ver o novo padrão de implantação, que começa iniciando uma tarefa para obter o digest da imagem do containers e, em seguida, as tarefas subsequentes são iniciadas. Observe que os eventos mais antigos são exibidos por último.

$ aws ecs describe-services --cluster $CLUSTER --services $SERVICE --query 'services[0].events'
[
    {
        "id": "bf43bbc6-ad78-4316-9a8c-6b561a0c035a",
        "createdAt": "2024-06-07T14:22:31.089000+00:00",
        "message": "(service fargate-service-demo) has reached a steady state."
    },
    {
        "id": "4c3f3830-6291-47e0-a0d6-ee19f43076f8",
        "createdAt": "2024-06-07T14:22:31.088000+00:00",
        "message": "(service fargate-service-demo) (deployment ecs-svc/4506290861204002986) deployment completed."
    },
    {
        "id": "350e8c3c-890e-428c-846f-f900d964f234",
        "createdAt": "2024-06-07T14:22:13.171000+00:00",
        "message": "(service fargate-service-demo) registered 2 targets in (target-group arn:aws:elasticloadbalancing:us-west-2:111222333444:targetgroup/defaulttgtss/74939c377ec7273a)"
    },
    {
        "id": "985ce76c-ade8-4103-9569-82dca19f95af",
        "createdAt": "2024-06-07T14:21:24.685000+00:00",
        "message": "(service fargate-service-demo) has started 2 tasks: (task 569abf2a0c1f4694882c643194278919)."
    },
    {
        "id": "290cdfd3-513a-4477-83d9-690352865bc6",
        "createdAt": "2024-06-07T14:21:18.138000+00:00",
        "message": "(service fargate-service-demo) registered 1 targets in (target-group arn:aws:elasticloadbalancing:us-west-2:111222333444:targetgroup/defaulttgtss/74939c377ec7273a)"
    },
    {
        "id": "63bfc91d-8ad6-4764-9c35-149fdfa668e9",
        "createdAt": "2024-06-07T14:20:33.898000+00:00",
        "message": "(service fargate-service-demo) has started 1 tasks: (task 08738ec750d84695ae2e12800d7a31df)."
    }
]

Existem alguns cenários em que uma tag de imagem de container não é resolvida para um digest de imagem de container, como serviços que usam o CodeDeploy ou controlador externo de implantação. Para obter uma lista completa de exceções, consulte a documentação do Amazon ECS.

Conclusão

Com o lançamento da consistência da versão do software, os usuários agora podem garantir que todas as tarefas executadas como parte de um serviço do Amazon ECS utilizem a mesma imagem de container imutável. Essa melhoria aumenta significativamente a confiabilidade e a segurança dos aplicativos em containers executados no Amazon ECS. Ao eliminar o risco de as tarefas usarem involuntariamente diferentes versões de imagem de container, os desenvolvedores podem ter mais confiança na consistência e previsibilidade de suas cargas de trabalho. Para saber mais sobre como usar esse recurso e outros recursos do Amazon ECS, consulte a documentação do Amazon ECS. Também incentivamos você a compartilhar seus comentários e sugestões no roteiro público dos serviços de containers da AWS.

Este blog é uma tradução do blog original em inglês (link aqui).

Autores

	Olly Pomeroy é Developer Advocate na Amazon Web Services. Ele faz parte da equipe de containers, trabalhando com AWS Fargate e em projetos relacionados como container runtimes e containerd.

Tradutores

Marcelo Moras é Arquiteto de Soluções na AWS atendendo clientes Enterprise com foco em mercado financeiro. Com mais de 15 anos de experiência atuando com infraestrutura, administração de sistemas, redes, containers e segurança.

Daniel Abib é Senior Solution Architect na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem.

https://www.linkedin.com/in/danielabib/

O blog da AWS