从根本上来说，所有的主要软件，包括开源的，都位于基于镜像的容器之上。 这就是说把软件装入容器的本质就是一种平台迁移。也意味着有些程序很容易迁移到容器中，而另外有些程序迁移起来就困难一些。

大概3年半以前，我开始使用基于镜像的容器。那时，我将大量的应用程序进行了容器化。我知道了哪些是真实的，哪些是骗人的。今天，我想简单介绍一下如何设计Linux容器，同时简单地讨论一下有关图像签名的知识。

如何设计Linux容器

大部分人对基于镜像的Linux容器感到混淆的是，它其实把操作系统分成了两个部分：内核和用户空间。传统操作系统的内核运行在硬件之上，我们从不和它之间交互，而真正交互的是用户空间，用户空间包括通过文件浏览器或运行ls命令所看到的全部文件、库和程序。当你使用ifconfig命令改变一个IP地址时，你实际上是利用一个用户空间程序对TCP协议栈进行了内核改变。如果他们学习过Linux/Unix基础，这种观点会让人感到混淆。

过去，用户空间中的库文件支持那些和内核交互的程序（如ifconfig、sysctl、tuned-adm）以及面向用户的程序（如web服务器或数据库）。所有的东西都被放在一个单一的文件系统层次结构中。用户可以检查/sbin或/lib目录以查看支持操作系统本身的所有程序和库，或者检查 /usr/sbin或/usr/lib 目录以查看面向用户的程序和库（查看文件系统层次结构标准）。这种模型带来的问题是操作系统程序和业务支撑程序之间从来没有完全的隔离。/usr/bin目录中程序可能依赖于/lib目录中的库文件。 如果需要对某个应用程序做些改变，可能就会破坏操作系统。反之，如果负责安全更新的小组需要修改某个库文件，就会（经常这样）破坏面向业务的应用程序。这就很混乱。

使用基于镜像的容器（例如Docker、LXD和RKT），应用程序所有者可以将/sbin、/lib、/usr/bin和/usr/lib中的所有依赖关系打包和修改，而无需担心会破坏底层操作系统。从本质上来说，使用基于镜像的容器再次将操作系统清晰地分成了两个部分：内核和用户空间。现在dev和ops就可以相互独立地更新各自的内容了，有点...

使用基于镜像的容器还有一些严重的混乱。通常情况下，每个应用程序所有者（或开发者）并不想负责更新程序的依赖关系（例如openssl、glibc），也不想加强底层的部件（例如XML解析器、JVM）以及处理性能设置相关的问题。过去，这些问题是由运营团队负责完成的。既然我们把大量依赖关系都打包进了容器中，那么对于容器中各种依赖关系的责任分配是许多组织依然要面临的现实问题。

将现有的程序迁移到Linux容器中

从本质上来说，将软件装入容器中是一种平台迁移。我想强调的是造成难以将一些程序迁移到容器中的原因是什么。

如今开发人员已经可以对/sbin、/lib、 /usr/bin和/usr/lib中的内容有了完全控制。但是，他们仍面临一个挑战，即还需要将数据和配置放入 /etc或/var/lib这样的文件夹中。对于使用基于镜像的容器来说，这不是一个好主意。我们真的需要将代码、配置和数据更好地分离。我们需要开发者在容器中提供代码，而从环境中得到数据与配置，例如开发、测试或生产。

这就是说当我们（或者是平台更好）实例化一个容器时，需要挂载/etc中的一些文件或者/var/lib中的一些目录。这样，我们就可以移动容器的位置，但仍然从环境中获取配置和数据。很酷，对吗？不过，还有一个问题，就是我们必须能将配置和数据完全隔离开来。 像Apache、MySQL、MongoDB或Nginx等许多现代开源程序默认情况下就是这样做的，但是许多自助开发的程序、遗产程序或专有程序默认不是这样的。这是令很多组织最为头痛的问题。对于开发人员来说，最好的做法是开始构建新的程序并且迁移遗传代码以便将配置与数据完全隔离。

镜像签名简介

信任是容器的一个主要问题。用户使用容器镜像签名技术可以为一个镜像添加一个数字指纹。然后可以用该指纹做加密测试以便进行信任验证。通过这种方法，容器镜像的用户可以对源进行验证并信任该容器镜像。

容器社区经常使用“容器镜像”这个说法，但是这种命名方法可能相当混乱。Docker、LXD和RKT使用的概念是拉取远程文件并将它们作为容器来运行。每种技术都以不同的方式来对待容器镜像。LXD用一个单一的层来放置一个单一的容器镜像，而Docker和RKT则使用由多个层所组成基于OCI（Open Container Image）的镜像。更糟糕的是，不同的小组（或者甚至是一些组织）可能负责一个容器镜像的不同层。容器镜像的概念隐含着容器镜像格式（Container Image Format）的概念。拥有一个标准化的镜像格式（例如OCI）将会使得一个生态系统在容器扫描、签名以及在云供应商之间移动等方面蓬勃发展。

现在我们来看签名。

容器存在一个问题，我们要把一些代码、二进制和库打包进一个容器镜像。一旦我们将代码打包，基本上就要用人们所称的注册服务器（Registry Servers）来共享它，注册服务器从本质上来说就是fancy文件服务器。一旦代码被共享，它基本上就是匿名的，而没有使用某种形式的加密签名。更糟的是，容器镜像通常由一些镜像层组成，这些镜像层又由不同的人或不同的小组来控制。每个小组要能够对最后那个小组的工作进行检查，并增加自己的工作，然后把他们的印章盖在上面。接下来需要把它发送给下一个小组。

容器镜像（其实是由多个镜像组成的）的最终用户必须检查整个监管链。他们需要对曾添加文件到容器镜像的每个小组进行信任验证。对于最终用户来说，对容器镜像的每个单一层有信心是至关重要的。

8月24日，Scott McCarty 在ContainerCon将发表一场演讲， 题目是发展成熟的容器：迁移传统的和现有的程序。观众们会对容器是如何工作的有新的理解，并且能够基于已有的架构知识而进入容器的世界。他会讲授有哪些程序更容易放进容器以及为什么，他也会讲解有哪些类型的程序难以放进容器以及为什么。他会提供大量的范例，以帮助观众们建立对构建程序并将自己的程序迁移到容器中的自信。