6大分类17大有用的docker工具：再见 Docker 我删除了使用六年的

6大分类17大有用的docker工具：再见 Docker 我删除了使用六年的Buildah 负责构建 OCI 镜像。令人困惑的是，podman build 也能够用于构建 Docker 镜像，但其速度太慢而且默认使用 vfs 存储驱动的设置会占用大量磁盘空间。相比之下，buildah bud（「利用 Dockerfile 构建」）对我来说速度更快，而且能够自动覆盖存储驱动。Buildahzwischenzugs 原本由 Docker 负责的工作现在基本都由红帽发布的三款工具接管了，分别是 Podman、Skopeo 与 Buildah。它们都不需要守护程序，也不需要访问 root 权限组。PodmanPodman 能够替代大部分子命令（run push pull 等等）。由于不需要守护程序，而且会利用用户命名空间模拟容器中的 root，所以 Podman 不需要接入具有 root 权限的 socket——这就解决了 Docker 长期以来一直面临的老大难问题。

近日，网友 zwischenzugs 发文称，他把自己已经使用了六年的家庭服务器中的 docker 都删除了，并使用了其它开源软件来替代 Docker。

为什么要和 Docker 告别？

为什么 zwischenzugs 会选择把所有家庭服务器里的 Docker 都一齐删除（apt purge -y docker-ce）呢？因为他总是会遇到一个反复出现且令人头痛的问题：“Docker 守护程序在多个核心上占用 100% CPU 资源，并导致主机无法正常使用。”

zwischenzugs 认为出现这种情况，最可能的原因是脚本失控导致启动了太多容器，但是他也一直没能找出更深层次的原因，因为如果想搞清楚原因，必须先删除所有容器，然后重启守护程序。由于已经删除了 Docker，这时再去探究根源似乎也没什么必要了。

当然，删除了 Docker，并不意味着 zwischenzugs 对 Docker 有所抱怨，只是他突然又想到了之前听过的一个争论：“Docker 干嘛要配一个守护程序？”

替换 Docker 的具体步骤

zwischenzugs 原本由 Docker 负责的工作现在基本都由红帽发布的三款工具接管了，分别是 Podman、Skopeo 与 Buildah。它们都不需要守护程序，也不需要访问 root 权限组。

Podman

Podman 能够替代大部分子命令（run push pull 等等）。由于不需要守护程序，而且会利用用户命名空间模拟容器中的 root，所以 Podman 不需要接入具有 root 权限的 socket——这就解决了 Docker 长期以来一直面临的老大难问题。

Buildah

Buildah 负责构建 OCI 镜像。令人困惑的是，podman build 也能够用于构建 Docker 镜像，但其速度太慢而且默认使用 vfs 存储驱动的设置会占用大量磁盘空间。相比之下，buildah bud（「利用 Dockerfile 构建」）对我来说速度更快，而且能够自动覆盖存储驱动。

用户命名空间允许无 root 构建的功能对我来说同样非常重要。现在，至少在 Ubuntu 上，我们已经能够利用 /etc/subuid 与 /etc/subgid 以开箱即用的方式享受这一便利。

Skopeo

Skopeo 工具允许我们对 Docker 与 OCI 镜像执行 psuh、pull 以及 copy 等操作。

与半年前相比，如今在 Ubuntu 上安装这些工具已经变得非常简便。不过，runc 好像还是需要独立安装，其实 runc 也可以预先设置好。

安装好之后，我们就来一起看看具体的替换步骤吧。首先，要在 cron 当中替换掉所有 Docker 实例，并通过 Podman 替换所有 CI 任务。这项工作非常轻松，Ansible 脚本就能轻松搞定，剩下的一点问题在 GitHub 库里搜索一下也可快速解决。

在完成上述操作后，可以利用 sysdig 查看是否还有指向 docker 的引用调用：sysdig | grep -w docker，需要注意的是，这项操作比较占用资源，可能会大大降低系统运行速度。

在确定不存在任何 docker 调用之后，可以运行以下命令：apt remove -y docker-ce。

为了保证之后还能找到某些需要使用的配置，zwischenzugs 并没有彻底删除所有用例。当在一切开始稳定运行之后，最后一步就是进行“大扫除”：删除 /etc/apt/* 当中所有指向 Docker apt repo 的剩余源；使用 delgroup docker 从系统当中删除 docker 组；删除 etc/docker / *、 /etc/default/docker 以及 /var/lib/docker 当中的所有剩余文件。

也许有人会好奇 Docker Compose 是如何处理的？zwischenzugs 表示：“我其实一直没用它，所以也就没什么问题。如果使用了的朋友可以尝试 podman-compose 项目，只不过该项目目前还不太成熟。”

替换前后，有何不同？

完成这番替换之后，有哪些不同呢？zwischenzugs 表示：“除了告别守护程序和告别 sudo 访问要求之外，我并没觉得有什么其它区别。对用户来说，builds 都存放在本地（~/.local/containers 当中）而非全局（/var/lib/docker 当中）。这也与此次使用的工具的设计原理保持一致，即面向用户而非面向守护程序。不过由于我的家庭服务器中只有一个 Docker 用户，所以也谈不上有多大区别。”

另一个重大差异在于，与 Docker 相比，podman pull 会并行下载所有层。如果一次性 pull 太多镜像可能会引发问题，但是 zwischenzugs 表示，就他自己的用例而言，目前一切运转良好。

网友如何看待？

这篇博文发布之后，在 Hacker News 上引发了网友的广泛讨论，有网友表示：“放弃 Docker 似乎正在成为新的潮流，最近看到了好几篇这样的文章，我仔细查看了每篇文章，得出了一个结论，那就是如果你有比较多的时间，且愿意接受比较多的限制，那么 Docker 是有很多替代品的。”

因为前文中，zwischenzugs 提到了出现异常情况可能的原因是脚本失控导致启动了太多容器，所以也有网友建议可以修复错误脚本，不需大动干戈切换容器平台来解决。

不过，也有网友对 Docker 本身提出了疑问，Docker 到底能带来什么样实质性的好处：用户真的能够从容器中获得好的抽象，从而为部署挑战提供了更好的解决方案? 例如，无需考虑应用程序中的 http 客户机被配置为与哪个主机通信，可以通过操作网络配置在容器级别神奇地重新定向它。如果构建的应用程序使用服务发现结构，那么同时使用 Docker 是否会获得额外的好处呢? 人们经常在本地运行生产 Docker 映像来调试生产应用程序问题吗? 是否存在这样的解决方案，将调试器附加到远程 QA 测试人员 chrome 实例上，然后自动将调试器附加到处理与该浏览器相关的请求的生产容器集上?

您如何看待网友的这次 Docker 删除操作？删除 Docker 是否正在成为新的流行？Docker 到底能带来什么样实质性的好处？欢迎在下方留言评论。

原文链接：

https://zwischenzugs.com/2019/07/27/goodbye-docker-purging-is-such-sweet-sorrow/