小心 Docker

公认的答案是欠复杂。
docker-ce由www.example.com提供docker.com，docker.io由Debian提供。
从表面上看，这意味着您可以立即安装docker.io，而对于docker-ce，您必须事先从www.example.com附加一个外部存储库docker.com。
然而，更重要的是，尽管这两个软件包都提供了Docker的正确发布版本，但它们具有非常不同的内部结构：

• docker.io采用Debian（或Ubuntu）的方式：每个外部依赖项都是一个单独的软件包，可以并将独立更新。
• docker-ce采用Go的方式：所有的依赖项都在构建之前被拉到 source tree中，然后整个过程形成一个单独的包。所以你总是一次更新Docker的所有依赖项。

后一种方法的问题是它违背了Debian/Ubuntu试图做的很多事情。

如果每个人都像docker-ce那样做...

...您的系统上将有许多库的174个版本，这不仅消耗大量内存;它们也使得你根本不可能判断你的库XYZ的7.6.5版本中是否有这个可怕的安全漏洞，更不用说关闭这个漏洞（或者你拥有的所有109个示例）了。
更糟糕的是，174个版本中的一个很可能是三年前的XYZ版本5.4.3，它有另一个非常不同的，但同样巨大的安全漏洞，世界早已忘记了，但它仍然会快乐地存在于您的系统中。
一些备注：

• 很多网页称docker.io“过时”，那是因为它有一年左右没有维护，截至2019年8月，情况已不再如此。
• 我今天学到了所有这些here，现在将从使用docker-ce切换到使用docker.io--大概再也不会回去了。
• Debian/Ubuntu打包系统如此复杂是有原因的，一个很好的原因。

正如BobHy在评论中指出的那样，docker-ce方法也有一个优势：它不太可能与库XYZ有兼容性问题。您必须权衡您的风险。

旧版本的Docker二进制文件被称为 docker 或 docker-engine 或 docker-io。

docker-io包仍然是Debian/Ubuntu在official repositories上提供的Docker发行版的名称。
docker-ce是docker.com直接提供的认证版本，也可以是built from source。

在Debian/Ubuntu平台上使用名称 docker-io 的主要原因是为了避免与Docker系统托盘二进制文件的名称冲突。
http://manpages.ubuntu.com/manpages/precise/man1/docker.1.html
Docker有一个企业版（EE）和一个免费的社区版（CE）。
在安装Docker Community Edition（www.example.com上的docker-ce）之前docker.com，您可能需要删除较旧的二进制文件。
CentOS/Red Hat Linux（右半球）：

• 一个六个 *

sudo yum remove docker \
                  docker-client \
                  docker-client-latest \
                  docker-common \
                  docker-latest \
                  docker-latest-logrotate \
                  docker-logrotate \
                  docker-engine

Ubuntu/Debian：

• Install Docker Engine on Ubuntu**********

sudo apt-get remove docker docker-engine docker.io containerd runc

在Ubuntu上的试运行比较：

sudo apt-get install docker.io --dry-run

输出：

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  bridge-utils cgroupfs-mount containerd pigz runc ubuntu-fan
Suggested packages:
  ifupdown aufs-tools debootstrap docker-doc rinse zfs-fuse | zfsutils
The following NEW packages will be installed:
  bridge-utils cgroupfs-mount containerd docker.io pigz runc ubuntu-fan
