【翻译】Docker, Containerd & Standalone Runtimes— 这里有你想知道的 #57
Labels
translate
翻译的国外文章
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
原文地址
文章首发
这片文章旨在想您介绍Containerd在docker架构中的集成。
让我们先来定义Docker Daemon然后看它是如何定义进docker架构和Containerd当中的。
Docker Daemon
像进程有守护进程一样（Like the init has its daemon）， cron有crond, dhcp有dhcpd, Docker 也有自己的守护进程dockerd。
你能使用下面的命令列出所有的Linux的守护进程：
译者注：
并且在输出中grep出dockerd
你可可能会看到
docker-containerd-shim，我们将要这篇文章的后面去讲解。如果你已经运行了docker，那么当你在命令后输入
dockerd的时候会出现类似下面的信息：现在让我们来停止docker：
然后在命令行使用
dockerd命令运行守护进程。使用
dockerd在命令行运行docker的守护进程是一个很好的debug工具，你能在命令行上看到真实的运行轨迹。现在如果你在另一个窗口运行或者删除一个容器，你就能看到docker的守护进程连接了docker的客户端和容器。
下面是docker的全局架构（docker的C/S架构）：
Containerd
它的目的是破坏docker架构中的模块化（its purpose is breaking up more modularity to Docker architecture）和与其他行业参（云提供者以及编排服务）与者相比更加中立。
据Solomon Hykes说，截止到2016年的4月，被包含在Docker 1.11中的Containerd已经被部署在数百万的机器中，宣布扩展Containerd的roadmap得到了许多云提供厂商的一件，这些云厂商包括阿里云，AWS，谷歌，IBM，微软和其他容器生态系统的活跃成员。
更多的docker引擎的功能将要被添加到containerd中，以至于containerd 1.0将要提供在linux或者windows上管理容器的所有原语：
你可能为了构建，传输，运行容器化应用继续使用docker，但是如果你寻找一种标准化组建那么你可以考虑containerd。
Docker Engine 1.11是第一个基于runC（基于OCI技术的runtime）和containerd构建的版本。下图是containerd的集成架构：
Open Container Initiative (OCI)组织成立于2015年的6月，旨在建立容器的通用标准为了避免在容器系统内部可能存在的碎片和分裂。
它包含两个标准：
runtime规范概述了如何在磁盘上解压文件系统包。
如果你导出和提出一个镜像你能看到这个json的文件。下面的这个例子，我们将要使用busybox作为例子：
现在我们在rootfs中已经有一个提取出来的busybox的镜像。
tree -d my_container/ my_container/ └── rootfs ├── bin ├── dev │ ├── pts │ └── shm ├── etc ├── home ├── proc ├── root ├── sys ├── tmp ├── usr │ └── sbin └── var ├── spool │ └── mail └── www我们能够通过下面的命令生成config.json这个文件：
生成的配置文件如下：
{ "ociVersion": "1.0.0-rc2-dev", "platform": { "os": "linux", "arch": "amd64" }, "process": { "terminal": true, "consoleSize": { "height": 0, "width": 0 }, "user": { "uid": 0, "gid": 0 }, "args": [ "sh" ], "env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "TERM=xterm" ], "cwd": "/", "capabilities": [ "CAP_AUDIT_WRITE", "CAP_KILL", "CAP_NET_BIND_SERVICE" ], "rlimits": [ { "type": "RLIMIT_NOFILE", "hard": 1024, "soft": 1024 } ], "noNewPrivileges": true }, "root": { "path": "rootfs", "readonly": true }, "hostname": "runc", "mounts": [ { "destination": "/proc", "type": "proc", "source": "proc" }, { "destination": "/dev", "type": "tmpfs", "source": "tmpfs", "options": [ "nosuid", "strictatime", "mode=755", "size=65536k" ] }, { "destination": "/dev/pts", "type": "devpts", "source": "devpts", "options": [ "nosuid", "noexec", "newinstance", "ptmxmode=0666", "mode=0620", "gid=5" ] }, { "destination": "/dev/shm", "type": "tmpfs", "source": "shm", "options": [ "nosuid", "noexec", "nodev", "mode=1777", "size=65536k" ] }, { "destination": "/dev/mqueue", "type": "mqueue", "source": "mqueue", "options": [ "nosuid", "noexec", "nodev" ] }, { "destination": "/sys", "type": "sysfs", "source": "sysfs", "options": [ "nosuid", "noexec", "nodev", "ro" ] }, { "destination": "/sys/fs/cgroup", "type": "cgroup", "source": "cgroup", "options": [ "nosuid", "noexec", "nodev", "relatime", "ro" ] } ], "hooks": {}, "linux": { "resources": { "devices": [ { "allow": false, "access": "rwm" } ] }, "namespaces": [ { "type": "pid" }, { "type": "network" }, { "type": "ipc" }, { "type": "uts" }, { "type": "mount" } ], "maskedPaths": [ "/proc/kcore", "/proc/latency_stats", "/proc/timer_list", "/proc/timer_stats", "/proc/sched_debug", "/sys/firmware" ], "readonlyPaths": [ "/proc/asound", "/proc/bus", "/proc/fs", "/proc/irq", "/proc/sys", "/proc/sysrq-trigger" ] } }现在你就可以编辑这个配置文件里面的内容，然后不通过docker启动一个容器，通过runc：
首先在你第一次用它的时候要先安装它：
你也能通过源文件安装它：
runC是一个完全符合规范的容器运行时，它允许你扩展（spin）一个容器，能与它们进行交互并且管理它们的声明周期，这要是为什么一个引擎（比如docker）构建的容器，能够在另一个容器中运行的原因。
容器作为runC的一个子进程，也能不通过守护进程（docker的守护进程）切入一些变量到系统之中。
runC构建在libcontainer上，libcontainer也是为docker引擎安装提供相同的容器库。在docker1.11之前，docker引擎用来管理存储，网络，容器以及镜像等等，现在docker的架构被拆为了四个部分：
二进制文件分别称为：
为了运行一个容器，docker engine创建了一镜像，然后把它传递给containerd，然后containerd去调用containerd-shm ，containerd-shm 再去调用runC去运行这个容器。containerd-shim 允许runC在创建容器之后退出。这样我们就可以运行无守护进程的容器，因为我们没必要去为容器运行长时间的runtime进程。
目前，容器通过runC（经由containerd）创建的，但是可能通过另一种非runC的二进制暴露出相同的docker命令行以及接收OCI包。
你能在你的机器上看到不同的runtime通过下面的命令：
docker info|grep -i runtime如果用的默认的会得到下面的输出：
通过下面的命令你可以增加一个runtime：
按流程它们只是一个containerd-shim，它管理标准的IO的先入先出队列，和保证在容器挂掉的时候能启动容器。
它也负责发送容器退出的状态给像docker这样的上层。
下图是当前的docker的架构。
Containerd实现了容器runtime，声明周期的支持和执行（create, start, stop, pause, resume, exec, signal & delete）这些特性。其他的特性（比如存储，日志等）被其他的组件实现。下图是Containerd Github 的一个图，展示了不同的特性并告诉这个特性是是否在范围Containerd之内。
我们运行容器：
如果你运行
ps aux命令，你能注意到docker-containerd-shim和容器运行通过下面的一些参数关联：这是具有正确格式的完整行：
db5218c494190c11a2fcc9627ea1371935d7021e86b5f652221bdac1cf182843是你创建容器之后能看到的id。
总结
Docker的每个版本都在变化和发展，但有一些重大变化，比如Containerd的集成。在这篇文章中，我们已经看到了在这次集成（Containerd的集成）之后Docker发生了什么变化，以及OCI（在Docker的帮助下）如何通过引入使用独立运行时的可能性来改变容器世界。
The text was updated successfully, but these errors were encountered: