我发现了另一个相关的情况会导致这种情况,并认为我会把它放在这里以防其他人遇到它。如果您TaskDefinition
使用实际上不存在于其中的图像定义 a,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
这一切对我来说似乎都是明智的,但事实证明,在编写/部署时有两个问题导致它挂起。
- 设置为 2,这
DesiredCount
意味着它实际上会尝试启动服务并运行它,而不仅仅是定义它。如果我设置DesiredCount
为 0,这工作得很好。
Image
定义的 in还不MyECSTaskDefinition
存在。我将存储库作为此模板的一部分,但实际上我并没有向它推送任何内容。因此,当MyECSServiceDefinition
尝试启动DesiredCount
2 个实例时,它挂起,因为该图像实际上在存储库中不可用(因为存储库实际上只是在同一个模板中创建的)。
因此,目前,解决方案是创建 CloudFormation 堆栈,其中 aDesiredCount
为 0 Service
,将相应的内容上传Image
到存储库,然后更新 CloudFormation 堆栈以扩展服务。或者,有一个单独的模板来设置像存储库这样的核心基础架构,将构建上传到那个,然后有一个单独的模板来运行来设置Services
它们自己。
希望对遇到此问题的人有所帮助!