是时候替换你的docker了

罪恶的 docker

还记得之前写过一篇关于docker 启动时候宿主机 CPU 使用百分百的问题

使用 docker 的时候常见疑问点

单个过程可能是单个故障点。
该进程拥有所有子进程(正在运行的容器)。
如果发生故障,则存在孤儿容器。
构建容器导致安全漏洞。
所有 Docker 操作都必须由具有相同完全根权限的一个或多个用户执行。

docker架构

常见尴尬场景:

由于之前对 docker 的理解不深,所以上手就直接用了。慢慢发现有一些配置文件或者其他的需要更改的时候,必须先删除所有容器,然后重启守护程序……………..(那这样意义何在?)

衍生出来几个问题

Docker 干嘛要配一个守护程序?
虽然我们把业务解耦到不同的容器中,但是由于这么多的容器底层都是同一个父进程–Docker-daemon,这相当于把鸡蛋分开到不同的篮子里,但是所有的篮子都在同一辆车上。

总结一下

Docker 是一个以 root 身份在你的系统上运行的守护程序,它利用 Linux 内核的功能来管理正在运行的容器。除了运行容器之外,它还可以轻松管理容器镜像 —— 与容器注册库交互、存储映像、管理容器版本等。它基本上支持运行单个容器所需的所有操作。

但即使 Docker 是管理 Linux 容器的一个非常方便的工具,它也有两个缺点:它是一个需要在你的系统上运行的守护进程,并且需要以 root 权限运行,这可能有一定的安全隐患。然而,Podman 在解决这两个问题。


下面来介绍一下 podman

podman logo
Podman 是一个容器运行时环境,提供与 Docker 非常相似的功能。正如已经提示的那样,它不需要在你的系统上运行任何守护进程,并且它也可以在没有 root 权限的情况下运行。让我们看看使用 Podman 运行 Linux 容器的一些示例。
podman run
你会发现启动一个容器 并不需要先启动 docker 了。甚至没有 podman 的进程。使得容器就是容器 轻量级了很多。

podman架构

课外讲讲发展史

为什 docker 做的那么早,但是这么不尽人意呢?

一、缘起
1.1、鸿蒙
在上古时期,天地初开,一群称之为 “运维” 的人们每天在一种叫作 “服务器” 的神秘盒子中创造属于他们的世界;他们在这个世界中每日劳作,一遍又一遍的写入他们的历史,比如搭建一个 nginx、布署一个 java web 应用…

大多数人其实并没有那么聪明,他们所 “创造” 的事实上可能是有人已经创造过的东西,他们可能每天都在做着重复的劳动;久而久之,一些人厌倦了、疲惫了…又过了一段时间,一些功力深厚的老前辈创造了一些批量布署工具来帮助人们做一些重复性的劳动,这些工具被起名为 “Asible”、”Chef”、”Puppet” 等等…

而随着时代的发展,”世界” 变得越来越复杂,运维们需要处理的事情越来越多,比如各种网络、磁盘环境的隔离,各种应用服务的高可用…在时代的洪流下,运维们急需要一种简单高效的布署工具,既能有一定的隔离性,又能方便使用,并且最大程度降低重复劳动来提升效率。

1.2、创世
在时代洪流的冲击下,一位名为 “Solomon Hykes” 的人异军突起,他创造了一个称之为 Docker 的工具,Docker 被创造以后就以灭世之威向运维们展示了它的强大;一个战斗力只有 5 的运维只需要学习 Docker 很短时间就可以完成资深运维们才能完成的事情,在某些情况下以前需要 1 天才能完成的工作使用 Docker 后几分钟就可以完成;此时运维们已经意识到 “新的时代” 开启了,接下来 Docker 开源并被整个运维界人们使用,Docker 也不断地完善增加各种各样的功能,此后世界正式进入 “容器纪元”。


二、纷争
2.1、发展
随着 Docker 的日益成熟,一些人开始在 Docker 之上创造更加强大的工具,一些人开始在 Docker 之下为其提供更稳定的运行环境…

其中一个叫作 Google 的公司在 Docker 之上创建了名为 “Kuberentes” 的工具,Kubernetes 操纵 Docker 完成更加复杂的任务;Kubernetes 的出现更加印证了 Docker 的强大,以及 “容器纪元” 的发展正确性。

2.2、野心
当然这是一个充满利益的世界,Google 公司创造 Kubernetes 是可以为他们带来利益的,比如他们可以让 Kubernetes 深度适配他们的云平台,以此来增加云平台的销量等;此时 Docker 创始人也成立了一个公司,提供 Docker 的付费服务以及深度定制等;不过值得一提的是 Docker 公司提供的付费服务始终没有 Kubernetes 为 Google 公司带来的利益高,所以在利益的驱使下,Docker 公司开始动起了歪心思: 创造一个 Kubernetes 的替代品,利用用户粘度复制 Kubernetes 的成功,从 Google 嘴里抢下这块蛋糕!此时 Docker 公司只想把蛋糕抢过来,但是他们根本没有在意到暗中一群人创造了一个叫 “rkt” 的东西也在妄图夺走他们嘴里的蛋糕。

2.3、冲突
在一段时间的沉默后,Docker 公司又创造了 “Swarm” 这个工具,妄图夺走 Google 公司利用 Kubernetes 赢来的蛋糕;当然,Google 这个公司极其庞大,人数众多,而且在这个社会有很大的影响地位…

终于,巨人苏醒了,Google 联合了 Redhat、Microsoft、IBM、Intel、Cisco 等公司决定对这个爱动歪脑筋的 Docker 公司进行制裁;当然制裁的手段不能过于暴力,那样会让别人落下把柄,成为别人的笑料,被人所不耻;最总他们决定制订规范,成立组织,明确规定 Docker 的角色,以及它应当拥有的能力,这些规范包括但不限于 CRI、CNI 等;自此之后各大公司宣布他们容器相关的工具只兼容 CRI 等相关标准,无论是 Docker 还是 rkt 等工具,只要实现了这些标准,就可以配合这些容器工具进行使用。


三、成败
自此之后,Docker 跌下神坛,各路大神纷纷创造满足 CRI 等规范的工具用来取代 Docker,Docker 丢失了往日一家独大的场面,最终为了顺应时代发展,拆分自己成为模块化组件;这些模块化组件被放置在 mobyproject 中方便其他人重复利用。

时至今日,虽然 Docker 已经不负以前,但是仍然是容器化首选工具,因为 Docker 是一个完整的产品,它可以提供除了满足 CRI 等标准以外更加方便的功能;但是制裁并非没有结果,Google 公司借此创造了 cri-o 用来满足 CRI 标准,其他公司也相应创建了对应的 CRI 实现;为了进一步分化 Docker 势力,一个叫作 Podman 的工具被创建,它以 cri-o 为基础,兼容大部份 Docker 命令的方式开始抢夺 Dcoker 用户;到目前为止 Podman 已经可以在大部份功能上替代 Docker。


本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!