关于segmentfault:不止Docker8款容器管理开源方案

Docker 诞生于 2013 年，并遍及了容器的概念，以至于大多数人依然将容器的概念等同于“Docker 容器”。

作为第一个吃螃蟹的人，Docker 设置了新加入者必须恪守的规范。例如，Docker 有一个大型零碎镜像库。所有的代替计划都必须应用雷同的镜像格局，同时试图扭转 Docker 所基于的整个堆栈的一个或多个局部。

在此期间，呈现了新的容器规范，容器生态系统朝着不同方向倒退。当初除了 Docker 之外，还有很多办法能够应用容器。

在本文中，咱们将介绍以下内容：

1. 将 Chroot、cgroups 和命名空间作为容器的技术根底
2. 定义 Docker 所基于的软件堆栈

1. 阐明 Docker 和 Kubernetes 须要保持和恪守的规范

1. 介绍代替解决方案，这些解决方案尝试应用具备更好更平安的组件来替换原始 Docker 容器。

容器的软件堆栈

像 Chroot 调用、cgroups 和命名空间等 Linux 个性帮忙容器在与所有其余过程隔离的状况下运行，从而保障运行时的安全性。

Chroot

所有相似 Docker 的技术都起源于相似 Unix 操作系统（OS）的根目录。在根目录上方是根文件系统和其余目录。

从久远来看，这是很危险的，因为根目录中任何不须要的删除都会影响整个操作系统。这就是为什么存在一个零碎调用 chroot()。它创立了额定的根目录，例如一个用于运行遗留软件，另一个用于蕴含数据库等等。

对于所有这些环境，chroot 仿佛是一个真正的根目录，而是实际上，它只是将路径名增加到任何以 / 结尾的名字上。真正的根目录依然存在，并且任何过程都能够援用指定根目录以外的任何地位。

Linux cgroups

自 2008 年 2.6.24 版本以来，Control groups (cgroups) 始终是 Linux 内核的一项性能。Cgroup 将同时限度、隔离和测量多个过程的系统资源（内存、CPU、网络和 I /O）应用状况。

假如咱们想阻止用户从服务器发送大量电子邮件。咱们创立了一个内存限度为 1GB、CPU 占用率为 50% 的 cgroup，并将应用程序的 processid 增加到该组中。当达到这些限度时，零碎将限度电子邮件发送过程。它甚至可能终止过程，这取决于托管策略。

Namespaces

Linux 命名空间是另一个有用的形象层。命名空间容许咱们领有许多过程档次，每个档次都有本人的嵌套“子树（subtree）”。命名空间能够应用全局资源，并将其出现给其成员，就像它是本人的资源一样。

具体来看，Linux 零碎开始时的过程标识符（PID）为 1，并且所有其余过程将蕴含在其树中。PID 命名空间容许咱们逾越一棵新树，它领有本人的 PID 1 过程。当初有两个值为 1 的 PID，每个命名空间能够产生本人的命名空间，并且雷同的过程能够附加了几个 PID。

子命名空间中的一个过程将不晓得父级的过程存在，而父命名空间将能够拜访整个子命名空间。

有七种类型的名称空间：cgroup、IPC、网络、mount、PID、用户和 UTS。

Network Namespace

一些资源是稀缺的。依照常规，有些端口具备预约义的角色，不利用于其余任何用处：端口 80 仅服务于 HTTP 调用，端口 443 仅服务于 HTTPS 调用等等。在共享主机环境中，两个或多个站点能够监听来自端口 80 的 HTTP 申请。第一个取得该端口的站点不容许任何其余应用程序拜访该端口上的数据。第一个应用程序在互联网上是可见的，而其余所有应用程序将不可见。

解决方案是应用网络命名空间，通过网络命名空间，外部过程将看到不同的网络接口。

在一个网络命名空间中，同一端口能够是凋谢的，而在另一个网络命名空间中，能够敞开该端口。为此，咱们必须采纳额定的“虚构”网络接口，这些接口同时属于多个命名空间。两头还必须有一个路由器过程，将达到物理设施的申请连贯到相应的名称空间和其中的过程。

简单吗？这就是为什么 Docker 和相似工具如此受欢迎。当初让咱们来介绍一下 Docker，以及它的代替计划。

Docker: 人人可用的容器

在容器统治云计算世界之前，虚拟机十分风行。如果你有一台 Windows 机器，但想为 iOS 开发挪动应用程序，你能够购买一台新的 Mac，或者将其虚拟机装置到 Windows 硬件上。虚拟机也可能是轻便的，它们常常吞噬不须要的资源，而且启动速度通常很慢（长达一分钟）。

