linux 容器

在过去的几年中，容器不仅成为开发人员，而且也成为企业的热门话题。 这种日益增长的兴趣引起了对安全性改进和强化以及为可伸缩性和互操作性做准备的需求。 这需要大量的工程，这是在Red Hat的企业级发生了多少工程的故事。

当我在2013年秋天与Docker Inc.（）的代表首次会面时，我们正在研究如何使Red Hat Enterprise Linux（RHEL）使用Docker容器。 （此后，Docker项目的一部分已更名为Moby 。）在将该技术引入RHEL时，我们遇到了一些问题。 第一个主要障碍是获得受支持的写时复制（COW）文件系统来处理容器图像分层。 红帽最终贡献了一些COW实现，包括Device Mapper ， btrfs和OverlayFS的第一个版本。 对于RHEL，尽管我们对OverlayFS的支持越来越紧密，但我们默认使用Device Mapper。

下一个主要障碍是启动容器的工具。 当时，上游docker使用LXC工具启动容器，而我们不希望支持RHEL中设置的LXC工具。 在使用上游docker之前，我曾与libvirt团队合作开发了一个名为virt-sandbox的工具，该工具使用libvirt-lxc来启动容器。

libvirt-lxc与libvirt通信以启动容器。 这种方法引起了严重的关注。 请考虑以下示例，该示例使用Docker客户端（ docker-cli ）和启动容器进程（ pid1OfContainer

docker-cli→docker-daemon→libvirt-lxc→pid1OfContainer

我不喜欢在您的工具之间使用两个守护程序来启动容器和最终运行的容器的想法。

我的团队与上游docker开发人员一起在容器运行时的本机Go编程语言实现libcontainer上进行了艰苦的工作 。 该库最终作为OCI运行时规范的初始实现与runc一起发布。

docker - cli → docker -daemon @ pid1OfContainer

docker-cli的子进程，但实际上他们已经执行了客户端/服务器操作，并且容器进程作为完全独立的环境的子进程运行。 此客户端/服务器操作可能导致不稳定和潜在的安全隐患，并且阻止了有用的功能。 例如， systemd具有称为套接字激活的功能，您可以在其中设置守护程序，使其仅在进程连接到套接字时才运行。 这意味着您的系统使用更少的内存，并且只有在需要时才执行服务。 套接字激活的工作方式是systemd在TCP套接字上侦听，并且当有数据包到达套接字时，systemd激活通常在套接字上侦听的服务。 服务激活后，systemd将套接字移交给新启动的守护程序。 将该守护程序移动到基于Docker的容器中会导致问题。 单元文件将使用Docker CLI启动容器，而systemd没有简单的方法通过Docker CLI将连接的套接字传递给Docker守护程序。

诸如此类的问题使我们意识到，我们需要使用替代方法来运行容器。

容器编排问题

上游docker项目使使用容器变得容易，它仍然是学习Linux容器的好工具。 您可以通过运行简单的命令（例如docker run -ti fedora sh）快速体验启动容器的操作，并且立即进入容器。

当您开始同时运行多个容器并将它们连接到一个功能更强大的应用程序中时，容器的真正威力就显现出来。 设置多容器应用程序的问题是复杂性Swift增加，并且使用简单的Docker命令将其连接起来就分崩离析了。 如何在资源有限的节点群集中管理容器应用程序的放置或编排？ 如何管理自己的生命周期，依此类推？

在第一个DockerCon上，至少有七个不同的公司/开源项目展示了如何编排容器。 红帽公司的OpenShift有一个名为geard的项目，该项目大致基于我们所展示的OpenShift v2容器（称为“齿轮”）。 红帽认为我们需要重新审视业务流程，也许需要与开源社区中的其他人合作。

Google展示了Kubernetes容器编排的基础，该知识基于Google在编排其内部架构方面所掌握的全部知识。 OpenShift决定放弃我们的Gear项目，并开始在Kubernetes上与Google合作。 Kubernetes现在是GitHub上最大的社区项目之一。

Kubernetes

Kubernetes的开发是为了使用Google的lmctfy容器运行时。 Lmctfy已于2014年夏天移植到Docker上。Kubernetes在Kubernetes集群中的每个节点上运行一个守护程序，称为kubelet 。 这意味着原始的带有Docker 1.8的Kubernetes看起来像：

kubelet→dockerdaemon @ PID1

返回两守护程序系统。

runc启动容器：

kubelet→dockerdaemon @ runc @ PID1

Docker 1.12添加了一个容器守护进程来启动容器。 其主要目的是满足Docker Swarm（一个Kubernetes竞争对手）的需求：

kubelet→dockerdaemon→容器@runc @ pid1

