文章目录
1. 什么是Dockerfile2. Dockerfile的基本结构2.1 基础镜像（FROM）2.2 维护者信息（MAINTAINER 或 LABEL）2.3 工作目录（WORKDIR）2.4 复制文件（COPY或ADD）2.4.1 COPY指令2.4.2 ADD指令2.4.3 COPY指令和ADD指令的主要区别2.4.4 优先使用COPY指令还是ADD指令
2.5 运行命令（RUN）2.6 设置环境变量（ENV）2.7 暴露端口（EXPOSE）2.8 容器启动时默认执行的命令（CMD或ENTRYPOINT）2.8.1 CMD指令2.8.2 ENTRYPOINT指令2.8.3 CMD指令和ENTRYPOINT指令的主要区别2.8.4 docker run命令行指定参数时CMD指令和ENTRYPOINT指令的区别2.8.4.1 CMD2.8.4.2 ENTRYPOINT
3. 使用Dockerfile自定义镜像示例3.1 创建Python文件3.2 编写Dockerfile文件3.3 构建镜像3.4 启动容器
4. 主流编程语言和中间件的基础Docker镜像4.1 编程语言4.2 中间件4.3 带有slim后缀的镜像与没有slim后缀的镜像的区别
5. 编写Dockerfile的最佳实践5.1 选择合适的基础镜像5.1.1 使用官方镜像5.1.2 选择轻量级镜像
5.2 多阶段构建5.3 减少镜像层数5.4 优化镜像体积5.4.1 清理缓存5.4.2 合并指令
5.5 遵循单一职责原则5.6 使用标签和环境变量5.7 使用 .dockerignore文件
6. 构建镜像时可能遇到的问题6.1 问题呈现6.2 问题产生的原因6.3 解决方法
1. 什么是Dockerfile
简单来说，Dockerfile 就是用来自定义镜像的
Dockerfile 是一个用于定义和构建 Docker 镜像的文本文件。Dockerfile 中包含一系列指令和参数，用于描述镜像的构建过程，包括基础镜像的选择、软件包的安装、文件的复制、环境变量的设置等
2. Dockerfile的基本结构
2.1 基础镜像（FROM）
每个 Dockerfile 的第一条指令必须是 FROM，用于指定构建新镜像所基于的基础镜像。例如：
FROM ubuntu:22.04
2.2 维护者信息（MAINTAINER 或 LABEL）
指定镜像的维护者信息。 MAINTAINER 指令已被弃用，推荐使用 LABEL 指令。例如：
LABEL maintainer="yourname@example.com"
2.3 工作目录（WORKDIR）
进入容器内部时默认的目录就是工作目录
设置容器内的工作目录，后续的 COPY、RUN 等指令都会在这个目录下执行。例如：
WORKDIR /app
可以在 Dockerfile 中多次使用 WORKDIR 指令。每次使用都会更改当前的工作目录如果指定的目录不存在，WORKDIR 会自动创建该目录
2.4 复制文件（COPY或ADD）
如果想复制多个文件到镜像中，可以使用多个 COPY 指令
将本地文件或目录复制到镜像中。例如：
COPY ./ /app/
2.4.1 COPY指令
基本语法：
COPY
功能：仅用于将文件或目录从构建上下文复制到镜像中
特点：
简单直观：COPY 的行为非常明确，只执行复制操作不支持 URL：不能用于从远程 URL 下载文件不支持自动解压缩：不能自动解压缩压缩文件（如 .tar, .zip 等）
示例：
# 复制当前目录的所有文件到镜像的 /app 目录
COPY . /app/
# 复制单个文件到镜像的 /app 目录
COPY package.json /app/
2.4.2 ADD指令
基本语法：
ADD
功能：除了复制文件或目录外，还支持从远程 URL 下载文件以及自动解压缩压缩文件
特点：
支持 URL：可以从远程 URL 下载文件并复制到镜像中自动解压缩：如果源文件是压缩格式（如 .tar, .tar.gz, .zip 等），ADD 会自动解压缩文件行为复杂：由于支持多种功能，ADD 的行为可能不如 COPY 直观，容易引起混淆
示例：
# 从远程 URL 下载文件并复制到镜像中
ADD https://example.com/file.zip /app/
# 自动解压缩压缩文件
ADD file.tar.gz /app/
# 复制并自动解压缩
ADD source.tar.gz /app/
2.4.3 COPY指令和ADD指令的主要区别
功能COPYADD复制本地文件/目录✅✅从远程 URL 下载❌✅自动解压缩压缩文件❌✅行为明确性高中推荐使用场景简单的文件复制需要自动解压缩或从 URL 下载
2.4.4 优先使用COPY指令还是ADD指令
在编写Dockerfile时，推荐优先使用COPY而不是ADD，原因有几个：
明确性：COPY命令的功能非常明确，就是将文件从本地复制到Docker镜像中。而ADD命令除了复制文件外，还可以执行URL下载和解压操作，这可能会引入不必要的复杂性可预测性：ADD命令如果用于复制本地tar文件，会自动解压文件。这种行为可能会导致构建过程变得不那么可预测，尤其是当你不期望文件被解压时。而COPY命令总是按原样复制文件，不会进行任何额外的处理避免潜在问题：由于ADD可以处理URL，如果URL中包含特殊字符，可能会造成构建失败。此外，如果URL指向的文件是tar文件，它会被自动解压，这可能会导致不可预见的结果维护性：使用COPY可以使得Dockerfile更加清晰，对于其他开发者来说更容易理解。它减少了构建上下文的歧义，使得构建过程更易于维护最佳实践：许多Docker最佳实践指南推荐使用COPY，因为它遵循了最小惊讶原则（Principle of Least Astonishment），即系统行为应该尽可能符合用户的预期
因此，除非你需要从URL下载文件或者自动解压tar文件，否则应该优先使用COPY。这样可以使 Dockerfile 更加简洁、明确和可靠
2.5 运行命令（RUN）
在镜像构建过程中执行命令，用于安装软件包或配置环境。例如：
RUN apt-get update && apt-get install -y python3
2.6 设置环境变量（ENV）
定义环境变量，可以在后续的指令中使用。例如：
ENV NAME World
2.7 暴露端口（EXPOSE）
如果想放行多个端口，可以使用多个EXPOSE指令
声明容器运行时监听的端口。例如：
EXPOSE 80
2.8 容器启动时默认执行的命令（CMD或ENTRYPOINT）
指定容器启动时默认执行的命令。例如：
ENTRYPOINT ["python3", "app.py"]
2.8.1 CMD指令
在Dockerfile中，如果定义了多条CMD指令，只有最后一条会被使用。这是因为Docker在构建镜像时会忽略之前的CMD定义，仅保留最后一条CMD指令的主要作用是为容器启动提供默认命令，但如果用户通过docker run命令指定了其他命令，这些默认命令会被覆盖。因此，保留最后一条CMD可以确保容器启动时有明确的默认行为
基本语法：
CMD ["executable", "param1", "param2"] # 推荐的 exec 形式
CMD command param1 param2 # shell 形式
CMD ["param1", "param2"] # 作为 ENTRYPOINT 的默认参数
功能：提供容器启动时默认执行的命令和参数
如果在运行容器时使用了 docker run 命令并提供了参数，这些参数会覆盖 Dockerfile 中的 CMD 指令CMD 可以被 docker run 命令行中指定的命令完全替代
示例：
# 使用 exec 形式
CMD ["python", "app.py"]
# 使用 shell 形式
CMD python app.py
# 作为 ENTRYPOINT 的默认参数
ENTRYPOINT ["python"]
CMD ["app.py"]
2.8.2 ENTRYPOINT指令
在Dockerfile中，如果定义了多条ENTRYPOINT指令，只有最后一条ENTRYPOINT指令会生效
基本语法：
ENTRYPOINT ["executable", "param1", "param2"] # exec 形式
ENTRYPOINT command param1 param2 # shell 形式
功能：提供容器启动时执行的命令和参数，且这些参数不能被 docker run 命令行中指定的参数覆盖
ENTRYPOINT 指定的命令和参数是固定的，容器启动时总是会执行这些命令如果在 docker run 命令中提供了参数，这些参数会作为参数传递给 ENTRYPOINT 指定的命令，而不是替代它可以与 CMD 结合使用，CMD 提供默认的参数，ENTRYPOINT 提供固定的命令
示例：
# 使用 exec 形式
ENTRYPOINT ["python", "app.py"]
# 使用 shell 形式
ENTRYPOINT python app.py
# 结合 CMD 使用
ENTRYPOINT ["python"]
CMD ["app.py"]
2.8.3 CMD指令和ENTRYPOINT指令的主要区别
特性CMDENTRYPOINT覆盖方式可以被 docker run 命令行中指定的命令完全替代不能被 docker run 命令行中指定的命令替代， docker run 命令中的参数会传递给 ENTRYPOINT用途提供默认的命令和参数提供固定的命令，容器总是执行相同的命令灵活性高低组合使用可以与 ENTRYPOINT 结合使用，CMD 提供默认参数可以与 CMD 结合使用，CMD 提供默认参数推荐使用场景当你希望容器有默认的行为，但允许用户在运行时覆盖当你希望容器总是执行相同的命令，不希望被覆盖
将 ENTRYPOINT 和 CMD 结合使用，可以提供更灵活的配置：
ENTRYPOINT: 定义固定的命令CMD: 提供默认的参数，可以被 docker run 命令行中指定的参数覆盖
以下是将 ENTRYPOINT 和 CMD 结合使用的例子：
ENTRYPOINT：定义固定的命令CMD：提供默认的参数，可以被 docker run 命令行中指定的参数覆盖
ENTRYPOINT ["python"]
CMD ["app.py"]
运行容器时未提供参数：
docker run my-python-app
容器将执行 python app.py
运行容器时提供参数：
docker run my-python-app --help
容器将执行 python --help，覆盖了 CMD 提供的默认参数 app.py
2.8.4 docker run命令行指定参数时CMD指令和ENTRYPOINT指令的区别
2.8.4.1 CMD
FROM ubuntu:22.04
CMD ["echo", "Hello, World!"]
运行容器：
docker run my-ubuntu
输出：
Hello, World!
覆盖 CMD：
docker run my-ubuntu echo "Hello, Docker!"
输出：
Hello, Docker!
2.8.4.2 ENTRYPOINT
FROM ubuntu:22.04
ENTRYPOINT ["echo", "Hello, World!"]
运行容器:
docker run my-ubuntu
输出：
Hello, World!
尝试覆盖 ENTRYPOINT：
docker run my-ubuntu echo "Hello, Docker!"
输出：
Hello, World! echo Hello, Docker!
注意：ENTRYPOINT 的命令不会被覆盖，echo "Hello, Docker!" 会被当作参数传递给 echo "Hello, World!"指令
由于 echo 可以同时接收多个字符串参数，每个参数可以使用双引号包裹起来，也可以不用双引号包裹，所以 echo 和 “Hello, Docker” 分别作为两个参数传递给了 echo "Hello, World!" 指令
echo "Hello, World!" echo "Hello, Docker!"
3. 使用Dockerfile自定义镜像示例
我们来做一个案例：使用 Dockerfile 构建基于 ubuntu 22.04 的镜像，安装 Python3 并输出 “Hello, world”
3.1 创建Python文件
echo "print(\"Hello, world\")" > hello.py
3.2 编写Dockerfile文件
# 使用 ubuntu 22.04 作为基础镜像
FROM ubuntu:22.04
# 设置环境变量，防止交互式提示
ENV DEBIAN_FRONTEND=noninteractive
# 更新系统包列表
RUN apt-get update && apt-get install -y --no-install-recommends \
python3 \
python3-pip \
&& rm -rf /var/lib/apt/lists/*
# 设置工作目录
WORKDIR /app
# 使用 COPY 指令复制本地 Python 脚本到容器的工作目录
COPY hello.py /app/
# 设置容器启动命令，运行 Python 脚本
CMD ["python3", "hello.py"]
在 Dockerfile 中设置环境变量 DEBIAN_FRONTEND=noninteractive 的目的是为了防止在安装软件包时出现交互式提示。这通常发生在运行 apt-get 或 apt 命令时，尤其是在需要确认操作或配置选项的情况下
以下是具体的原因：
自动化构建过程：在自动化构建Docker镜像的过程中，交互式提示会中断构建流程，因为Docker无法响应这些提示。设置 DEBIAN_FRONTEND=noninteractive 可以确保安装过程完全自动化，无需人工干预非交互式环境：Docker容器通常在后台运行，没有用户界面。因此，即使有交互式提示，用户也无法与之交互。设置该环境变量可以避免因等待用户输入而导致安装过程挂起保持构建的一致性：交互式提示可能会导致不同的构建结果，取决于是否有用户在场进行响应。通过消除这些提示，可以确保每次构建都产生相同的结果提高构建速度：交互式提示需要等待用户输入，这会减慢构建过程。通过设置为非交互模式，可以加快构建速度
3.3 构建镜像
构建容器时 Docker 默认会将 Dockerfile 所在的目录以及 Dockerfile 所在目录的子目录作为构建上下文如果构建容器时使用啦或访问了构建上下文以外的目录或文件，Docker 将无法访问到这些文件
sudo docker build --tag ubuntu-python:1.0.0 ./
构建完成后，使用 docker images 命令来查看新创建的镜像：
sudo docker images
3.4 启动容器
使用 --rm 选项，Docker 将在容器退出时自动删除它，这样就不会留下任何容器实例。这对于一次性任务或者测试运行非常有用，因为它们不需要持久化容器状态如果容器在运行期间创建了任何需要保留的数据，确保你已经将这些数据导出到容器外部，因为一旦容器被删除，其中的所有数据都会丢失
sudo docker run --rm ubuntu-python:1.0.0
4. 主流编程语言和中间件的基础Docker镜像
主流编程语言和中间件的官方通常都会提供对应的基础 Docker 镜像，这些镜像为开发者提供了构建应用程序的环境
4.1 编程语言
Python
python:3.9-slim：Python 3.9 的 slim 版本基础镜像python:3.9-alpine：Python 3.9 基于 Alpine 的轻量级基础镜像 Java
openjdk:17-slim：OpenJDK 17 的 slim 版本基础镜像openjdk:17-jdk-alpine：OpenJDK 17 基于 Alpine 的基础镜像 Node.js
node:14-slim：Node.js 14 的 slim 版本基础镜像node:14-alpine：Node.js 14 基于 Alpine 的基础镜像 Go
golang:1.16：Go 1.16 的基础镜像golang:1.16-alpine：Go 1.16 基于 Alpine 的基础镜像 Ruby
ruby:2.7-slim：Ruby 2.7 的 slim 版本基础镜像ruby:2.7-alpine：Ruby 2.7 基于 Alpine 的基础镜像 PHP
php:7.4-fpm-slim：PHP 7.4 的 FPM slim 版本基础镜像php:7.4-fpm-alpine：PHP 7.4 的 FPM 基于 Alpine 的基础镜像
4.2 中间件
Apache
httpd:2.4-alpine：Apache HTTP Server 2.4 基于 Alpine 的基础镜像 Nginx
nginx:latest：最新版本的 Nginx 基础镜像nginx:alpine：Nginx 基于 Alpine 的基础镜像 MySQL
mysql:8.0：MySQL 8.0 的基础镜像mysql:5.7：MySQL 5.7 的基础镜像 PostgreSQL
postgres:13：PostgreSQL 13 的基础镜像postgres:alpine：PostgreSQL 基于 Alpine 的基础镜像 MongoDB
mongo:4.4：MongoDB 4.4 的基础镜像mongo:4.4-xenial：MongoDB 4.4 基于 Ubuntu Xenial 的基础镜像 Redis
redis:6.0：Redis 6.0 的基础镜像redis:6.0-alpine：Redis 6.0 基于 Alpine 的基础镜像
4.3 带有slim后缀的镜像与没有slim后缀的镜像的区别
带有slim 后缀的 Docker 镜像与没有 slim 后缀的镜像的主要区别在于它们的体积和包含的工具集：
体积更小：slim 镜像通常体积更小，因为它们移除了许多非必需的包和工具，只保留了运行特定应用程序所必需的部分。这有助于减少存储需求和加快镜像的下载速度工具集有限：由于 slim 镜像移除了许多非必需的工具，所以在这些镜像中可能没有一些常用的命令行工具，如 vim, curl, wget 等
如果你的应用程序不需要这些被移除的工具，那么使用 slim 镜像通常不会影响你的应用程序的正常运行。实际上，使用 slim 镜像可能会让你的应用程序部署更快，因为镜像体积更小
5. 编写Dockerfile的最佳实践
5.1 选择合适的基础镜像
5.1.1 使用官方镜像
优先选择官方维护的基础镜像，如 python, node, openjdk 等。这些镜像经过严格测试和安全审查
FROM node:18-alpine
5.1.2 选择轻量级镜像
使用 slim 或 alpine 版本可以显著减小镜像体积。例如，python:3.11-slim 或 node:18-alpine
5.2 多阶段构建
多阶段构建中的去除过程是由Docker自身完成的当定义一个多阶段构建的Dockerfile时，Docker会按照Dockerfile中的指令顺序执行构建过程，并且只保留最后一个FROM指令所定义的镜像
使用多阶段构建可以将构建工具和依赖留在中间阶段，而最终镜像只包含运行时所需的文件
这样做可以显著减小镜像的体积，因为不需要在最终镜像中包含构建工具和依赖，这些通常占用了大量的空间
此外，由于最终镜像中只包含运行时所需的文件，这也提高了安全性，因为攻击者无法利用构建工具和依赖进行攻击
# 使用Maven 3.8.6和OpenJDK 17的基础镜像作为构建环境
FROM maven:3.8.6-openjdk-17 AS builder
# 设置工作目录为 /app
WORKDIR /app
# 将 pom.xml 文件从构建上下文复制到 /app 目录下
COPY pom.xml ./
# 执行 Maven 命令 dependency:go-offline，下载所有依赖并将它们缓存起来，以便在没有网络的情况下也可以进行构建
RUN mvn dependency:go-offline
# 将构建上下文中的所有文件（除了已经复制的 pom.xml）复制到 /app 目录下
COPY ./ ./
# 执行 Maven 命令 package -DskipTests，打包应用，同时跳过测试
RUN mvn package -DskipTests
# 使用 OpenJDK 17 的精简版镜像作为运行环境的基础镜像
FROM openjdk:17-jdk-slim
# 从第一阶段（名为 builder）的 /app/target/myapp.jar 复制到当前镜像的 /usr/local/bin/myapp.jar
COPY --from=builder /app/target/myapp.jar /usr/local/bin/myapp.jar
# 设置容器启动时执行的命令。这里，容器启动时会运行 JAR 文件，作为应用程序的入口点
CMD ["java", "-jar", "/usr/local/bin/myapp.jar"]
5.3 减少镜像层数
合并相关的 RUN, COPY, ADD 指令，使用 && 将多个命令串联起来，以减少镜像层数
RUN apt-get update && apt-get install -y \
curl \
vim \
&& rm -rf /var/lib/apt/lists/*
5.4 优化镜像体积
5.4.1 清理缓存
在安装软件包后，清理包管理器缓存。例如，在 Debian/Ubuntu 系统中，使用 apt-get clean 和 rm -rf /var/lib/apt/lists/* 清理缓存
RUN apt-get update && apt-get install -y \
curl \
vim \
&& apt-get clean && rm -rf /var/lib/apt/lists/*
5.4.2 合并指令
在Dockerfile中，每个RUN指令都会在镜像中创建一个新的层当构建镜像时，Docker会为每个RUN指令执行的操作创建一个临时的容器，并在该容器中执行指令执行完成后，Docker会将容器的文件系统保存为一个层，并将其添加到镜像中
将多个 RUN 指令合并为一个，减少镜像层数
RUN apt-get update && apt-get install -y \
curl \
vim \
&& apt-get clean && rm -rf /var/lib/apt/lists/*
5.5 遵循单一职责原则
一个容器只运行一个进程，避免将多个服务打包在一个容器中
5.6 使用标签和环境变量
ENV：设置环境变量，避免硬编码敏感信息LABEL：为镜像添加元数据，如维护者信息、用途等
5.7 使用 .dockerignore文件
创建一个 .dockerignore 文件，排除不必要的文件和目录：
创建文件：在的 Dockerfile 所在的目录下创建一个名为 .dockerignore 的文件编写规则：在 .dockerignore 文件中，每一行包含一个需要排除的文件或目录的路径
node_modules
*.log
6. 构建镜像时可能遇到的问题
6.1 问题呈现
在使用 docker build 指令构建镜像时，可能会遇到以下警告信息
DEPRECATED: The legacy builder is deprecated and will be removed in a future release. Install the buildx component to build images with BuildKit: https://docs.docker.com/go/buildx/
6.2 问题产生的原因
这个警告信息表明 Docker 正在使用传统的构建器（legacy builder），而传统的构建起将在未来的版本中被弃用
Docker 推荐使用 BuildKit，这是一个更现代、更高效的构建系统，用于构建 Docker 镜像
6.3 解决方法
参考我的另一篇博文：使用docker build命令构建镜像时遇到警告信息 The legacy builder is deprecated and will be removed in a future release