docker.io 与 docker-ce 和 docker-ee（现在称为 "Mirantis Kubernetes Engine"）的关系是什么？
What is docker.io in relation to docker-ce and docker-ee (now called "Mirantis Kubernetes Engine")?
以前，要安装 docker 我会使用
apt-get install docker.io
但是，我最近注意到安装docker的文档，它使用docker-ce。我试图找出两者之间的区别，但一无所获。 docker.io 与 docker-ce 的关系是什么？
旧版本的 Docker 二进制文件被称为 docker 或 docker-engine 或 docker-io
docker-io 软件包仍然是 Debian/Ubuntu 在其 official repos 上提供的 docker 版本使用的名称.
docker-ce 是 docker.com and can also be built from source.
直接提供的认证版本
在 Debian/Ubuntu 平台上使用名称 docker-io 的主要原因是为了避免与 docker 系统托盘二进制文件发生名称冲突。
http://manpages.ubuntu.com/manpages/precise/man1/docker.1.html
Docker有企业版（EE）和免费社区版（CE）
在安装 Docker 社区版（docker-ce 来自 docker.com）之前，您可能需要删除旧的二进制文件。
Centos/RHL:
https://docs.docker.com/engine/installation/linux/docker-ce/centos/
sudo yum remove docker \
docker-client \
docker-client-latest \
docker-common \
docker-latest \
docker-latest-logrotate \
docker-logrotate \
docker-engine
Ubuntu/Debian:
https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/
$ sudo apt-get remove docker docker-engine docker.io containerd runc
Dry-运行 比较 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-ce
接受的答案不够复杂。
docker-ce 由 docker.com 提供，
docker.io 由 Debian 提供。
从表面上看，这意味着您可以立即安装 docker.io，而对于 docker-ce，您必须事先从 docker.com 附加一个外部存储库。
然而，更重要的是，虽然这两个软件包都提供了 Docker 的正确发布版本，但它们具有 非常不同的内部结构 :
docker.io 以 Debian（或 Ubuntu）的方式做到这一点：每个外部依赖项都是一个单独的包，可以并且将独立更新。docker-ce 以 Golang 方式进行：在构建和整个过程之前，所有依赖项都被拉入 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 Enterprise 现在是 Mirantis Kubernetes Engine:
其他答案写在Docker sold their enterprise assets to Mirantis之前。那次收购带来了巨大的变化......
如果您现在访问link“企业版”- https://docs.docker.com/ee/ - you'll find oogatz. That's because "Docker Enterprise" is now "Mirantis Kubernetes Engine
Swarm 的未来：
随着 Kubernetes 的采用和 Mirantis 购买 Docker 的企业资产，swarm 的未来受到质疑.然而，swarm 容器编排的未来现在似乎更加确定，因为根据这个blog post 其中指出：
"...customers have spoken — and many of them are completely satisfied
using Swarm instead of Kubernetes for container orchestration. With
that in mind, we’re excited to announce Swarm-only mode: a new
Mirantis Kubernetes Engine configuration option that dedicates the
platform exclusively to Swarm orchestration and Docker containers."
因此，出于企业规划的目的，swarm 似乎在 Kubernetes 世界中拥有未来。
但这并不是 Mirantis 的所有变化...
Docker CE 现在（主要）由第三方开发：
随着 v20.10 版本 于 20201209 生效，Docker CE 现在是 product of TWO separate Github Projects:
- docker/cli（仍由 Docker 管理）
- moby/moby（由第三方管理）
因此从 v20.10 开始，The Moby Project 现在将完成开发 Docker CE[=82 的繁重工作=] 而 Mirantis 追求货币化 Mirantis Kubernetes Engine。不要抱怨：Mirantis 毕竟是一家企业，他们必须盈利；没有惊喜。
Docker CE 的 docker-cli 部分仍然由 Docker 开发.显然 docker-cli 位很有趣，他们将其保留在内部...
结论：
在 IBM 收购了 Red Hat 并且 CentOS 被淘汰后，我想依赖 [=116 的组织也有类似的担忧=] 关于 Docker CE post Mirantis 收购的未来的容器化。看起来 Moby 项目 可以 接管 Mirantis 以拉动他们的 (5) 开发人员。但它最终会导致 Docker 的分叉，并且发展会走不同的道路。
Red Hat 雇用了 CentOs 项目人员（你不知道？），所以他们总是有责任遵循 RH 给他们的指示。我不知道 Docker 是否雇用或以其他方式支付剩余的 22/27 Moby 开发人员。考虑到 Mirantis 面临的商业压力需要 Docker 进行有利可图的收购，因此 Docker 格局未来可能会有进一步的 material 变化，这使得在当前格局下规划商业决策具有挑战性。 .
docker.io
这是由 Linux 发行版提供的。他们自己编译上游 docker 引擎，并添加一些特定于发行版的代码，主要是启动脚本。选择此名称是因为 docker 已被不相关的项目占用。此外，Debian 目前还有其他几个相关的软件包：
- docker-doc：单独打包的文档。
- rootlesskit：对于 运行 在没有 root 用户的情况下启用 docker 引擎。
- docker-compose：这是一个很好的选择，因为 Docker Inc 正在打包 compose，但是随着 compose 的第 2 版，它正在发生变化，它是用 Go 编写的并直接包含在docker命令行界面。
- docker-registry：注册表服务器的独立包装，尽管用例尚不清楚，因为几乎每个人 运行 都将其作为
registry:2 图像中的容器。
- credential helpers：有几个用于这些的包，如果您向云供应商验证您的注册表，它们会很有用。
docker-ce
这是社区版，又名 Docker Inc. 的 OSS 版本。这是大多数人在 Linux 上安装 docker 时的想法。此外，docker 存储库目前提供以下内容：
- docker-ce-cli: 可以只安装命令行不带引擎，用于远程访问其他主机上的docker引擎
- docker-ce-rootless-extras：在 docker 的最新版本中启用无根支持已经付出了很多努力，因此您可以 运行 作为您的用户的引擎而不是作为 root。
- docker-scan-plugin：这是一个可用于图像的漏洞扫描器。
docker-ce 的安装说明可从 Docker's website 获得。
docker-ee
这是企业版，是 Docker Inc. 的一部分，已出售给 Mirantis。有（自拆分以来我没有密切关注它）一些额外的功能编译到这个版本中，但是安装这个版本的两个主要原因是供应商支持（付费）和将它用作其他商业产品的基础，如UCP 和 DTR，它们是 Swarm/Kubernetes 之上的 UI 和注册服务器。除非您一直从事 Mirantis 销售并拥有许可证密钥，否则我认为没有任何理由安装此版本。
在 docker.io 和 docker-ce
之间选择
主要决定是从您的 Linux 发行版还是直接从 Docker 公司安装 docker 的 OSS 版本。需要考虑的几点：
- 关于 https://docs.docker.com 的文档将集中在 docker-ce.
- 来自 Docker Inc. 的问题支持将希望您安装他们的版本。只有当您是打包产品的开发人员时才公平，您只想支持自己的打包。
- 补丁和新版本将在 docker.io 之前的 docker-ce 提供。这对于时间敏感的安全问题可能很重要。
- 安装 docker-ce 需要向您的 sources.list 添加另一个存储库，这是一个值得信任的供应商，以及一个要随每个补丁更新的软件包列表。
- 如果您只需要 CLI 以便可以在远程机器上访问 docker（例如
DOCKER_HOST=ssh://you@example.com docker ps），您将需要使用 docker-ce-cli 包。
对我来说，如果您要为 运行ning 容器设置专用机器，请选择 docker-ce。如果您只是 运行 偶尔使用容器，请不要跟随 Docker Inc. 上游所做的事情，而是将机器用于许多其他任务，使用 docker.io 可以简化您的工作流程.
以前，要安装 docker 我会使用
apt-get install docker.io
但是，我最近注意到安装docker的文档，它使用docker-ce。我试图找出两者之间的区别，但一无所获。 docker.io 与 docker-ce 的关系是什么？
旧版本的 Docker 二进制文件被称为 docker 或 docker-engine 或 docker-io
docker-io 软件包仍然是 Debian/Ubuntu 在其 official repos 上提供的 docker 版本使用的名称.
docker-ce 是 docker.com and can also be built from source.
直接提供的认证版本在 Debian/Ubuntu 平台上使用名称 docker-io 的主要原因是为了避免与 docker 系统托盘二进制文件发生名称冲突。
http://manpages.ubuntu.com/manpages/precise/man1/docker.1.html
Docker有企业版（EE）和免费社区版（CE）
在安装 Docker 社区版（docker-ce 来自 docker.com）之前，您可能需要删除旧的二进制文件。
Centos/RHL:
https://docs.docker.com/engine/installation/linux/docker-ce/centos/
sudo yum remove docker \
docker-client \
docker-client-latest \
docker-common \
docker-latest \
docker-latest-logrotate \
docker-logrotate \
docker-engine
Ubuntu/Debian:
https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/
$ sudo apt-get remove docker docker-engine docker.io containerd runc
Dry-运行 比较 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-ce
接受的答案不够复杂。
docker-ce 由 docker.com 提供，
docker.io 由 Debian 提供。
从表面上看，这意味着您可以立即安装 docker.io，而对于 docker-ce，您必须事先从 docker.com 附加一个外部存储库。
然而，更重要的是，虽然这两个软件包都提供了 Docker 的正确发布版本，但它们具有 非常不同的内部结构 :
docker.io以 Debian（或 Ubuntu）的方式做到这一点：每个外部依赖项都是一个单独的包，可以并且将独立更新。docker-ce以 Golang 方式进行：在构建和整个过程之前，所有依赖项都被拉入 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 Enterprise 现在是 Mirantis Kubernetes Engine:
其他答案写在Docker sold their enterprise assets to Mirantis之前。那次收购带来了巨大的变化......
如果您现在访问link“企业版”- https://docs.docker.com/ee/ - you'll find oogatz. That's because "Docker Enterprise" is now "Mirantis Kubernetes Engine
Swarm 的未来：
随着 Kubernetes 的采用和 Mirantis 购买 Docker 的企业资产，swarm 的未来受到质疑.然而，swarm 容器编排的未来现在似乎更加确定，因为根据这个blog post 其中指出：
"...customers have spoken — and many of them are completely satisfied using Swarm instead of Kubernetes for container orchestration. With that in mind, we’re excited to announce Swarm-only mode: a new Mirantis Kubernetes Engine configuration option that dedicates the platform exclusively to Swarm orchestration and Docker containers."
因此，出于企业规划的目的，swarm 似乎在 Kubernetes 世界中拥有未来。
但这并不是 Mirantis 的所有变化...
Docker CE 现在（主要）由第三方开发：
随着 v20.10 版本 于 20201209 生效，Docker CE 现在是 product of TWO separate Github Projects:
- docker/cli（仍由 Docker 管理）
- moby/moby（由第三方管理）
因此从 v20.10 开始，The Moby Project 现在将完成开发 Docker CE[=82 的繁重工作=] 而 Mirantis 追求货币化 Mirantis Kubernetes Engine。不要抱怨：Mirantis 毕竟是一家企业，他们必须盈利；没有惊喜。
Docker CE 的 docker-cli 部分仍然由 Docker 开发.显然 docker-cli 位很有趣，他们将其保留在内部...
结论：
在 IBM 收购了 Red Hat 并且 CentOS 被淘汰后，我想依赖 [=116 的组织也有类似的担忧=] 关于 Docker CE post Mirantis 收购的未来的容器化。看起来 Moby 项目 可以 接管 Mirantis 以拉动他们的 (5) 开发人员。但它最终会导致 Docker 的分叉，并且发展会走不同的道路。
Red Hat 雇用了 CentOs 项目人员（你不知道？），所以他们总是有责任遵循 RH 给他们的指示。我不知道 Docker 是否雇用或以其他方式支付剩余的 22/27 Moby 开发人员。考虑到 Mirantis 面临的商业压力需要 Docker 进行有利可图的收购，因此 Docker 格局未来可能会有进一步的 material 变化，这使得在当前格局下规划商业决策具有挑战性。 .
docker.io
这是由 Linux 发行版提供的。他们自己编译上游 docker 引擎，并添加一些特定于发行版的代码，主要是启动脚本。选择此名称是因为 docker 已被不相关的项目占用。此外，Debian 目前还有其他几个相关的软件包：
- docker-doc：单独打包的文档。
- rootlesskit：对于 运行 在没有 root 用户的情况下启用 docker 引擎。
- docker-compose：这是一个很好的选择，因为 Docker Inc 正在打包 compose，但是随着 compose 的第 2 版，它正在发生变化，它是用 Go 编写的并直接包含在docker命令行界面。
- docker-registry：注册表服务器的独立包装，尽管用例尚不清楚，因为几乎每个人 运行 都将其作为
registry:2图像中的容器。 - credential helpers：有几个用于这些的包，如果您向云供应商验证您的注册表，它们会很有用。
docker-ce
这是社区版，又名 Docker Inc. 的 OSS 版本。这是大多数人在 Linux 上安装 docker 时的想法。此外，docker 存储库目前提供以下内容：
- docker-ce-cli: 可以只安装命令行不带引擎，用于远程访问其他主机上的docker引擎
- docker-ce-rootless-extras：在 docker 的最新版本中启用无根支持已经付出了很多努力，因此您可以 运行 作为您的用户的引擎而不是作为 root。
- docker-scan-plugin：这是一个可用于图像的漏洞扫描器。
docker-ce 的安装说明可从 Docker's website 获得。
docker-ee
这是企业版，是 Docker Inc. 的一部分，已出售给 Mirantis。有（自拆分以来我没有密切关注它）一些额外的功能编译到这个版本中，但是安装这个版本的两个主要原因是供应商支持（付费）和将它用作其他商业产品的基础，如UCP 和 DTR，它们是 Swarm/Kubernetes 之上的 UI 和注册服务器。除非您一直从事 Mirantis 销售并拥有许可证密钥，否则我认为没有任何理由安装此版本。
在 docker.io 和 docker-ce
之间选择主要决定是从您的 Linux 发行版还是直接从 Docker 公司安装 docker 的 OSS 版本。需要考虑的几点：
- 关于 https://docs.docker.com 的文档将集中在 docker-ce.
- 来自 Docker Inc. 的问题支持将希望您安装他们的版本。只有当您是打包产品的开发人员时才公平，您只想支持自己的打包。
- 补丁和新版本将在 docker.io 之前的 docker-ce 提供。这对于时间敏感的安全问题可能很重要。
- 安装 docker-ce 需要向您的 sources.list 添加另一个存储库，这是一个值得信任的供应商，以及一个要随每个补丁更新的软件包列表。
- 如果您只需要 CLI 以便可以在远程机器上访问 docker（例如
DOCKER_HOST=ssh://you@example.com docker ps），您将需要使用docker-ce-cli包。
对我来说，如果您要为 运行ning 容器设置专用机器，请选择 docker-ce。如果您只是 运行 偶尔使用容器，请不要跟随 Docker Inc. 上游所做的事情，而是将机器用于许多其他任务，使用 docker.io 可以简化您的工作流程.