Назад | Перейти на главную страницу

AWS ECS: сервис + автоматическое масштабирование против задачи запуска пользовательских данных

Пытаюсь осмыслить ECS, используя запуск EC2 (не Fargate, по крайней мере, пока).

Предположим, что есть одна длительная задача, которую я хочу запускать с каждым экземпляром контейнера. Предполагаемым механизмом для этого является служба, которая запускает столько экземпляров задач, сколько я настраиваю - в этом случае я начинаю с того же количества задач, что и экземпляры контейнеров.

Похоже, что автомасштабирование существует на двух уровнях: кластер может автоматически масштабировать свои экземпляры, а Служба может автоматически масштабировать количество задач. Кажется, нет никакого способа синхронизировать эти два слоя без Fargate.

Один из подходов, которые я придумал для обхода этого ограничения, заключается в том, чтобы масштабирование запускалось сигналом CloudWatch на кластер, а затем используйте крючок жизненного цикла для создания экземпляра, чтобы запустить масштабирование Службы. Я до сих пор не понял, как это будет работать для масштабирования - есть ли какое-нибудь автоматически сгенерированное событие для масштабирования службы?

затем

Я видел руководство AWS по запуску задачи при запуске контейнера. Суть вопроса, казалось бы, заключалась в данных пользователя 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==--

Хотя в начале статьи есть отказ от ответственности, я понял, что это означает, что этот метод использования awscli запуск Задачи снимет все опасения.

Я что-то пропустил? Является ли это жизнеспособной альтернативой Сервису с автомасштабированием?

После обсуждения этого вопроса с парнем из службы поддержки AWS это кажется довольно хорошим решением моей проблемы.

Чтобы настроить это, мне нужно было создать группу автомасштабирования, используя конфигурацию запуска, в основе которой был AMI, оптимизированный для Amazon ECS, и назначить ей роль с разрешениями ECS. Затем я смог включить пользовательские данные, как показано. Когда все было настроено правильно (и у экземпляров был общедоступный доступ в Интернет), экземпляры регистрировались в моем кластере ECS при запуске, и они выполняли мою задачу.

Это НЕ было бы хорошим решением для контейнера, который живет независимо от задач, которые вы хотите запустить, или для задачи, которая может быть перезапущена в случае сбоя без перезапуска всего контейнера.