k8s 抛弃 docker 之后， docker 还有前途吗？

[julyclyde]

换个角度，新人还有必要从 docker 开始学吗？

感觉不如直接 podman 或者 containerd 算了？

[duke807]

從來沒用過 docker ，用不上，喜歡裸跑

[lntouchables]

@duke807 经典答非所问

[bootvue]

没前途了 但是最好系统学一下

[k9982874]

也不是什么规模的项目都无脑 k8s
中小规模的项目还是用 docker 方便

[Hanggi]

完全没必要在意，继续用 docker 就好了，不影响的。

[bwangel]

如果问题是，是否有必要阅读 docker 的代码？我觉得这个还要犹豫一下？

如果只是学习 docker 的用法，那没什么犹豫的，直接学就好了，这个很简单的，一周就了解的差不多了。

[star7th]

直接学 docker ，因为 docker 现存的资源资料多，生态完善。你学好 docker 使用其他也完全无障碍。

[yangyaofei]

k8s 是既定标准, docker 难道不是了? 再说了, 我一个小项目还要上 k8s, 牙签搅水缸. 本来仨程序猿搞定的, 上了 k8s 再来一个会运维 k8s 的?

podman 和 containerd 和 docker 有啥区别? 命令都一样. 又不是看源码

一般项目, docker-compose 基本就完全够了, 就是个工具有啥前途不前途的.

[christin]

docker 只能做 k8s ？一棍子打死系列

[dayeye2006199]

LZ 可以了解一下 containerd, runc, OCI ，这些都是广义上 docker 的构成部分

[BeautifulSoap]

说真的，docker 这东西这么简单，花个几天时间就基本学会了用法和 Dockerfile 还有 docker-compose 了，为什么还会纠结学不学这问题

[CallMeReznov]

不知道这个比喻恰当不恰当.
考驾照时的车都是柴油皮卡,自己买几乎自动挡汽油车.
你使用某一种车型学习驾驶技术是可以其他同类型车辆互通的.

当然,开卡车的话还是得重新学习一下.

[encro]

经典回答：


学不需要理由，不学有一万个理由。

[encro]

大部分人只是学习命令行接口，
接口方面 podman 完全兼容 docker 。
只是没有 dockerd 。。。docker-compose 都兼容了。
从使用上来说，学了 docker 命令，基本就等于学了 podman 。
哪怕你只是稍微浏览了了一眼 podman 介绍，试了一下，也不至于有这个问题。

所以被喷是理所当然的。

[Webpoplayer]

我的环境来说,docker-compose 够用了 ..

[tftk]

学习的话概念差不多，docker 的文档写的比较好

[JaguarJack]

我只用 docker 做开发环境

[bruce0]

容器我拿 docker 学习入门的，那时候好像还没有 podman 之类的，后面在云服务器上和自己的本地 linux 都装了 podman ，因为这个是发行版自带的，不想折腾了

日常使用这俩基本没啥差别，唯一让我感到有区别的地方，docker 在机器重启后原来用 docker 运行的容器都会恢复，podman 需要手动恢复，官方推荐用 systemctl 自己加入开机服务

这东西本来就是很相似的东西，有点像 mysql 和 Mariadb 日常的基础使用，基本感受不到区别

[ch2]

docker 又不是只有 k8s 一个用途，k8s 才是真的非必要没有学的价值，而 docker 不管学不学 k8s 都要用

[ytll21]

对于程序员而言，开发代码是用不到 docker 的，只有运维才需要学习吧。

[luckyrayyy]

各类容器其实差别不大的，你把一个搞懂了用熟悉了，别的只看看区别部分就行了

[ch2]

@ytll21 怎么编译 docker ？最方便的办法是用 docker 编译它自己。不用 docker 你想跑个 build 都难上加难

[sanxianA]

