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

【问题标题】：Cloudformation template for creating ECS service stuck in CREATE_IN_PROGRESS用于创建 ECS 服务的 Cloudformation 模板卡在 CREATE_IN_PROGRESS
【发布时间】：2015-12-20 01:26:00
【问题描述】：

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

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

查看 ECS 控制面板，我可以看到服务已稳定，一切正常。我还可以看到容器是稳定的，并且没有被终止/重新创建。

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

有人遇到过类似的问题吗？

【问题讨论】：

云的形成是什么失败了？你有任何失败的事件吗？你能复制粘贴云形成事件日志吗？
这通常意味着您的实例/任务没有正常启动。
@Mircea 是 ECS 服务创建失败，并显示服务无法稳定的消息。然而，在 ECS 控制面板中看到一条矛盾的消息，表明服务已稳定。
@tedder42 这就是我所怀疑的，但是，如果我禁用堆栈的回滚，我可以成功访问我的服务/容器/任务，所以它看起来确实能够出现。就实例而言，集群和实例已经启动，因为它们是在不同的模板中创建的。我还能够验证它们是否按预期工作。
似乎有其他人有同样的问题：forums.aws.amazon.com/thread.jspa?threadID=190250

标签： amazon-web-services amazon-cloudformation amazon-ecs

【解决方案1】：

您的AWS::ECS::Service 需要为TaskDefinition 注册完整的ARN（来源：See the answer from ChrisB@AWS on the AWS forums）。关键是使用完整的 ARN，包括修订 设置您的 TaskDefinition。如果您跳过修订版（以下示例中的: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"]]}
        }
    }
}

这是通过 aws cli 和 jq 获取最新版本的 MyTaskDefinition 的好方法：

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

【讨论】：

我的检索最新版本的命令：aws ecs list-task-definitions --family-prefix dev-device-settings --sort DESC | jq --raw-output .taskDefinitionArns[0] | tr ':' '\n' | tail -1
更简单的方法是使用!Ref 函数返回AWS::ECS::TaskDefinition 的ARN。像这样构建 ARN 非常复杂。看这个页面的返回值：docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/…

【解决方案2】：

我发现了另一个相关的情况会导致这种情况，并认为我会把它放在这里以防其他人遇到它。如果你定义一个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

这对我来说似乎都是明智的，但事实证明，在编写/部署时有两个问题导致它挂起。

DesiredCount 设置为 2，这意味着它实际上会尝试启动服务并运行它，而不仅仅是定义它。如果我将DesiredCount 设置为 0，就可以了。
MyECSTaskDefinition 中定义的Image 尚不存在。我将存储库作为此模板的一部分，但实际上我并没有向它推送任何内容。因此，当 MyECSServiceDefinition 尝试启动 2 个实例的 DesiredCount 时，它会挂起，因为存储库中实际上没有图像（因为存储库实际上只是在同一个模板中创建的）。

因此，目前，解决方案是为 Service 创建具有 0 的 DesiredCount 的 CloudFormation 堆栈，将适当的 Image 上传到存储库，然后更新 CloudFormation 堆栈以扩展服务。或者，有一个单独的模板来设置核心基础架构（如存储库），将构建上传到那里，然后有一个单独的模板来运行以设置 Services 本身。

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

【讨论】：

此外，如果任务定义没有适当的ExecutionRole 权限，服务将在CREATING 状态下挂起。当我尝试创建 LogConfiguration 时发生了这种情况。
如果存储库中不存在图像标签也会发生，例如可能是错别字
"希望对遇到此问题的人有所帮助！"它确实做到了！非常感谢！
我把所有东西都放在一个堆栈中，将DesiredCount 设置为 0 固定 ECS::Service CREATE_IN_PROGRESS 需要很长时间然后构建 feil，谢谢 :)
如果您只想拥有一个不需要更新的脚本，另一种方法是利用 CloudFormation 挂起的长时间（它实际上是在重试并重试查找图像时）挂起）。这为手动将图像上传到 ECR 提供了充足的时间，然后 CloudFormation 会在上传后立即找到它。

【解决方案3】：

无需为 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

【讨论】：

效果很好......只要任务定义在同一个堆栈中。否则，Fn::ImportValue 是跨堆栈执行此操作的好方法。 docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/…

【解决方案4】：

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

【讨论】：

服务在 ECS UI 中报告为稳定，期望计数和运行计数均设置为 1。命中容器也按预期工作，ELB 正确报告实例.就像通知没有通过 Cloudformation

【解决方案5】：

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

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

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

【讨论】：

【解决方案6】：

要添加另一个数据点，我已经看到 AWS::ECS::Service 永久卡在 CREATE_IN_PROGRESS 中，如果 ECR 泊坞窗图像不是 a) 可从 ECR repo 和 b) 通过健康检查。

我已尝试多次使用 valid-image-hash-but-failing-health-check 容器启动 AWS::ECS::Service，然后修复映像并执行各种“将所需计数设置为零”、“设置它回来了”，等等，没有任何 AFAICT 让它解开。

我最终必须删除堆栈，并从立即通过健康检查的图像重新开始。然后就可以正常使用了。

超级变态。

【讨论】：

【解决方案7】：

我遇到了同样的问题。我通过增加为任务定义分配的内存大小来解决问题。

您正在运行的容器不得超过您的 ECS 实例上的可用内存。

【讨论】：

【解决方案8】：

为了增加另一种可能性，我曾经遇到过这个问题，模板一切正常，所需任务计数 = 正在运行的任务数等。结果发现其中一个底层 EC2 实例卡在 100% CPU 附近状态（但 EC2 将其视为“健康”）。它阻止了 CloudFormation 验证该特定实例。我杀死了坏的 EC2 实例，ECS 启动了一个真正健康的实例。

【讨论】：