☰

AWS ECS: tarefa de serviço + escalonamento automático vs lançamento de dados do usuário

tag-icon • tag-icon amazon-web-services autoscaling aws-cli amazon-ecs
AWS ECS: tarefa de serviço + escalonamento automático vs lançamento de dados do usuário

Tentando entender o ECS usando o lançamento do EC2 (não o Fargate, pelo menos por enquanto).

Suponha uma única tarefa de longa duração que desejo iniciar com cada instância de contêiner. O mecanismo pretendido para isso parece ser um Serviço, que iniciará tantas instâncias de tarefas quanto eu configurar - neste caso, começo com o mesmo número de tarefas que as instâncias de contêiner.

O dimensionamento automático parece existir aqui em duas camadas: o cluster pode dimensionar automaticamente suas instâncias e o serviço pode dimensionar automaticamente o número de tarefas. Não parece haver nenhuma maneira de sincronizar essas duas camadas sem o Fargate.

Uma abordagem que criei para contornar essa limitação é fazer com que o escalonamento horizontal seja acionado por um alarme do CloudWatch noconjuntoe, em seguida, use um gancho de ciclo de vida na criação da instância para acionar a expansão no Serviço. Ainda não descobri como isso funcionaria para ampliação - existe algum evento gerado automaticamente para redução de serviço?

então

Eu vium guia da AWS para iniciar uma tarefa na inicialização do contêiner. O cerne da questão parece ser estes dados do usuário MIME:

Content-Type: multipart/mixed; boundary="==BOUNDARY=="
MIME-Version: 1.0

--==BOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"

#!/bin/bash
# Specify the cluster that the container instance should register into cluster=your_cluster_name

# Write the cluster configuration variable to the ecs.config file
# (add any other configuration variables here also)
echo ECS_CLUSTER=$cluster >> /etc/ecs/ecs.config

# Install the AWS CLI and the jq JSON parser
yum install -y aws-cli jq

--==BOUNDARY==
Content-Type: text/upstart-job; charset="us-ascii"

#upstart-job
description "Amazon EC2 Container Service (start task on instance boot)"
author "Amazon Web Services"
start on started ecs

script
    exec 2>>/var/log/ecs/ecs-start-task.log
    set -x
    until curl -s http://localhost:51678/v1/metadata
    do
        sleep 1
    done

    # Grab the container instance ARN and AWS region from instance metadata
    instance_arn=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | 
.ContainerInstanceArn' | awk -F/ '{print $NF}' )
    cluster=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .Cluster' | awk -F/ '{print $NF}' )
    region=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .ContainerInstanceArn' | awk -F: '{print $4}')

    # Specify the task definition to run at launch
    task_definition=my_task_def

    # Run the AWS CLI start-task command to start your task on this container instance
    aws ecs start-task --cluster $cluster --task-definition $task_definition --container-instances $instance_arn --started-by $instance_arn --region $region
end script
--==BOUNDARY==--

Embora haja uma isenção de responsabilidade no início do artigo, entendi que isso significa que esse método de uso awsclipara executar uma tarefa atenuaria todas as preocupações.

Perdi algo? Esta é uma alternativa viável para um serviço com escalonamento automático?

Responder1

Depois de discutir isso com um suporte da AWS, esta parece ser uma solução muito boa para o meu problema.

Para configurar isso, precisei criar um grupo de escalonamento automático usando uma configuração de inicialização que tivesse como base uma AMI otimizada para Amazon ECS e atribuir a ele uma função que tivesse permissões de ECS. Então consegui incluir os dados do usuário conforme mostrado. Quando tudo estivesse configurado corretamente (e as instâncias tivessem acesso público à Internet), as instâncias se registrariam em meu cluster ECS na inicialização e executariam minha tarefa.

Esta NÃO seria uma boa solução para ter um contêiner que vive independentemente da(s) tarefa(s) que você deseja executar, ou para uma tarefa que pode ser reiniciada quando falha sem reiniciar todo o contêiner.

informação relacionada