docker-哪种方法更适合发现容器就绪状态？

发布时间：2020-12-16 03:25:08 所属栏目：安全来源：网络整理

导读：这个问题已经讨论了很多次,但是我想听听一些使用以下每种方法的最佳实践和实际示例：设计能够检查依赖服务运行状况的容器.简单的脚本whait-for-it对于这种类型的开发容器可能很有用,但不适用于更复杂的部署.例如,数据库可以接受连接,但尚未应用迁移. 使容器

这个问题已经讨论了很多次,但是我想听听一些使用以下每种方法的最佳实践和实际示例：

>设计能够检查依赖服务运行状况的容器.简单的脚本whait-for-it对于这种类型的开发容器可能很有用,但不适用于更复杂的部署.例如,数据库可以接受连接,但尚未应用迁移.
>使容器能够在Consul / etcd中发布自己的状态.所有相关服务将轮询某些端点,该端点包含所需服务的状态.看起来不错,但似乎多余,不是吗？
>通过外部调度程序管理容器的启动顺序.

在交付过程中缺少Swarm / Kubernetes / etc等编排者的情况下,上述哪种方法更可取？

最佳答案

我可以在这些方面对kubernetes的观点持怀疑态度.

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,它们按顺序运行,然后再运行主容器.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!