CloudFormation yaml

本文介绍了CloudFormation yaml-如何强制输入数字类型?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我正在尝试创建ECS任务定义作为CloudFormation堆栈的一部分.

I'm trying to create an ECS task definition as part of a CloudFormation stack.

到目前为止，我的任务定义是这样的...

My task definition so far looks like this...

TaskDefinition: Type: AWS::ECS::TaskDefinition Properties: RequiresCompatibilities: - EC2 ExecutionRoleArn: !Ref MyTaskRole ContainerDefinitions: - Name: !Ref ServiceName Image: amazon/amazon-ecs-sample PortMappings: - ContainerPort: 3000 HostPort: 0 Protocol: tcp MemoryReservation: 128

当我尝试运行此命令时，出现以下错误...

When I try to run this, I get the following error...

#/ContainerDefinitions/0/MemoryReservation: expected type: Number, found: String

因此，看来CloudFormation会将128转换为字符串，然后堆栈失败.

So it seems that CloudFormation is converting 128 to a string, and then the stack fails.

定义此值以使其保持数字的正确方法是什么?

What is the correct way to define this value so that it remains a number?

推荐答案

事实证明，CloudFormation报告的错误实际上与故障无关.上面的代码非常好.

It turned out that the error that was being reported by CloudFormation actually wasn't anything to do with the failure. The code above was perfectly fine.

就我而言，问题在于我定义了日志记录部分的方式，该部分随后出现在模板中.

In my case the problem was with the way I'd defined the logging section which appeared later in the template.

由此得出的结论是，CloudFormation调试起来非常混乱，如果您收到这样的错误，请不要认为这实际上是导致堆栈失败的原因.

The takeaway from this, is that CloudFormation is very confusing to debug, and if you receive an error like this, don't assume it is what's actually causing the stack to fail.

要找到实际的问题，我必须首先删除导致类型转换错误的属性MemoryReservation和PortMappings，然后显示关于定义日志记录部分的方式的错误.修复该错误后，我能够重新添加其他属性，并且工作正常.

To find the actual problem, I had to first remove the properties which were causing the type conversion error, MemoryReservation and PortMappings, and then it showed an error about the way I'd defined my logging section. After fixing that fault, I was able to re-add the other properties, and it worked fine.

我现在怀疑，因为我的日志记录部分不正确，因此可能没有正确解析整个ContainerDefinitions，从而可能导致误导类型不匹配错误.

I suspect now that because my logging section was incorrect, the whole ContainerDefinitions perhaps wasn't being parsed correctly, potentially causing the misleading type mismatch error.