这里写目录标题
- 1. Podman 容器 pod 管理工具
- 1.1. 什么是 Podman
- 1.1.1. Roadmap
- 1.2. Podman 历史
- 1.2.1. 缘起
- 1.2.1.1. 鸿蒙
- 1.2.1.2. 创世
- 1.2.2. 纷争
- 1.2.2.1. 发展
- 1.2.2.2. 野心
- 1.2.2.3. 冲突
- 1.2.2.4. 成败
1. Podman 容器 pod 管理工具
1.1. 什么是 Podman
Podman 是 Libpod 的一部分, 它的定义可以简单用这个命令表示: alias docker=podman
Libpod 是一个创建容器 pod 的工具和库, 它包含 pod 管理工具 Podman, Podman 管理 pod、容器、容器镜像和容器卷。
在较高的层面上, Libpod 和 Podman 的作用范围如下:
- 支持多种镜像格式, 包括 OCI 和 Docker。
- 支持多种方式下载镜像, 包括信任和镜像验证。
- 容器镜像管理, 管理镜像层、覆盖文件系统等。
- 全面管理容器生命周期。
- 支持 pod 管理容器组。
- pos 和容器的资源隔离。
- 与 CRI-O 集成以共享容器和后端代码。
- 支持 Fedora、RHEL 与 Ubuntu 等的不同版本。
1.1.1. Roadmap
- 允许 Podman CLI 使用 Varlink 后端连接到远程 Podman 实例。
- 将 Libpod 集成到 CRI-O 中以替换其现有的容器管理后端。
- 进一步改进 Podman pod 命令
- 不需要 root(rootless) 容器的进一步改进
1.2. Podman 历史
1.2.1. 缘起
1.2.1.1. 鸿蒙
在上古时期, 天地初开, 一群称之为 “运维” 的人们每天在一种叫作 “服务器” 的神秘盒子中创造属于他们的世界; 他们在这个世界中每日劳作, 一遍又一遍的写入他们的历史, 比如搭建一个 nginx、布署一个 java web 应用…
大多数人其实并没有那么聪明, 他们所 “创造” 的事实上可能是有人已经创造过的东西, 他们可能每天都在做着重复的劳动; 久而久之, 一些人厌倦了、疲惫了… 又过了一段时间, 一些功力深厚的老前辈创造了一些批量布署工具来帮助人们做一些重复性的劳动, 这些工具被起名为 “Asible”、“Chef”、“Puppet” 等等…
而随着时代的发展, “世界” 变得越来越复杂, 运维们需要处理的事情越来越多, 比如各种网络、磁盘环境的隔离, 各种应用服务的高可用… 在时代的洪流下, 运维们急需要一种简单高效的布署工具, 既能有一定的隔离性, 又能方便使用, 并且最大程度降低重复劳动来提升效率。
1.2.1.2. 创世
在时代洪流的冲击下, 一位名为 “Solomon Hykes” 的人异军突起, 他创造了一个称之为 Docker 的工具, Docker 被创造以后就以灭世之威向运维们展示了它的强大。
一个战斗力只有 5 的运维只需要学习 Docker 很短时间就可以完成资深运维们才能完成的事情, 在某些情况下以前需要 1 天才能完成的工作使用 Docker 后几分钟就可以完成; 此时运维们已经意识到 “新的时代” 开启了, 接下来 Docker 开源并被整个运维界人们使用, Docker 也不断地完善增加各种各样的功能, 此后世界正式进入 “容器纪元”。
1.2.2. 纷争
1.2.2.1. 发展
随着 Docker 的日益成熟, 一些人开始在 Docker 之上创造更加强大的工具, 一些人开始在 Docker 之下为其提供更稳定的运行环境…
其中一个叫作 Google 的公司在 Docker 之上创建了名为 “Kuberentes” 的工具, Kubernetes 操纵 Docker 完成更加复杂的任务; Kubernetes 的出现更加印证了 Docker 的强大, 以及 “容器纪元” 的发展正确性。
1.2.2.2. 野心
当然这是一个充满利益的世界, Google 公司创造 Kubernetes 是可以为他们带来利益的, 比如他们可以让 Kubernetes 深度适配他们的云平台, 以此来增加云平台的销量等; 此时 Docker 创始人也成立了一个公司, 提供 Docker 的付费服务以及深度定制等。
不过值得一提的是 Docker 公司提供的付费服务始终没有 Kubernetes 为 Google 公司带来的利益高, 所以在利益的驱使下, Docker 公司开始动起了歪心思: 创造一个 Kubernetes 的替代品, 利用用户粘度复制 Kubernetes 的成功, 从 Google 嘴里抢下这块蛋糕! 此时 Docker 公司只想把蛋糕抢过来, 但是他们根本没有在意到暗中一群人创造了一个叫 “rkt” 的东西也在妄图夺走他们嘴里的蛋糕。
1.2.2.3. 冲突
在一段时间的沉默后, Docker 公司又创造了 “Swarm” 这个工具, 妄图夺走 Google 公司利用 Kubernetes 赢来的蛋糕; 当然, Google 这个公司极其庞大, 人数众多, 而且在这个社会有很大的影响地位…
终于, 巨人苏醒了, Google 联合了 Redhat、Microsoft、IBM、Intel、Cisco 等公司决定对这个爱动歪脑筋的 Docker 公司进行制裁; 当然制裁的手段不能过于暴力, 那样会让别人落下把柄, 成为别人的笑料, 被人所不耻。
最总他们决定制订规范, 成立组织, 明确规定 Docker 的角色, 以及它应当拥有的能力, 这些规范包括但不限于 CRI、CNI 等; 自此之后各大公司宣布他们容器相关的工具只兼容 CRI 等相关标准, 无论是 Docker 还是 rkt 等工具, 只要实现了这些标准, 就可以配合这些容器工具进行使用。
1.2.2.4. 成败
自此之后, Docker 跌下神坛, 各路大神纷纷创造满足 CRI 等规范的工具用来取代 Docker, Docker 丢失了往日一家独大的场面, 最终为了顺应时代发展, 拆分自己成为模块化组件; 这些模块化组件被放置在 mobyproject 中方便其他人重复利用。
时至今日, 虽然 Docker 已经不负以前, 但是仍然是容器化首选工具, 因为 Docker 是一个完整的产品, 它可以提供除了满足 CRI 等标准以外更加方便的功能; 但是制裁并非没有结果, Google 公司借此创造了 cri-o 用来满足 CRI 标准, 其他公司也相应创建了对应的 CRI 实现。
为了进一步分化 Docker 势力, 一个叫作 Podman 的工具被创建, 它以 cri-o 为基础, 兼容大部份 Docker 命令的方式开始抢夺 Dcoker 用户; 到目前为止 Podman 已经可以在大部份功能上替代 Docker。