容器是规范软件单元，具备运行程序所需的所有：操作系统、数据库、镜像、图标，软件库、代码和所需的其余组件。容器的运行也与所有其余容器，甚至与操作系统自身隔离。与虚拟机相比，容器是轻量级的，所以它们能够疾速启动，并且容易被替换。

要运行隔离和爱护，容器须要基于 Chroot、cgroups 和命名空间。

容器的镜像是在理论机器上造成应用程序的模板，可能依据单个镜像创立尽可能多的容器，一个名为 Dockerfile 的文本文件蕴含了组装镜像所需的所有信息。

Docker 带来的真正反动是创立了 Docker 镜像仓库和开发了 Docker 引擎，这些镜像以雷同的形式在各地运行，作为第一个被宽泛采纳的容器镜像，造成了一个不成文的世界规范，所有起初的入局者都必须关注它。

CRI and OCI

OCI 全称为 Open Container Initiative，它公布镜像和容器的标准。它于 2015 年由 Docker 发动，并被微软、Facebook、英特尔、VMWare、甲骨文和许多其余行业巨头承受。

OCI 还提供了标准的一个实现，被称为 runc，它能够间接应用容器，创立并运行它们等。

容器运行时接口（Container Runtime Interface，简称 CRI）是一个 Kubernetes API，它定义了 Kubernetes 如何与容器运行时交互。它也是标准化的，所以咱们能够抉择采纳哪个 CRI 实现。

用于 CRI 和 OCI 的容器的软件堆栈

Linux 是运行容器的软件堆栈中最根本的局部：

请留神，Containerd 和 CRI- O 都保持 CRI 和 OCI 标准。对于 Kubernetes 而言，这意味着它能够应用 Containerd 或 CRI-O，而用户不会留神到其中的区别。它还能够应用咱们当初要提到的任何其余代替计划——这正是创立和采纳了 OCI 和 CRI 等软件规范的指标。

Docker 软件堆栈

Docker 的软件堆栈包含：

docker-cli，面向开发者的 Docker 命令行界面

containerd，最后由 Docker 编写，起初作为一个独立的我的项目启动; 它实现了 CRI 标准

runc，它实现了 OCI 标准

容器（应用 chroot、cgroups、命名空间等）

Kubernetes 的软件堆栈简直是雷同的；Kubernetes 应用 CRI-O，而不是 Containerd，这是由 Red Hat / IBM 和其他人创立的 CRI 实现。

containerd

containerd 作为一个守护程序在 Linux 和 Windows 上运行。它加载镜像，将其作为容器执行，监督底层存储，并负责整个容器的运行工夫和生命周期。

Containerd 诞生于 2014 年，一开始作为 Docker 的一部分，2017 年成为云原生计算基金会（CNCF）中的一个我的项目，并于 2019 年年初毕业。如果你想理解一些 Containerd 的应用技巧，欢送查看下方的文章：

配置 containerd 镜像仓库齐全攻略

runc

runc 是 OCI 标准的参考实现。它创立并运行容器以及其中的过程。它应用较低级别的 Linux 个性，比方 cgroup 和命名空间。

runc 的代替计划包含 Kata-Runtime、GVisor 和 CRI-O。

Kata-Runtime 应用硬件虚拟化作为独自的轻量级 VM 实现 OCI 标准。它的运行时与 OCI、CRI- O 和 Containerd 兼容，因而它能够与 Docker 和 Kubernetes 无缝工作。

Google 的 gVisor 创立蕴含本人内核的容器。它通过名为 runsc 的我的项目实现 OCI，该我的项目与 Docker 和 Kubernetes 集成。有本人内核的容器比没有内核的容器更平安，但它不是万能的，而且这种办法在资源应用上要付出代价。

CRI- O 是一个纯正为 Kubernetes 设计的容器堆栈，是 CRI 规范的第一个实现。它从任何容器镜像仓库中 提取镜像，能够作为应用 Docker 的轻量级代替计划。

明天它反对 runc 和 Kata Containers 作为容器运行时，但也能够插入任何其余 OC 兼容的运行时（至多在实践上）。

它是一个 CNCF 孵化我的项目。

Podman

Podman 是一个没有守护过程的 Docker 替代品。它的命令无意与 Docker 尽可能兼容，以至于您能够在 CLI 界面中创立一个别名并开始应用单词“Docker”而不是“podman”。

Podman 的指标是取代 Docker，因而保持应用雷同的命令集是有意义的。Podman 试图改良 Docker 中的两个问题。

