Dockerfile 详解
一、什么是 Dockerfile
Dockerfile 就是用来自定义镜像的
Dockerfile 是一个用于定义和构建 Docker 镜像 的文本文件。Dockerfile 中包含一系列指令和参数，用于描述镜像的构建过程，包括基础镜像的选择、软件包的安装、文件的复制、环境变量的设置等。
二、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 <src> <dest>
功能：仅用于将文件或目录从构建上下文复制到镜像中
特点：
- 简单直观：COPY 的行为非常明确，只执行复制操作
- 不支持 URL：不能用于从远程 URL 下载文件
- 不支持自动解压缩：不能自动解压缩文件（如 .tar .zip等）
示例：
# 复制当前目录的所有文件到镜像的 /app 目录
COPY . /app/# 复制单个文件到镜像的 /app 目录
COPY package.json /app/
2.4.2 ADD 指令
基本语法：
ADD <src> <dest>
功能：除了复制文件或目录外，还支持从远程 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指令的主要区别
| 功能 | COPY | ADD |
|---|---|---|
| 复制本地文件/目录 | ✅ | ✅ |
| 从远程 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指令的主要区别
| 特性 | CMD | ENTRYPOINT |
|---|---|---|
| 覆盖方式 | 可以被 docker run 命令行中指定的命令完全替代 | 不能被 docker run 命令行中指定的命令替代， docker run 命令中的参数会传递给 ENTRYPOINT |
| 用途 | 提供默认的命令和参数 | 提供固定的命令，容器总是执行相同的命令 |
| 灵活性 | 高 | 低 |
| 组合使用 | 可以与 ENTRYPOINT 结合使用，CMD 提供默认参数 | 可以与 CMD 结合使用，CMD 提供默认参数 |
| 推荐使用场景 | 当你希望容器有默认的行为，但允许用户在运行时覆盖 | 当你希望容器总是执行相同的命令，不希望被覆盖 |
将 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.04CMD ["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.04ENTRYPOINT ["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!"
三、使用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
四、主流编程语言和中间件的基础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 的基础镜像
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 镜像可能会让你的应用程序部署更快，因为镜像体积更小
五、编写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