Docker Build 命令详解：从入门到实战

在现代软件开发和部署流程中，Docker 已经成为不可或缺的工具。它通过容器化技术，极大地简化了应用的打包、分发和运行。而构建 Docker 镜像，是将你的应用及其所有依赖打包成可移植单元的第一步，也是最核心的一步。docker build 命令正是负责执行这一关键任务的工具。

本文将带您深入了解 docker build 命令，从基础概念到高级用法，再结合实战示例，助您彻底掌握 Docker 镜像的构建过程。

1. Docker 镜像与 Dockerfile 基础概念

在深入 docker build 命令之前，我们先来理解几个核心概念：

Docker 镜像 (Image): Docker 镜像是一个轻量级、独立、可执行的软件包，包含运行一个特定应用所需的一切：代码、运行时环境、库、环境变量和配置文件等。镜像可以看作是一个只读的模板。
容器 (Container): 容器是 Docker 镜像的一个运行实例。一个镜像可以创建多个容器。容器是可读写的，它们在镜像层之上添加了一个薄的读写层。
Dockerfile: Dockerfile 是一个文本文件，其中包含了一系列指令，这些指令描述了如何一步步构建一个 Docker 镜像。docker build 命令读取 Dockerfile 中的指令并执行，从而自动化地创建镜像。

简单来说，Dockerfile 是构建镜像的“菜谱”，docker build 命令就是根据这个“菜谱”来“烹饪”镜像。

2. `docker build` 命令入门

docker build 命令的基本语法如下：

bash docker build [OPTIONS] PATH | URL | -

这个命令有三个主要部分：

docker build: 命令本身。
[OPTIONS]: 可选参数，用于控制构建过程，比如指定标签、使用缓存、构建参数等。
PATH | URL | -: 构建上下文 (Build Context)。这是构建命令的必需参数，它指定了 Dockerfile 所在的目录（路径）、一个 Git 仓库的 URL 或一个 Tarball 的 URL。或者使用 - 从标准输入读取 Dockerfile。

2.1 构建上下文 (Build Context)

理解构建上下文是使用 docker build 的关键。构建上下文是指本地文件系统中的一个目录（通常是当前目录 .），或者一个可以通过 URL 访问到的资源。在构建过程中，Docker Daemon（Docker守护进程）会将整个构建上下文的内容发送给它。Dockerfile 中的 COPY 和 ADD 等指令就是从这个上下文中复制文件到镜像中。

重要提示: 将整个构建上下文发送给 Docker Daemon 可能包含大量不需要的文件，这会减慢构建速度并占用不必要的资源。因此，建议将构建上下文设置为仅包含Dockerfile和构建所需文件的最小目录。使用 .dockerignore 文件可以进一步排除不需要的文件（类似于 Git 的 .gitignore）。

示例:

假设你的项目结构如下：

my-app/ ├── Dockerfile ├── app.py ├── requirements.txt └── static/ └── index.html

你在 my-app 目录下执行构建命令：

bash docker build .

这里的 . 就代表当前目录 my-app 作为构建上下文。Docker Daemon 会将 my-app 目录下的所有文件（除了 .dockerignore 中指定的）都发送过去。Dockerfile 中的 COPY app.py /app/ 才能找到并复制 app.py 文件。

2.2 第一个 Dockerfile 和构建命令

让我们创建一个最简单的 Dockerfile 来构建一个基于 Alpine Linux 的镜像：

“`dockerfile

Dockerfile

FROM alpine:latest
RUN echo “Hello, Docker Build!”
“`

将上面的内容保存为名为 Dockerfile 的文件，放在一个空目录中。然后在这个目录下打开终端，执行构建命令：

bash docker build .

执行后，你会看到类似以下的输出：

Sending build context to Docker daemon 2.048kB Step 1/2 : FROM alpine:latest ---> a24bb4013296 Step 2/2 : RUN echo "Hello, Docker Build!" ---> Running in a0a1c2d3e4f5 Removing intermediate container a0a1c2d3e4f5 ---> b1c2d3e4f5a6 Successfully built b1c2d3e4f5a6

