北京
大多数ECS蓝绿部署教程最终都指向同一套技术栈：AWS CodeDeploy、部署组、AppSpec文件、生命周期钩子、加权流量转移、复杂的回滚编排。CodeDeploy确实能用，但我在实际部署中反复遇到一个现实限制——无法让内部团队在正式生产URL上验证新版本，就直接向客户开放。
这成了整个方案的设计动机。我不想要：独立的预发域名、重复的ALB、临时预览环境、"接近生产"的测试。我想要更简单的东西：内部用户先看新版本，客户继续看稳定版本，两者共用同一生产域名，回滚即时，部署保持完全零停机。
于是我构建了一套Terraform驱动的部署工作流，使用ECS Fargate、应用型负载均衡器（ALB）、ALB监听器优先级、源IP路由和Terraform本身，完全不用CodeDeploy。实际运行后，这套方案成了我许多ECS工作负载的首选。
核心思路很直接：BLUE和GREEN环境跑在同一ALB后面。内部办公网/VPN的IP先路由到GREEN，其他人继续访问BLUE。这意味着QA和内部团队可以在真实生产基础设施上直接验证新版本，再开始公开推广。域名、SSL证书、ALB、认证流程、重定向、网络路径，全部相同。不会出现"预发环境没问题，一上生产就崩"的意外。
很多部署问题只在真实的生产路由路径上才会暴露。举个例子：内部用户打开https://nginx.jayakrishnayadav.cloud，立刻看到GREEN版本；同时，公网用户继续看到BLUE。没有DNS切换，没有重复基础设施，只靠ALB监听器路由。
架构流程是这样的：请求先到应用型负载均衡器，然后分流——内部办公/VPN IP走GREEN目标组，公网用户走BLUE目标组，分别对应ECS GREEN任务和ECS BLUE任务。金丝雀路由规则优先评估，如果请求源IP匹配内部CIDR段，流量进GREEN，其余回落到BLUE。
我把Terraform结构做成模块化，方便跨服务复用。根目录下有main.tf、variables.tf、outputs.tf，env目录放backend.hcl和terraform.tfvars，modules目录包含vpc、iam、alb、ecs-cluster、ecs-blue-green-service等模块，还有scripts目录放zero-downtime-test.sh脚本。
每个ECS服务配套：BLUE ECS服务、GREEN ECS服务、BLUE目标组、GREEN目标组、生产监听器规则、可选的金丝雀监听器规则。整个部署行为取决于ALB监听器优先级，金丝雀规则优先评估，源IP匹配内部CIDR就进GREEN。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
