这是一个创建于 2530 天前的主题，其中的信息可能已经有所发展或是发生改变。
https://github.com/alibaba/pouch
11 月 19 日上午，在《中国开源年会》现场，阿里巴巴正式开源了基于 Apache 2.0 协议的容器技术 Pouch。Pouch 是一款轻量级的容器技术，拥有快速高效、可移植性高、资源占用少等特性，主要帮助阿里更快的做到内部业务的交付，同时提高超大规模下数据中心的物理资源利用率。开源之后，Pouch 成为一项普惠技术，人人都可以在 GitHub 上获取，GitHub 项目地址： https://github.com/alibaba/pouch 。
Pouch 的开源，是阿里看好容器技术的一个信号。时至今日，全球范围内，容器技术在大多数企业中落地，已然成为一种共识。如何做好容器的技术选型，如何让容器技术可控，相信是每一个企业必须考虑的问题。Pouch 无疑使得容器生态再添利器，在全球巨头垄断的容器开源生态中，为中国技术赢得了一块阵地。
1 Pouch 技术现状
此次开源 Pouch，相信行业中很多专家都会对阿里目前的容器技术感兴趣。到底阿里玩容器是一个侠之大者，还是后起之秀呢？以过去看未来，技术领域尤其如此，技术的沉淀与积累，大致可以看清一家公司的技术实力。
1.1 Pouch 演进
追溯 Pouch 的历史，我们会发现 Pouch 起源于 2011 年。当时，Linux 内核之上的 namespace、cgroup 等技术开始成熟，LXC 等工具也在同时期诞生不久。阿里巴巴作为一家技术公司，即基于 LXC 研发了容器技术 t4，并在当时以产品形态给集团内部提供服务。此举被视为阿里对容器技术的第一次探索，也为阿里的容器技术积淀了最初的经验。随着时间的推移，两年后，Docker 横空出世，其镜像技术层面，极大程度上解决了困扰行业多年的“软件封装”问题。镜像技术流行开来后，阿里没有理由不去融合这个给行业带来巨大价值的技术。于是，在 2015 年，t4 在自身容器技术的基础上，逐渐吸收社区中的 Docker 镜像技术，慢慢演变，打磨为 Pouch。
带有镜像创新的容器技术，似一阵飓风，所到之处，国内外无不叫好，阿里巴巴不外如是。2015 年末始，阿里巴巴集团内部在基础设施层面也在悄然发生变化。原因很多，其中最简单的一条，相信大家也不难理解，阿里巴巴体量的互联网公司，背后必定有巨大的数据中心在支撑，业务的爆炸式增长，必定导致基础设施需求的增长，也就造成基础设施成本的大幅提高。容器的轻量级与资源消耗低，加上镜像的快速分发，迅速让阿里巴巴下定决心，在容器技术领域加大投入，帮助数据中心全面升级。
1.2 阿里容器规模
经过两年多的投入，阿里容器技术 Pouch 已经在集团基础技术中，扮演着极其重要的角色。2017 年双 11，巨额交易 1682 亿背后，Pouch 在“超级工程”中做到了：
- 100%的在线业务 Pouch 化
- 容器规模达到百万级
回到阿里集团内部，Pouch 的日常服务已经覆盖绝大部分的事业部，覆盖的业务场景包括：电商、广告、搜索等；覆盖技术栈包括：电商应用、数据库、大数据、流计算等；覆盖编程语言：Java、C++、NodeJS 等。
- Pouch 技术优势
阿里巴巴容器技术如此之广的应用范围，对行业来说实属一大幸事，因为阿里已经用事实说明：容器技术已经在大规模生产环境下得到验证。然而，由于 Pouch 源自阿里，而非社区，因此在容器效果、技术实现等方面，两套体系存在差异。换言之，Pouch 存在不少独有的技术优势。
2.1 隔离性强
隔离性是企业走云化之路过程中，无法回避的一个技术难题。隔离性强，意味着技术具备了商用的初步条件；反之则几乎没有可能在业务线上铺开。哪怕是阿里巴巴这样的技术公司，实践容器技术伊始，安全问题都无法幸免。众所周知，行业中的容器方案大多基于 Linux 内核提供的 cgroup 和 namespace 来实现隔离，然后这样的轻量级方案存在弊端：
- 容器间，容器与宿主间，共享同一个内核；
- 内核实现的隔离资源，维度不足。
面对如此的内核现状，阿里巴巴采取了三个方面的工作，来解决容器的安全问题：
- 用户态增强容器的隔离维度，比如网络带宽、磁盘使用量等；
- 给内核提交 patch，修复容器的资源可见性问题，cgroup 方面的 bug ；
- 实现基于 Hypervisor 的容器，通过创建新内核来实现容器隔离。
容器安全的研究，在行业中将会持续相当长时间。而阿里在开源 Pouch 中，将在原有的安全基础上，继续融合 lxcfs 等特性与社区共享。同时阿里巴巴也在计划开源“阿里内核”，将多年来阿里对 Linux 内核的增强回馈行业。
2.2 P2P 镜像分发
随着阿里业务爆炸式增长，以及 2015 年之后容器技术的迅速普及，阿里容器镜像的分发也同时成为亟待解决的问题。虽然，容器镜像已经帮助企业在应用文件复用等方面，相较传统方法做了很多优化，但是在数以万计的集群规模下，分发效率依然令人抓狂。举一个简单例子：如果数据中心中有 10000 台物理节点，每个节点同时向镜像仓库发起镜像下载，镜像仓库所在机器的网络压力，CPU 压力可想而知。
基于以上场景，阿里巴巴镜像分发工具“蜻蜓”应运而生。蜻蜓是基于智能 P2P 技术的通用文件分发系统。解决了大规模文件分发场景下分发耗时、成功率低、带宽浪费等难题。大幅提升发布部署、数据预热、大规模容器镜像分发等业务能力。目前，“蜻蜓”和 Pouch 同时开源，项目地址为： https://github.com/alibaba/dragonfly。Pouch 与蜻蜓的使用架构图如下：
2.3 富容器技术
阿里巴巴集团内部囊括了各式各样的业务场景，几乎每种场景都对 Pouch 有着自己的要求。如果使用外界“单容器单进程”的方案，在业务部门推行容器化存在令人难以置信的阻力。阿里巴巴内部，基础技术起着巨大的支撑作用，需要每时每刻都更好的支撑业务的运行。当业务运行时，技术几乎很难做到让业务去做改变，反过来适配自己。因此，一种对应用开发、应用运维都没有侵入性的容器技术，才有可能大规模的迅速铺开。否则的话，容器化过程中，一方面得不到业务方的支持，另一方面也需要投入大量人力帮助业务方，非标准化的实现业务运维。
阿里深谙此道，内部的 Pouch 技术可以说对业务没有任何的侵入性，也正是因为这一点在集团内部做到 100%容器化。这样的容器技术，被无数阿里人称为“富容器”。
“富容器”技术的实现，主要是为了在 Linux 内核上创建一个与虚拟机体验完全一致的容器。如此一来，比一般容器要功能强大，内部有完整的 init 进程，以及业务应用需要的任何服务，当然这也印证了 Pouch 为什么可以做到对应用没有“侵入性”。技术的实现过程中，Pouch 需要将容器的执行入口定义为 systemd，而在内核态，Pouch 引入了 cgroup namespace 这一最新的内核 patch，满足 systemd 在富容器模式的隔离性。从企业运维流程来看，富容器同样优势明显。它可以在应用的 Entrypoint 启动之前做一些事情，比如统一要做一些安全相关的事情，运维相关的 agent 拉起。这些需要统一做的事情，倘若放到用户的启动脚本，或镜像中就对用户的应用诞生了侵入性，而富容器可以透明的处理掉这些事情。
2.4 内核兼容性
容器技术的井喷式发展，使得不少走在技术前沿的企业享受到技术红利。然后，“长尾效应”也注定技术演进存在漫长周期。Pouch 的发展也在规模化进程中遇到相同问题。
但凡规模达到一定量，“摩尔定律”决定了数据中心会存有遗留资源，如何利用与处理这些物理资源，是一个大问题。阿里集团内部也是如此，不管是不同型号的机器，还是从 2.6.32 到 3.10+的 Linux 内核，异构现象依然存在。倘若要使所有应用运行 Pouch 之中，Pouch 就必须支持所有内核版本，而现有的容器技术支持的 Linux 内核都在 3.10 以上。不过技术层面万幸的是，对 2.6.32 等老版本内核而言，namespace 的支持仅仅缺失 user namespace ；其他 namespace 以及常用的 cgroup 子系统均存在；但是 /proc/self/ns 等用来记录 namespace 的辅助文件当时还不存在，setns 等系统调用也需要在高版本内核中才能支持。而阿里的技术策略是，通过一些其他的方法，来绕过某些系统调用，实现老版本内核的容器支持。
当然，从另一个角度而言，富容器技术也很大程度上，对老版本内核上的其他运维系统、监控系统、用户使用习惯等实现了适配，保障 Pouch 在内核兼容性方面的高可用性。
因此综合来看，在 Pouch 的技术优势之上，我们不难发现适用 Pouch 的应用场景：传统 IT 架构的的迅速容器化，企业大规模业务的部署，安全隔离要求高稳定性要求高的金融场景等。
- Pouch 架构 凭借差异化的技术优势，Pouch 在阿里巴巴大规模的应用场景下已经得到很好的验证。然而，不得不说的是：目前阿里巴巴内部的 Pouch 与当前开源版本依然存在一定的差异。
虽然优势明显，但是如果把内部的 Pouch 直接开源，这几乎是一件不可能的事。多年的发展，内部 Pouch 在服务业务的同时，存在与阿里内部基础设施、业务场景耦合的情况。耦合的内容，对于行业来说通用性并不强，同时涉及一些其他问题。因此，Pouch 开源过程中，第一要务即解耦内部依赖，把最核心的、对社区同样有巨大价值的部分开源出来。同时，阿里希望在开源的最开始，即与社区站在一起，共建 Pouch 的开源社区。随后，以开源版本的 Pouch 逐渐替换阿里巴巴集团内部的 Pouch，最终达成 Pouch 内外一致的目标。当然，在这过程中，内部 Pouch 的解耦工作，以及插件化演进工作同样重要。而在 Pouch 的开源计划中，明年 3 月底会是一个重要的时间点，彼时 Pouch 的 1.0 版本将发布。
从计划开源的第一刻开始，Pouch 在生态中的架构图就设计如下：
Pouch 的生态架构可以从两个方面来看：第一，如何对接容器编排系统；第二，如何加强容器运行时。
容器编排系统的支持，是 Pouch 开源计划的重要板块。因此，设计之初，Pouch 就希望自身可以原生支持 Kubernetes 等编排系统。为实现这点，Pouch 在行业中率先支持 container 1.0.0。目前行业中的容器方案 containerd 主要停留在 0.2.3 版本，新版本的安全等功能还无法使用，而 Pouch 已经是第一个吃螃蟹的人。当前 Docker 依然是 Kubernetes 体系中较火的容器引擎方案，而 Kubernetes 在 runtime 层面的战略计划为使用 cri-containerd 降低自身与商业产品的耦合度，而走兼容社区方案的道路，比如 cri-containerd 以及 containerd 社区版。另外，需要额外提及的是，内部的 Pouch 是阿里巴巴调度系统 Sigma 的重要组成部分，同时支撑着“混部”工程的实现。Pouch 开源路线中，同样会以支持“混部”为目标。未来，Sigma 的调度（ scheduling ）以及混部（ co-location ）能力有望服务行业。
生态方面，Pouch 立足开放；容器运行时方面，Pouch 主张“丰富”与“安全”。runC 的支持，可谓顺其自然。runV 的支持，则表现出了和生态的差异性。虽然 docker 默认支持 runV，然而在 docker 的 API 中并非做到对“容器”与“虚拟机”的兼容，从而 Docker 并非是一个统一的管理入口。而据我们所知，现有企业中仍有众多存量虚拟机的场景，因此，在迎接容器时代时，如何通过统一的运维入口，同时管理容器和虚拟机，势必会是“虚拟机迈向容器”这个变迁过渡期中，企业最为关心的方案之一。Pouch 的开源形态，很好的覆盖了这一场景。runlxc 是阿里巴巴自研的 lxc 容器运行时，Pouch 对其的支持同时也意味着 runlxc 会在不久后开源，覆盖企业内部拥有大量低版本 Linux 内核的场景。
Pouch 对接生态的架构如下，而 Pouch 内部自身的架构可参考下图：
和传统的容器引擎方案相似，Pouch 也呈现出 C/S 的软件架构。命令行 CLI 层面，可以同时支持 Pouch CLI 以及 Docker CLI。对接容器 runtime，Pouch 内部通过 container client 通过 gRPC 调用 containerd。Pouch Daemon 的内部采取组件化的设计理念，抽离出相应的 System Manager、Container Manager、Image Manager、Network Manager、Volume Manager 提供统一化的对象管理方案。
4.写在最后 如今 Pouch 的开源，意味着阿里积累的容器技术将走出阿里，面向行业。而 Pouch 的技术优势，决定了其自身会以一个差异化的容器解决方案，供用户选择。 企业在走云化之路，拥抱云原生（ Cloud Native ）时，Pouch 致力于成为一款强有力的软件，帮助企业的数字化转型做到最稳定的支持。
Pouch 目前已经在 GitHub 上开源，GitHub 地址为： https://github.com/alibaba/pouch，欢迎任何形式的开源参与。
 |
