【云原生】Docker—Dockerfile写法与用法以及dockerfile简介与构建镜像详解【附加实战】

原创 已于 2023-09-09 18:20:01 修改 · 7k 阅读 · 253 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#docker #容器 #云原生 #运维 #dockerfile

于 2022-06-15 08:30:00 首次发布

文章目录

一、dockerfile简介

  什么是dockerfile？

  Dockerfile 是一个用来构建镜像的文本文件，文本内容包含了一条条构建镜像所需的指令(Instruction)和操作命令;每一条指令构建一层镜像，因此每一条指令的内容，就是描述该层镜像应当如何构建（也就是你要执行的操作命令）。

  dockerfile是什么？

  •  dockerfile是纯文本文件；
  •  dockerfile是用来构建镜像的；
  •  dockerfile 用于指示 docker image build 命令自动构建Image的源代码；

dockerfile构建镜像的的格式：

docker build -t 要打的镜像名:版本号 Dockerfile路径

dockerfile构建镜像的的实例：

docker build -t work:v1 .

  为什么要用dockerfile？

  ❓在dockerhub中官方提供很多镜像已经能满足我们99％的服务了,为什么还需要自定义镜像？

  🤔️解析：是，官方的镜像很多，同时也可以满足我们99％的服务；但是，如果有的公司要做自己的产品，那么，官网的镜像肯定是没有的，这时候就需要用到自定义镜像，而自定义镜像就是dockerfile构建成的；

  🥳我们可以用dockerfile自定义写需要的操作，来用dockerfile的指令来实现，最终采用docker build来构建镜像，构建完镜像可以采用docker save 命令打成tar包，以便于日后在其他服务器上使用，也可以采用docker push提交到私有镜像仓库或dockerhub中。

在这里插入图片描述
如上图所示，Dockerfile是独立于本地docker实例的一个文本文件，用于自动化地构建具有特定功能的docker镜像。

Dockerfile镜像构建三部曲：
（1）构建Dockerfile文件；
（2）采用docker build命令构建镜像；
（3）采用docker run命令依据镜像运行容器实例。

  Dockerfile、Docker镜像和Docker容器的关系

从应用软件开发角度来看，它们分别表示软件开发的三个阶段：

  • （1）Dockerfile是软件开发的原材料；
  • （2）Docker镜像是软件的交付品；
  • （3）Docker容器是Docker交付镜像的实例化，代表软件的实际运行过程。

在这里插入图片描述

总结：Dockerfile面向开发，Docker镜像为交付标准，Docker容器与部署、运维相关，三则相辅相成缺一不可，他们是Docker的三大基石。Docker在实际运行中，Dockerfile、Docker镜像、Docker容器三者的运作内容如下所示：

  • 1、Dockerfile定义了进程需要的一切内容，包括：代码执行、文件/环境变量、依赖包、运行环境、操作系统发行版本、服务进程、内核进程等等，很多与操作系统底层相关的内容。
  • 2、通过docker build指令会生成一个Docker镜像，它是为用户提供各种服务的基础；
  • 3、Docker容器则是一个实例化的服务进程。

二、DockerFile需要注意的编写规范

1. # 代表注释

2.指令必须要大写，后面最少需要带一个参数，最多无限制;

3.执行dockerfile的时候，指令是按照从上到下的顺序执行的；

三、Docekrfile指令解析

注意：指令全部都必须为大写，后面跟的是你要执行的操作命令

指令功能简介
FROM指定构建新image是使用的基础image，通常必须是Dockerfile的第一个有效指令；定义一个基础镜像。
LABEL附加到image之上的元数据，键值格式；定义一些元数据。
ENV以键值格式设定环境变量，可被其后的指令所调用，且基于新生成的image运行的Container中也会存在这些变量。
RUN以FROM中定义的image为基础环境运行指令命令，生成结果将作为新image的一个镜像层，并可由后续指令所使用。RUN后跟要执行的命令。
CMD基于dockerfile生成的image运行的container时，CMD能够指定容器中默认运行的程序，因而其只应该定义一次。
ENTRYPOINT类似于CMD指令的功能，但不能被命令行指定要运行的应用程序覆盖，且与CMD共存时，CMD的内容将作为该指令中定义的程序的参数。
WORKDIR相当于cd切换目录的命令，如果切换的那个地方没有哪个目录，则会自动创建一个目录。
COPY相当于cp命令，复制主机上或者前一阶段构建结果中（需要使用–from选项）文件或目录生成新的镜像。
ADD与COPY指令的功能相似，但ADD传输压缩包的时候，是可以解压的。
VOLUME指定基于新生成的Image运行Container时期望作为volume使用的目录。
EXPOSE指定基于新生成的lmage运行Container时期望 暴露的端口，但实际暴露与否取决于"docker run”命令的选项，支持TCP和UDP协议。
USER为Dockerfile中该指令后面的RUN、CMD和ENTRYPOING指令中要运行的应用程序指定运行者身份UID，以及一个可选的GID。
ARG定义专用于build过程中的变量，但仅对该指标之后的调用生效，其值可由命令行选项"–build-arg"进行传递。
ONBUILD触发器，生效于由该Dockerfile 构建出的新l/mage被用于另一个Dockerfile中的FROM指令作为基础镜像时。
STOPSIGNAL用于通知Container终止的系统调用信号。
HEALTHCHECK定义检测容器应用的健康状态的具体方法。
SHELL为容器定义运行时使用的默认shel程序，Linux系统默认使用 [/bin/sh”，“-c”], Windows默认使用 [’cmd’, “/S’,”/C’]。

四、常用的Dockerfile指令详解、格式与用法

（必须）是写dockerfile必须有的，没有加的是（可选）的。

4.1 FROM（必须）

指定一个基础镜像，必须为第一个命令。

格式

FROM 基础镜像

举例

一个nvidia、cuda10.1的centos7基础镜像

FROM nvidia/cuda:10.1-cudnn7-devel-centos7

4.2 MAINTAINER

维护者信息，可以写邮箱，编辑人等等。

格式

MAINTAINER 邮箱/名字

举例

展示邮箱和名字