0 upgraded, 7 newly installed, 0 to remove and 70 not upgraded.
Inst pigz (2.4-1 Ubuntu:18.04/bionic [amd64])
Inst bridge-utils (1.5-15ubuntu1 Ubuntu:18.04/bionic [amd64])
Inst cgroupfs-mount (1.4 Ubuntu:18.04/bionic [all])
Inst runc (1.0.0~rc7+git20190403.029124da-0ubuntu1~18.04.2 Ubuntu:18.04/bionic-updates, Ubuntu:18.04/bionic-security [amd64])
Inst containerd (1.2.6-0ubuntu1~18.04.2 Ubuntu:18.04/bionic-updates, Ubuntu:18.04/bionic-security [amd64])
Inst docker.io (18.09.7-0ubuntu1~18.04.4 Ubuntu:18.04/bionic-updates, Ubuntu:18.04/bionic-security [amd64])
Inst ubuntu-fan (0.12.10 Ubuntu:18.04/bionic [all])
Conf pigz (2.4-1 Ubuntu:18.04/bionic [amd64])
Conf bridge-utils (1.5-15ubuntu1 Ubuntu:18.04/bionic [amd64])
Conf cgroupfs-mount (1.4 Ubuntu:18.04/bionic [all])
Conf runc (1.0.0~rc7+git20190403.029124da-0ubuntu1~18.04.2 Ubuntu:18.04/bionic-updates, Ubuntu:18.04/bionic-security [amd64])
Conf containerd (1.2.6-0ubuntu1~18.04.2 Ubuntu:18.04/bionic-updates, Ubuntu:18.04/bionic-security [amd64])
Conf docker.io (18.09.7-0ubuntu1~18.04.4 Ubuntu:18.04/bionic-updates, Ubuntu:18.04/bionic-security [amd64])
Conf ubuntu-fan (0.12.10 Ubuntu:18.04/bionic [all])

第二个命令：

sudo apt-get install docker-ce --dry-run

输出：

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  aufs-tools cgroupfs-mount containerd.io docker-ce-cli libltdl7 pigz
The following NEW packages will be installed:
  aufs-tools cgroupfs-mount containerd.io docker-ce docker-ce-cli libltdl7 pigz
0 upgraded, 7 newly installed, 0 to remove and 70 not upgraded.
Inst pigz (2.4-1 Ubuntu:18.04/bionic [amd64])
Inst aufs-tools (1:4.9+20170918-1ubuntu1 Ubuntu:18.04/bionic [amd64])
Inst cgroupfs-mount (1.4 Ubuntu:18.04/bionic [all])
Inst containerd.io (1.2.10-3 Docker CE:bionic [amd64])
Inst docker-ce-cli (5:19.03.5~3-0~ubuntu-bionic Docker CE:bionic [amd64])
Inst docker-ce (5:19.03.5~3-0~ubuntu-bionic Docker CE:bionic [amd64])
Inst libltdl7 (2.4.6-2 Ubuntu:18.04/bionic [amd64])
Conf pigz (2.4-1 Ubuntu:18.04/bionic [amd64])
Conf aufs-tools (1:4.9+20170918-1ubuntu1 Ubuntu:18.04/bionic [amd64])
Conf cgroupfs-mount (1.4 Ubuntu:18.04/bionic [all])
Conf containerd.io (1.2.10-3 Docker CE:bionic [amd64])
Conf docker-ce-cli (5:19.03.5~3-0~ubuntu-bionic Docker CE:bionic [amd64])
Conf docker-ce (5:19.03.5~3-0~ubuntu-bionic Docker CE:bionic [amd64])
Conf libltdl7 (2.4.6-2 Ubuntu:18.04/bionic [amd64])

docker-ce binaries往往是最新版本，并包括docker-ce-cli。

docker.io

这是由Linux发行版提供的。他们自己编译上游Docker引擎，并添加一些发行版特定的代码，主要是在启动脚本中。之所以选择这个名字是因为docker已经被一个不相关的项目占用了。此外，Debian目前还有一些其他相关的软件包：

• docker-doc：单独打包的文档。
• 无根套件：用于在没有root用户的情况下运行Docker引擎。
• 对接-组合：自从Docker Inc打包compose以来，这是一个很好的选择，但随着compose的第2版（用Go语言编写，并直接包含在Docker CLI中），这一点正在发生变化。
• 码头注册处：注册表服务器的独立打包，尽管用例并不清楚，因为几乎每个人都将其作为registry:2映像中的容器运行。
• 凭据帮助程序：有几个包可以实现这些功能，如果您向云供应商验证注册表，这些包可能会很有用。

码头-ce

这是社区版，也就是Docker Inc.发布的OSS。这是大多数人在Linux上安装Docker时想到的。此外，目前在Docker repos上可以找到以下内容：

• 码头-采-克利：您可以只安装命令行而不安装引擎，并使用它远程访问其他主机上的Docker引擎。
• 码头-ce-无根-额外：在docker的最新版本中，已经做了很多工作来启用无根支持，这样您就可以以用户身份而不是根身份运行引擎。
• 停靠扫描插件：这是一个漏洞扫描程序，您可以使用它来扫描映像。