每个

现在，我们有了一个三守护程序系统，如果其中任何守护程序出了问题，那么整个纸牌屋就会分崩离析。

迈向集装箱标准化

CoreOS，rkt和备用运行时

CoreOS为上游docker提供了一个替代的容器运行时，称为rkt （火箭）。 他们还引入了称为appc

这引发了红旗。 当我第一次开始使用上游docker处理容器时，我最大的担心是我们最终会遇到多种规格。 我不希望RPM与Debian之类的战争影响未来20年Linux软件的发行。 appc引入的一个很好的结果是，它说服了上游docker与开源社区合作，创建了一个名为开放容器倡议 （OCI）的标准机构。

OCI一直在制定两个规范：

OCI运行时规范

OCI图像格式规范

开放容器计划（Open Container Initiative）通过为行业提供围绕容器映像和运行时进行标准化的场所，帮助释放了工具和编排领域的创新。

抽象运行时接口

利用此标准化的创新之一是Kubernetes编排领域。 作为Kubernetes努力的大力支持者，CoreOS除了向上游docker引擎之外，还向Kubernetes提交了一系列补丁，以添加对通过rkt进行通信和运行容器的支持。 Google和上游Kubernetes看到，添加这些补丁，并可能在将来添加新的容器运行时接口，将会使Kubernetes的代码过于复杂。 上游Kubernetes团队决定实施称为容器运行时接口（CRI）的API协议规范。 然后他们将重新设计Kubernetes以调用CRI而不是Docker引擎，因此任何想要构建容器运行时接口的人都可以实现CRI的服务器端，并且可以支持Kubernetes。 上游Kubernetes创建了一个大型测试套件，供CRI开发人员进行测试以证明他们可以为Kubernetes提供服务。 目前正在进行一项工作，从Kubernetes删除所有Docker引擎调用，并将它们放在一个名为docker-shim的垫片后面。

容器工具的创新

Skopeo的容器注册表创新

几年前，我们在原子CLI上与Project Atomic团队合作。 我们希望能够在容器映像位于容器注册表上时对其进行检查。 当时，在容器注册表中查看与容器映像关联的JSON数据的唯一方法是将映像拉到本地服务器，然后可以使用docker inspect读取JSON文件。 这些图像可能非常大，高达数GB。 因为我们想允许用户检查图像并决定不拉图像，所以我们想向docker inspect添加一个新的--remote接口。 上游docker拒绝了pull请求，告诉我们他们不想使Docker CLI复杂化，并且我们可以轻松地构建自己的工具来做到这一点。

我的团队在安东尼奥·穆尔达卡 （ Antonio Murdaca）的带领下实现了这一想法并创建了skopeo 。 Antonio不仅止步于拉取与图像关联的JSON文件，他决定实现整个协议，以将容器图像从容器注册表中拉出到本地主机或从本地主机中拉出。

现在，在原子CLI中大量使用Skopeo做诸如检查容器的新更新和原子扫描内部之类的事情。 Atomic还使用skopeo来拉入和推送图像，而不是使用上游docker守护程序。

容器/图像

执行助手程序，但会考虑使用skopeo使用的库。 我们决定将skopeo拆分为一个库和可执行文件，并创建映像

容器/图像库和skopeo用于其他几个上游项目和云基础架构工具。 Skopeo和容器/映像已经发展到可以支持除Docker之外的多个存储后端，并且可以在容器注册表和许多很酷的功能之间移动容器映像。 关于skopeo的一件好事是它不需要任何守护程序即可完成其工作。 容器/图像库的突破还使我们能够添加增强功能，例如容器图像签名 。

图像处理和扫描方面的创新

原子

atomic mount

docker保存以创建tarball，然后将磁盘上的tarball炸开，最后检查内容。 这是一个缓慢的操作。

atomic mount

并开始检查内容。 完成后，请执行以下操作：

原子扫描中使用此功能，它使您可以使用一些最快的容器扫描仪。

工具协调问题

原子安装正在幕后进行。 Docker守护程序不知道其他进程正在使用该映像。 这可能会导致问题（例如，如果您在上面安装了Fedora映像，然后有人去执行了docker rmi fedora

集装箱存放

为了解决此问题，我们开始研究将图形驱动程序代码从上游docker守护程序中拉出到其自己的存储库中。 Docker守护程序将其所有锁定都锁定在图形驱动程序的内存中。 我们希望将这种锁定转移到文件系统中，这样我们可以有多个不同的进程能够同时操作容器存储，而不必执行单个守护进程。

