Joyent 最近发布的3.0 版ContainerPilot 是一种可在容器内部运行多个进程的Init 系统。该系统可自动实现服务注册,服务发现、运行状况检查,以及进程的生命周期管理任务。它提供了一种基于HTTP 的全新API,简化的配置语言,目前仅支持Consul。
通过处理随后启动的子进程,容器中的Init 系统可顺利应对 PID-1 问题。ContainerPilot 最初在构建时采用了单一“主”应用程序的概念,在第 3 版中,它可以充当容器内多个进程的控制器,这一改进主要来自用户反馈,因为很多用户对进程间依赖性的不同选项感到困惑。在本次发布的新版本中,每个进程都有自己的运行状况检查、依赖性、运行频率,以及启动和关闭过程中的生命周期钩子等机制。
如果诸如服务发现代理等支撑进程独立于主应用运行,通常就会导致容器中运行多个进程。此类进程的配置方法可能与主应用有所不同,同时主要还取决于同一个容器或外部容器中运行的其他服务。这些因素导致编排任务变得复杂无比。
对此Joyent 提出了一种名为“ Autopilot ”的概念,借此可将编排方面的所有工作转移给应用程序本身,这样就不再需要外部的编排程序了。此时的编排通常涉及服务端点在注册表中的注册操作,注册后才能被其他服务查找,此外还提供了运行状况检查的相关定义,以及依赖项的定义和生命周期管理。在 ContainerPilot 的产品中,目前的最新版仅支持使用 Hashicorp 的 Consul 作为服务发现机制。原本对 etcd 的支持已取消。
图片来源: https://www.joyent.com/blog/containerpilot-hello-world
ContainerPilot 中基于 HTTP 的全新 API 可供用户向控制应用程序及其环境发送信号。HTTP 请求可发送至容器内部的 Socket 中,借此更新环境变量,切换维护模式,记录 Prometheus 端点的度量指标,或重载 ContainerPilot 配置。这种方式取代了原本基于信号的机制,原先的机制只能切换状态,但无法提供结果反馈。
第 3 版中的配置语言整合了用户定义服务生命周期事件之间依赖性的方法。例如,可以定义 nginx 仅在内部的 Consul 代理启动之后再启动。这种依赖性可以通过启动或停止其他服务的方式定义,或针对服务的任何中间状态来定义。该版本还将之前定义的所有“行为”钩子进行了整合,组成了一种名为作业(Job)的抽象。不同作业可相互绑定,借此创建由依赖应用组成的链条。
ContainerPilot 是由 Joyent 原有的一个名为 ContainerBuddy 的产品发展而来的,目前该产品也已成为一个开源项目,可访问这里获取。
阅读英文原文: ContainerPilot 3.0 Released with Multiprocess Container Support
评论