Sending build context...: Docker Daemon 正在接收构建上下文。
Step 1/2 : FROM alpine:latest: 执行 Dockerfile 中的第一条指令 FROM。它从 Docker Hub 下载 alpine:latest 镜像（如果本地没有的话）。
---> a24bb4013296: 这一步构建完成，生成了一个中间镜像层，ID 是 a24bb4013296。
Step 2/2 : RUN echo "Hello, Docker Build!": 在上一步生成的镜像层之上，执行 RUN 指令。Running in ... 显示了 Docker 为执行 RUN 命令创建了一个临时容器。
Removing intermediate container ...: RUN 命令执行完成后，临时容器被删除。
---> b1c2d3e4f5a6: 这一步也构建完成，生成了新的镜像层，ID 是 b1c2d3e4f5a6。这个 ID 就是最终构建好的镜像的 ID。
Successfully built b1c2d3e4f5a6: 构建成功，并显示了最终镜像的 ID。

此时，你可以使用 docker images 命令查看本地镜像列表，会看到刚刚构建的镜像（它没有仓库名和标签，只有 Image ID）。

2.3 给镜像打标签 (`-t`)

直接使用 Image ID 来引用镜像很不方便。通常我们会给镜像打上一个人类可读的标签。使用 -t 或 --tag 选项可以实现这一点。标签的格式通常是 [仓库名/][镜像名][:标签]，其中仓库名和标签都是可选的。

bash docker build -t my-alpine-app:v1.0 .

现在，再次运行 docker images，你会看到一个名为 my-alpine-app、标签为 v1.0 的镜像。

你也可以在一次构建中打多个标签：

bash docker build -t my-alpine-app:v1.0 -t my-alpine-app:latest .

这样，同一个镜像会同时拥有 v1.0 和 latest 两个标签。

3. 深入 Dockerfile 指令

Dockerfile 是构建镜像的核心，理解并正确使用 Dockerfile 中的各种指令至关重要。以下是一些最常用和重要的指令：

FROM <image> [AS <name>]:
- 用途: 指定构建过程所基于的父镜像（Base Image）。Dockerfile 中的第一条非注释指令必须是 FROM。
- 说明: 父镜像可以是任何有效的 Docker 镜像，通常从 Docker Hub 获取。AS <name> 用于给当前阶段命名，这在多阶段构建中非常有用。
- 示例:
  dockerfile FROM ubuntu:20.04 FROM python:3.9-slim AS builder
RUN <command>:
- 用途: 在当前镜像层之上执行任何命令，并在执行后提交结果生成新的镜像层。常用于安装软件包、创建目录、编译应用等。
- 语法:
  - Shell 形式: RUN command param1 param2 （命令在 /bin/sh -c 或等效的 shell 中运行）
  - Exec 形式: RUN ["executable", "param1", "param2"] （直接执行可执行文件）