@ytll21 不会的啊，如果是有引入 devops 之类的解决方案的开发，是需要最起码了解 dockerfile 之类的语法，还有 docker 运行环境的特性来提高开发效率的。对自己写出来的东西的运行环境越了解，才能在排障的时候更快定位故障

[xratzh]

我基本都迁移到 docker 了，现在新的技术出来其实也没有多么方便。无非就是从 60 到 95 的感觉，现在 98 的技术出来了。

[yyfearth]

@ytll21 不是哦 首先 docker 不是只用来部署线上服务的 很多时候也用来开发测试 或者本地搭建环境和脚手架
如果线上用了容器 这样本地环境和线上环境比较相似 可以避免一些麻烦

另外 现在越来越多全栈 其中 devops 也是很重要的一个技能 你的的代码你要自己部署上线 就是可能有运维帮忙 对于全栈 负责任的人还是自己

就算有专业的运维 如果线上用容器 也应该和开发一起讨论容器的一些细节和兼容问题 比如那个 Linux 发行版 以及某些库的版本
另外如果线上出问题 那么肯定也要跑到容器里面 或者拉下来一个容器来测试复现之类的 那么基本的容器的操作还是要会的

总之 现在除非真的在一个地方养老 如果是做线上系统的 还是一定要学一下容器的

[julyclyde]

docker 把 containerd 分离出来之后，“docker 自己”其实已经没什么独门绝技了吧
感觉已经没有自己的护城河了

它能做的事情，podman 都能做；它不符合的标准，containerd 都符合
那，继续用它的“必要性”在哪儿呢？

[julyclyde]

@yangyaofei docker 已经把标准凝聚到 containerd 里面了。“docker 自己”现在只有命令行习惯这一个标准，还被 podman 抄了


@bruce0 你已经入门了就不是我问的情况了
我是在考虑培养新人的路子，是不是可以直接 podman 算了。反正“docker 和”podman 都一样

[julyclyde]

@bwangel 不同代的 docker 源代码差异太大了：
从最古代的“一个可执行文件”，到“c/s 架构”，到“c/s/containerd/runc”四层架构，变化太大了

[acmore]

如果你接触的东西没有让你学习的动力或契机，那么就不用学，无论 K8S 拥抱还是抛弃都不用学。

[FrankFang128]

学东西，学的是概念，不是具体的工具。

[cheng6563]