可从Docker's website获得安装docker-ce的说明。

Docker

这是企业版，是Docker公司的一部分，被卖给了米兰提斯。（自从拆分之后我就没有密切关注它）这个版本中编译了一些额外的特性，但是安装这个版本的两个主要原因是供应商支持并将其用作其他商业产品（如UCP和DTR）的基础，这是在Swarm/Kubernetes和注册表服务器上的UI。除非你一直在与Mirantis销售部门合作，并且有一个许可证密钥，否则我不认为有任何理由安装这个版本。

在docker.io和docker-ce之间选择

主要决定是从Linux发行版还是直接从Docker Inc.安装OSS版本的Docker。需要考虑的几点：

• https://docs.docker.com上的文档将集中在docker-ce上。
• Docker Inc.的问题支持会希望你安装了他们的版本。如果你是一个打包产品的开发人员，你只想支持你自己的打包，这才是公平的。
• 补丁和新版本将在docker.io之前从docker-ce获得。这对于时间敏感的安全问题可能很重要。
• 安装docker-ce需要在你的sources.list中添加另一个仓库，这是另一个值得信任的供应商，也是另一个要随每个补丁更新的包列表。
• 如果您只想使用CLI来访问远程计算机（例如DOCKER_HOST=ssh://you@example.com docker ps）上的Docker，则需要使用docker-ce-cli包。

对于我来说，如果你要设置一个专用的机器来运行container，那么就使用docker-ce，而如果你只是偶尔运行一个container，不要遵循Docker Inc.在上游所做的，而是使用这个机器来执行许多其他任务，那么使用docker.io可以简化你的工作流。

Docker Enterprise***现在是***米兰提斯Kubernetes引擎：

其他的答案都是在Docker sold their enterprise assets to Mirantis之前写的。那次收购带来了很大的变化...
如果您现在访问“企业版"的链接-https://docs.docker.com/ee/-您将找到oogatz。这是因为“Docker Enterprise”现在是“***Mirantis Kubernetes Engine***”
蜂群的未来：
随着Kubernetes和Mirantis收购Docker的Enterprise资产，**swarm的未来还不确定。但是，swarm**容器编排的未来现在似乎更加确定，因为它是Mirantis Kubernetes Engine v3.5的一个主要功能，根据blog post，它声明：
“...客户已经表达了意见，他们中的许多人对使用Swarm而不是Kubernetes进行容器编排非常满意。考虑到这一点，我们非常高兴地宣布推出纯Swarm模式：全新的Mirantis Kubernetes引擎配置选项，该平台专用于Swarm编排和Docker容器。”
因此，出于企业规划的目的，看起来swarm在Kubernetes的世界里有前途。
但这还不是米兰提斯的全部变化...

***Docker CE***现在（大部分）由第三方开发：

从20201209年的***v20.10版本***起生效，***Docker CE***现在是product of two separate GitHub Projects：

• docker/cli（仍由Docker管理）
• moby/moby（由第三方管理）

因此，从v20.10开始，The Moby Project现在将承担开发***Docker CE***的繁重工作，而Mirantis则致力于将***Mirantis Kubernetes Engine***货币化。米兰提斯毕竟是一家企业，他们必须盈利;这并不奇怪。
Docker CE***的docker-cli部分仍然是由Docker开发的。显然docker-cli位很有趣，他们将其保留在内部...

结论：

在IBM收购Red Hat和***CentOS***被淘汰之后，我想依赖Docker容器化的组织对***Docker CE**在收购Mirantis之后的未来也有类似的担忧。看起来Moby Project**可以 * 接管Mirantis的开发人员。但它最终会导致Docker的分叉和开发走上不同的道路。
红帽雇佣了CentOS项目人员（ 你不知道？）所以他们总是有义务遵循红帽给他们的方向。我不知道Docker是否雇佣或以其他方式支付剩余的22/27 Moby开发人员。考虑到Mirantis承受的商业压力，未来Docker的前景可能会有进一步的实质性变化，这使得Docker成为一个有利可图的收购项目，从而使规划商业化在当前形势下做出的决定...