PouchContainer 富容器技术解析

背景

PouchContainer 源自阿里巴巴内部场景，诞生初期，在如何为互联网应用保驾护航方面，倾尽了阿里巴巴工程师们的设计心血。

PouchContainer 的强隔离、富容器等技术特性是最好的证实。在阿里巴巴的体量规模下，PouchContainer 对业务的支撑获得双 11 前所未有的检验，开源以后，阿里容器成为一项普惠技术，定位于「助力企业快速实现存量业务容器化」。

初次接触容器技术时，阿里巴巴内部有着惊人规模的存量业务，如何经过技术快速容器化存量业务，是阿里容器技术当年在内部铺开时的重点难题。发展到今天，开源容器技术逐渐普及，面对落地，相信很多存在大量存量业务的企业，一样为这些业务的如何容器化而犯愁。云原生领域，CNCF 基金会推崇的众多先进理念，绝大多数都创建在业务容器化的基础之上。假若企业业务在云原生的入口容器化方面没有踩准步点，后续的容器编排、Service Mesh 等行业开源技术红利更是无从谈起。

经过七年的实践经验，阿里巴巴容器技术 PouchContainer 用事实向行业传递这样的信息 —— 富容器是实现企业存量业务快速容器化的首选技术。

什么是富容器？

富容器是企业打包业务应用、实现业务容器化过程当中，采用的一种容器模式。此模式能够帮助企业IT技术人员打包业务应用时，几乎不费吹灰之力。经过富容器技术打包的业务应用能够达到如下两个目的：

● 容器镜像实现业务的快速交付

● 容器环境兼容企业原有运维体系

技术角度而言，富容器提供了有效路径，帮助业务在单个容器镜像中除了业务应用自己以外，还打包更多业务所需的运维套件、系统服务等；同时相比于较为简单的单进程容器，富容器在进程组织结构层面，也有着巨大的变革：容器运行时内部自动运行 systemd 等管家进程。如此一来，富容器模式下的应用，有能力在不改变任何业务代码、运维代码的状况下，像在物理机上运行如出一辙。能够说，这是一种更为通用的「面向应用」的模式。

换言之，富容器在保障业务交付效率的同时，在开发和运维层面对应用没有任何的侵入性，从而有能力帮助 IT 人员更多聚焦业务创新。

适用场景

富容器的适用场景极广。能够说企业几乎全部的存量业务，均可以采纳富容器做为容器化方案首选。容器技术流行以前，有接近二十年的时间，企业 IT 服务运行在裸金属或者虚拟机中。企业业务的稳定运行，有很是大的功劳来源于运维工做，若是细分，包括「基础设施运维」以及「业务运维」。全部的应用运行，都依赖于物理资源；全部的业务稳定，都仰仗于监控系统、日志服务等运维体系。那么，咱们有理由相信，在业务容器化过程当中，企业坚定不能对运维体系置之不理，不然后果可想而知。

所以，存量业务容器化过程当中，须要考虑兼容企业原有运维体系的场景，都在 PouchContainer 富容器技术的使用范围以内。

富容器技术实现

既然能够业务兼容原有运维体系，那么富容器技术又是经过什么样的技术来实现的呢？下图清晰的描述了富容器技术的内部状况。

富容器技术能够彻底百分百兼容社区的 OCI 镜像，容器启动时将镜像的文件系统做为容器的 rootfs。运行模式上，功能层面，除了内部运行进程，同时还包括容器启停时的钩子方法（prestart hook 和 poststop hook）。

富容器内部运行进程

若是从内部运行进程的角度来看待 PouchContainer 的富容器技术，咱们能够把内部运行进程分为 4 类：

● pid=1 的 init 进程

● 容器镜像的 CMD

● 容器内部的系统 service 进程

● 用户自定义运维组件

pid=1 的 init 进程

富容器技术与传统容器最明显的差别点，即容器内部运行一个 init 进程，而传统的容器（如 docker 容器等）将容器镜像中指定的 CMD 做为容器内 pid=1 的进程。PouchContainer 的富容器模式能够运行从三种 init 进程中选择：

● systemd

● sbin/init

● dumb-init

众所周知，传统容器做为一个独立运行环境，内部进程的管理存在必定的弊端：好比没法回收僵尸进程，致使容器消耗太多进程数、消耗额外内存等；好比没法友好管理容器内部的系统服务进程，致使一些业务应用所须要的基本能力欠缺等，好比 cron 系统服务、syslogd 系统服务等；好比，没法支持一些系统应用的正常运行，主要缘由是某些系统应用须要调用 systemd 来安装 RPM 包……