我们创建了一个名为container / storage的项目，该项目可以执行运行，构建和存储容器所需的所有COW功能，而无需一个过程来控制和监视它（即不需要守护程序）。 现在，skopeo和其他工具和项目可以利用该存储。 其他开放源代码项目已开始使用容器/存储，并且在某些时候，我们希望将该项目合并回上游docker项目。

取消停靠，让我们创新

如果您考虑使用Kubernetes使用Docker守护程序在节点上运行容器时会发生什么情况，那么首先Kubernetes将执行以下命令：

此命令告诉kubelet在节点上运行NGINX应用程序。 kubelet调用CRI，并要求它启动NGINX应用程序。 此时，实现CRI的容器运行时必须执行以下步骤：

让我们看一下上述功能：

这意味着我们可以使用这些工具来实现使用容器的功能，而无需使用大型容器守护程序。

在基于中型和大型DevOps的CI / CD环境中，效率，速度和安全性至关重要。 并且，只要您的工具符合OCI规范，开发人员或操作员就应该使用最佳工具，以实现通过CI / CD管道到生产的自动化。 大多数容器工具都隐藏在业务流程或更高级别的容器平台技术之下。 我们设想到某个时候，运行时或映像包工具的选择可能会成为容器平台的安装选项。

系统（独立）容器

atomic host

flanneld ，它必须在启动Docker守护程序之前运行，以便将Docker守护程序传递给网络接口以运行Kubernetes Pod。 而且，flanneld将etcd用于其数据存储。 需要启动flanneld之前运行该守护程序。

如果我们想将etcd和flanneld作为容器图像进行运输，那么我们遇到了麻烦。 我们需要容器运行时守护程序来启动容器化的应用程序，但是这些应用程序需要在容器运行时守护程序启动之前运行。 我已经看到了几种处理这种情况的工具，但是没有一个是干净的。 另外，Docker守护程序当前还没有合适的方法来配置容器启动的优先级顺序。 我已经看到了有关此问题的建议，但是它们看起来都像是旧的SysVInit启动服务的方式（而且我们知道所造成的复杂性）。

系统的

atomic install --system etcd ，它将使用skopeo进入容器注册表并拉下etcd OCI映像。 然后，它将图像爆炸（或扩展）到OSTree后备存储中。 因为我们在生产中运行etcd，所以我们将映像视为只读。 接下来， atomic命令从容器映像中获取systemd单位文件模板，并在磁盘上创建一个单位文件以启动该映像。 单元文件实际上使用runc在主机上启动容器（尽管不需要runc

原子安装--system flanneld会发生类似的情况，除了这次flanneld单元文件指定在启动前需要运行etcd单元。

系统启动时，systemd确保etcd在flanneld之前运行，并且直到flanneld启动之后才启动容器运行时。 这使您可以将Docker守护程序和Kubernetes移至系统容器中。 这意味着您可以启动原子主机或基于rpm的传统操作系统，该操作系统将整个容器编排堆栈作为容器运行。 这非常强大，因为我们知道客户希望继续独立于这些组件来修补其容器主机。 此外，它将主机操作系统的占用空间降至最低。

原子install --system httpd命令安装的Apache容器。 将以与启动基于rpm的httpd服务相同的方式启动该容器映像（ systemctl start httpd除外，但httpd将在容器中启动）。 该存储可能是本地的，这意味着主机上的/ var / www已安装到容器中，并且该容器在端口80上侦听本地网络。这表明您可以在容器内部的主机上运行传统的工作负载，而无需容器运行时守护程序。

建筑容器图像

从我的角度来看，过去四年中有关容器创新的最可悲的事情之一就是缺乏用于构建容器映像的机制的创新。 容器映像不过是压缩包和一些JSON文件的压缩包。 容器的基本映像是rootfs以及描述基本映像的JSON文件。 然后，当您添加图层时，图层之间的差异会随着对JSON文件的更改而被压缩。 这些图层和基本文件一起压缩，以形成容器映像。

build和Dockerfile格式进行构建

• 除了执行Docker命令外，没有人构建标准工具来创建OCI映像。
• -containers和OpenShift S2I（Source2Image）之类的工具在后台也使用了docker -engine

• 巨大 。

• 由于这些原因，一些人已经请求压缩图像以消除层的机制。 我认为上游docker终于接受了满足需求的东西。
• 这些秘密可以最终存储在图像中的层中。 并且开发人员需要跳过圈来删除秘密。
• -v卷开关，但上游docker未接受这些补丁。

• 构建工件最终出现在容器映像内部。 因此，尽管Dockerfiles非常适合入门或在笔记本电脑上构建容器，同时试图了解您可能想要构建的映像，但它们实际上并不是在大型企业环境中构建映像的有效或高效手段。 在自动容器平台的背后，您不必在乎是否使用了更有效的方法来构建符合OCI的图像。