1
Tinet 2017-12-13 14:08:41 +08:00
手动赞一个
|
 |
2
hantsy 2017-12-13 14:21:07 +08:00
Pouch 在 Github 上提交记录才只有这两个月，如果是 2011 年到到现在应该都有几年的提交记录吧，即使你是从其它地方或者其它 Repos 搬过来的，也应该连同 Commit Log 一起搬迁吧。
|
|
3
hantsy 2017-12-13 14:29:23 +08:00
[End User Quick Start]( https://github.com/alibaba/pouch/blob/master/INSTALLATION.md#end-user-quick-start) 没提及各操作系统简单的本地试用方法，比如基于虚拟机 VirtualBox， 或者 Vagrant 等。
|
 |
4
allensun OP @hantsy 内部的代码通用性不高，放出来，对外部价值不大。所以，我们从 0 开始在 github 上和社区上共建 Pouch。欢迎参与，有任何问题，都可以在 github 上提哈 ：）
|
|
5
allensun OP @hantsy 现在提供的是开发者体检方法，end-user 的体验方法还没有准备。主要原因是：现在处于高速迭代期，等 alpha 版本，beta 版本或者 rc 版本，1.0 版本之后，再邀请 end-user 来参与。
|
 |
6
yongzhong 2017-12-13 15:07:48 +08:00
说一个题外话,一时兴起在 pouch 的仓库里搜索"docker"关键字,意外的搜到了不少和 moby 仓库相似的内容
比如这两个文档里的某些内容,连时间都一模一样 https://github.com/alibaba/pouch/blob/feae25ff6211357224b3256ed82281c995974b0c/apis/swagger.yml https://github.com/moby/moby/blob/3b14e5980ef681c47faf128b5c23cb972fd8851d/api/swagger.yaml |
 |
7
HarrisonZ 2017-12-13 15:36:54 +08:00
rkt 好
|
|
8
allensun OP @yongzhong 您所言无差。Pouch 沿用了 moby 的 API。Pouch 没有理由创造一套新的 API，这是 Docker 对行业很大的贡献。这里的确是沿用了很多 Moby 项目的 swagger 文件。
不过值得一提的是，Moby 使用了 Swagger，却没有使用 swagger 来生成 API ；而 Pouch 的 API 代码，在数据交换方面，全部是 swagger 来生成的。 |
|
10
allensun OP 欢迎大家 Star 关注哈，谢谢。
|
 |
11
shiny 2017-12-13 18:43:31 +08:00  1
这几年阿里的开源项目越来越多， 赞一下。希望同样重视开源项目的生态和社区。
|
 |
12
zingl 2017-12-13 21:04:21 +08:00
都 100%内部应用了，为什么还要 alpha
|
 |
13
flyspace15 2017-12-13 22:12:15 +08:00
从 0 开始，要做的工作很多啊！如何才能追赶上 docker 呢？
|
|
14
allensun OP @zingl
互联网公司业务主导，不少的技术对外通用性不是很高，直接把内部的拿到外部，价值不是很大。比如说，内部的东西很多和会内核耦合，而阿里内核和外部的 Linux 内核差异很大 |
|
15
allensun OP @flyspace15
主要还是有差异化的存在吧，不能说要追赶上吧 |
 |
16
SlipStupig 2017-12-14 01:11:08 +08:00
继 dubbo 后又一个提升 kpi 的重量产品
|
 |
17
anmaz 2017-12-14 07:26:15 +08:00 via Android
年底了，阿里的小伙伴们压力山大，这不又“”开源”了。
|
 |
18
blless 2017-12-14 07:40:57 +08:00 via Android
…之前看过几个阿里开源的小项目，也是容器相关，真的太粗糙了，dockerfile 明显没有按官方最佳实践来写
|
|
19
blless 2017-12-14 07:51:21 +08:00 via Android
https://github.com/AliyunContainerService/fluentd-pilot 补上地址 很好奇为啥是用的另一个项目的路径 可能没啥人用就不管了 issue 也很久没回复了…
|
|
20
allensun OP @SlipStupig 我个人刚到阿里，在阿里的工作是专职做开源，目前团队也有好几位专职人员。说是团队年底凑 KPI，有点不太合适，毕竟这个团队的工作就是全职开源 Pouch
|
|
21
allensun OP @blless 开源的第一步是 sharing，这一步也可以给行业带来巨大价值。开源不是免费，开源也和商业化不矛盾。但是无论如何，维护也蛮需要成本，在商业变化的情况，有时候难免出现不维护的情况。我相信这样的情况在全球很多开源软件项目的公司中，都会存在。不过大家说的很多都对，阿里正在逐渐改变自身对开源的做法。
|
|
23
allensun OP @boyxupers 那也不见得。如果您觉得好的话，可以 Star，也会提高 Pouch 的影响力，让更多人知道与使用 Pouch。
|
 |
24
dodo20120 2017-12-14 15:30:34 +08:00
阿里的开源真不是我有偏见，从 kissy 到 weex，一路走来，发现不是内部人真不怎么敢用，一言不合就结束了使命。
|
 |
25
candy1764 2017-12-16 09:03:13 +08:00
docker 目前的确存在问题，但是阿里的开源项目，能走到什么地位，还需要持续关注。
|
Select Language