Шаблон Cloudformation для создания сервиса ECS застрял в CREATE_IN_PROGRESS

Ваш AWS::ECS::Service должен зарегистрировать полный ARN для TaskDefinition (Источник: См. Ответ ChrisB @ AWS на форумы AWS). Главное - установить в TaskDefinition полный ARN, включая ревизию. Если вы пропустите ревизию (:123 в приведенном ниже примере), будет использоваться последняя ревизия, но CloudFormation по-прежнему выходит на обед с «CREATE_IN_PROGRESS» примерно на час, прежде чем потерпит неудачу. Вот один из способов сделать это:

"MyService": {
    "Type": "AWS::ECS::Service",
    "Properties": {
        "Cluster": { "Ref": "ECSClusterArn" },
        "DesiredCount": 1,
        "LoadBalancers": [
            {
                "ContainerName": "myContainer",
                "ContainerPort": "80",
                "LoadBalancerName": "MyELBName"
            }
        ],
        "Role": { "Ref": "EcsElbServiceRoleArn" },
        "TaskDefinition": {
            "Fn::Join": ["", ["arn:aws:ecs:", { "Ref": "AWS::Region" },
            ":", { "Ref": "AWS::AccountId" },
            ":task-definition/my-task-definition-name:123"]]}
        }
    }
}

Вот отличный способ получить последнюю версию MyTaskDefinition с помощью aws cli и jq:

aws ecs list-task-definitions --family-prefix MyTaskDefinition | jq --raw-output .taskDefinitionArns[0][-1:]

Я нашел другой связанный сценарий, который вызовет это, и подумал, что помещу его здесь, если кто-то еще столкнется с этим. Если вы определите TaskDefinition с изображением, которое на самом деле не существует в его ContainerDefinition, а затем попытаетесь запустить это TaskDefinition как службу, вы столкнетесь с той же проблемой зависания (или, по крайней мере, с чем-то похожим на ту же проблему) .

ПРИМЕЧАНИЕ: все приведенные ниже фрагменты YAML находятся в одном шаблоне CloudFormation.

Итак, в качестве примера я создал это Repository:

MyRepository:
    Type: AWS::ECR::Repository

А потом я создал это Cluster:

MyCluster:
    Type: AWS::ECS::Cluster

А это TaskDefinition (в сокращении):

MyECSTaskDefinition:
    Type: AWS::ECS::TaskDefinition
    Properties:
        # ...
        ContainerDefinitions:
            # ...
              Image: !Join ["", [!Ref "AWS::AccountId", ".dkr.ecr.", !Ref "AWS::Region", ".amazonaws.com/", !Ref MyRepository, ":1"]]
            # ...

Определив их, я создал Service вот так:

MyECSServiceDefinition:
    Type: AWS::ECS::Service
    Properties:
        Cluster: !Ref MyCluster
        DesiredCount: 2
        PlacementStrategies:
            - Type: spread
              Field: attribute:ecs.availability-zone
        TaskDefinition: !Ref MyECSTaskDefinition

Все это казалось мне разумным, но оказалось, что в этом написании / развертывании есть две проблемы, из-за которых он завис.

1. Для DesiredCount установлено значение 2, что означает, что он фактически попытается развернуть службу и запустить ее, а не просто определить ее. Если я установлю DesiredCount на 0, это будет работать нормально.
2. Image, определенный в MyECSTaskDefinition, еще не существует. Я сделал репозиторий как часть этого шаблона, но на самом деле я ничего в него не вставлял. Поэтому, когда MyECSServiceDefinition попытался развернуть DesiredCount из 2 экземпляров, он завис, потому что изображение на самом деле не было доступно в репозитории (потому что репозиторий буквально только что был создан в том же шаблоне).

Итак, на данный момент решение состоит в том, чтобы создать стек CloudFormation с DesiredCount = 0 для Service, загрузить соответствующий Image в репозиторий, а затем обновить стек CloudFormation для масштабирования службы. Или, как вариант, иметь отдельный шаблон, который настраивает основную инфраструктуру, такую ​​как репозиторий, загружать в него сборки, а затем иметь отдельный шаблон для запуска, который настраивает сами Services.

Надеюсь, что это поможет любому, у кого есть эта проблема!

Нет необходимости регистрировать полный ARN для TaskDefinition, потому что, когда логический идентификатор этого ресурса предоставляется встроенной функции Ref, Ref возвращает имя ресурса Amazon (ARN).

В следующем примере функция Ref возвращает ARN задачи MyTaskDefinition, например arn: aws: ecs: us-west-2: 123456789012: task / 1abf0f6d-a411-4033-b8eb-a4eed3ad252a.

{"Ref": "MyTaskDefinition"}

Источник http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-taskdefinition.html

Думаю, у меня была аналогичная проблема. Попробуйте посмотреть свойство «DesiredCount» в шаблоне службы. Я думаю, CloudFormation укажет, что создание / обновление все еще продолжается, пока Служба не достигнет этого числа «DesiredCount» в вашем кластере.

Все, что препятствует достижению определением службы ECS желаемого количества. В одном из примеров отсутствуют разрешения в политиках, связанных с ролью, используемой экземплярами. Проверьте журналы агента ECS экземпляров (/var/log/ecs/ecs-agent.log. timestamp).

Другой пример: у экземпляров недостаточно памяти для соответствия запрошенному желаемому количеству .... событий будет отображаться что-то вроде этого:

"... службе myService не удалось разместить задачу, потому что ни один экземпляр контейнера не отвечал всем ее требованиям. Ближайшему соответствующему экземпляру контейнера 123456789 недостаточно памяти ..."

Чтобы добавить еще одну точку данных, я видел, как AWS::ECS::Service постоянно застревает в CREATE_IN_PROGRESS, если образ докера ECR не одновременно а) доступен из репозитория ECR и б) проходит проверку работоспособности.

Я несколько раз пытался загрузить AWS::ECS::Service с контейнером valid-image-hash-but-failing-health-check, затем исправить образ и выполнить различные операции «установить желаемый счетчик на ноль», «вернуть его обратно» и т. Д. ., и ничто AFAICT не отключает его.

В конце концов мне придется удалить стек и начать с изображения, которое немедленно проходит проверку работоспособности. Тогда нормально работает.

Супер хлопья.

У меня такая же проблема. Я решил, увеличив объем выделенной памяти для определения задачи.

Контейнеры, которые вы используете, не должны превышать доступную память на вашем экземпляре ECS.

Чтобы добавить еще одну возможность, я столкнулся с этой проблемой один раз, когда все было в порядке с шаблоном, желаемое количество задач = количество запущенных задач и т. Д. Оказалось, что один из базовых экземпляров EC2 застрял около 100% состояния ЦП (но EC2 посчитал это «здоровым»). Это мешало CloudFormation проверить этот конкретный экземпляр. Я убил плохой экземпляр EC2, и ECS создала действительно здоровый.