富容器的 init 进程在运维模式上，毫无疑问能够解决以上问题，给应用带来更好的体验。init 进程在设计时就加入了能够 wait 消亡进程的能力，便可以轻松解决上图中业务进程运行过程当中诞生的 Zombie 僵尸进程；同时管理系统服务也是它的本职工做之一。若是一来，一些最为基本的传统运维能力，init 进程即帮助用户解决了大半，为运维体系作好了坚实的基础。

容器镜像的CMD
容器镜像的 CMD，也就是传统意义上咱们但愿在容器内部运行的业务。好比，用户在容器化一个 Golang 的业务系统打包成镜像时，确定会在 Dockerfile 中将该业务系统的启动命令指定为 CMD，从而保证将来经过该镜像运行容器起，会执行这条 CMD 命令运行业务系统。

固然，容器镜像的 CMD 表明业务应用，是整个富容器的核心部分，全部的运维适配都是为了保障业务应用更加稳定的运行。

容器内系统 service 进程

服务器编程发展了数十年，不少的业务系统开发模式均基于裸金属上的 Linux 操做系统，或者虚拟化环境的下的 Linux 环境。久而久之，不少业务应用的开发范式，会很是频繁地与系统服务进程交互。好比，使用 Java 编程语言编写的应用程序，颇有可能经过 log4j 来配置日志的管理方式，也能够经过 log4j.properties 配置把应用日志重定向到运行环境中的 syslogd，假若应用运行环境中没有 syslogd 的运行，则极有可能影响业务的启动运行。

再好比，业务应用须要经过 crond 来管理业务须要的周期性任务，假若应用运行环境中没有 crond 系统守护进程，业务应用也就不可能经过 crontab 来配置周期任务；再好比，容器内部的 sshd 系统服务系统，能够快速帮助运维工程师快速进度应用运行现场，定位并解决问题等。

PouchContainer 的富容器模式，考虑到了行业大量有需求和系统服务交付的应用，富容器内部的 init 进程有能力很是方面的原生管理多种系统服务进程。

用户自定义运维组件

系统服务的存在能够辅助业务的正常运行，可是不少状况下这还不够，企业自身针对基础设施以及应用配备的运维组件，同时起到为业务保驾护航的做用。好比，企业运维团队须要统一化的为业务应用贴近配置监控组件；运维团队必须经过自定义的日志 agent 来管理容器内部的应用日志；运维团队须要自定义本身的基础运维工具，以便要求应用运行环境符合内部的审计要求等。

正由于富容器内部存在 init 进程，用户自定义的运维组件，能够如往常健康稳定的运行，提供运维能力。

富容器启停执行 hook

最终富容器内部运行的任务进程，能够保障应用的运行时稳定正常，然而对于运维团队而言，负责内容的范畴每每要比单一的运行时广得多。通俗而言，运维的职责还须要覆盖运行时以前的环境准备工做，以及运行时结束后的善后工做。对于应用而言，也就是咱们一般意义上提到的 prestart hook 以及 poststop hook。

PouchContainer 的富容器模式，能够容许用户很是方便的指定应用的启停执行 hook： prestart hook 以及 poststop hook。 运维团队指定 prestart hook，能够帮助应用在运行以前，在容器内部作符合运维需求的一些初始化操做，好比：初始化网络路由表、获取应用执行权限、下载运行时所需的证书等。运维团队指定 poststop hook，能够帮助应用在运行结束或者异常退出以后，执行统一的善后工做，好比，对中间数据的清理以便下一次启动时的纯净环境；假若是异常退出的话，能够即时汇报出错信息，知足运维需求等。

咱们能够发现，富容器内部的启停 hook，对容器的运维能力又作了一层拔高，大大释放了运维团队对应用的灵活管理能力。

总结

通过阿里巴巴内部大量业务的锤炼，PouchContainer 已经帮助超大致量的互联网公司实现了全部在线业务的容器化。毫无疑问，富容器技术是最为实用、对应用开发以及应用运维没有任何侵入性的一项技术。开源的PouchContainer 更是但愿技术能够普惠行业，帮助大量的企业在存量业务的容器化方面，赢得本身的时间，快速拥抱云原生技术，大步迈向数字化转型。

本文做者：孙宏亮

阅读原文

本文来自云栖社区合做伙伴“阿里技术”，如需转载请联系原做者。