首先，Docker 总是应用外部守护过程执行。守护过程是在后盾运行的单过程。如果它失败了，整个零碎就会失败。

第二，Docker 作为后盾过程运行，具备 root 权限，所以当你给一个新的用户拜访权时，你实际上是给了整个服务器的拜访权。

Podman 是一个近程 Linux 客户端，可间接从操作系统运行容器。你也能够以 rootless 模式运行它们。它从 DockerHub 下载镜像，并以与 Docker 完全相同的形式运行它们，具备完全相同的命令。

Podman 以 root 以外的用户身份运行命令和镜像，所以它比 Docker 更平安。另一方面，有许多为 Docker 开发的工具在 Podman 上是不可用的，如 Portainer 和 Watchtower。解脱 Docker 意味着放弃你之前建设的工作流程。

Podman 的目录构造与 buildah、skopeo 和 CRI- I 相似。它的 Pod 也十分相似于 KubernetesPod。

Linux 容器：LXC 和 LXD

LXC（LinuX Containers）于 2008 年推出，是 Linux 上第一个上游内核的容器。Docker 的第一个版本应用了 LXC，但在起初的倒退中，因为曾经实现了 runc，所以 LXC 被移除了。

LXC 的指标是应用一个 Linux 内核在一个管制主机上运行多个隔离的 Linux 虚拟环境。为此，它应用了 cgroups 性能，而不须要启动任何虚拟机；它还应用命名空间，将应用程序与底层零碎齐全隔离。

LXC 旨在创立零碎容器，简直就像你在虚拟机中一样——但硬件开销很小，因为这些硬件是被虚拟化的。

LXC 不模仿硬件和软件包，只蕴含须要的应用程序，所以它简直以裸机速度执行。相同，虚拟机蕴含整个操作系统，而后模仿硬件，如硬盘、虚构处理器和网络接口。

所以，LXC 是小而快的，而虚拟机是大而慢的。另一方面，虚拟环境不能被打包成现成的、可疾速部署的机器，而且很难通过 GUI 治理控制台进行治理。LXC 要求技术人员有很高的技术水平，并且优化后的机器可能与其余环境不兼容。

LXC VS Docker

LXC 就像 Linux 上的一个增压 chroot，它产生的“小”服务器启动更快，须要更少的 RAM。然而，Docker 提供了更多个性：

• 跨机器的可移植部署：应用一个版本的 Docker 创立的对象能够传输并装置到任何其余反对 Docker 的 Linux 主机上。
• 版本控制：Docker 能够用一种相似 git 的形式跟踪版本——您能够创立容器的新版本，将它们回滚等等。
• 重复使用组件：应用 Docker，您能够将曾经创立的包重叠到新包中。如果您想要一个 LAMP 环境，能够装置一次它的组件，而后将它们作为事后制作的 LAMP 镜像从新应用。
• Docker 镜像存档：能够从专用站点下载数十万个 Docker 镜像，并且很容易将新镜像上传到这样的镜像仓库中。

LXC 面向系统管理员，而 Docker 更面向开发人员。这就是 Docker 更受欢迎的起因所在。

LXD

LXD 有一个特权守护过程，它通过本地 UNIX socket 和网络（如果启用）公开 REST API。您能够通过命令行工具拜访它，但它总是应用 REST API 调用进行通信。无论客户端是在本地机器上还是在近程服务器上，它的性能都是一样的。

LXD 能够从一台本地机器扩大到几千台近程机器。与 Docker 相似，它是基于镜像的，所有更风行的 Linux 发行版都能够应用镜像。Ubuntu 的公司 Canonical 正在赞助 LXD 的开发，因而它将始终运行在 Ubuntu 以及其余相似 Linux 操作系统的最新版本上。LXD 能够与 OpenNebula 和 OpenStack 规范无缝集成。

从技术上讲，LXD 是站在 LXC 的肩膀上（两者都应用雷同的 liblxc 库和 Go 语言创立容器），但 LXD 的指标是改善用户体验。

Docker 会永远存在吗？

Docker 领有 1100 万开发者、700 万个应用程序和每月 130 亿次的镜像下载。如果仅仅说 Docker 依然是领导，那就太轻描淡写了。然而，在这篇文章中，咱们曾经看到，当初曾经有许多产品能够取代 Docker 软件栈的一个或多个局部，并且通常状况下没有兼容性问题。而且与 Docker 提供的服务相比，其他软件的次要指标是安全性。

原文链接：

https://community.suse.com/po…