Linux云计算——docker镜像（三）

一、docker 介绍

1.1 Docker 镜像分层原理

针对镜像体积过大的问题，讲师深入讲解了 Docker 镜像的联合文件系统（UnionFS）分层机制：

1.1.1 分层存储结构

读写层与只读层：镜像由只读层（Read-only layers）和顶部的读写层（Container layer）组成。只读层即镜像层，读写层为容器层。

基础镜像层：最底层为基础镜像（Base Image），提供操作系统环境。

1.1.2 分层构建逻辑

指令与分层对应：Dockerfile 中的每一条指令都会创建一个新的镜像层。例如，`RUN` 命令执行的结果、`COPY` 复制的文件都会形成独立的层。

复用机制：若多个镜像基于同一基础镜像，且中间层内容相同，Docker 会复用这些层，从而节省存储空间。

1.2 Docker 镜像分层构建原理

1.2.1 镜像分层结构与缓存复用机制

分层存储架构： Docker 镜像由基础镜像层、普通镜像层和容器层构成。基础镜像层提供基础环境（如 CentOS），普通镜像层依次叠加操作（如复制源码、安装依赖）。

缓存复用逻辑： 在执行 `docker build` 过程中，每一层镜像构建时会复用上一层的缓存环境。例如，在安装依赖环境时，会自动继承并复制基础镜像层（CentOS）的环境，避免重复构建。

镜像大小累加：镜像层的大小是累计的，每一层约占用 10MB 空间。若镜像层数过多，会导致最终镜像体积过大，因此需优化 Dockerfile 以减少层数。

1.2.2 叠加挂载（Union Mount）技术

多文件系统合并：多个镜像层（本质是目录）通过叠加挂载技术（如 AUFS）统一挂载到容器层。容器层最终呈现的是所有下层镜像层文件的合并视图。

容器启动机制：容器启动时，会从镜像的容器层复制完整的运行环境（包括 Nginx 二进制文件及启动命令）到容器的运行时空间，从而启动为 Up 状态。

1.2.3 镜像存储与删除机制

物理存储位置：镜像层在宿主机上表现为 `/var/lib/docker/overlay2/` 目录下的独立文件。删除镜像时会逐层删除对应的文件。

打包逻辑：所有镜像层叠加挂载后，与容器层一起被打包成一个完整的镜像文件，表现为唯一的镜像 ID。

1.3 Dockerfile 核心指令详解

1.3.1 文件操作与目录管理指令

FROM 与 RUN指令：`FROM` 用于指定基础镜像（操作系统环境）；`RUN` 用于执行命令并产生新的镜像层。

COPY 与 ADD 的区别：`COPY` 仅用于简单的文件复制；`ADD` 具备自动解压功能（针对压缩包）或从网络下载文件的能力。由于 `ADD` 会增加镜像层，非必要情况下建议优先使用 `COPY`。

WORKDIR 工作目录设置：用于设置当前及后续镜像层的默认工作目录。若不设置，后续操作（如 `RUN`）默认在根目录执行，可能导致路径错误。

1.3.2 环境配置与启动指令

ENV 环境变量：用于在构建镜像时预设环境变量（如数据库密码、Java 环境变量），避免在运行容器时重复通过 `-e` 参数指定。

EXPOSE端口声明：声明容器运行时监听的端口。若未声明，即使运行容器时使用了 `-p` 参数，Docker 也可能无法正确识别容器内部端口。

1.3.3 容器启动入口指令

CMD 与 ENTRYPOINT 的异同：两者均用于指定容器启动时的默认执行命令。`CMD` 可被 `docker run` 后的命令覆盖，而 `ENTRYPOINT` 通常作为主进程入口，不易被覆盖。

指令生效规则：若 Dockerfile 中存在多个 `CMD` 指令，仅最后一个生效；`ENTRYPOINT` 与 `CMD` 结合使用时，`CMD` 的内容会作为参数传递给 `ENTRYPOINT`。

二、Dockerfile 实例部署

2.1 Nginx 镜像构建与静态资源部署

针对前端项目（dist 包）在 Nginx 容器中的部署问题， Dockerfile 的编写与调试过程：

2.1.1.、静态资源路径映射方案

