学习笔记-架构的演进之容器的封装-3月day06

前言

当文件系统、访问、资源都可以被隔离后，容器就已经具备它降生所需要的全部前置支撑条件了。为了降低普通用户综合使用 namespaces、cgroups 这些低级特性的门槛，2008 年 Linux Kernel 2.6.24 内核在刚刚开始提供 cgroups 的同一时间，就发布了名为Linux 容器（LinuX Containers，LXC）的系统级虚拟化功能。

封装应用的Docker

2013 年宣布开源的 Docker，毫无疑问是容器发展历史上里程碑式的发明，然而 Docker 的成功似乎没有太多技术驱动的成分。它的容器化能力直接来源于 LXC，它的镜像分层组合的文件系统直接来源于AUFS。

why Docker not LXC?

在LXC以及更早的OpenVZ 和 Linux-VServer视角来看，容器都是一种封装系统的轻量级虚拟机，而 Docker 眼中的容器的定义则是一种封装应用的技术手段。这两种封装理念在技术层面并没有什么本质区别，但在应用效果上差异可就相当大了。
以封装系统为出发点，如果仍然是按照先装系统再装软件的思路，就永远无法做到一两分钟甚至十几秒钟就构造出一个合乎要求的软件运行环境，这也就决定了 LXC 不可能形成今天的容器生态。

为什么要用 Docker 而不是 LXC？（Why would I use Docker over plain LXC？）
Docker 除了包装来自 Linux 内核的特性之外，它的价值还在于：
跨机器的绿色部署：Docker 定义了一种将应用及其所有的环境依赖都打包到一起的格式，仿佛它原本就是绿色软件一样。而 LXC 并没有提供这样的能力，使用 LXC 部署的新机器很多细节都要依赖人的介入，虚拟机的环境基本上肯定会跟你原本部署程序的机器有所差别。
以应用为中心的封装：Docker 封装应用而非封装机器的理念贯穿了它的设计、API、界面、文档等多个方面。相比之下，LXC 将容器视为对系统的封装，这局限了容器的发展。
自动构建：Docker 提供了开发人员从在容器中构建产品的全部支持，开发人员无需关注目标机器的具体配置，就可以使用任意的构建工具链，在容器中自动构建出最终产品。
多版本支持：Docker 支持像 Git 一样管理容器的连续版本，进行检查版本间差异、提交或者回滚等操作。从历史记录中，你可以查看到该容器是如何一步一步构建成的，并且只增量上传或下载新版本中变更的部分。
组件重用：Docker 允许将任何现有容器作为基础镜像来使用，以此构建出更加专业的镜像。
共享：Docker 拥有公共的镜像仓库，成千上万的 Docker 用户在上面上传了自己的镜像，同时也使用他人上传的镜像。
工具生态：Docker 开放了一套可自动化和自行扩展的接口，在此之上用户可以实现很多工具来扩展其功能，比如容器编排、管理界面、持续集成，等等。
——Solomon Hykes，2013

从开源到现在，只过了短短数年时间，Docker 就已经成为了软件开发、测试、分发、部署等各个环节都难以或缺的基础支撑，而它自身的架构也发生了相当大的改变：Docker 被分解为了几个子系统，包括 Docker Client、Docker Daemon、Docker Registry、Docker Container 等等，以及 Graph、Driver、libcontainer 等各司其职的模块。2014 年，Docker 开源了自己用 Golang 开发的libcontainer，这是一个越过 LXC 直接操作 namespaces 和 cgroups 的核心模块，有了 libcontainer 以后，Docker 就能直接与系统内核打交道，不必依赖 LXC 来提供容器化隔离能力了。

2015 年，在 Docker 的主导和倡议下，多家公司联合制定了“开放容器交互标准”（Open Container Initiative，OCI），这是一个关于容器格式和运行时的规范文件，其中包含了运行时标准（runtime-spec ）、容器镜像标准（image-spec）和镜像分发标准（distribution-spec，分发标准还未正式发布）。

• 运行时标准定义了应该如何运行一个容器、如何管理容器的状态和生命周期、如何使用操作系统的底层特性（namespaces、cgroup、pivot_root 等）；
• 容器镜像标准规定了容器镜像的格式、配置、元数据的格式，你可以理解为对镜像的静态描述；
• 镜像分发标准则规定了镜像推送和拉取的网络交互过程。

为了符合 OCI 标准，Docker 推动自身的架构继续向前演进：

附

此文章为3月Day06学习笔记，内容来源于极客时间《周志明的软件架构课》