Pulumi踩坑记录：自动化部署 | 看完就会搭

Pulumi踩坑记录：自动化部署 | 看完就会搭
我上周刚用Pulumi部署了一个微服务，结果半夜CI/CD报错说资源状态不一致，查了三个小时才发现是声明式配置没同步。别傻乎乎地以为配置文件改了就万事大吉，Pulumi的state文件和代码里声明的资源必须完全匹配，否则它会说“我不会动你”，但实际资源已经变了。你得养成每次更新前先用`pulumi preview`看下变化，别等报错才慌。

我之前用Pulumi写了个AWS资源模板，结果部署完发现VPC子网的CIDR冲突了。Pulumi默认不会检查CIDR是否重叠，它只会按你写的配置创建。你得自己算好IP段，或者用`aws ec2 describe-subnets`查下已有的子网，避免踩雷。别想着靠Pulumi自动处理这些，它不负责你写的IP是否合法。

有一次我用Pulumi写了个Kubernetes部署，结果发现Helm模板里的变量没传，导致Deployment一直失败。Pulumi的变量绑定不像Terraform那样严格，你得手动检查每个资源的参数是否都从配置文件里取了值。尤其是Secrets这种敏感信息，别写死在代码里，用`config`加载，别用环境变量。

我之前在Pulumi里写了多个资源，结果因为忘记加`dependsOn`，导致ECS任务和日志组的顺序不对，任务启动不了。Pulumi的依赖管理不像Kubernetes那么直观，你得自己搞清楚哪些资源必须先创建。ECS任务必须等日志组创建完成才能运行，否则会报找不到日志组的错误。别以为它能自动推断，有时候你得自己写依赖关系。

有一次我用Pulumi部署了多个模块，结果因为模块间的参数传递写错了，导致整个架构崩掉。Pulumi的模块参数是按名字匹配的，你得确保每个参数名在调用时都正确无误。如果模块里有一个参数叫`vpcId`，你在调用的时候也必须用`vpcId`，不能写成`vpc`或者其他。别想着用默认值糊过去，这部分容易出错，得仔细核对。

我之前用Pulumi写了个混合云架构，结果发现本地的state文件和AWS的state不一致。Pulumi的state管理有点坑，你得指定好state后端，比如用S3存储，否则本地改动会覆盖云端。你得在`Pulumi.yaml`里设好`state`字段，别等部署后才发现资源状态混乱。别用本地state，尤其是在团队协作中，state文件就是你的责任。