当弹性负载均衡器（ELB）与自动缩放组关联时，可以指定宽限期，在此期间新的EC2实例将不会被终止，即使它们被ELB标记为不健康。是否可以指定一个类似的宽限期，在此期间新的ECS任务不会被其关联的ECS服务杀死和重新启动，即使运行任务的ECS实例已被ELB标记为不健康？
更新
在我们当前的用例中，作为ECS任务运行的docker容器包含一个JBoss实例，它在启动时加载了许多缓存。这些缓存可能需要几分钟才能加载。但是，一旦容器启动，ECS服务就会使用ELB注册容器实例。这意味着可以在准备接受流量之前将流量路由到新容器。我们可以增加健康检查间隔和健康/不健康的阈值＆＃34;在ELB上防止ELB将流量路由到实例，并且ECS服务重新启动容器，直到缓存已加载。但是，不希望增加运行状况检查间隔和阈值，因为如果在加载高速缓存后将实例标记为运行状况不佳，则ECS服务应尽快重新启动容器（这需要更短的运行状况检查间隔和更小的阈值）。
因此，是否可以应用宽限期，在此期间ELB不会将流量路由到新容器，并且ECS服务不会重新启动容器（即使它未通过运行状况检查）？或者没有，对于我们的用例解决方案是否有任何建议？
答案 0 :(得分：2)
如果其他人通过谷歌发现自己在linked support thread，请注意这已添加到AWS，它被称为healthCheckGracePeriodSeconds https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html#ECS-CreateService-request-healthCheckGracePeriodSeconds
答案 1 :(得分：1)
在与支持团队讨论后，事实证明ECS无法支持我们当前的用例。
有一种解决方法可以解决我们面临的一个问题。该解决方法是创建一个单独的，必要的健康检查容器，并在与实际应用程序容器相同的ECS任务中。运行状况检查容器的目的是监视应用程序容器以确定应用程序何时完全启动。如果它检测到应用程序未能启动，则退出，导致ECS服务循环任务。然后，ELB被配置为对健康检查容器执行其健康检查，健康检查容器将始终通过相关端口报告它已启动。此解决方法将阻止ECS服务因健康检查失败而循环ECS任务。
但是，ELB将立即开始将流量路由到应用程序容器。即使应用程序容器尚未准备好接收流量（例如，因为它仍在等待加载缓存），它也会这样做。目前，没有办法延迟ELB将流量发送到应用程序容器，因为ECS服务不提供支持宽限期。我们设法通过SQS向我们的应用程序容器提供消息并且只有在缓存完全加载时才从队列中提取消息，从而解决了这个问题。但是，我们有未来的用例（例如服务Web请求），这不是一个可行的选择。为此，我打算提出宽限期的功能请求。
另外，Kubernetes（http://kubernetes.io/v1.0/docs/user-guide/walkthrough/k8s201.html#application-health-checking）和Marathon（https://mesosphere.github.io/marathon/docs/health-checks.html）已经支持此选项进行运行状况检查，如果有人读到这个选项很高兴不使用托管服务。
答案 2 :(得分：0)
使用env var ECS_CONTAINER_STOP_TIMEOUT