MAINTAINER liucy
MAINTAINER 121212@qq.com
MAINTAINER 121212@163.com

4.3 USER

指定运行容器时的用户名或 UID，后续的 RUN 也会使用指定用户。使用USER指定用户时，可以使用用户名、UID或GID，或是两者的组合。当服务不需要管理员权限时，可以通过该命令指定运行用户。并且可以在之前创建所需要的用户

格式

USER 用户名
&&
USER user:group　
&&　
USER uid　　
&&
USER uid:gid　　
&&
USER user:gid　　
&&
USER uid:group

举例

指定root用户

USER root

4.4 ENV（必须）

设置环境变量

格式

ENV 环境变量路径

举例

设置jdk1.8的环境变量

ENV JAVA_HOME=/usr/local/jdk1.8.0_333/
ENV export JRE_HOME=$JAVA_HOME/jre
ENV export CLASSPATH=.:$JAVA_HOME/lib:$JRE_HOME/lib
ENV PATH=$JAVA_HOME/bin:$PATH

4.5 VOLUME

用于指定持久化目录（指定此目录可以被挂载出去）

格式

VOLUME 挂载路径

举例

挂载到/data目录

VOLUME ["/data"]

4.6 EXPOSE

设置端口，EXPOSE指令是声明运行时容器提供服务端口，这只是一个声明，在运行时并不会因为这个声明应该就会开启这个端口的服务。

在Dockerfile中写入这样的声明有两个好处：
是帮助镜像使用者理解这个镜像服务的守护端口，以方便配置映射；
在运行是使随机端口映射时，也就是docker run -P(大写)时，会自动随机映射EXPOSE端口。

格式

EXPOSE 端口号

举例

设置一个8080端口

EXPOSE 8080

4.7 COPY

复制文件，相当于linux命令中的cp命令；
功能类似ADD，但是是不会自动解压文件，也不能访问网络资源

格式

COPY 源文件及路径 目标路径

举例

复制一个mysql到/usr/local/下

COPY /root/mysql /usr/local/

4.8 ADD

将本地文件添加到容器中，tar类型文件会自动解压(网络压缩资源不会被解压)，可以访问网络资源，类似wget。

格式

ADD 源文件及路径 目标路径

举例

移动一个mysql-2-2.tar

ADD /usr/local/mysql-2-2.tar /root/

4.9 WORKDIR

切换目录，相当于linux命令中的cd命令，切换到这个目录，进入容器时就是这个目录，所以，workdir就属于启动默认的目录。

格式

WORKDIR 目录名

举例

设置启动就在/data/目录

WORKDIR /data/

4.10 RUN（必须）

构建镜像时执行的命令，执行的命令就是你指定的要他干什么，使用linux命令就可以。

格式

RUN 要执行的命令

举例

打镜像时下载一个netstat命令

RUN yum -y install net-tools

4.11 CMD

构建镜像后调用，也就是在容器启动时才进行调用。写一次dockerfile只能出现一次CMD，而出现CMD的地方，就属于结尾，如果下面有RUN指令，则都不执行。

格式

CMD 要执行的命令

举例

执行删除dockerfile（打完镜像，要删除dockerfile）

CMD rm -rf /data/dockerfile

五、docker build构建镜像

dockerfile构建镜像的的格式：

docker build -t 要打的镜像名:版本号 Dockerfile路径

dockerfile构建镜像的的实例：

docker build -t work:v1 .

六、【实战】docker自定义镜像

说明：

  此处只是测试使用，并不能用到生产中，（生产中要根据自己的情况来写），可以构建成镜像，也可以创建容器，可以进入容器查看这些文件，但是web页面访问不到，因为没有加入jar包之类的，可以自行放入一个jar包，端口设置3000，然后启动jar包就可以了去访问web页面了。

前言：
  有一点特别重要，构建镜像的时候要看好你的文件是不是这个目录，要不然打到一半会报错，说找不到文件，切记要记得放文件，在放文件的目录执行。

1、编写Dockerfile

#创建Dockerfile文本
vim Dockerfile

#设置基础镜像
FROM nvidia/cuda:10.1-cudnn7-devel-centos7
#维护者信息
MAINTAINER liucy
MAINTAINER 121212@qq.com
MAINTAINER 121212@163.com
#指定运行时的用户以及镜像的实际用户
USER root
#下载netstat命令
RUN yum -y install net-tools
#设置jdk1.8的环境
ENV JAVA_HOME=/usr/local/jdk1.8.0_333/
ENV export JRE_HOME=$JAVA_HOME/jre
ENV export CLASSPATH=.:$JAVA_HOME/lib:$JRE_HOME/lib
ENV PATH=$JAVA_HOME/bin:$PATH
#开放一个3000端口
EXPOSE 3000
#移动并解压Grafana.tar安装包
ADD /root/Grafana.tar /home/
#复制当前目录下的所有到/data/cs/里
COPY ./ /data/home/
#设置python3.6.8环境
RUN cd /data/Python-3.6.8/ && ./configure --prefix=/root/python36 && make && make install && ln -s /root/python36/bin/python3.6 /usr/bin/python3 && ln -s /root/python36/bin/pip3 /usr/bin/pip3
#切换到/data/目录
WORKDIR /data/
#最后执行删除Dockerfile
CMD rm -rf Dockerfile

2、构建镜像

docker build -t dockerfile:v1 .

等待构建完成。

3、查看镜像

[root@cs ~]# docker images
REPOSITORY                 TAG                 IMAGE ID            CREATED             SIZE
dockerfile                 v1                 15c89s63e742      2 months ago           8.5GB

七、总结

  相关文章

【云原生】Docker—Dockerfile写法与用法以及dockerfile简介与构建镜像详解
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Linux中基于Docker搭建harbor私有镜像仓库（超级详细）
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Docker搭建harbor私有镜像仓库（命令行模式）
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Docker发布/上传镜像到dockerhub&&下载/拉取镜像&&删除dockerhub镜像
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
linux（centos）中部署docker（步骤超全，含带一些发展史和一些概念）
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
如何从docker镜像里提取dockerfile
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

  相关专栏

