我们部署了一个Docker镜像，该镜像运行一个简单的Sinatra API到ECS Fargate服务。现在，我们的任务定义使用:production标记来定义图像。我们希望使用CodeDeploy进行蓝色/绿色部署。
当代码更改时，我们应该推送一个带有:production标签的新映像，并在我们的服务上强制进行新部署，还是在我们的任务定义中使用特定标签(例如:97b9d390d869874c35c325632af0fc1c08e013cd(并创建一个新的任务修订，然后更新我们的服务以使用这个新的任务修正？
我们对第二种方法的担忧是，我们看不到任何关于任务修订的生命周期规则，所以它们会一直累积到我们有成千上万吗？
如果我们使用第一种方法，CodeDeploy是否能够在出现问题的情况下回滚失败的部署？
简短回答
在这两种情况下，如果您的新映像以某种方式崩溃，但您当前的旧任务应该仍然有效，则没有定义回滚。但是，如果您正在使用健康检查，并且当前运行的任务低于所需数量(可能是由于用户流量溢出等原因(，Fargate将使用包含坏图像的最新任务定义修订版启动新任务。
答案很长
由于您只是要求CodeDeploy根据您的映像启动任务，因此它将创建一个新的任务定义，该定义具有您的映像的URI来提取正确的映像。这个新的任务定义将始终用于启动新的Fargate任务。
因此，当Fargate发现它需要创建任务时，它总是会尝试使用最新的版本，而该版本总是图像不好的版本。
好的一面是，如果你的旧映像任务工作正常，它应该仍然有效，因为最小运行任务是1，而另一个任务连续失败，你的旧图像任务不会被停用。
但是，您可以通过添加CloudWatch事件来触发lambda来克服这一问题，该lambda可以使用良好的图像标记更新新的任务修订版，也可以使用以前的任务定义修订版运行当前的Fargate。以下是AWS的一篇文章：https://aws.amazon.com/blogs/compute/automating-rollback-of-failed-amazon-ecs-deployments/
更多关于Fargate部署如何在这里工作并帮助您的旧任务在新部署失败时运行的信息，它将首先提供新任务，当所有新任务运行良好时，它将解除旧任务的任务。所以，在新任务不能正常运行的情况下，旧任务应该仍然有效。