这个问题已经讨论了很多次,但是我想听听一些使用以下每种方法的最佳实践和实际示例：
>设计能够检查依赖服务运行状况的容器.简单的脚本whait-for-it对于这种类型的开发容器可能很有用,但不适用于更复杂的部署.例如,数据库可以接受连接,但尚未应用迁移.
>使容器能够在Consul / etcd中发布自己的状态.所有相关服务将轮询某些端点,该端点包含所需服务的状态.看起来不错,但似乎多余,不是吗？
>通过外部调度程序管理容器的启动顺序.
在交付过程中缺少Swarm / Kubernetes / etc等编排者的情况下,上述哪种方法更可取？
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.
听起来您想区分活跃程度和准备程度. Kubernetes允许使用both types of probes,您可以使用它检查运行状况并在为任何流量提供服务之前等待.
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?
我同意.必须单独维护状态不是优选的.但是,在绝对必要的情况下,如果您确实要存储资源的状态,则可以使用third party resource.
Manage startup order of containers by external scheduler.
这似乎与讨论最为相关.但是,很快将被Kubernetes v1.5中的有状态集取代的Pet Sets给您提供了Pod初始化的确定性顺序.对于单个容器上的容器,有init-containers,它们按顺序运行,然后再运行主容器.