《docker从入门到精通》《Linux从入门到精通》可以关注专栏奥，会持续更新的。

Dockerfile文件编写
m_2076的博客
12-18 2793
Dockerfile 是一个文本文件，其内包含了一条条的指令(Instruction)，用于构建镜像。每一条指令构建一层镜像，因此每一条指令的内容，就是描述该层镜像应当如何构建。dockerfile的原理就是镜像分层。
Docker高级篇之Dockerfile解析
qq_43456605的博客
06-06 1539
DockerFile是用来构建Docker镜像的文本文件，是由一条条构建镜像的指令和参数构成的脚本。
Docker从零学习系列之Dockerfile
https://ophome.blog.csdn.net,在IT行业有多年的工作经验，尤其是在Python、Linux、负载均衡、Nginx和服务器运维等领域。
08-31 722
本文系统介绍了Dockerfile的核心概念与实用技巧。主要内容包括：1）Dockerfile基础语法解析，涵盖FROM、RUN、COPY等指令的使用方法；2）生产级Dockerfile编写指南，重点讲解多阶段构建、安全优化等高级特性；3）常见问题解决方案，如镜像瘦身、缓存优化等；4）提供完整的检查清单和最佳实践。通过具体案例演示如何构建高效安全的应用镜像，帮助开发者掌握Docker容器化部署的核心技能。
Dockerfile基本结构及编写详解
qq_36305027的博客
01-07 2405
Dockerfile基本结构及编写详解
【Docker】Dockerfile 文件编写
u013675821的博客
08-02 3424
编写 Dockerfile 是创建 Docker 镜像的核心步骤。Dockerfile 是一个文本文件，其中包含了构建镜像所需的一系列指令和配置。在本文中，我们将详细介绍 Dockerfile 的编写，包括其基本结构、常用指令、优化技巧和示例。
二、Dockerfile 编写
骑士梦的博客
07-10 1957
一、Dockerfile 指令 二、常用软件 Dockerfile 三、Docker 私有仓库搭建
使用Dockerfile构建镜像实践[详细]
一切有为法，如梦亦如幻，如露亦如电，应作如是观。
09-05 1027
Dockerfile是一个用来构建镜像的文本文件，文本内容包含了一条条构建镜像所需的指令和说明。
Docker容器-从最基础到Dockerfile、Docker-compose，有这一篇足够了！！！
h16678481的博客
06-20 2235
Docker从0-1，从小白-熟练使用容器的高手
2.认识Dockerfile，如何用Dockerfile构建镜像
qq_25798883的博客
12-14 296
2.认识Dockerfile（从docker到k8s容器化云原生技术从零基础到实战），本套技术博客包含了docker、docker-compose、如何用gitlab以及jinkins搭建CICD流水线自动化到部署到K8S容器云平台，实现千万级流量集群应用的部署！
Dockerfile学习
orz_include的博客
04-21 1094
最后一个 . 是上下文路径，是指 docker 在构建镜像，有时候想要使用到本机的文件（比如复制），docker build 命令得知这个路径后，会将路径下的所有内容打包。1、Dockerfile 是一个文本文件，其内包含了一条条的 指令(Instruction)，每一条指令构建一层，因此每一条指令的内容，就是描述该层应当如何构建。命令构建镜像，其实并非在本地构建，而是在服务端，也就是 Docker 引擎中构建的。所不同的是，ARG 所设置的构建环境的环境变量，在将来容器运行时是不会存在这些环境变量的。
Dockerfile 构建缓存机制深度解析：BuildKit 与传统构建对比实战 关键词 Dockerfile 构建缓存、BuildKit、传统构建器、缓存命中、LLB 构建图、层复用、构建优化、企业级CI系统、构建稳定性、性能调优 摘要 在企业级容器构建场景中，Dockerfile 缓存机制的理解深度直接影响构建性能、持续集成效率与调试稳定性。许多开发者在多阶段构建、频繁迭代与并发流水线中，频繁遭遇“缓存未命中”、“构建时间剧增”或“产物无法复用”等问题，却难以精准定位底层原因。本文聚焦 Dockerfile 构建缓存机制，从传统构建引擎到 BuildKit 的演进路径，系统解析缓存的层级模型、命中规则、哈希生成逻辑与复用判定条件，深入剖析实际工程中缓存失效的典型成因，并结合真实案例演示如何通过 BuildKit 实现更细粒度、更稳定、更高效的构建复用路径，输出一整套可验证、可调优、可迁移的构建优化实战方法论。 目录 第一章：Dockerfile 缓存机制概述与误解澄清 Docker 构建缓存的基础概念 什么是缓存命中？什么不是？ 常见缓存误区：RUN 指令变化为何导致全链条失效 构建缓存与镜像层的差异边界 第二章：传统 Docker 构建引擎的缓存命中逻辑拆解 缓存命中规则：按行匹配 + 哈希比较 每一层的内容变更如何影响缓存行为 指令顺序与缓存不可控性的内在关联 使用场景下的传统构建问题实录 第三章：BuildKit 构建引擎的底层机制详解 BuildKit 架构概览：LLB DAG 构建图 内容寻址与缓存复用：从层到内容块的粒度转变 --mount=type=cache、构建参数分离等增强功能 并行执行与跳过无关步骤的智能机制 第四章：缓存失效典型场景分析与真实复现 COPY 顺序变动、时区变化、GIT 元数据污染等问题 环境变量污染导致缓存失效的根本原因 RUN 指令链式编写中的非预期失效案例 企业流水线中间件影响构建缓存的真实案例解析 第五章：构建缓存的调试技巧与可视化工具实践 使用 --progress=plain 查看缓存命中路径 docker history 与 docker build --no-cache 的辅助诊断 结合 dive 工具可视化构建层变化 BuildKit 日志分析：理解跳过与命中行为 第六章：构建性能与缓存策略设计的工程路径 如何组织 Dockerfile 结构以最大化缓存复用 指令拆分策略与多阶段拆层设计 编译类项目（如 Node、Go、Python）缓存粒度控制 配合 CI/CD 流水线缓存共享的优化策略 第七章：BuildKit 构建缓存高级应用实战 使用 --mount=type=cache,target=/root/.npm 缓存依赖 构建缓存目录映射与清理策略 基于内容地址的镜像复用设计 构建缓存导出与导入机制（--cache-to / --cache-from） 第八章：从传统构建到 BuildKit 架构迁移的实战路线 企业项目中如何无痛切换至 BuildKit 构建体系 BuildKit 与 CI 工具（如 GitHub Actions、GitLab CI、Jenkins）的整合实践 构建缓存稳定性对比分析与效果评估 未来构建架构演进趋势预判与优化建议 第一章：Dockerfile 缓存机制概述与误解澄清 Docker 构建缓存的基础概念 Docker 构建缓存是指，在构建镜像时，对于已执行过的构建步骤（Dockerfile 指令），若内容与历史一致，可重用历史构建产物，避免重复执行相同步骤，从而加快构建速度、减少资源浪费。每条 Dockerfile 指令在构建过程中都会生成一个中间层（layer），这些中间层会被缓存下来供后续使用。 缓存的核心目的是复用已有构建产物，本质是对每条指令及其上下文状态（文件、参数、环境等）进行哈希比对，以判断是否可以跳过执行过程直接应用结果。Docker 使用缓存加速的是构建过程，不是最终镜像体积的优化机制。理解这一点对于调试缓存相关问题至关重要。 什么是缓存命中？什么不是？ “缓存命中”意味着 Docker 构建引擎在执行某条指令时，判断该指令及其上下文与历史记录中的某一项完全一致，因此跳过实际执行，直接复用该步骤的构建结果。 缓存命中具备两个必要条件： 指令文本内容完全一致（如 RUN apt update && apt install -y curl） 上下文输入未发生变化，如： 被 COPY 的文件没有修改过； 依赖的环境变量值未改变； 构建上下文目录中无新增、删除、修改文件； 基础镜像未变更； 构建参数保持一致。 反之，只要以上任一条件未满足，即发生缓存失效（miss），Docker 将执行该指令，并使其后续所有指令的缓存全部失效，重新执行。 常见误判： 仅因 Dockerfile 指令未改动就认为一定命中缓存； 未意识到 .dockerignore 配置变化也会导致 COPY 缓存失效； 将依赖频繁变更的文件放在靠前指令位置，导致整个构建链路频繁失效。 常见缓存误区：RUN 指令变化为何导致全链条失效 在传统构建模式中，Docker 会按顺序执行 Dockerfile 中每一条指令，并在执行完成后将其生成的层作为缓存项记录下来。指令一旦发生任何变更，Docker 会中止该步骤后的所有缓存复用。 例如： FROM node:18 COPY . /app RUN npm install RUN npm run build dockerfile 1 2 3 4 若 RUN npm install 改成 RUN npm install --legacy-peer-deps，则该行变更导致其后的 RUN npm run build 缓存失效，必须重新执行。而且 npm install 的执行内容通常包含网络请求与依赖解析，时间成本高，失效代价大。 更隐蔽的是，当 COPY 的目录中某个文件（如 package-lock.json）变动，哪怕 RUN npm install 指令不变，缓存也无法命中，因为输入文件发生了变化。 构建缓存与镜像层的差异边界 缓存与镜像层虽然一一对应，但二者用途与管理逻辑完全不同。 缓存层的本质是构建时用于加速复用的中间产物，生命周期依赖构建链路，可能被覆盖或失效；而镜像层是构建完成后的最终产物，用于生成镜像快照并被容器运行时加载，属于运行态依赖。 关键区别如下： 项目 缓存层（Build Cache） 镜像层（Image Layer） 作用 构建时复用构建步骤 构建完成后生成容器镜像 管理方式 与构建上下文紧耦合，临时可变 由 docker image 管理，可长期保存 生命周期 可因指令或上下文变化而失效 不随 Dockerfile 修改自动失效 可见性 默认不可见（除非使用 dive 或历史构建记录） 可通过 docker image ls 和 docker history 查看 命中机制 哈希比对输入、上下文与指令 静态快照结果 开发者常常将构建失败归咎于“缓存未生效”，而真实情况往往是由于混淆了这两者之间的职责边界，误判了导致重构的根因。 第二章：传统 Docker 构建引擎的缓存命中逻辑拆解 缓存命中规则：按行匹配 + 哈希比较 Docker 传统构建器采用“按顺序处理 + 层缓存”机制，对于每一条指令，都会生成一段 SHA256 哈希（包括指令本身、输入文件的哈希、构建参数等）。若当前指令的哈希与已有缓存中某条记录一致，即可命中缓存。 关键点是：Docker 不会智能判断哪些部分不变，它仅根据文本内容与上下文输入的一致性做全量比对。 例如，以下两条指令逻辑一致，但文本不同，缓存不命中： RUN apt-get install curl RUN apt-get install curl -y dockerfile 1 2 即使执行结果一样，只要写法不同，Docker 就会视为新的构建路径，生成新的缓存层。 每一层的内容变更如何影响缓存行为 每一层的缓存判定严格依赖前一层的输出。当某层发生变动，其后所有层都将失效。这种设计是为保证构建的一致性与可复现性，但也带来缓存失效“传染性”的问题。 如下 Dockerfile： FROM python:3.11 COPY requirements.txt . RUN pip install -r requirements.txt COPY . . RUN python setup.py install dockerfile 1 2 3 4 5 当 requirements.txt 更新时，RUN pip install 无法命中缓存，进而影响到后续的 COPY . . 和 RUN python setup.py install。即便代码无变动，也需重新打包，构建时间显著增加。 为了降低这种影响，最佳实践是将稳定文件（如依赖文件）置于前面，确保代码层与依赖层解耦。 指令顺序与缓存不可控性的内在关联 Dockerfile 的指令顺序直接决定了构建缓存的命中路径。只要前面的指令变动，后面的所有缓存均失效。这种顺序敏感性要求开发者以“缓存命中优先”为指导思想设计 Dockerfile 结构。 常见失误： 将 COPY . 放在很早的阶段，导致任何代码变动都让所有构建缓存失效； 合并多个逻辑步骤在同一 RUN 指令中，调试困难且影响后续缓存； 将 GIT 仓库整个 copy 进构建上下文，.git 目录变动频繁干扰缓存。 更好的做法是： COPY requirements.txt . RUN pip install -r requirements.txt COPY . . RUN python setup.py install dockerfile 1 2 3 4 5 这样可将依赖安装与代码打包分离，最大限度复用已有依赖缓存。 使用场景下的传统构建问题实录 以下为真实 CI 环境中出现过的缓存失效场景案例： 某大型微服务构建链路每日构建时间波动超过 4 倍。排查后发现 .dockerignore 配置不完整，.git 目录频繁变动引发 COPY 缓存层失效。 Java 项目构建中 COPY . . 尽管无代码更改却触发完整构建。最终定位是一个临时日志文件未忽略，触发指令上下文变更。 开发者修改一行 RUN 指令格式，将 && 换成 \ 换行符，导致全链路重新构建。虽然逻辑不变，但哈希已然不同，缓存失效。 这些案例均指向一个共性：在传统 Docker 构建器中，缓存机制对指令文本与上下文高度敏感，极易被微小变更破坏。因此，理解缓存逻辑并设计良好的 Dockerfile 构建路径是构建效率与稳定性的关键。 第三章：BuildKit 构建引擎的底层机制详解 BuildKit 架构概览：LLB DAG 构建图 BuildKit 是 Docker 近年推出的新一代构建后端，其核心特点在于使用 LLB（Low Level Build）格式表示构建计划，通过构建指令转化为有向无环图（DAG），从而实现并行构建、跳过无关步骤、精细化缓存复用等能力。 LLB DAG 与传统线性执行逻辑相比具备更强的表达能力。每一个构建节点不仅表示某个指令（如 COPY、RUN），还包含其依赖关系、输入文件状态与上下文配置，构建器据此调度指令，执行前先判断输入变化，只有真正变更的节点才重新执行。 LLB 构建图的生成由 docker build 时自动完成（需启用 BuildKit）。构建图的静态结构决定了后续缓存复用策略，这也是 BuildKit 能比传统模式更智能跳过非必要步骤的基础。 内容寻址与缓存复用：从层到内容块的粒度转变 BuildKit 的缓存机制不再基于“镜像层”的抽象，而是引入了内容寻址存储（Content Addressed Storage），每个构建输入的实际内容都会被独立哈希后存储为可复用的内容块（chunk），执行过程以内容哈希而非层编号为单位判断缓存。 这意味着： 相同文件哪怕出现在不同路径，只要内容未变都能复用； 不再依赖 Dockerfile 指令顺序进行粗粒度层命中判断； 构建结果可按输入粒度重构，提升复用效率。 BuildKit 使用 llbsolver 组件实现内容指纹比对机制。对于如依赖下载、文件编译等可确定性步骤，即使 Dockerfile 改动较大，也可通过重用中间指令结果大幅缩短构建时间。 --mount=type=cache、构建参数分离等增强功能 BuildKit 支持原生挂载类型的扩展能力，最常见的是 --mount=type=cache，用于将某些路径挂载为构建缓存目录，避免每次执行都重新下载或编译。例如： RUN --mount=type=cache,target=/root/.cache/pip \ pip install -r requirements.txt dockerfile 1 2 该挂载路径会在多次构建中自动保留上次的内容，极大提升如 Python、Node、Go 等依赖密集型项目的构建速度。 此外，BuildKit 也支持构建参数与构建输出分离控制，如： --build-arg 参数可与 RUN 隔离，避免无关参数污染缓存； 使用 --output 将构建结果导出至宿主路径或 OCI 镜像； 支持缓存导入导出（--cache-from / --cache-to）配合 CI 构建缓存中心。 这些机制共同构成了更灵活、颗粒度更小、构建时间更可控的缓存策略体系。 并行执行与跳过无关步骤的智能机制 基于 DAG 的结构，BuildKit 可自动推导哪些指令可并行执行。例如： RUN go mod download RUN npm install dockerfile 1 2 若前者用于服务 A，后者用于服务 B，BuildKit 将自动调度并发执行，从而大幅压缩构建时间。而在传统 Docker 引擎中，这种串行执行导致构建效率低下。 此外，当某条指令的依赖（上下文、输入、参数）未变时，BuildKit 将智能跳过构建步骤，避免重建。例如下列场景： COPY scripts/ /opt/scripts/ RUN chmod +x /opt/scripts/start.sh dockerfile 1 2 若 scripts/ 目录未变，则无论 Dockerfile 其余部分如何修改，BuildKit 均可跳过该步骤。 这种智能调度机制让 BuildKit 在大规模构建任务中具备压倒性性能优势，也为构建流程的可观测性与性能分析提供坚实基础。 第四章：缓存失效典型场景分析与真实复现 COPY 顺序变动、时区变化、GIT 元数据污染等问题 COPY 指令是缓存失效的高频触发点。其失效触发因素包括但不限于： 源文件内容发生变动； COPY 源路径顺序调整； .dockerignore 配置改动； .git 目录中提交哈希变动； 文件权限、修改时间戳发生变化（如不同操作系统时区差异）。 案例复现： COPY . . dockerfile 1 若构建上下文中包含 .git/ 目录，每次提交都会引发该指令缓存失效，即使项目业务代码无变化。解决办法是明确 .dockerignore 文件中排除 .git： .git 1 另一个常见问题是文件系统时区差异引发的元数据变化。开发者在不同操作系统下进行文件同步操作，可能导致构建上下文中文件的 mtime 改变，间接触发 COPY 缓存失效。 环境变量污染导致缓存失效的根本原因 RUN 指令依赖环境变量时，只要变量内容发生变化，即会生成新的哈希值，导致该指令缓存失效。 例如： ARG BUILD_ENV ENV BUILD_ENV=${BUILD_ENV} RUN echo $BUILD_ENV dockerfile 1 2 3 若构建时多次传入不同参数： docker build --build-arg BUILD_ENV=staging . docker build --build-arg BUILD_ENV=production . bash 1 2 则上述 RUN 步骤会生成两个不同的缓存路径。若 BUILD_ENV 只影响启动行为，而不影响构建过程，建议不要参与 RUN 或 COPY 的上下文内容。可通过构建阶段拆分方式解耦： ARG BUILD_ENV ENV RUNTIME_ENV=${BUILD_ENV} FROM base as builder # 构建内容不受 BUILD_ENV 影响 FROM base COPY --from=builder /app /app ENV RUNTIME_ENV=${BUILD_ENV} dockerfile 1 2 3 4 5 6 7 8 9 这样构建产物可复用，而仅在最终镜像中注入运行参数。 RUN 指令链式编写中的非预期失效案例 链式 RUN 指令可提高构建效率，但也会放大缓存失效影响。例如： RUN apt update && apt install -y curl && apt install -y git dockerfile 1 若 apt install -y git 有变动（如版本锁定变更），将导致整条指令重新执行，甚至因 apt update 可变行为引发不一致构建结果。 优化方式是将 RUN 拆分为多个指令，并结合 BuildKit 的缓存能力保留稳定步骤： RUN apt update RUN apt install -y curl RUN apt install -y git dockerfile 1 2 3 或在 CI 中固定依赖版本，并缓存 APT 目录内容。 企业流水线中间件影响构建缓存的真实案例解析 在某大型微服务平台中，构建缓存失效被归因于 GitLab Runner 自动注入的环境变量。每次构建，CI 工具都会附加构建时间戳、commit id 等变量至构建上下文，间接影响 RUN、ENV、LABEL 指令的缓存命中。 具体表现： Dockerfile 中写有 LABEL build_time=$BUILD_TIME； $BUILD_TIME 在每次 CI 构建中由外部工具动态注入； 每次构建都生成不同 LABEL，导致所有后续指令缓存全部失效。 解决方案是： 移除非必要 LABEL； 将动态构建信息放入最终容器外部 metadata； 或在构建后单独注入镜像元信息，避免污染主构建路径。 此类流水线变量污染是构建缓存体系中被长期忽视但影响极大的问题，需在工程配置中进行隔离设计。 第五章：构建缓存的调试技巧与可视化工具实践 使用 --progress=plain 查看缓存命中路径 启用 BuildKit 构建时，Docker 默认使用简洁的进度条模式输出构建过程，难以直接判断某条指令是否命中缓存。通过添加参数 --progress=plain 可启用详细日志输出，显示每一步指令的缓存行为： DOCKER_BUILDKIT=1 docker build --progress=plain . bash 1 输出示例： #5 [internal] load build definition from Dockerfile #5 sha256:... #5 DONE 0.1s #6 [2/5] RUN npm install #6 CACHED 1 2 3 4 5 关键字段为 CACHED，表示该步骤已成功从缓存中复用，而不是重新执行。若某步骤显示 DONE 并伴随执行时间，说明其缓存未命中并已重新执行。通过该日志可以快速定位缓存未命中的具体步骤。 docker history 与 docker build --no-cache 的辅助诊断 docker history 命令可列出镜像各层的构建信息，包括创建指令、体积、创建时间： docker history my-image:latest bash 1 输出示例： IMAGE CREATED CREATED BY SIZE <id> 2 minutes ago /bin/sh -c npm install 180MB <id> 2 minutes ago /bin/sh -c COPY . . 40MB 1 2 3 该命令可用于分析镜像是否因缓存失效而重新创建了多个相似层（例如重复的 RUN 层），也可用于比对有无重复内容残留。 另外，当怀疑缓存污染或非预期命中时，可强制跳过缓存： docker build --no-cache . bash 1 用于验证不同构建路径结果是否一致，是定位构建不一致性问题的关键手段。 结合 dive 工具可视化构建层变化 dive 是一款专用于 Docker 镜像分析的工具，支持镜像结构层级可视化、每层文件变化查看、冗余检测、效率评估等。 安装 dive 后： dive my-image:latest bash 1 功能包括： 查看每一层变更的文件、目录结构； 判断某些指令是否引入了未预期的文件； 识别临时文件未清理、依赖残留等镜像膨胀问题； 检查 COPY 或 RUN 层带来的缓存重复。 尤其在调试构建产物未清理、缓存未复用引发的体积暴涨问题时，dive 是最直观、最可靠的分析利器。 BuildKit 日志分析：理解跳过与命中行为 对于更复杂的调试场景，可开启 BuildKit 的详细调试日志。以 CLI 启动构建时，可设置以下环境变量： DOCKER_BUILDKIT=1 BUILDKIT_PROGRESS=plain docker build . bash 1 在容器化构建系统中使用 BuildKit 守护进程（如 buildkitd）时，可直接在启动参数中启用 debug 模式，并查看日志： buildkitd --debug bash 1 调试日志中会记录每个节点的哈希对比、输入路径、缓存状态、跳过原因，典型输出如下： solver: caching disabled for op: RUN apt update solver: operation did not match cache key solver: using previous result for op: COPY /src -> /app 1 2 3 通过这些日志可识别为何某一步骤未命中缓存，例如： 内容哈希差异； 上游依赖变更； 构建参数不同； 上下文路径被修改。 结合 llb 构建图理解缓存判定的路径，是排查复杂缓存异常最根本的方法。 第六章：构建性能与缓存策略设计的工程路径 如何组织 Dockerfile 结构以最大化缓存复用 构建性能的根本在于设计良好的缓存结构，而这取决于 Dockerfile 的组织方式。设计原则如下： 固定输入放前，例如依赖文件、配置模板、脚本等变更频率低的内容应优先 COPY； 高变动步骤靠后，如业务代码、构建参数应尽可能延后执行，避免频繁触发大面积缓存失效； 指令最小化原则，每条 RUN、COPY、ADD 应职责单一，便于缓存颗粒化复用； 分阶段构建产物，避免冗余中间层直接进入最终镜像。 典型模式优化前： COPY . . RUN npm install RUN npm run build dockerfile 1 2 3 优化后： COPY package.json package-lock.json ./ RUN npm install COPY . . RUN npm run build dockerfile 1 2 3 4 前者任一文件改动都会失效 npm 缓存，后者则可稳定命中依赖层。 指令拆分策略与多阶段拆层设计 将多个依赖合并为一条 RUN 虽然构建更快，但会导致缓存控制失效，调试困难。推荐做法是拆分 RUN 步骤，配合多阶段构建对产物路径进行精确隔离。 错误范式： RUN apt update && apt install -y curl && pip install -r requirements.txt dockerfile 1 优化拆分： RUN apt update && apt install -y curl COPY requirements.txt . RUN pip install -r requirements.txt dockerfile 1 2 3 配合如下多阶段拆分： FROM python:3.11 as builder COPY requirements.txt . RUN pip install -r requirements.txt COPY . . RUN python setup.py build FROM python:3.11-slim COPY --from=builder /app /app dockerfile 1 2 3 4 5 6 7 8 9 通过精细拆层，可以提高复用率，同时将不必要文件隔离在 builder 阶段。 编译类项目（如 Node、Go、Python）缓存粒度控制 对于需要依赖管理与构建的项目，构建缓存应覆盖依赖、构建产物与最终打包三个阶段。各类语言推荐策略： Node.js COPY package*.json ./ RUN npm ci COPY . . RUN npm run build dockerfile 1 2 3 4 使用 npm ci 保证锁定版本，缓存 npm 目录。 Go COPY go.mod go.sum ./ RUN go mod download COPY . . RUN go build -o app main.go dockerfile 1 2 3 4 先下载依赖，再构建二进制，保持 go mod 缓存稳定。 Python COPY requirements.txt . RUN pip install -r requirements.txt COPY . . RUN python setup.py install dockerfile 1 2 3 4 结合 --mount=type=cache 保持依赖目录缓存（如 ~/.npm、~/.cache/pip、/go/pkg/mod）。 配合 CI/CD 流水线缓存共享的优化策略 在企业级流水线中，可通过导入导出缓存目录，实现跨构建任务的缓存复用。例如 GitHub Actions、GitLab CI 支持如下机制： docker build \ --build-arg BUILDKIT_INLINE_CACHE=1 \ --cache-from=type=registry,ref=myrepo/app:cache \ --cache-to=type=registry,ref=myrepo/app:cache,mode=max \ -t myrepo/app:latest . bash 1 2 3 4 5 --cache-from 指定远程已有缓存； --cache-to 将当前构建缓存导出； BUILDKIT_INLINE_CACHE=1 使镜像内嵌缓存元信息，支持镜像复用缓存路径。 这一机制可显著提升多分支并发构建效率，降低构建时间波动，支撑频繁发布的 DevOps 流水线。 第七章：BuildKit 构建缓存高级应用实战 使用 --mount=type=cache,target=/root/.npm 缓存依赖 BuildKit 引入的 --mount=type=cache 机制允许为某些路径挂载持久缓存卷，实现跨次构建的缓存复用。常用于 Node、Python、Go 等语言的依赖缓存目录。 示例：Node 项目缓存 npm 目录 RUN --mount=type=cache,target=/root/.npm \ npm install dockerfile 1 2 等效于将 /root/.npm 映射为 BuildKit 的构建缓存卷，在多次构建中保留依赖下载记录，避免反复联网拉取，构建时间可减少 60% 以上。 其他常用挂载路径： Python: --mount=type=cache,target=/root/.cache/pip Go: --mount=type=cache,target=/go/pkg/mod Rust: --mount=type=cache,target=/usr/local/cargo/registry 注意：该机制只在启用 BuildKit 且使用 RUN --mount=... 时生效，传统构建器无法识别。 构建缓存目录映射与清理策略 尽管 type=cache 提供了高效复用路径，但其默认行为是自动持久化，可能造成磁盘占用持续增长。为此，BuildKit 支持以下控制参数： uid/gid：指定缓存挂载目录权限； sharing=locked：避免并发构建冲突； max-size：限制缓存占用体积； mode=max（导出缓存时）：强制保存所有中间层缓存。 示例： RUN --mount=type=cache,target=/root/.cache/pip,sharing=locked \ pip install -r requirements.txt dockerfile 1 2 清理方式： 使用 BuildKit 管理工具清理构建缓存； 手动清理 /var/lib/buildkit 下的缓存目录； 在 CI 任务后定期触发 buildctl prune 指令。 合理控制缓存保留策略是提升构建性能、控制资源占用的平衡关键。 基于内容地址的镜像复用设计 BuildKit 的缓存判定基于内容寻址模型（Content Addressable Storage），每个输入文件都会生成唯一哈希，用于判断变更与否。 在此基础上可实现跨项目复用策略设计： 将稳定依赖（如编译器、系统依赖）封装为内容稳定的构建基镜像； 将中间构建结果导出为镜像并带缓存元数据； 多个项目共享一组构建依赖镜像并复用缓存。 示例：构建环境镜像复用 FROM node:20 as deps COPY package*.json ./ RUN --mount=type=cache,target=/root/.npm npm ci dockerfile 1 2 3 将 deps 阶段构建结果缓存导出，再供后续项目构建时指定 --cache-from 实现跨项目缓存共享。 构建缓存导出与导入机制（--cache-to / --cache-from） BuildKit 支持将构建缓存导出至外部缓存源（如镜像仓库、文件系统、内嵌镜像），并在后续构建中导入使用，以达到流水线缓存跨任务共享效果。 导出缓存： docker buildx build \ --build-arg BUILDKIT_INLINE_CACHE=1 \ --cache-to=type=registry,ref=myrepo/app:buildcache,mode=max \ -t myrepo/app:latest . bash 1 2 3 4 导入缓存： docker buildx build \ --cache-from=type=registry,ref=myrepo/app:buildcache \ -t myrepo/app:latest . bash 1 2 3 其中： BUILDKIT_INLINE_CACHE=1 表示将缓存元信息嵌入镜像； mode=max 表示包含所有中间层缓存； registry 类型可适配多数主流云镜像仓库。 这种导出-导入机制适用于 GitHub Actions、GitLab CI 等跨节点构建环境，构建时间提升可达 3~5 倍。 第八章：从传统构建到 BuildKit 架构迁移的实战路线 企业项目中如何无痛切换至 BuildKit 构建体系 BuildKit 兼容标准 Dockerfile，但其高级能力需要构建命令显式启用或调整参数。迁移过程可拆分为以下步骤： 启用 BuildKit 构建引擎： export DOCKER_BUILDKIT=1 docker build . bash 1 2 升级构建 CLI 工具（推荐使用 docker buildx） docker buildx create --name mybuilder --use docker buildx inspect --bootstrap bash 1 2 逐步重构 Dockerfile： 拆分 COPY 和 RUN 指令； 引入 --mount=type=cache 缓存依赖； 通过 --output 输出构建产物而非 image； 使用多阶段构建隔离产物生成与镜像输出。 验证构建一致性与镜像体积对比； 将构建命令替换为 BuildKit 支持版本，并集成缓存导入导出流程。 迁移过程通常不需要重写 Dockerfile，只需启用参数和适当结构优化即可完成过渡。 BuildKit 与 CI 工具（如 GitHub Actions、GitLab CI、Jenkins）的整合实践 GitHub Actions 示例： - uses: docker/setup-buildx-action@v2 - name: Build with cache run: | docker buildx build \ --cache-from=type=gha \ --cache-to=type=gha,mode=max \ -t my-image . yaml 1 2 3 4 5 6 7 8 GitLab CI 示例： build: script: - docker buildx create --use - docker buildx build \ --cache-from=type=registry,ref=gitlab.myregistry/cache:latest \ --cache-to=type=registry,ref=gitlab.myregistry/cache:latest,mode=max \ -t my-image . yaml 1 2 3 4 5 6 7 Jenkins Pipeline 示例： 启用 BuildKit 构建容器； 使用 docker buildx 指令替换传统构建命令； 配合 buildctl CLI 实现缓存状态管理。 CI 环境中整合 BuildKit 的关键在于：提前准备好共享缓存的拉取和推送策略，减少重复构建步骤，提高流水线效率。 构建缓存稳定性对比分析与效果评估 特性 传统构建器 BuildKit 缓存粒度 镜像层级 文件级内容块 缓存复用率 低（指令依赖大） 高（跳过无关步骤） 并行执行 否 是 缓存跨任务共享 不支持 支持导入导出机制 缓存可控性 弱 强（mount、输出） CI 集成友好性 一般 极佳 企业项目真实案例中，将构建时间从平均 9 分钟缩减至 2 分钟，构建一致性问题大幅减少，缓存污染率下降超 70%。 未来构建架构演进趋势预判与优化建议 Docker 构建体系正从“层叠式构建+命令式控制”向“内容寻址+DAG驱动+声明式构建”转型。BuildKit、Buildpacks、Nix-based 系统构建、Bazel 等均强调： 可复现性（Reproducibility）； 可组合性（Composable）； 可观测性（Observable）； 构建缓存最大化。 未来构建链路建议重点优化方向： 使用 buildx bake 实现声明式构建配置； 将构建缓存与仓库、CDN 解耦，实现跨地域缓存复用； 接入 SBOM（软件物料清单）与安全分析流程； 引入构建分析指标，如缓存命中率、构建路径热度分析等。 以 BuildKit 为代表的新型构建体系，将成为容器构建在企业工程体系中的默认架构组件，越早迁移，越早收益。 ———————————————— 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-NC-SA 版权协议，转载请附上原文出处链接和本声明。 原文链接：https://blog.csdn.net/sinat_28461591/article/details/148482240
最新发布
09-29
### 构建优化实战方法 在 Dockerfile 构建中，可遵循以下设计原则来优化缓存结构： 1. **固定输入放前**：将依赖文件、配置模板、脚本等变更频率低的内容优先使用 `COPY` 指令复制到镜像中。例如： ```dockerfile ...
dockerfile编写
08-20
docker使用文档dockerfile的编写，使用dockerfile编写
【云原生 | Docker 高级篇】05、DockerFile 详解
GG Bond 的博客
10-10 744
DockerFile 详解！！！
Docker 之DockerFile
finalheart的博客
08-26 6173
本篇记录一下DockerFile怎么写。 1. 关于dockerFile Dockerfile 是一个文本文件，其内包含了一条条的指令(Instruction)，每一条指令构建一层，因此每一条指令的内容，就是描述该层应当如何构建。 因此不要写太多指令，可以将多个指令写在一条。 首先创建一个文件夹然后进入这个文件夹创建一个名字叫 Dockerfile 的文件。如下我创建一个dock......
编写 DockerFile
weixin_30919919的博客
11-24 185
编写 DockerFile 本节内容简介 在前面的实验中我们多次用到的 Dockerfile，在本实验里我们将通过完成一个实例来学习Dockerfile的编写。 本节中，我们需要依次完成下面几项任务： Dockerfile 基本框架 Dockerfile 编写常用命令 从 Dockerfile 构建镜像 本次实验的需求是完成一个Dockerfile，通过该Dockerf...
Docker之编写Dockerfile
dzh1125641239的博客
05-29 1593
编写DockFile实现安装httpd服务 1.开启docker服务，导入rhel镜像 [root@server1 ~]# systemctl start docker [root@server1 ~]# docker load -i rhel7.tar 2.编写Dockerfile [root@server1 ~]# mkdir /tmp/docker [root@server1 ~]# cd...
【Docker】如何编写Dockerfile，深入理解 Dockerfile：构建精简且高效的容器镜像
q742971636的博客
01-23 4567
CMD提供容器默认的执行命令，可以被运行容器时传入的命令覆盖。ENTRYPOINT配置容器启动时执行的默认可执行文件，可以被运行容器时传入的命令追加到其参数之后。综合来说，CMD通常用于提供应用的默认启动命令，而ENTRYPOINT通常用于配置容器以类似可执行程序的方式运行。你也可以同时使用它们，以ENTRYPOINT提供基础执行文件，而CMD提供默认参数。
评论 117
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

A-刘晨阳

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值