linux低级格式化命令_低级Linux容器运行时的历史

linux低级格式化命令

在Red Hat，我们喜欢说：“容器是Linux，Linux是容器”。这就是这个意思。传统容器是系统上的进程，通常具有以下三个特征：

1.资源限制

2.安全约束

通常，您不希望容器能够互相攻击或攻击主机系统。我们利用Linux内核的多个功能来建立安全性隔离，例如SELinux，seccomp，功能等。

3.虚拟分离

容器进程不应查看容器外部的任何进程。他们应该在自己的网络上。容器进程需要能够绑定到不同容器中的端口80。每个容器都需要一个不同的映像视图，需要自己的根文件系统（rootfs）。在Linux中，我们使用内核名称空间来提供虚拟分隔。

因此，在cgroup中运行，具有安全设置并在名称空间中运行的进程可以称为容器。查看在Red Hat Enterprise Linux 7系统上的PID 1，systemd，您可以看到systemd在cgroup中运行。

# tail -1 /proc/1/cgroup

        1:name=systemd:/

ps命令向您显示系统进程具有SELinux标签...

# ps -eZ | grep systemd

        system_u:system_r:init_t:s0             1 ?     00:00:48 systemd

和功能。

# grep Cap /proc/1/status

        ...

        CapEff: 0000001fffffffff

        CapBnd: 0000001fffffffff

        CapBnd:    0000003fffffffff

最后，如果查看/proc/1/ns子目录，将看到systemd在其中运行的名称空间。

ls -l /proc/1/ns

        lrwxrwxrwx. 1 root root 0 Jan 11 11:46 mnt -> mnt:[4026531840]

        lrwxrwxrwx. 1 root root 0 Jan 11 11:46 net -> net:[4026532009]

        lrwxrwxrwx. 1 root root 0 Jan 11 11:46 pid -> pid:[4026531836]

        ...

如果PID 1（实际上是系统上的所有其他进程）都具有资源限制，安全设置和名称空间，那么我认为系统上的每个进程都在容器中。

容器运行时工具只需修改这些资源约束，安全设置和名称空间。然后，Linux内核执行进程。启动容器后，容器运行时可以监视容器内部或容器的stdin / stdout的PID 1 —容器运行时管理这些进程的生命周期。

容器运行时

您可能会对自己说，良好的systemd听起来非常类似于容器运行时。好了，在讨论了为什么容器运行时为什么不使用systemd-nspawn作为启动容器的工具的电子邮件讨论之后，我认为值得讨论容器运行时并提供一些历史背景。

Docker通常被称为容器运行时，但是“容器运行时”是一个重载术语。当人们谈论“容器运行时”时，他们实际上是在谈论开发人员功能随附的高级工具，例如Docker， CRI-O和RKT 。它们是API驱动的。它们包括诸如从容器注册表中提取容器映像，设置存储以及最终启动容器的概念。启动容器通常涉及运行专用工具，该工具将内核配置为运行容器，这些工具也称为“容器运行时”。我将它们称为“低级容器运行时”。像Docker和CRI-O这样的守护进程，以及像Podman和Buildah这样的命令行工具，应该被称为“容器管理器”。

最初编写Docker时，它使用lxc工具集启动了容器，该工具集早于systemd-nspawn 。 Red Hat与Docker的最初合作是试图将libvirt （ libvirt-lxc ）集成到Docker中，以替代lxc工具，RHEL不支持lxc工具。 libvirt-lxc也未使用systemd-nspawn 。当时，systemd团队说systemd-nspawn只是用于测试的工具，而不是用于生产的工具。

同时，上游Docker开发人员（包括我的Red Hat团队的一些成员）决定，他们希望使用golang本机方式来启动容器，而不是启动单独的应用程序。 libcontainer的工作开始了，它是用于启动容器的本地golang库。红帽工程公司认为这是前进的最佳途径，因此放弃了libvirt-lxc 。

后来，由于人们希望能够以其他方式发射容器，因此成立了开放容器倡议（OCI）。传统的以名称空间分隔的容器很流行，但是人们也渴望虚拟机级隔离。英特尔和Hyper.sh致力于KVM分隔的容器，而微软则致力于基于Windows的容器。 OCI想要一个定义容器是什么的标准规范，因此OCI运行时规范诞生了。

OCI运行时规范定义了一个JSON文件格式，该格式描述了应运行的二进制文件，应如何包含它以及容器的rootfs位置。工具可以生成此JSON文件。然后其他工具可以读取此JSON文件并在rootfs上执行一个容器。 Docker的libcontainer部分已分解并捐赠给OCI。上游Docker工程师和我们的工程师帮助创建了一个新的前端工具，以读取OCI运行时规范JSON文件并与libcontainer交互以运行容器。这个名为runc工具也被捐赠给了OCI。尽管runc可以读取OCI JSON文件，但用户可以自己生成它。 runc成为最受欢迎的低级容器运行时。几乎所有的容器管理工具都支持runc ，包括CRI-O，Docker，Buildah，Podman和Cloud Foundry Garden 。从那时起，其他工具也实现了OCI运行时规范，以执行符合OCI的容器。

创建了Clear Containers和Hyper.sh的runV工具都是为了使用OCI运行时规范来执行基于KVM的容器，并且它们将自己的努力结合到了一个名为Kata的新项目中。去年，Oracle创建了一个用Rust编写的名为RailCar的OCI运行时工具的演示版。 GitHub项目已经更新了两个月，所以尚不清楚它是否仍在开发中。几年前，Vincent Batts致力于添加工具nspawn-oci ，该工具解释OCI运行时规范文件并启动systemd-nspawn ，但没人真正接受它，它不是本机实现。

如果有人想实现本机systemd-nspawn --oci OCI-SPEC.json并使其得到systemd团队的支持，那么CRI-O，Docker和Podman最终将可以在runc和清除Container / runV（ Kata ）。（我的团队中没有人正在为此工作。）

最重要的是，三到四年前，上游开发人员想编写一个用于启动容器的低级golang工具，而该工具最终成为runc 。当时，那些开发人员拥有一个基于C的工具来执行此操作，称为lxc并放弃了它。我非常确定，在他们决定构建libcontainer的时候，他们不会对systemd-nspawn或运行“名称空间”分隔容器的任何其他非本地（golang）方式感兴趣。

翻译自: https://opensource.com/article/18/1/history-low-level-container-runtimes

linux低级格式化命令