容器技术的发展与基本原理
|
容器运行时分为低层运行时和高层运行时，功能各有侧重。低层运行时主要负责运行容器，可在给定的容器文件系统上运行容器的进程;高层运行时则主要为容器准备必要的运行环境，如容器镜像下载和解压并转化为容器所需的文件系统、创建容器的网络等，然后调用低层运行时启动容器。主要的容器运行时的关系如下图所示。
OCI运行时规范 成立于2015年的OCI是Linux基金会旗下的合作项目，以开放治理的方式制定操作系统虚拟化(特别是Linux容器)的开放工业标准，主要包括容器镜像格式和容器运行时(runtime)。初始成员包括Docker、亚马逊、CoreOS、谷歌、微软和VMware等公司。OCI成立之初，Docker公司为其捐赠了容器镜像格式和运行时的草案及相应的实现代码。原来属于Docker的libcontainer项目被捐赠给OCI，成为独立的容器运行时项目runC。 OCI运行时规范定义了容器配置、运行时和生命周期的标准，主流的容器运行时都遵循OCI运行时的规范，从而提高系统的可移植性和互操作性，用户可根据需要进行选择。 首先，容器启动前需要在文件系统中按一定格式存放所需的文件。OCI运行时规范定义了容器文件系统包(filesystem bundle)的标准，在OCI运行时的实现中通常由高层运行时下载OCI镜像，并将OCI镜像解压成OCI运行时文件系统包，然后OCI运行时读取配置信息和启动容器里的进程。OCI运行时文件系统包主要包括以下两部分。 config.json：这是必需的配置文件，存放于文件系统包的根目录下。OCI运行时规范对Linux、Windows、Solaris和虚拟机4种平台的运行时做了相应的配置规范。 容器的根文件系统：容器启动后进程所使用的根文件系统，由 config.json 中的root.path属性确定该文件系统的路径，通常是“rootfs/”。 然后，在定义文件系统包的基础上，OCI运行时规范制定了运行时和生命周期管理规范。生命周期定义了容器从创建到删除的全过程，可用以下三条命令说明。 “create”命令：在调用该命令时需要用到文件系统包的目录位置和容器的唯一标识。在创建运行环境时需要使用config.json里面的配置。在创建的过程中，用户可加入某些事件钩子(hook)来触发一些定制化处理，这些事件钩子包括prestart、createRuntime和createContainer。 “start”命令：在调用该命令时需要运行容器的唯一标识。用户可在 config.json 的process 属性中指明运行程序的详细信息。“start”命令包括两个事件钩子：startContainer和poststart。 “delete”命令：在调用该命令时需要运行容器的唯一标识。在用户的程序终止后(包括正常和异常退出)，容器运行时执行“delete”命令以清除容器的运行环境。“delete”命令有一个事件钩子：poststop。 除了上述生命周期命令，OCI运行时还必须支持另外两条命令。 “state”命令：在调用该命令时需要运行容器的唯一标识。该命令查询某个容器的状态，必须包括的状态属性有ociVersion、id、status、pid和bundle，可选属性有annotation。不同的运行时实现可能会有一些差异。下面是一个容器状态的例子： { "ociVersion": "1.0.1", "id": "oci-container001", "status": "running", "pid": 8080, "bundle": "/containers/nginx", "annotations": { "key1": "value1" } } “kill”命令：在调用该命令时需要运行容器的唯一标识和信号(signal)编号。该命令给容器进程发送信号，如Linux操作系统的信号9表示立即终止进程。 runC runC是OCI运行时规范的参考实现，也是最常用的容器运行时，被其他多个项目使用，如containerd和CRI-O等。runC也是低层容器运行时，开发人员可通过runC实现容器的生命周期管理，避免烦琐的操作系统调用。根据OCI运行时规范，runC不包括容器镜像的管理功能，它假定容器的文件包已经从镜像里解压出来并存放于文件系统中。runC创建的容器需要手动配置网络才能与其他容器或者网络节点连通，为此可在容器启动之前通过OCI定义的事件钩子来设置网络。 由于runC提供的功能比较单一，复杂的环境需要更高层的容器运行时来生成，所以runC常常成为其他高层容器运行时的底层实现基础。 containerd 在OCI成立时，Docker公司把其Docker项目拆分为runC的低层运行时及高层运行时功能。2017年，Docker公司把这部分高层容器运行时的功能集中到containerd项目里，捐赠给云原生计算基金会。 containerd 已经成为多个项目共同使用的高层容器运行时，提供了容器镜像的下载和解压等镜像管理功能，在运行容器时，containerd先把镜像解压成OCI的文件系统包，然后调用runC运行容器。containerd提供了API，其他应用程序可以通过API与containerd交互。“ctr”是containerd的命令行工具，和“docker”命令很相像。但作为容器运行时，containerd只注重在容器运行等方面，因而不包含开发者使用的镜像构建和镜像上传镜像仓库等功能。 Docker Docker引擎是最早流行也是最广泛使用的容器运行时之一，是一个容器管理工具，架构如下图所示。Docker的客户端(命令行CLI工具)通过API调用容器引擎Docker Daemon(dockerd)的功能，完成各种容器管理任务。
Docker引擎在发布时是一个单体应用，所有功能都集中在一个可执行文件里，后来按功能分拆成runC和containerd两个不同层次的运行时，分别捐献给了OCI和CNCF。上面两节已经分别介绍了runC和containerd的主要特点，剩下的dockerd就是Docker公司维护的容器运行时。 dockerd同时提供了面向开发者和面向运维人员的功能。其中，面向开发者的命令主要提供镜像管理功能。容器镜像一般可由Dockerfile构建(build)而来。Dockerfile是一个文本文件，通过一组命令关键字定义了容器镜像所包含的基础镜像(base image)、所需的软件包及有关应用程序。在Dockerfile编写完成以后，就可以用“docker build”命令构建镜像了。下面是一个Dockerfile的简单例子： FROM ubuntu:18.04 EXPOSE 8080 CMD ["nginx", "-g", "daemon off;"] 容器的镜像在构建之后被存放在本地镜像库里，当需要与其他节点共享镜像时，可上传镜像到镜像仓库(Registry)以供其他节点下载。 （编辑：应用网_阳江站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
