4. 标准极简容器runC

introduction

这玩意儿是啥, 有点神秘 , 名字带run都有点神秘, 神秘 (神必). 现在你知道 (顿), 容器相关的神奇表现是怎么搞出来的, 但你也知道 (顿), 这些是我们自己打的草稿, 离真正的docker, 架构那些设计, 还有一些距离. 我想弥补这些距离, 讲真的, 我想弥补这些距离

1. linux, 提供了一些可以拿来隔离的手段

2. libcontainer, 包装了这些手段, 然后你调用库函数就能实现隔离

3. runC, 包装了这个库, 变成了一个启停容器的命令行的工具

4. docker, 包装了runC, 变成了一个特性丰富的, 管容器的, 命令行的工具

为什么呢? 你要包装一下LinuxAPI方便docker调用我可以理解, 但为什么要做出两套命令行工具呢? 原因是某一天大家觉得容器真好用, 于是每家就都想自己做出一套自己的容器, 整出自己的"Docker". 可是这样不行, 容器引擎五花八门就跟铁轨修的乱七八糟一样麻烦. 于是就找来几家大佬, 说你们自研没问题, 但我们得符合一些容器规范, 于是我们就有了Open Container Format规范, Docker说好的我提供一种引擎能起容器, 也符合这套规范, 于是就有了runC

我们希望这个引擎能够:

那么关于这套标准, 他是这样说的: 我们希望这个引擎能不受硬件制约, 无论在任何架构上, 你的引擎都能起出一模一样的容器. 同时我们希望你的引擎应该老老实实的做好一个引擎该做的事, 无论是什么客户端, 无论是任何编排工具来了都能通过调你接口起容器. 标准里, 启动一个容器需要的材料包含:

• config.json , 配置文件 : 比如环境变量, 初始(pid=0)进程的运行参数, 配置信息, 是否绑定终端, 内存限制, 文件系统的挂载点设置, 支持设置容器运行前/后执行的脚本文件(钩子)

• rootfs, 包含 /bin, /lib等, 值得一提, 为了能起容器我们其实只要求rootfs下包含所需要的目录与文件, 但是并没有要求过镜像. 镜像这种特性其实是docker为了方便存储rootfs自己想出来的, runC作为纯粹的容器引擎, 没有

👆除去上面用于启动一个容器的文件, 我们还需要为每个容器生成一个名为 state.json 的文件, 用于记录容器的运行状态. 里面包含有 容器ID, pid 等.