- 最佳实践: 为了减少镜像层数和镜像大小，尽量将多个 RUN 命令合并成一个，并使用 && 连接，同时注意清理不需要的临时文件（如包管理器的缓存）。
- 示例:
  dockerfile RUN apt-get update && apt-get install -y some-package && rm -rf /var/lib/apt/lists/* RUN ["/bin/bash", "-c", "echo hello"]
COPY <src>... <dest> / COPY ["<src>",... "<dest>"]:
- 用途: 从构建上下文目录中复制文件或目录到镜像的文件系统中指定路径。
- 说明: src 是构建上下文中的路径，dest 是镜像中的绝对路径或相对于 WORKDIR 的路径。如果 dest 不存在，会自动创建。
- 与 ADD 的区别: COPY 仅支持本地文件复制；ADD 除了复制本地文件，还支持解压 Tarball 和从 URL 下载文件。通常推荐使用 COPY，因为它更明确，不易产生意外行为。
- 示例:
  dockerfile COPY app.py /app/ COPY ./src /app/src COPY requirements.txt . # 复制到当前 WORKDIR
ADD <src>... <dest> / ADD ["<src>",... "<dest>"]:
- 用途: 功能类似于 COPY，但额外支持以下功能：
  - src 可以是一个 URL。
  - 如果 src 是一个本地的 Tar 压缩文件，Docker 会自动将其解压到 dest。
- 最佳实践: 尽量使用 COPY，只有在需要自动解压本地 Tar 文件或从 URL 下载时才考虑使用 ADD。
- 示例:
  dockerfile ADD https://example.com/somefile.tar.gz /tmp/ # 下载并自动解压 ADD myarchive.tar.gz /app/ # 解压本地 Tar 到 /app
WORKDIR /path/to/workdir:
- 用途: 设置后续 RUN, CMD, ENTRYPOINT, COPY, ADD 等指令执行时的当前工作目录。如果目录不存在，会自动创建。
- 说明: 建议在 Dockerfile 中明确设置工作目录，而不是依赖默认值。可以使用多个 WORKDIR 指令，后续指令会在前一个 WORKDIR 设置的基础上进行相对路径操作。
- 示例:
  dockerfile WORKDIR /app COPY . . # 复制构建上下文内容到 /app RUN echo "Current dir: $(pwd)" # 会输出 /app
CMD <command> / CMD ["executable","param1","param2"] / CMD ["param1","param2"] (作为 ENTRYPOINT 的参数):
- 用途: 设置容器启动时默认执行的命令。一个 Dockerfile 只能有一个 CMD，如果有多个，只有最后一个生效。
- 语法:
  - Shell 形式: CMD command param1 param2 （在 shell 中运行，适用于执行带有变量或需要 shell 特性的命令）
  - Exec 形式: CMD ["executable", "param1", "param2"] （首选，直接执行可执行文件）
  - Default Parameters 形式: CMD ["param1", "param2"] （用于为 ENTRYPOINT 指令提供默认参数）
- 与 ENTRYPOINT 的区别: CMD 可以在 docker run 命令中被覆盖（docker run <image> <new_command>）；ENTRYPOINT 通常不易被覆盖，它的作用是使容器像一个可执行程序一样运行。如果同时定义了 ENTRYPOINT 和 CMD，CMD 的内容会作为参数传递给 ENTRYPOINT。
- 示例:
  dockerfile CMD ["python", "app.py"] # Exec 形式，推荐 CMD python app.py # Shell 形式 CMD ["--help"] # 作为 ENTRYPOINT ["my-app"] 的默认参数
ENTRYPOINT <command> / ENTRYPOINT ["executable", "param1", "param2"]:
- 用途: 配置一个作为容器主命令执行的命令。与 CMD 类似，但通常用作容器的可执行入口。一个 Dockerfile 只能有一个 ENTRYPOINT。
- 语法: 同 CMD。
- 用途: 常用于创建一个可执行的容器。当与 CMD 结合使用时，CMD 提供默认参数，docker run 命令行提供的参数会覆盖 CMD 的默认参数，然后这些参数一起传递给 ENTRYPOINT。
- 示例:
  dockerfile ENTRYPOINT ["/app/run.sh"] # 如果 CMD 为 ["--help"]，运行容器时默认执行 /app/run.sh --help # 如果运行 docker run my-image --version，则执行 /app/run.sh --version
ENV <key>=<value> ...:
- 用途: 设置环境变量。这些环境变量在构建过程中（在 RUN 指令中可以使用）和容器运行时都有效。
- 说明: 可以一次设置多个环境变量。
- 示例:
  dockerfile ENV APP_HOME=/app ENV PATH=$APP_HOME/bin:$PATH VERSION=1.0
EXPOSE <port> [<port>/<protocol>...]:
- 用途: 声明容器运行时监听的端口。这仅是一个文档说明，告诉用户容器暴露了哪些端口。要实际映射端口，需要在 docker run 命令中使用 -p 选项。
- 示例:
  dockerfile EXPOSE 80 EXPOSE 8000/tcp 5432/udp
VOLUME <mountpoint> / VOLUME ["<mountpoint>", ...]:
- 用途: 创建一个挂载点，可以将主机目录或其它容器的数据卷挂载到容器中。这用于持久化数据或共享数据。
- 说明: 仅声明容器内部的挂载点，实际的卷创建或绑定挂载需要在 docker run 命令中使用 -v 或 --mount 选项。
- 示例:
  dockerfile VOLUME /data VOLUME ["/app/logs", "/app/config"]
USER <user>[:<group>]:
- 用途: 设置后续 RUN, CMD, ENTRYPOINT 指令执行时的用户和用户组。默认是 root。
- 最佳实践: 为了安全起见，除非必要，否则不要使用 root 用户运行容器内的进程。可以创建一个非特权用户并在 USER 指令中指定。
- 示例:
  dockerfile RUN groupadd -r myuser && useradd -r -g myuser myuser USER myuser CMD ["/app/run_as_user.sh"]
ARG <name>[=<default value>]:
- 用途: 定义一个构建参数 (Build Argument)，可以在 docker build 命令中使用 --build-arg <name>=<value> 选项来传递值。这些值在构建过程中可用（例如在 RUN 指令中），但在容器运行时不可用（除非使用 ENV 指令将 ARG 的值显式设置为环境变量）。
- 与 ENV 的区别: ARG 仅在构建时有效，ENV 在构建时和运行时都有效。
- 示例:
  dockerfile ARG VERSION=latest ARG BUILD_DATE ENV APP_VERSION=$VERSION # 将构建参数转换为环境变量 RUN echo "Building version $VERSION built on $BUILD_DATE"
- 构建命令: docker build --build-arg VERSION=v1.1 --build-arg BUILD_DATE=$(date +%F) -t my-app .
LABEL <key>="<value>" [<key>="<value>" ...]:
- 用途: 为镜像添加元数据（metadata）。可以用于组织镜像、过滤镜像、提供信息等。
- 示例:
  dockerfile LABEL maintainer="Your Name <[email protected]>" LABEL version="1.0" LABEL description="This is a sample web application image."
HEALTHCHECK [OPTIONS] CMD command / HEALTHCHECK NONE:
- 用途: 配置容器的健康检查。Docker 可以定期执行一个命令来检查容器是否健康运行。
- 选项: --interval, --timeout, --start-period, --retries。
- 示例:
  dockerfile HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1
SHELL ["executable", "parameters"]:
- 用途: 覆盖用于 RUN, CMD, ENTRYPOINT 的 shell 形式指令的默认 shell。默认是 ["/bin/sh", "-c"] (Linux) 或 ["cmd", "/S", "/C"] (Windows)。
- 示例:
  dockerfile SHELL ["/bin/bash", "-c"] RUN echo "Hello, world!" # 会在 /bin/bash -c "echo \"Hello, world!\"" 中运行
STOPSIGNAL signal:
- 用途: 设置发送给容器以退出的系统调用信号。默认为 SIGTERM。
- 示例:
  dockerfile STOPSIGNAL SIGKILL
ONBUILD <instruction>:
- 用途: 定义一个触发器指令。当当前镜像被用作另一个镜像的 FROM 父镜像时，ONBUILD 后面的指令将在子镜像构建时执行。
- 示例:
  dockerfile ONBUILD COPY . /app/src ONBUILD RUN echo "This runs in the derived image"
  当另一个 Dockerfile FROM your-image-with-onbuild 时，COPY . /app/src 和 RUN echo ... 会在子镜像构建的第一步执行。

4. Docker Build 的高级特性与最佳实践

4.1 利用构建缓存

Docker Build 具有强大的构建缓存机制。Docker Daemon 会将每个成功执行的 Dockerfile 指令的结果作为一个镜像层缓存起来。下次构建时，如果遇到完全相同的指令，并且该指令所依赖的文件（对于 COPY/ADD）没有变化，Docker 会直接使用缓存的镜像层，而不是重新执行该指令。这极大地加速了构建过程。

缓存失效规则:

FROM 指令：如果父镜像发生变化（例如 alpine:latest 更新了），缓存就会失效。
RUN 指令：如果指令字符串完全一样，则命中缓存。
COPY / ADD 指令：Docker 会检查源文件和目标文件的内容（校验和）和元数据（修改时间等）。如果源文件或目标文件发生变化，缓存就会失效。
指令顺序：如果 Dockerfile 中的指令顺序发生变化，缓存也会失效。一旦某个指令没有命中缓存，其后的所有指令的缓存都会失效，需要重新执行。

利用缓存的技巧:

将 Dockerfile 中不经常变化的指令放在前面（如 FROM, RUN apt-get update）。
将经常变化的指令放在后面（如 COPY app.py）。
对于 Node.js, Python 等项目，先复制依赖文件 (package.json, requirements.txt)，然后安装依赖，最后复制应用代码。这样，如果只有应用代码变动而依赖不变，安装依赖的步骤可以利用缓存：

“`dockerfile

Example: Python app

FROM python:3.9-slim
WORKDIR /app
COPY requirements.txt . # Step 1: Copy dependency file
RUN pip install -r requirements.txt # Step 2: Install dependencies (cache friendly if requirements.txt doesn’t change)
COPY . . # Step 3: Copy application code (this step invalidates cache if code changes)
CMD [“python”, “app.py”]
“`

强制禁用缓存:

使用 --no-cache 选项可以完全禁用构建缓存，强制重新执行所有指令：

bash docker build --no-cache -t my-app:latest .
这在排除构建问题时可能有用，但会显著增加构建时间。

4.2 `.dockerignore` 文件

为了优化构建上下文，减少发送到 Docker Daemon 的文件数量，可以使用 .dockerignore 文件。该文件的语法类似于 .gitignore，用于指定在构建上下文中要忽略的文件和目录。

示例 .dockerignore 文件:

.git .gitignore node_modules/ tmp/ *.log

这样，在构建时，Docker Daemon 不会将 .git 目录、node_modules 目录等发送到构建上下文。

4.3 多阶段构建 (Multi-stage Builds)

多阶段构建是构建高效、小型镜像的强大技术。它允许你在一个 Dockerfile 中使用多个 FROM 指令，每个 FROM 指令定义一个独立的构建阶段。你可以在前一个阶段编译、测试或构建应用，然后只将最终生成的、可执行的 artifact 复制到下一个（通常是最终的）轻量级运行时镜像中。中间阶段及其包含的所有构建依赖（编译器、SDK、临时文件等）都不会包含在最终镜像中，从而大大减小镜像体积和攻击面。

语法:

使用 FROM <image> AS <stage-name> 给阶段命名。然后使用 COPY --from=<stage-name> 或 COPY --from=<stage-index> 从前一个阶段复制文件。

示例 (Go 应用):

“`dockerfile

Stage 1: Builder

FROM golang:1.18 AS builder

WORKDIR /app

COPY go.mod go.sum ./
RUN go mod download

COPY *.go .
RUN go build -o /app/my-app

Stage 2: Runner

FROM alpine:latest

WORKDIR /app

COPY –from=builder /app/my-app . # Copy the built binary from the builder stage

CMD [“./my-app”]
“`

在这个例子中，第一阶段 (builder) 包含了 Go SDK 和所有构建依赖。第二阶段 (alpine) 是一个非常小的基础镜像。最终的镜像只包含从 builder 阶段复制过来的编译好的 my-app 可执行文件，而不包含 Go SDK 和源码，体积会非常小。

使用 docker build . 构建时，Docker 会执行所有阶段，但最终只生成最后一个阶段的镜像。你也可以使用 --target <stage-name> 选项来构建到指定阶段，这在调试构建过程时很有用。

bash docker build --target builder -t my-app-builder . # 只构建 builder 阶段

4.4 BuildKit (下一代构建引擎)

BuildKit 是 Docker 提供的一个更现代、更强大、更安全的镜像构建引擎。它带来了许多改进，包括：

并行构建: 可以并行执行 Dockerfile 中的独立指令，显著提升构建速度。
跳过未使用的阶段: 对于多阶段构建，如果未使用 --target 指定，BuildKit 会自动跳过最终镜像不需要的阶段，进一步加快构建。
新的构建特性: 支持 Secrets（安全地将敏感信息传递给构建过程）、SSH mounts（在构建过程中通过 SSH 访问私有仓库）、Cache mounts（在不同构建之间共享缓存目录）等。
更好的缓存管理。
更详细的构建输出。

启用 BuildKit:

环境变量: 在执行 docker build 命令前设置 DOCKER_BUILDKIT=1。
bash DOCKER_BUILDKIT=1 docker build -t my-app .
Daemon 配置: 在 /etc/docker/daemon.json 中添加 "features": {"buildkit": true} 并重启 Docker Daemon（生产环境推荐）。

示例: 使用 BuildKit Secrets (假设有一个 secret 文件 my-token):

“`dockerfile

syntax=docker/dockerfile:1.2 # Specify BuildKit frontend

FROM alpine:latest
RUN –mount=type=secret,id=mysecret cat /run/secrets/mysecret
“`

构建命令 (假设你的 secret 文件在 /path/to/my-token):

bash DOCKER_BUILDKIT=1 docker build --secret id=mysecret,src=/path/to/my-token -t secret-builder .
这样，my-token 文件的内容就会安全地传递到构建过程中的 /run/secrets/mysecret，不会残留在镜像层中。

4.5 使用构建参数 `--build-arg`

前面提到 ARG 指令定义构建参数。使用 --build-arg <name>=<value> 选项可以在构建时为这些参数赋值。这使得构建过程更加灵活，可以根据需要构建不同版本或配置的镜像。

示例:

Dockerfile:
dockerfile FROM ubuntu:latest ARG VERSION=1.0 RUN echo "Building version: $VERSION" ENV APP_VERSION=$VERSION

构建命令:
bash docker build --build-arg VERSION=2.5 -t my-app:2.5 . docker build -t my-app:latest . # 使用默认值 1.0

5. `docker build` 实战示例

5.1 构建一个简单的 Node.js Web 应用

假设你的 Node.js 应用结构如下：

nodejs-app/ ├── Dockerfile ├── package.json ├── package-lock.json └── server.js

package.json:
json { "name": "simple-node-app", "version": "1.0.0", "description": "A simple Node.js web app", "main": "server.js", "scripts": { "start": "node server.js" }, "dependencies": { "express": "^4.17.1" } }

server.js:
“`javascript
const express = require(‘express’);
const app = express();
const port = 3000;

app.get(‘/’, (req, res) => {
res.send(‘Hello from Dockerized Node.js App!’);
});

app.listen(port, () => {
console.log(App listening at http://localhost:${port});
});
“`

Dockerfile (nodejs-app/Dockerfile):
“`dockerfile

Use a multi-stage build for smaller image size

Stage 1: Builder – Install dependencies

FROM node:18-alpine AS builder

WORKDIR /app

Copy package.json and package-lock.json first to leverage cache

COPY package*.json ./

Install dependencies

RUN npm ci

Copy the rest of the application code

COPY . .

Stage 2: Runner – Minimal runtime image

FROM node:18-alpine

WORKDIR /app

Copy only node_modules and the app code from the builder stage

COPY –from=builder /app/node_modules ./node_modules
COPY –from=builder /app/server.js .

Expose the port the app runs on

EXPOSE 3000

Define the command to run the application

CMD [“node”, “server.js”]
“`

构建命令 (在 nodejs-app 目录下):

bash docker build -t simple-node-app:latest .

解释:

Stage 1 (builder):
- 使用 node:18-alpine 作为基础镜像，它包含了 Node.js 运行时和 npm。
- 设置工作目录为 /app。
- 先 COPY package*.json ./：这是为了利用缓存。如果 package.json 或 package-lock.json 没有变化，即使其他应用代码变化了，npm ci 这一步也可以直接使用缓存。
- RUN npm ci: 安装项目依赖。使用 npm ci 比 npm install 更适合 CI/CD 环境，它会基于 package-lock.json 精确安装依赖，并且速度更快。
- COPY . .: 复制剩余的所有应用代码到 /app。
Stage 2 (runner):
- 再次使用 node:18-alpine 作为基础镜像。注意这里没有安装任何构建工具或开发依赖。
- 设置工作目录为 /app。
- COPY --from=builder /app/node_modules ./node_modules: 从 builder 阶段的 /app/node_modules 复制已经安装好的依赖到当前阶段。
- COPY --from=builder /app/server.js .: 从 builder 阶段复制主应用文件。
- EXPOSE 3000: 声明容器将监听 3000 端口。
- CMD ["node", "server.js"]: 设置容器启动时执行的命令。

这样构建出的 simple-node-app:latest 镜像将只包含运行应用所需的 Node.js 运行时、node_modules 目录和 server.js 文件，而不会包含构建阶段产生的其他临时文件和工具，体积会小得多。

构建完成后，你可以运行容器：

bash docker run -d -p 3000:3000 simple-node-app:latest
然后访问 http://localhost:3000 即可看到 “Hello from Dockerized Node.js App!”。

5.2 使用 `.dockerignore` 优化构建

在上面的 Node.js 示例中，如果你有 node_modules 目录在本地，并且没有使用 .dockerignore，Docker 会尝试将其也复制到构建上下文中。这会浪费带宽和时间，因为你已经在 Dockerfile 中通过 npm ci 安装了依赖。

在 nodejs-app 目录下创建 .dockerignore 文件：

node_modules/ npm-debug.log Dockerfile .git .gitignore *.swp

现在再次构建，你会发现 “Sending build context to Docker daemon” 这一步发送的数据量变小了。

6. 进一步探索的选项

除了上述内容，docker build 还有一些其他有用的选项：

-f /path/to/Dockerfile: 指定非默认名称或位置的 Dockerfile 文件。
bash docker build -f dockerfiles/prod.Dockerfile -t my-app:prod .
--iidfile /path/to/imageid.file: 将构建完成后镜像的 ID 写入指定文件。
--squash: （注意：此选项有一些限制和潜在问题，且在某些场景下不推荐，多阶段构建通常是更好的选择）尝试将新的文件系统层压缩为单个新层。
--platform linux/amd64 等：指定构建目标平台（当使用 Buildx 或 BuildKit 时）。

7. 总结

docker build 命令是 Docker 工作流程的核心。通过学习如何编写高效的 Dockerfile，并结合构建上下文、缓存机制、.dockerignore 文件、多阶段构建以及 BuildKit 等高级特性，您可以创建出体积更小、构建更快、更安全可靠的 Docker 镜像。

从基础的 FROM 和 RUN 到高级的多阶段构建和 BuildKit 特性，本文为您提供了 docker build 的全面指南。掌握了这些知识，您就能更好地将您的应用打包成可移植的 Docker 镜像，为后续的容器化部署打下坚实的基础。

持续实践和探索，结合您的具体应用场景，您将能更有效地利用 Docker 的强大功能。

Docker Build 命令详解：从入门到实战

1. Docker 镜像与 Dockerfile 基础概念

2. docker build 命令入门

2.1 构建上下文 (Build Context)

2.2 第一个 Dockerfile 和构建命令

Dockerfile

2.3 给镜像打标签 (-t)

3. 深入 Dockerfile 指令

4. Docker Build 的高级特性与最佳实践

4.1 利用构建缓存

Example: Python app

4.2 .dockerignore 文件

4.3 多阶段构建 (Multi-stage Builds)

Stage 1: Builder

Stage 2: Runner

4.4 BuildKit (下一代构建引擎)

syntax=docker/dockerfile:1.2 # Specify BuildKit frontend

4.5 使用构建参数 --build-arg

5. docker build 实战示例

5.1 构建一个简单的 Node.js Web 应用

Use a multi-stage build for smaller image size

Stage 1: Builder – Install dependencies

Copy package.json and package-lock.json first to leverage cache

Install dependencies

Copy the rest of the application code

Stage 2: Runner – Minimal runtime image

Copy only node_modules and the app code from the builder stage

Expose the port the app runs on

Define the command to run the application

5.2 使用 .dockerignore 优化构建

6. 进一步探索的选项

7. 总结

2. `docker build` 命令入门

2.3 给镜像打标签 (`-t`)

4.2 `.dockerignore` 文件

4.5 使用构建参数 `--build-arg`

5. `docker build` 实战示例

5.2 使用 `.dockerignore` 优化构建