1. 概述

1.1 使用容器的目的

• 让应用更稳定、可靠的运行
• 降低服务部署和运维成本

1.2 应用开发部署方式的变迁

1.3 云原生

云原生指应用从设计之初就为云环境而构建。

CNCF关于云原生的定义：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

四个关键特征及其带来的好处:

2. 使用容器部署服务

2.1 容器概念

容器与虚拟机的主要区别：

容器和虚拟机共存互补：

• 优先选择容器的情况：追求快速迭代、弹性伸缩的微服务架构；需要极高的资源利用率以节约成本；实践CI/CD（持续集成/持续部署）
• 优先选择虚拟机的情况：应用需要完整的操作系统功能或运行不同内核的操作系统（如在Linux服务器上运行Windows应用）；对安全隔离性有极高要求（如金融、政务等多租户场景）

2.1.1 容器实现

CNCF容器运行时项目列表：

业界常用容器运行时工具：

2.1.2 Docker容器架构

Docker没有发明新技术，而是把 Linux 已有的 namespace、cgroup、chroot 和 unionfs 机制组合起来，用来管理容器的生命周期、镜像的生命周期。

• docker（客户端）：是一个可执行的二进制文件，接收并解析用户输入的命令后发送给dockerd
• dockerd：是一个由 systemd 管理的服务端守护进程，主要功能如下：
  • dockerd 自己并不直接创建容器，它会将这项任务委托给更底层的 containerd，containerd 再通过 containerd-shim 调用 runc 来实际创建容器
  • 生命周期管理：根据指令创建、启动、停止、删除容器。
  • 镜像管理：构建镜像，或从仓库（如 Docker Hub）拉取和推送镜像
  • 资源管理管理容器的网络连接和数据存储卷等

2.1.3 Docker容器模型

业务进程在容器中运行原理如图所示：

• Linux Namespace：Namespace 技术实际上修改了应用进程看待整个计算机“视图”，即它的“视线”被操作系统做了限制，只能“看到”某些指定的内容
• Linux Cgroup：限制一个进程组能够使用的资源上限，包括 CPU、内存、磁盘、网络带宽等等
• 文件系统

2.2 容器镜像

容器镜像的应用场景：

• 镜像是应用及其环境的静态视图。
• 镜像根据Dockerfile中的配置构建的按照一定标准组织起来的一系列文件。

容器镜像的要点：

• 联合文件系统（Union File System）：将多个不同位置的目录联合挂载（union mount）到同一个目录下
  • 从镜像仓库拉取到的“镜像”，实际上就是一个操作系统的 rootfs，它的内容是操作系统的所有文件和目录。
• 镜像分层

以一个golang镜像为例，执行 docker image inspect golang:1.20.5 可以得到镜像元数据：

• GraphDriver 存储驱动信息：GraphDriver 部分显示了该镜像使用 overlay2 存储驱动时的具体目录结构
  • LowerDir：包含多个以冒号分隔的目录路径，这些是镜像的只读层，按从底层到顶层的顺序排列。每个目录对应一个镜像层，存储着该层的文件变更。
  • UpperDir：是可写层目录，当基于该镜像创建容器时，容器的所有写操作都会记录在此处。
  • MergedDir：是 LowerDir 和 UpperDir 合并后的视图，也就是容器实际看到的统一文件系统。
  • WorkDir：是 overlay2 驱动内部使用的工作目录。
• RootFS 根文件系统信息：RootFS 部分描述了镜像的文件系统层次结构：
  • Type: “layers” 表明这是一个分层文件系统。
  • Layers：数组中的每个元素都是一个 SHA256 哈希值，唯一标识一个镜像层。这些哈希值与 LowerDir 中的层是一一对应的关系。
• 镜像层结构分析：该镜像由 6 个层组成（对应 Layers 数组中的 6 个哈希值）。每个层都包含文件系统的变更集，Docker 利用这种分层结构实现了镜像的共享和高效存储。当运行容器时，overlay2 驱动会将这些层与一个可写层（UpperDir）组合，通过 MergedDir 为容器提供统一的文件系统视图。

2.2.1 OCI镜像规范

2.2.2 Dockerfile

通常通过 Dockerfile 构建镜像。

• Dockefile详情见官网文档。
• Dockerfile 最佳实践：https://docs.docker.com/build/building/best-practices/

简单Dockerfile示例：

