容器基础镜像的编写及最佳实践

字数 14353阅读 5746评论 2赞 10

> 本文为云原生应用创新实践联盟—— 容器云安全方向课题组线上交流活动总结，相关协作专家如下所示， 更多内容可[**点击此处进入云原生应用创新实践联盟**](https://cnaipa.talkwithtrend.com/?action-topic-id-403) 进行查看。

> **执笔专家：**  
**张工 课题组特邀外部专家 **
twt社区云原生应用创新实践联盟—— 容器云安全方向课题组特邀外部专家。 目前就职某股份制银行负责容器安全相关架构师岗位，对容器具有丰富的实践经验。参与过银行容器云平台建设及安全规划工作，现在主要负责容器云安全及规划方面建设工作，擅长容器、云计算、安全等技术领域。

> **顾问专家：**  
**谭龙飞  容器云安全用户委员会委员**
  twt社区云原生应用创新实践联盟—— 容器云安全方向课题组专家。 负责云安全工作，擅长容器、linux。
**王蕊 容器云自动化运维用户委员会委员**  
twt社区云原生应用创新实践联盟——容器云安全方向课题组特邀外部专家。 北银金科云计算应用部资深架构师，从事企业级系统开发，架构设计工作10余年，曾就职于Sun中国工程研究院，IBM全球解决方案服务部，Watson医疗等部门。在Cloud和微服务等主流技术和大型系统现代化改造，微服务，云原生系统设计领域有丰富经验。

# 导读：
容器始于镜像，在容器作为云原生架构上的工作负载发挥其应用价值之前，它以镜像的形式存在并流转。相比于攻击生命周期较短的容器，聪明的攻击者往往会选择投毒镜像，这样不管是基于该镜像运行容器抑或是生成新的镜像，全部都将含有恶意成分。不够了解镜像，就无法建立对镜像的管理体系。镜像有哪些种类？镜像里有哪些内容？镜像该由谁来构建又如何构建？

通过本内容学习您将清楚了解到容器镜像的基本概念，容器镜像在容器云平台系统组成中的位置，镜像主要特点以及容器镜像和虚拟机镜像的区别。基于以上基本概念了解的前提下，**本文延伸讲解容器镜像的分类，各类镜像如何在企业业务中使用，维护。其中最重要部分是给大家讲解各类镜像的构建方式以及镜像构建的最佳实践。最后简要总结如何通过自动化的方式进行镜像创建管理。**具体实践中每个容器云平台的实现方式不同，大家可以在工作中根据业务需要进一步丰富。镜像是容器之源，在文末介绍了从镜像到容器运行起来的过程，结合操作系统核心技术解释了如何通过其中涉及的各类技术实现容器的虚拟化。

总之，**通过本内容的学习可以零基础了解镜像的基本概念，同时逐步掌握镜像的构建原理以及镜像构建方面的企业最佳实践，为大家在以后工作中创建镜像奠定技术基础。**

# 基本概念
## Docker系统组成
Docker的整体系统包括以下主要组成部分：Docker client，Docker daemon，Docker registry，Docker镜像，Docker容器，他们之间的关系如下图：
![](/home/attachment/202210/08/1210417_166520900716359.png)
Docker架构主要分为客户端和服务端，客户端负责发起请求，服务端负责接受,解析和处理请求，图示中的Docker Client即为Docker客户端的一个命令行工具，用户通过Docker Client与Docker Daemon进行通信并返回结果给用户。也可以使用其他工具通过Docker Api 与Docker Daemon通信。

拿一个简单的拉取镜像并运行容器的过程举例便于大家更好的理解容器系统架构。从上图中我们可以看到，当daemon接收到由client发起的docker run等运行容器指令时，docker系统先会由registry（本地镜像仓库）中拉取镜像，图示中拉取了ubuntu：14.04镜像。当由 ubuntu:14.04 镜像启动容器时，ubuntu:14.04 镜像的镜像层layer内容将作为容器的 rootfs；而 ubuntu:14.04 镜像的 yaml文件（json格式），会由 Docker daemon 解析成为该docker运行起来后的各项配置，并提取出其中的容器执行入口 CMD 信息，以及容器进程的环境变量 ENV 信息，最终初始化容器进程。当然，容器进程的执行入口来源于镜像提供的 rootfs。

在传统的 Linux 操作系统内核启动时，首先挂载一个只读的 rootfs，当系统检测其完整性之后，再将其切换为读写模式。而在 Docker 架构中，当 Docker daemon 为 Docker 容器挂载 rootfs 时，沿用了 Linux 内核启动时的做法，即将 rootfs 设为只读模式。但docker运行的下一步产生了与传统linux的差别，这里要特别注意，在挂载完毕之后，docker系统利用联合挂载(union mount)技术在已有的只读 rootfs 上再挂载一个读写层。可读写的层处于 Docker 容器文件系统的最顶层，其下可能联合挂载了多个只读的层，只有在Docker容器运行过程中文件系统发生变化时，才会把变化的文件内容写到可读写层，并如同photoshop中的多层覆盖一样，由最顶层的新的文件内容覆盖掉只读层中的旧版本文件（旧版本文件依旧存在只是被盖住了）。

## Docker镜像
Docker镜像是一个只读的Docker容器模板，含有启动Docker容器所需的文件系统结构及其内容，是启动一个Docker容器的基础，但是需要重点注意镜像中不包括系统内核，在下文也会讲述这是容器与虚拟机最关键的区别之一。Docker镜像的文件内容（rootfs）以及一些运行Docker容器的配置文件组成了Docker容器的静态运行环境。可以这么理解，Docker镜像是 Docker 容器的静态视角，Docker容器是Docker镜像的运行状态。镜像是容器之源，如果大家熟悉java，镜像和容器的关系类似class文件和java对象的关系。

## Docker镜像特点
**- 分层**
Docker 镜像是采用分层的方式构建的，每个镜像都由一系列的 "镜像层" 组成。分层结构是 Docker 镜像如此轻量的重要原因。当需要修改容器镜像内的某个文件时，只对处于最上方的读写层进行变动，不覆写下层已有文件系统的内容，已有文件在只读层中的原始版本仍然存在，但会被读写层中的新版本所隐藏。当使用 docker commit 提交这个修改过的容器文件系统为一个新的镜像时，保存的内容仅为最上层读写文件系统中被更新过的文件。分层达到了在不的容器同镜像之间共享镜像层的效果。

**- 写时复制（不变性）**

Docker 镜像使用了写时复制(copy-on-write)的策略。如果要在多个容器之间共享镜像，每个容器在启动的时候并不需要单独复制一份镜像文件，而是将所有镜像层以只读的方式挂载到一个挂载点，再在上面覆盖一个可读写的容器层。在未更改文件内容时，所有容器等于共享同一份数据，只有在 Docker 容器运行过程中文件系统发生变化时，才会把变化的文件内容写到可读写层，并隐藏只读层中的老版本文件。写时复制配合分层机制减少了镜像对磁盘空间的占用和容器启动时间。

**- 内容寻址**
在 Docker 1.10 版本后，Docker 镜像经历了较大的改动，其中最重要的特性便是引入了内容寻址存储(content-addressable storage) 的机制，根据文件的内容来索引镜像和镜像层。与之前版本对每个镜像层随机生成一个 UUID 不同，新模型对镜像层的内容计算校验和，生成一个内容哈希值，并以此哈希值代替之前的 UUID 作为镜像层的唯一标识。该机制主要提高了镜像的安全性，并在 pull、push、load 和 save 操作后检测数据的完整性。另外，基于内容哈希来索引镜像层，在一定程度上减少了 ID 的冲突并且增强了镜像层的共享。对于来自不同构建的镜像层，只要拥有相同的内容哈希，也能被不同的镜像共享。

**- 联合挂载**
通俗地讲，联合挂载技术可以在一个挂载点同时挂载多个文件系统，将挂载点的原目录与被挂载内容进行整合，使得最终可见的文件系统将会包含整合之后的各层的文件和目录。实现这种联合挂载技术的文件系统通常被称为联合文件系统(union filesystem)。docker依靠此技术实现镜像本身的只读层与生成容器以后产生的读写层的整合。

## Docker镜像和虚拟机镜像区别
容器是一个应用层抽象，用于将代码和依赖资源打包在一起。多个容器可以在同一台机器上运行，共享底层操作系统内核，但各自作为独立的进程在用户空间中运行。因为剥离了相对沉重的操作系统，所以与虚拟机相比，容器占用的空间较少（容器镜像大小通常只有几十兆），瞬间就能完成启动。

虚拟机 (VM) 是一个物理硬件层抽象，用于将一台服务器变成多台服务器。管理程序允许多个 VM 在一台机器上运行。每个 VM 都包含一整套操作系统、一个或多个应用、必要的二进制文件和库资源，因此占用大量空间。而且 VM 启动也十分缓慢。

需要理解的是，容器和虚拟化并不是一项冲突的技术，现实环境中在资源允许的情况下，可先通过虚拟化技术获得多台VM，再在VM上运行容器。
![](/home/attachment/202210/08/1210417_166520914744305.png)

## 容器和虚拟机区别
![](/home/attachment/202210/08/1210417_166520917434840.png)

# 镜像分类
根据实际容器镜像管理的经验，结合镜像的来源，镜像的用途以及镜像制作参与人员的不同将镜像分为4类：

**- 官方操作系统镜像**
此镜像是操作系统厂商给出的OS的最基础版本，比如ubuntu, suse12sp3，centos，redhat，alpine，windows NanoServer、Windows Server Core和windows insider等镜像，其中开源的镜像比如apline镜像可以通过Docker hub官方网站下载，如使用suse12sp3镜像需要请求SUSE官方支持获得。

为了便于维护，此类型镜像的版本需要尽量少，并且尽量简单。

**- 公司操作系统镜像**
此镜像是在原厂镜像的基础上安装了经过公司内部os运维人员审核过的工具包形成的镜像，此镜像的构建基于官方操作系统镜像。其中常见的工具包括必要的诊断、编辑工具等构建的符合行内规范的操作系统镜像。此部分镜像不区分应用运行环境，由容器云平台运维人员进行维护。

**- 公司基础镜像**
此镜像是在公司操作系统镜像基础上安装了符合公司版本规范的基础软件的镜像，比如安装了JDK，Tomcat，Apache，Nginx，Weblogic，Mysql等，此部分镜像不区分应用运行环境，由容器云平台运维人员进行运维。

**- 公司应用镜像**
此镜像是用于公司业务运行的镜像，构建于公司操作系统镜像或者公司基础镜像之上，一般为开发人员和运维人员共同构建，并且构建完毕以后随带一篇多个环境（开放/测试/生产）的部署说明，参数配置文件说明。

注意，不建议直接下载第三方甚至Docker hub上的基础镜像直接使用，比如nginx，tomcat镜像，理由：
1）安全可控的目的，防止有“毒”镜像。
2）未融入公司的软件配置规范、未进行性能优化以及安全加固

试读部分结束，继续阅读