单体临时容器：podman ，docker 都可以，docker 构建镜像创建容器比较快，podman 对于 rootless 友好
非集群的容器 /手动编排的集群容器：docker-compose (非 docker-swarm ）
自动编排的集群：k8s

[pydiff]

你试用一下 docker,podman 跟 contsinerd 就知道了，反正我的体验就是 docker 秒杀后者

[kingfalse]

k8s 跟 docker 两个东西，不是说 k8s 不用 docker ，docker 就会死

[xiaoz]

有必要，Docker 生态目前非常完善和成熟。而且你看很多开源工具的安装都有 docker 镜像，再比如很多 NAS 内置 docker 而不是 podman

[jsq2627]

"docker" 是个 umbrella term 。估计楼上每一层对楼主提问的“docker“都有不一样的理解。

[aecra]

k8s 和 docker 这两个的产品之争有必要陪他们玩吗？

[ragnaroks]

你放心，podman 会比 docker 先死

[zyy314680012]

开发用 docker 挺好

[a728976009]

docker 很早之前就开始了组件化，moby 早在几年前就搞起来了，从构建和运行的角度来看，docker 基本上可以等同于 buildkit 和 containerd 了，所以，弃用 docker 也就无从谈起。而从普遍适用性的角度来看，docker 仍然是最普遍的容器构建工具和运行时。
所谓 k8s 弃用 docker ，正确的说法应该是 k8s 弃用 docker-shim ，不得不说 google 的话术足够狡猾。
至于 podman ，从体验中看不到跟 docker 的任何优势，我用的是时候记得 dockerhub 的镜像还需要强制加上 docker.io 的 registry 前缀，就这一点就放弃了，一大堆已有的 dockerfile 总不能一个一个改吧，而且实测 buildkit 的构建效率也要比 buildah 快，没动力折腾。

[0312birdzhang]

@yangyaofei 一开口就是老 k8s 受害者了😂

[SIGEV13]

商业上前途没有以前那么好了。
工程上，他还是那个成熟的解决方案。
如果专注 k8s 开发，还是可以从 docker 开始熟悉工程环境。

[zhixi]

小厂一般的项目没有大规模集群上个 docker 就够了，k8s 这种又大又重的东西大部分小项目用就是给自己找麻烦。目标场景都不一样。

正常的竞争关系是
k8s vs swarm
docker vs podman

应该问，还有必要学 swarm 吗？

[junnplus]

可以用 nerdctl 来代替 docker cli
nerdctl 是 containerd 的一个非核心项目，兼容 docker cli 命令

[ch2]

@julyclyde podman 并不是对 docker 的完全兼容，大量的现存资料均是用 docker 作为 example 而不是 podman

[duke807]

你們可真夠雙標的

你們說 k8s 太重，大多數項目沒必要用，隱含意思是建議用 docker ，推導出 docker 有前途

而我一樓是說 docker 也太重，直接裸跑不用容器更方便，隱含意思是 docker 可有可無，沒啥前途

怎麼我就成經典答非所問了。。。

[ruidoBlanco]

玩过 k8s ，玩过 nomad ，但是现在我自己的几台 vps 组的是 docker swarm ，家里要拉什么服务起来还是 docker-compose 。

[zzyyqq]

我擦咧？ 刚他妈用上这俩东西就互相不兼容了？？？

[WildCat]

@xratzh 请问 98 的技术是啥

[tigerstudent]

@duke807 但你的一楼内容是一句话直接说没用过 docker ，确实是答非所问呐

[xuanbg]

用 docker 好多年，但貌似没学过呢。。。

[yangyaofei]

@julyclyde 他底层是啥又不影响使用的人,只和他自己的发展有关,而接口都是既定标准了. 我一个种地的只关心给不给水牛
@0312birdzhang 不是,我没有,我不会 k8s, (真的)😂

[bluehtt]

@tigerstudent #49 如果觉得他人的回复内容没什么意义，可以考虑 block 掉，没必要去争。除了争论无休止以外，争论的内容对于问题没有什么意义，也是答非所问。

回归正题，还是建议学习 Docker ，Docker 起码还是一个很方便的工具，生态好文档齐全。Podman 在这方面要替换掉 Docker 还是早了点。

[yangyaofei]

@zhixi 从易用性和学习难度上来说, swarm 甚至更好用,无论集群配置和 docker-compose 过渡上来说都更好(看了文档后), 而 k8s 符合 google 东西的特质,就是文档(甚至不止文档)要读很多遍才明白,甚至成功部署一个 k8s 对于小公司或者个人就够开香槟了.

对我来说, docker-compose 加上集群自动化和自动扩容自动更新镜像, 就足以满足我想象中能真正做出来的应用的项目的所有要求了

@ruidoBlanco 如果 gitlab 能支持 swarm 和 k8s 那样, 真的想考虑上 swarm 了

[killerv]

并不是 k8s 放弃 docker ，而是 k8s 放弃了 docker-shim ，这个对于开发者来说基本上是无感的，docker build 创建的镜像依然适用于任何 CRI 实现，docker 依然是相对简单好用的容器镜像维护工具。

[julyclyde]

@a728976009 k8s 弃用 docker-shim 其实就是弃用 dockerd 吧。
dockerd 在 containerd 里叫做 namespace moby ； kubelet 直接访问 containerd 是另一个 namespace 吧。这细节的差异将来会带来一些问题，比如 docker ps 看不到 kubelet 创建的容器之类的

我觉得其实就是其他公司在搞政治，包括从一开始劝说 docker 把 containerd 捐献出来，包括后面抛弃 docker-shim ，都是搞政治

podman 访问 docker hub 需要加域名这个……访问别人最好还是打个招呼吧，要不然会被骂死

[julyclyde]

@zhixi swam 好像已经 offically 凉了吧，还用问吗？

[julyclyde]

@junnplus 学习了，nerdctl
只是……nerd 这词……

[pckillers]

用过 podman ，网上的镜像十个里有 8 个运行有问题。 换了 docker ，一样的命令，都正常起来了。

podman 的 cli 操作本来就是抄 docker 的，还少了些东西，lz 这个学 podman 不学 docker 的发言实在是让人贻笑大方。

至于直接学习 containerd ？ lz 是打算直接写个代替 docker 或 podman 的程序嘛？ 笑死。

[NeoZephyr]

哪有抛弃，瞎说

[julyclyde]

@pckillers 直接用 containerd 其实还行吧

podman 运行不了常见镜像的事，我确实是没有深入试用过，对这些问题没什么体会。还需要进一步学习

[guanzhangzhang]

那你就别用，没人求你用

[junnplus]

@pckillers nerdctl 就是一个直接操作 containerd 的 cli

[uselessVisitor]

又不是所有公司都用 K8s

[ruidoBlanco]

@julyclyde swarm mode 并没有，而是已经包含在 docker engine 里面，可以说是整合更好了。完蛋的是 classic swarm 。

在 HN 上看到有人说他们在生产环境跑 1000 个节点的 swarm ，这已经远超 docker 官方建议的 100 个节点的数量。

事实是，工具都会被人将其潜能利用到极限（或者说是 abuse ）。将人与人区分开来的，不是人使用的工具，而是人能够如何使用工具。Linux namespace 那套东西，原本也是丢在那里好久没人用没人关心，直到有人开发出来了 docker 一举成名。这就好比穿搭，满身的名牌不一定会让人显得得体，但是干净整洁搭配得当就会。

如果有人觉得我穿戴不像样，一定不是我身上挂的名牌和大金链子不够，而是我自己不懂穿搭。所以呢，如果有人能够 1000 个节点跑 swarm ，它就没有任何理由不够我用。如果有不够用，那就是我自己水平不够，而不是 swarm 的问题。

https://docs.docker.com/engine/swarm/

[pckillers]

@junnplus 看了看 nerdctl 的 cli 语法也是与 docker 与 podman 很相近的。 所以这个不能叫学习 containerd ，只能叫学习 nerdctl 吧。

毕竟现在学习 docker 也是让 docker 操作 containerd 的啊。

[cokyhe]

后悔用 docker 太晚，以前的裸装项目现在迁移费劲

[junnplus]

@pckillers 你要学习 containerd 的话当然直接去看 containerd - -

nerdctl 只是一层 cli ，组合 containerd + buildkit + cni 等组件

[pavelpiero]

有前途：我司（）不便透露，但是业务量不输头部互联网，中间件集群全部基于 docker swarm ，比公司的 k8s 集群（主要部署 java php 应用）稳定很多。
部署中间件（ kafka es 等）来说，本地存储比 nfs ceph 等网络存储还是性能更高。
各有取舍

[julyclyde]

@guanzhangzhang 滚

[julyclyde]

@NeoZephyr 抛弃是这个 https://kubernetes.io/blog/2020/12/02/dockershim-faq/

[julyclyde]

@ruidoBlanco 谢谢指点。那几个都用 swarm 这个词，我应该是混淆了。

[dnsjia]

容器集群管理平台 https://github.com/dnsjia/luban

[NeoZephyr]

@julyclyde 首先 dockershim 是在哪里维护的，如果是在 kubernetes 里面，我觉得不支持很正常啊，如果是在 docker 里面维护的，那只需要 dockershim 能够实现 CRI 是不是就可以了