路径访问问题解决：针对 dist 包解压后无法直接访问首页的问题，提出了三种解决方案，包括修改 `COPY` 指令使用通配符、修改 Nginx 配置文件的根目录路径，或在访问 URL 中手动添加 `/dist` 路径。

相对路径构建规范：强调在 Dockerfile 中使用相对路径（`.`），若需使用绝对路径，必须在 `docker build` 命令中通过 `-f` 参数显式指定 Dockerfile 文件位置。

2.1.2 基础镜像构建与依赖安装

编译安装流程：演示了从 CentOS 基础镜像出发，通过 `ADD` 添加 Nginx 源码包，安装 GCC、PCRE 等编译依赖，执行 `./configure`、`make` 和 `make install` 的完整编译流程。

系统环境配置：配置了环境变量（`export`）、创建软链接（`ln -s`）以及创建 Nginx 运行用户组，确保服务在容器内可正常启动。

2.1.3 构建调试与错误修复

启动脚本语法修正：首次构建后容器启动失败，经排查发现 `CMD` 指令缺少分号结尾，导致无法识别命令，修正后容器成功运行。

资源文件迁移策略：为解决 `COPY` 指令导致的目录层级错误，调整策略为先将 dist 压缩包解压到 `/opt`，再使用 `mv` 命令将内容移动到 Nginx 的 HTML 目录，确保文件结构正确。

2.2.镜像优化策略与可用性权衡

2.2.1 体积与性能的权衡

镜像体积评估：首次构建的镜像体积约为 1.29GB，虽然体积较大，但确保了功能的完整性。

可用性优先原则：针对部分学员过度追求体积优化导致镜像无法运行（如 8MB 镜像无法承载高并发）的情况，强调优化必须在保证服务可用性的前提下进行，反对盲目追求极致的体积压缩。

2.2.2 构建缓存复用机制

分层构建加速：解释了 Docker 的分层构建机制，当修改 Dockerfile 中的某一层指令时，只有该层及后续层需要重新构建，前面的层可直接复用缓存，从而提升构建速度。

2.3 Dockerfile 高级指令交互机制

深入解析了 `ENTRYPOINT` 与 `CMD` 指令在容器启动时的交互逻辑：

2.3.1 指令执行优先级

参数传递逻辑：当 Dockerfile 中同时存在 `ENTRYPOINT` 和 `CMD` 指令时，`CMD` 的内容会作为参数传递给 `ENTRYPOINT` 执行。

组合执行示例：举例说明 `ENTRYPOINT $"ping", "-c3"$ ` 配合 `CMD $"192.168.110.129"$ `，最终执行的命令为 `ping -c3 192.168.110.129`。

2.3.2 官方镜像启动脚本分析

环境检测机制：官方 Nginx 镜像的 `docker-entrypoint.sh` 脚本，该脚本在启动前会检查配置文件、日志文件等环境依赖，若检测失败则容器启动失败。

参数解析逻辑：脚本通过 ` $1\`、\`$ 2` 等位置变量接收 `CMD` 传递的参数（如 `nginx`、`-s`、`reload`），并根据参数执行相应的逻辑判断。

三、Docker 镜像优化

3.1 Docker 镜像优化核心技术

3.1.1 减少镜像层数与无效缓存

