无负载均衡器下，如何通过ECS+Fargate+CodeDeploy部署Worker容器？

一、拆分ECS服务为独立Web和Sidekiq服务 #

直接将原单服务拆分为两个独立ECS服务，分别对应Ruby/Rails Web应用和Sidekiq任务：

• 为两者创建单独的任务定义：Web任务保留端口配置与NLB关联，Sidekiq任务无需端口映射。
• 两个服务可独立设置扩容策略（比如Web根据CPU使用率/请求量扩容，Sidekiq根据Redis队列长度扩容），完全满足独立扩容需求。

二、解决Sidekiq的健康检查问题（无需负载均衡） #

ECS支持容器级健康检查，这才是Worker容器的标准配置，不需要依赖NLB：

1. 在Sidekiq任务定义的容器配置中添加健康检查：
   • 使用官方推荐的sidekiqctl ping命令验证进程状态，配置示例：

     "healthCheck": {
       "command": ["CMD-SHELL", "bundle exec sidekiqctl ping /tmp/sidekiq.pid"],
       "interval": 30,
       "timeout": 5,
       "retries": 3,
       "startPeriod": 60
     }
     

   • 注意：确保Sidekiq启动时生成对应路径的pid文件，可根据实际部署调整文件路径。
2. 取消Sidekiq服务与NLB的关联：Worker服务不需要暴露端口到负载均衡，直接移除服务的负载均衡配置即可。

三、用CodeDeploy部署两个独立ECS服务 #

基于你已有的CodePipeline，可通过两种方式实现部署：

方式1：单Pipeline同时部署两个服务 #

在CodeDeploy部署阶段配置两个ECS部署组：

• Web服务继续使用蓝绿部署，依赖NLB完成流量切换。
• Sidekiq服务使用滚动部署：部署类型选滚动更新，设置合理的替换节奏（比如每次替换1个容器，等待30秒再继续），Worker容器不需要流量切换，直接逐步替换即可。

方式2：独立Pipeline分别部署 #

为Web和Sidekiq各建一条CodePipeline：

• 可设置触发条件为代码仓库对应目录的变更（比如Web代码在/web目录，Sidekiq在/worker目录），实现精细化部署触发。
• Sidekiq的Pipeline中，CodeDeploy阶段仅配置自身服务的滚动部署，无需负载均衡相关设置。

四、Sidekiq的其他部署替代方案 #

如果上述方案不匹配需求，还可考虑：

• ECS Fargate Spot实例：降低Sidekiq Worker的运行成本，适合非核心任务队列。
• 自定义健康检查脚本：若sidekiqctl ping不适用，可编写脚本检查Redis连接或队列状态，比如：

  bundle exec redis-cli PING | grep PONG
  

• AWS Batch：若Sidekiq任务以一次性批处理为主，可迁移到AWS Batch，无需长期运行Worker服务，更适配批处理场景。

内容的提问来源于stack exchange，提问作者Fransurbo