# 使用官方的轻量级 Python 运行时作为父镜像FROM python:3.9-slim# 设置镜像的维护者信息（新版推荐使用 LABEL）LABEL maintainer="your-email@example.com"LABEL version="1.0" description="示例应用"# 设置一个环境变量，用于防止 Python 在容器中生成 .pyc 文件ENV PYTHONDONTWRITEBYTECODE 1# 设置另一个环境变量，确保 Python 输出直接发送到终端而不被缓冲ENV PYTHONUNBUFFERED 1# 设置应用的工作目录路径ENV APP_HOME /app# 在镜像中创建工作目录WORKDIR $APP_HOME# 将当前目录（构建上下文）下的 requirements.txt 文件复制到容器的 /app 目录下COPY requirements.txt .# 运行命令，安装项目依赖# 将更新软件源列表、安装依赖、清理缓存合并到一层，以减少镜像层数和体积RUN apt-get update \    && apt-get install -y --no-install-recommends gcc \    && pip install --no-cache-dir -r requirements.txt \    && apt-get purge -y --auto-remove gcc \    && rm -rf /var/lib/apt/lists/*# 将当前目录下的所有文件复制到容器的工作目录中COPY . .# 声明容器在运行时将监听的端口号（这只是一个文档说明，实际映射需要在运行时指定）EXPOSE 8000# 在容器内创建一个卷挂载点，用于持久化数据或与宿主机共享数据VOLUME /app/data# 创建一个非 root 用户并切换，以增强容器运行时的安全性<cite data-id='190018'>190018</cite>RUN groupadd -r appuser && useradd -r -g appuser appuserUSER appuser# 定义一个健康检查命令，Docker 会定期执行 `curl -f http://localhost:8000/health/` 来检查应用状态HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \    CMD curl -f http://localhost:8000/health/ || exit 1# 配置容器启动时运行的命令（使用 exec 格式）# 如果 Dockerfile 中有 ENTRYPOINT，则 CMD 作为其默认参数CMD ["gunicorn", "--bind", "0.0.0.0:8000", "app:app"]

构建过程解析：

多阶段构建Dockerfile示例：

# 第一阶段：构建阶段FROM node:18 AS builderWORKDIR /appCOPY package*.json ./RUN npm ciCOPY . .RUN npm run build# 第二阶段：生产阶段，使用更小的基础镜像FROM node:18-alpineWORKDIR /app# 从 builder 阶段只复制构建好的结果，不复制源代码和 node_modulesCOPY --from=builder /app/dist ./distCOPY --from=builder /app/package*.json ./RUN npm ci --omit=devUSER nodeEXPOSE 3000CMD ["node", "dist/index.js"]

注意要点：

1. 使用 .dockerignore 文件：类似于 .gitignore，它可以排除不需要打入镜像的文件（如 node_modules, .git, .env 等），加速构建过程并减小镜像体积。
2. 优化指令顺序：将变化频率最低的指令（如安装依赖 COPY requirements.txt / RUN pip install）放在 Dockerfile 的前面，变化频率高的指令（如复制源代码 COPY . .）放在后面。这样可以充分利用 Docker 的构建缓存，极大提升构建速度。
3. 尽量保证镜像的轻量精简，不要增加不必要的文件。

2.2.3 制作镜像

使用 docker build 制作和所在环境CPU架构和操作系统类型一致的镜像：

docker build -t domain.io/demo:v1.0 -f Dockerfile --network=host .

手动创建多CPU架构的镜像：

• 在各自CPU架构的环境通过 docker build 构建tag带后缀的镜像
• 通过 docker manifest create 命令手动构建支持多架构的镜像
• 通过 docker manifest push 命令推送多架构镜像到镜像仓库

docker manifest create domain.io/demo:v1.0 domain.io/demo:v1.0-amd64 domain.io/demo:v1.0-arm64 --insecuredocker manifest push domain.io/demo:v1.0

使用 docker buildx 构建多CPU架构的镜像：

# 安装 buildx 后docker buildx create --use --name mybuilder --bootstrapdocker buildx build \  --platform linux/amd64,linux/arm64,linux/arm/v7 \  --push \  -t domain.io/demo:v1.0 .

执行docker manifest inspect domain.io/demo:v1.0查看镜像Manifest配置：

{   "schemaVersion": 2,   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",   "manifests": [      {         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",         "size": 1791,         "digest": "sha256:d6b022ac81f2367b0b8d560e5139c298ca0d0fb5b1e93a5f7d9f4096c19f0535",         "platform": {            "architecture": "amd64",            "os": "linux"         }      },      {         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",         "size": 1791,         "digest": "sha256:6caaeb33c0a0de9f72b261ed38449b9244ebe52aaa50c1d76cc7a8cacfee4db1",         "platform": {            "architecture": "arm64",            "os": "linux"         }      }   ]}

在一个安装 docker 的环境中，

• 执行 docker image ls 或 docker images可以查看本地镜像列表
• 执行 docker pull 或 docker image pull 从镜像仓库拉取镜像
• 执行 docker push 或 docker image push 向镜像仓库推送镜像
• 执行 docker image inspect {image id} 可以查看镜像详情
• 执行 docker image save image:tag -o file.tar 可以将镜像 image.tag 导出保存到 file.tag 文件中
• 执行 docker image load -i file.tar 可以将 file.tar 文件中保存的镜像导入

在一个安装了 containerd 的环境中，

• 执行 ctr i ls 可以查看当前环境中由 containerd 管理的镜像列表

在一个安装了 crictl 的环境中，

• 执行crictl image可以查看当前环境中的 OCI 镜像列表
• 执行crictl pull image:tag 可以拉取镜像 image:tag 到本地
• 执行 crictl inspecti image:tag 可以查看镜像 image:tag 的详细信息

在一台服务器上启动多个容器时，运行状态如下：

例如，Docker容器有如下五种网络模式：

containerd 本身不直接提供像 Docker 那样丰富的“网络模式”选项，而是通过插件机制来管理容器网络containerd 的网络能力主要由 CNI (Container Network Interface) 插件提供。这意味着，containerd 支持的网络类型取决于你安装和配置了哪些 CNI 插件。