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

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для запуска задачи снимет все опасения.

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

решение1

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

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

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

Связанный контент