用于创建ECS服务的Cloudformation模板卡在CREATE_IN_PROGRESS中

Question

我正在使用Cloudformation创建AWS ECS服务.

一切似乎都成功完成,我可以看到实例被附加到负载均衡器,负载均衡器正在声明实例是健康的,如果我点击负载均衡器,我成功地被带到了我的运行容器.

看看ECS控制面板,我可以看到服务已经稳定,一切看起来还不错.我还可以看到容器是稳定的,并且没有被终止/重新创建.

但是,Cloudformation模板永远不会完成,它会在CREATE_IN_PROGRESS大约30-60分钟之后停留,当它回滚时声称服务没有稳定.看看CloudTrail,我可以看到一些RegisterInstancesWithLoadBalancer实例化的ecs-service-scheduler,都具有相同的参数,即相同的实例ID和负载均衡器.我正在使用ECS的标准IAM角色和权限,因此它不应该是权限问题.

有人有类似的问题吗？

Answer 1

您AWS::ECS::Service需要注册完整的ARN TaskDefinition(来源:请参阅AWS论坛上ChrisB @ 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:]

Answer 2

无需为TaskDefinition注册完整的ARN,因为将此资源的逻辑ID提供给Ref内部函数,Ref返回Amazon资源名称(ARN).

在以下示例中,Ref函数返回MyTaskDefinition任务的ARN,例如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

Answer 3

我发现了另一个相关的情况，可能会导致这种情况，并认为我会将其放在此处，以防其他任何人碰到它。如果您TaskDefinition使用图像中实际上不存在的Image 定义了一个图像，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尝试启动DesiredCount2个实例中的一个时，它挂起了，因为该图像实际上在存储库中不可用（因为该存储库实际上是在同一模板中创建的）。

因此，目前，解决方案是创建一个CloudFormation堆栈，其的a DesiredCount为0 Service，将适当的内容上传Image到存储库，然后更新CloudFormation堆栈以扩展服务。或者，拥有一个单独的模板来设置诸如存储库之类的核心基础架构，将构建上传到该资源，然后再运行一个单独的模板来设置Services自身。

希望对任何遇到此问题的人有所帮助！

Answer 4

我想我有类似的问题.尝试查看服务模板中的"DesiredCount"属性.我认为CloudFormation将指示创建/更新仍在进行中,直到服务达到群集中的"DesiredCount"数量.

Answer 5

任何阻止 ECS 服务定义达到所需计数的因素。一个示例是附加到实例所使用的角色的策略中缺少权限。检查实例 ECS 代理日志 ( /var/log/ecs/ecs-agent.log.timestamp )。

另一个例子：实例没有足够的可用内存来匹配请求的所需计数......事件将显示如下内容：

“...service myService 无法放置任务，因为没有容器实例满足其所有要求。最接近的匹配容器实例 123456789 没有足够的可用内存...”