合并 RUN 指令：通过**`&&` 和换行符 `\`** 将多个 RUN 指令合并为一条，显著减少镜像层数，从而压缩体积。

清理构建缓存：在 RUN 指令末尾添加清理命令（如 `yum clean all`、`rm -rf /opt/nginx-1.22.0`），移除安装包和源码等无用文件，避免中间层缓存占用空间。

静默安装与黑洞输出：使用 `>/dev/null` 将软件安装过程中的输出信息重定向至黑洞，减少日志缓存。

3.1.2 选择轻量级基础镜像

基础镜像替换：对比 CentOS（约 200MB+）与 Alpine（约 5MB），演示了将基础镜像替换为 `alpine:3.18` 或 `alpine:3.22`，镜像体积从约 1.2GB 骤降至 200MB 左右。

包管理器差异：指出 Alpine 使用 `apk` 包管理器，需调整安装命令（如 `apk add --no-cache`）以适应新环境。

3.1.3 多阶段构建（Multi-stage Build）

构建与运行分离：利用 `FROM ... AS builder` 和 `FROM ... AS runtime` 将构建环境与运行环境分离。

仅复制产物：在运行阶段仅从构建阶段复制必要的运行文件（如 Jar 包、编译后的二进制文件），剔除编译工具链，极大减小最终镜像体积。

3.2 镜像构建速度优化

3.2.1 利用 .dockerignore 文件

排除非必要文件：在项目根目录创建 `.dockerignore` 文件，将 `node_modules`、`.git` 等无关文件排除在构建上下文外，减少 Docker Daemon 处理的文件量，从而提升构建速度。

3.2.2 网络与缓存处理

网络重试机制：遇到网络问题导致构建失败时，建议清理 Docker 缓存或重启 Docker 服务以重新下载依赖。

生产环境缓存警告：特别强调在生产环境中，严禁随意执行 `FLUSHALL` 等清空 Redis 缓存的命令，以免引发缓存雪崩和数据丢失。

3.3. 若依后端项目部署实战

3.3.1 环境准备与数据库配置

数据库容器化启动：必须先运行 MySQL 和 Redis 容器，并确保暴露 3306 和 6379 端口，以便后端应用连接。

配置文件修改：克隆若依代码后，需修改 `application.yml` 中的数据库连接地址为服务器 IP，确保网络可达。

3.3.2 Jar 包构建与镜像制作

容器化 Maven 打包 ：建议使用 Maven 容器挂载源码目录进行打包，避免宿主机环境不一致问题，打包完成后需将 Jar 包从容器中复制出来。

Dockerfile 编写：基于 JDK 环境编写 Dockerfile，将 Jar 包复制至容器内，并通过 CMD 命令启动应用。

总结：

bash 复制代码

Dockerfile  镜像制作

简单来说，就是把我们部署，配置服务的所有命令 整理出来，然后写入到dockerfile文件中
再配合加上 dockerfile 指令

镜像分层原理：
宏观上： 一个镜像（镜像id ）包含了 容器层和镜像层（基础镜像+镜像）
镜像分层的原理，主要是 "缓存复用+叠加挂载/联合挂载"
每一层镜像层本质来说，都是系统中的一个文件
然后所有镜像层，最终会联合挂载到容器层中，然后把容器层+镜像层的内容"打包"为我们使用的image

dockerfile中有一些常用的指令：
FROM 指定使用一个基础镜像（基础环境）
RUN 执行一条指令（会产生新的镜像层）
COPY/ADD：复制文件到镜像层中，add（附带解压功能+URL路径的文件下载+copy，并且会产生新镜像层）
ENV ： 设置环境变量
EXPOSE ： 指定容器暴露的端口号
WORKDIR:  设置工作目录
CMD/ENTRYPOINT：都是设置容器创建后运行的第一个任务进程

1、CMD 如果存在多条，哪条生效？ 最后一条
2、ENTRYPOINT 如果存在多条，哪条生效？最后一条
3、CMD ENTRYPOINT 同时存在，怎么生效 
ENTRYPOINT 作为主命令，CMD 的内容作为参数传递给它。


要注意 nginx镜像的大小 优化

CMD ["192.168.110.129"]
ENTRYPOINT ["ping","-c 3"]

Dockerfile 
1、有没有自己写过镜像，写过哪些镜像，怎么写的
2、Dockerfile 指令有哪些
3、ADD COPY 区别  CMD 和ENNTRYPOINT区别
4、镜像怎么优化
① 减少镜像层和缓存大小
RUN 
ADD
② 使用更为合适的基础镜像（有效减少镜像体积）

③ 多阶段构建
把镜像的build构建分为2个过程来完成
  第一个是构建阶段：把所有的安装部署过程全部完成
  第二个是runtime运行阶段：把构建阶段完成后，运行服务进程需要的文件copy复制过来，然后只
需要准备基础环境即可
④ 在本地创建.dockerignore ，把不用的文件放入到该隐藏文件中，以此优化镜像构建速度
Dockerfile 
docker build -t 


运行mysql 和redis 的数据库，把sql文件导入到mysql 数据库的ry-vue库中
dockerfile 写ruoyi 后端 
本质而言，就是跑一个jdk环境+ 运行jar包
1、git clone https://gitee.com/humajun/ruoyi.git
2、mvn package 首先（可以运行一个maven:jdk17 容器）
dockerfile 跑java jdk 环境+ jar CMD [java,-jar,ruoyi-admin.jar]

补充：