Docker诞生于2013年，并遍及了容器的概念，以至于大多数人依然将容器的概念等同于“Docker容器”。
作为第一个吃螃蟹的人，Docker设置了新加入者必须恪守的规范。例如，Docker有一个大型零碎镜像库。所有的代替计划都必须应用雷同的镜像格局，同时试图扭转Docker所基于的整个堆栈的一个或多个局部。
在此期间，呈现了新的容器规范，容器生态系统朝着不同方向倒退。当初除了Docker之外，还有很多办法能够应用容器。
在本文中，咱们将介绍以下内容：
- 将Chroot、cgroups和命名空间作为容器的技术根底
- 定义Docker所基于的软件堆栈
- 阐明Docker和Kubernetes须要保持和恪守的规范
- 介绍代替解决方案，这些解决方案尝试应用具备更好更平安的组件来替换原始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…
发表回复