与Buildah停靠

在2017年DevConf.cz大会上，我请团队的Nalin Dahyabhai研究构建所谓的container-coreutils ，基本上是使用container / storage和container / image库，并构建一系列可以模仿Dockerfile的语法。 纳林决定取名为buildah ，取笑我在波士顿的口音。 使用一些buildah原语，您可以构建容器映像：

• gcc ， make和dnf之类的工具，则可以阻止或限制攻击者。
• 由于这些图像是通过Internet拉动的，因此缩小容器的大小始终是一个好主意。
• uildroot中。
• run命令要求所有可执行文件都在容器映像中。 仅在容器映像中使用dnf要求存在整个Python堆栈，即使您从未在应用程序中使用Python。
• ctr = $（来自fedora的buildah） ：

• 使用容器/图像从容器注册表中提取Fedora图像。
• ctr

• mnt = $（buildah mount $ ctr） ：

• $ ctr
• 返回安装点的路径。
• 现在，您可以使用此安装点写入内容。

• dnf安装httpd –installroot = $ mnt ：

• 您可以在主机上使用命令将内容重定向到容器中，这意味着您可以将机密信息保留在主机上，而不必将其放入容器中，并且可以将构建工具保留在主机上。
• dnf

• cp foobar $ mnt / dir ：

• 您可以使用bash中可用的任何命令来填充容器。

• buildah commit $ ctr ：

• 您可以随时决定创建一个图层。 您控制图层而不是工具。

• buildah config --env container = oci --entrypoint / usr / bin / httpd $ ctr ：

• 可以指定Dockerfile内部可用的所有命令。

• buildah运行$ ctr dnf -y install httpd ：

• run ，但是buildah不再依赖容器运行时守护程序，而是执行runc在锁定的容器内运行命令。

• buildah build-using-dockerfile -f Dockerfile。 ： ansible-containers和OpenShift S2I之类的工具以使用buildah而不是需要容器运行时守护程序。 mknod功能。 mknod功能允许进程创建设备节点。 某些软件包安装会尝试创建设备节点，但在生产中几乎没有应用程序会这样做。 在生产中从容器中删除mknod功能将使您的系统更安全。 / usr 。 但是在生产中，我认为您确实应该以只读模式运行所有容器。 仅允许容器写入已批量安装到容器中的tmpfs或目录。 通过从建筑物中拆分容器的运行方式，我们可以更改默认值，并提供一个更加安全的环境。

• 是的，buildah可以使用Dockerfile构建容器映像。

CRI-O Kubernetes的运行时抽象

Kubernetes添加了一个API来为名为Pod的容器运行时接口（CRI）的Pod插入任何运行时。 我不是在系统上运行许多守护程序的忠实拥护者，但是我们添加了另一个守护程序。 我的团队由Mrunal Patel领导，于2016年底开始研究CRI-O守护程序。这是一个用于运行基于OCI的应用程序的Container Runtime Interface守护程序。 从理论上讲，将来我们可以将CRI-O代码直接编译到kubelet中，以消除第二个守护程序。

与其他容器运行时不同，CRI-O的唯一目的就是满足Kubernetes的需求。 请记住上述Kubernetes运行容器所需的步骤。

Kubernetes向kubelet发送一条消息，要求它运行NGINX服务器：

CRI-O旨在成为运行Kubernetes的稳定平台，并且除非通过整个Kubernetes测试套件，否则我们不会发布CRI-O的新版本。 所有转到https:///Kubernetes-incubator/cri-o的拉取请求都针对整个Kubernetes测试套件运行。 如果不通过测试，您将无法向CRI-O发送拉取请求。 CRI-O完全开放，我们有来自多家不同公司的贡献者，包括Intel，SUSE，IBM，Google，。 只要大多数维护者都同意CRI-O的补丁程序，即使该补丁程序不是Red Hat想要的，它也会被接受。

结论

我希望这次深入的探讨可以帮助您了解Linux容器的发展方式。 曾经，Linux容器是每个厂商都面对的情况。 Docker帮助专注于事实上的图像创建标准，并简化了用于容器的工具。 现在，“开放容器计划”意味着该行业正在围绕核心图像格式和运行时开展工作，这将围绕使工具更有效地实现自动化，更安全，高度可扩展且更易于使用而进行创新。 容器使我们能够以新颖的方式检查安装软件，无论它们是运行在主机上的传统应用程序，还是运行在云中的经编排的微服务。 在许多方面，这仅仅是开始。

翻译自: https://opensource.com/article/17/7/how-linux-containers-evolved

linux 容器