我继承了一个小型CDK项目，该项目具有cdk.context.json文件：
{
"vpc-provider:account=9015xxxxxxxx:filter.tag:Name=preprod-eu-west-1:region=eu-west-1:returnAsymmetricSubnets=true": {
"vpcId": "vpc-0d891xxxxxxxxxxxx",
"vpcCidrBlock": "172.35.0.0/16",
"availabilityZones": [],
"subnetGroups": [
{
"name": "Private",
"type": "Private",
"subnets": [
{
"subnetId": "subnet-0ad04xxxxxxxxxxxx",
"cidr": "172.35.a.0/22",
"availabilityZone": "eu-west-1b",
"routeTableId": "rtb-0fee4xxxxxxxxxxxx"
},
{
"subnetId": "subnet-08598xxxxxxxxxxxx",
"cidr": "172.35.z.0/22",
"availabilityZone": "eu-west-1c",
"routeTableId": "rtb-0f477xxxxxxxxxxxx"
}
]
},
{
"name": "Public",
"type": "Public",
"subnets": [
{
"subnetId": "subnet-0fba3xxxxxxxxxxxx",
"cidr": "172.35.y.0/22",
"availabilityZone": "eu-west-1b",
"routeTableId": "rtb-02dfbxxxxxxxxxxxx"
},
{
"subnetId": "subnet-0a3b8xxxxxxxxxxxx",
"cidr": "172.35.x.0/22",
"availabilityZone": "eu-west-1c",
"routeTableId": "rtb-02dfbxxxxxxxxxxxx"
}
]
}
]
}
}
这对于它所连接的预印本环境来说很好，但我现在需要部署到生产环境中。我可以手动生成相同的文件，但这感觉像是在浪费时间——我怀疑这是一个生成的文件。
我尝试过cdk context --build，希望它能生成这个文件，但它似乎不是——它似乎只是为了呼应已经存在的预印本。我能做些什么来避免手工构建(并避免猜测它想要哪个VPC和子网(？
该文件是为CDK堆栈部署到的任何环境生成的。
如果您想用您的暂存环境和生产的值填充它，您只需在激活生产AWS凭据后运行cdk synth(例如，使用--profile(。这将用新的值(除了已经存在的值之外(填充上下文，并且您应该将这些更改提交给VCS。
建议将该文件专门保存在VCS中，以避免在每次部署时重新填充。这使您的CDK应用程序具有确定性。
最佳实践：
提交cdk.context.json以避免不确定性行为
AWS CDK包括一种称为上下文提供程序的机制，用于记录非确定性值的快照，从而允许未来的合成操作生成完全相同的模板。新模板中唯一的更改是您在代码中所做的更改。当您使用构造的.fromLookup((方法时，调用的结果会缓存在cdk.context.json中，您应该将其与其他代码一起提交给版本控制，以确保将来执行cdk应用程序时使用相同的值。
更好的组织方式是使您的堆栈特定于环境，也就是说，为每个要部署到的环境实例化一次顶级堆栈或阶段，并指定env道具。然后部署成为cdk deploy MyStaginStack和cdk deploy MyProductionStack。尽管这不是问题的主题。
此文件是根据部署自动生成的。您应该将此文件从代码回购中排除。
更新
一些人评论说，应该提交该文件以保持部署的确定性。我认为这取决于你的环境。
上下文文件会随着您为不同的帐户/环境进行合成而更新。我遇到了一个场景，部署不成功，因为查找从上下文中返回了不正确的值。项目中的安装程序没有在部署中使用配置文件的选项。不允许从CICD管道提交。因此，无论最佳实践如何建议，这实际上都是你在项目中工作的限制。我可以从我的私人沙箱帐户生成它，我不想为客户端帐户提交。