这个问题已经讨论了很多次,但是我想听听一些使用以下每种方法的最佳实践和实际示例：@H_502_2@
>设计能够检查依赖服务运行状况的容器.简单的脚本whait-for-it对于这种类型的开发容器可能很有用,但不适用于更复杂的部署.例如,数据库可以接受连接,但尚未应用迁移.
>使容器能够在Consul / etcd中发布自己的状态.所有相关服务将轮询某些端点,该端点包含所需服务的状态.看起来不错,但似乎多余,不是吗？
>通过外部调度程序管理容器的启动顺序.@H_502_2@
在交付过程中缺少Swarm / Kubernetes / etc等编排者的情况下,上述哪种方法更可取？
@H_502_2@
Designing containers which are able to check the health of dependent services. Simple script whait-for-it can be useful for this kind of developing containers,but aren’t suitable for more complex deployments. For instance,database could accept connections but migrations aren’t applied yet.@H_502_2@
听起来您想区分活跃程度和准备程度. Kubernetes允许使用both types of probes,您可以使用它检查运行状况并在为任何流量提供服务之前等待.@H_502_2@
@H_502_2@
Make container able to post own status in Consul/etcd. All dependent services will poll certain endpoint which contains status of needed service. Looks nice but seems redundant,don’t it?@H_502_2@
我同意.必须单独维护状态不是优选的.但是,在绝对必要的情况下,如果您确实要存储资源的状态,则可以使用third party resource.@H_502_2@
@H_502_2@
Manage startup order of containers by external scheduler.@H_502_2@
这似乎与讨论最为相关.但是,很快将被Kubernetes v1.5中的有状态集取代的Pet Sets给您提供了Pod初始化的确定性顺序.对于单个容器上的容器,有init-containers,它们按顺序运行,然后再运行主容器.
