Docker 近几个版本都更新了什么？重点变化与实战源码一次看完

发布人：慈云数据-客服中心发布时间：16小时前阅读量：4

Docker 最新更新内容汇总｜附源码

本文整理 Docker 近几个版本中值得关注的更新方向，覆盖 Docker Engine、Docker Desktop、BuildKit、Docker Compose、Docker Scout、安全能力、镜像构建优化以及开发实践示例。文末附带可直接运行的示例源码，包括 Dockerfile、docker-compose.yml、.dockerignore 和简单应用代码，方便读者快速验证。

一、前言

Docker 作为容器化技术生态中最重要的工具之一，已经从早期单纯的“容器运行工具”，逐渐发展为覆盖开发、构建、测试、交付、安全扫描、供应链治理和云原生部署的一整套工程化平台。

近年来，Docker 的更新重点已经不再只是“能不能运行容器”，而是更加关注以下几个方向：

构建速度更快
镜像体积更小
开发体验更顺滑
安全扫描更自动化
供应链治理更完善
本地开发与生产环境更一致
跨平台构建更加稳定
Compose 编排能力持续增强

对于后端开发、运维工程师、DevOps 工程师以及架构师来说，理解 Docker 的最新变化，不仅能提升日常开发效率，也能帮助团队构建更加可靠、安全、可维护的交付流程。

二、Docker Engine 更新重点

Docker Engine 是 Docker 的核心运行时组件，主要负责镜像管理、容器生命周期管理、网络、存储、日志等能力。

近几个版本中，Docker Engine 的更新主要集中在以下几个方面。

1. BuildKit 默认化程度进一步提高

BuildKit 是 Docker 新一代镜像构建后端，相比传统构建方式，它具备更好的并行构建能力、更强的缓存机制和更灵活的构建语法。

现在越来越多 Docker 版本已经默认启用 BuildKit，开发者在使用：

docker build .

或者：

docker buildx build .

时，底层都会使用 BuildKit 的能力。

BuildKit 的优势包括：

支持更高效的分层缓存；
支持多阶段构建；
支持构建时挂载缓存；
支持构建时挂载密钥；
支持多平台镜像构建；
支持远程构建器；
构建日志更加清晰；
对 CI/CD 场景更友好。

例如，在构建 Node.js、Go、Java、Python 项目时，可以通过缓存依赖目录大幅减少二次构建时间。

2. 多平台构建能力增强

随着 Apple Silicon、ARM 服务器、边缘计算设备的普及，跨架构镜像越来越常见。

Docker 现在可以更方便地构建多平台镜像，例如：

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t yourname/demo-app:latest \
  --push .

这条命令可以同时构建 linux/amd64 和 linux/arm64 两种架构镜像，并推送到镜像仓库。

这对以下场景非常有用：

Mac M 系列芯片开发；
x86 服务器部署；
ARM 云服务器；
树莓派、边缘设备；
Kubernetes 多架构集群。

过去跨平台构建往往需要复杂配置，现在借助 buildx 和 BuildKit，流程已经大幅简化。

3. 容器运行安全能力持续增强

Docker Engine 在安全方面持续优化，包括：

rootless 模式；
用户命名空间隔离；
Seccomp 配置；
AppArmor / SELinux 支持；
只读文件系统；
capability 精简；
镜像签名与供应链安全配合；
更严格的默认网络与权限控制。

例如，运行容器时可以减少权限：

docker run \
  --read-only \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  nginx:latest

这表示：

容器文件系统只读；
删除所有 Linux capabilities；
禁止进程获取额外权限。

在生产环境中，这类参数可以显著降低容器逃逸和横向移动风险。

三、Docker Desktop 更新重点

Docker Desktop 是很多开发者日常使用 Docker 的入口，尤其在 macOS 和 Windows 环境中非常重要。

近几个版本 Docker Desktop 的更新重点主要包括开发体验、安全治理、扩展生态和企业管控能力。

1. Docker Desktop 性能持续优化

Docker Desktop 在 macOS 和 Windows 上并不是直接运行 Linux 容器，而是通过轻量级虚拟化环境运行 LinuxKit VM 或 WSL2 后端。

近几个版本中，Docker Desktop 持续优化了：

文件系统性能；
容器启动速度；
镜像拉取体验；
资源占用；
WSL2 集成；
Apple Silicon 兼容性；
后台服务稳定性；
Kubernetes 本地集成体验。

对于前端和后端开发者来说，最明显的感受是：

docker compose up 更快；
文件挂载延迟降低；
镜像构建速度更稳定；
开发环境不容易卡死；
多容器项目启动更平滑。

2. Docker Desktop Extensions 扩展生态

Docker Desktop 支持 Extensions，可以在图形界面中集成第三方工具，例如：

数据库管理；
日志查看；
镜像分析；
安全扫描；
Kubernetes 管理；
本地开发辅助工具；
CI/CD 相关工具。

这使 Docker Desktop 不再只是一个容器管理工具，而逐渐变成面向开发者的本地云原生工作台。

对于团队来说，可以通过扩展统一开发者工具链，减少新成员搭建环境的成本。

3. Docker Init 简化项目容器化

Docker 提供了 docker init 命令，用于帮助开发者快速为项目生成 Docker 相关配置。

在项目根目录执行：

docker init

Docker 会根据项目类型引导生成：

Dockerfile
.dockerignore
compose.yaml
README 或相关说明

这对于刚接触 Docker 的开发者非常友好，尤其适合 Node.js、Python、Go、Java 等常见项目。

虽然自动生成的配置未必完全适合生产环境，但它可以作为一个很好的起点，后续再根据实际需求优化。

四、Docker Compose 更新重点

Docker Compose 是本地开发、多服务编排和轻量级部署中最常用的工具之一。

从早期的 docker-compose 到现在的 docker compose，Compose 已经从独立 Python 工具逐渐演进为 Docker CLI 插件。

1. Compose V2 成为主流

现在推荐使用：

docker compose up

而不是旧命令：

docker-compose up

Compose V2 的优势包括：

与 Docker CLI 集成更紧密；
性能更好；
支持更多新特性；
跨平台体验一致；
与 BuildKit、Buildx 配合更自然；
维护更加活跃。

虽然旧版 docker-compose 在一些环境中仍然可用，但新项目建议统一使用 Compose V2。

2. Compose Watch 改善本地开发体验

Compose Watch 可以监听文件变化，并自动同步、重启或重新构建服务。

示例：

docker compose watch

配合 compose.yaml 中的 develop.watch 配置，可以实现类似本地热更新的体验。

例如：

develop:
  watch:
    - action: sync
      path: .
      target: /app
    - action: rebuild
      path: package.json

这表示：

普通源码变更时同步到容器；
package.json 变化时重新构建镜像。

对前端、Node.js、Python、Go 微服务开发都很有帮助。

3. Compose Profile 支持多环境组合

Compose Profile 可以让同一个 docker-compose.yml 支持不同运行模式。

例如：

services:
  app:
    image: demo-app

  redis:
    image: redis:7
    profiles:
      - cache

  adminer:
    image: adminer
    profiles:
      - debug

默认只启动 app，如果需要 Redis：

docker compose --profile cache up

如果需要调试工具：

docker compose --profile debug up

这让本地开发环境更加灵活，不必维护多个重复的 Compose 文件。

五、Docker Scout 与镜像安全扫描

Docker Scout 是 Docker 近年来重点发展的安全能力之一，主要用于分析镜像中的漏洞、依赖、SBOM 和供应链风险。

1. 漏洞扫描更加集成化

使用 Docker Scout，可以扫描镜像：

docker scout cves nginx:latest

它会分析镜像中存在的 CVE 漏洞，并给出修复建议。

这对于以下场景非常重要：

基础镜像升级；
生产镜像上线前检查；
CI/CD 安全门禁；
软件供应链审计；
依赖漏洞治理。

2. 支持 SBOM 分析

SBOM，即 Software Bill of Materials，软件物料清单。

它类似于软件项目的“配料表”，记录镜像中包含了哪些组件、依赖、版本和来源。

在现代软件供应链安全中，SBOM 越来越重要。

Docker Scout 可以帮助开发团队理解镜像内部到底包含了什么，而不是只知道镜像能运行。

3. 与 CI/CD 流程结合

在 CI/CD 中，可以将镜像扫描作为流水线的一部分。

示例流程：

拉取代码；
构建镜像；
运行单元测试；
扫描镜像漏洞；
如果存在高危漏洞则阻断发布；
推送镜像；
部署到测试或生产环境。

这使安全检查从“上线后补救”变成“上线前拦截”。

六、镜像构建最佳实践更新

随着 Docker 工具链更新，镜像构建方式也应该同步优化。

1. 使用更小的基础镜像

推荐优先考虑：

alpine
slim
distroless
官方运行时精简镜像

例如 Node.js 应用可以使用：

FROM node:20-alpine

相比完整 Debian 镜像，Alpine 体积更小，漏洞面也更低。

但需要注意：

Alpine 使用 musl libc，某些依赖可能存在兼容性问题。如果项目对二进制依赖较多，可以选择 slim 镜像，例如：

FROM node:20-slim

2. 多阶段构建成为标准写法

多阶段构建可以将“构建环境”和“运行环境”分离。

例如 Go 项目：

FROM golang:1.22 AS builder

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

COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o app .

FROM alpine:3.20

WORKDIR /app
COPY --from=builder /src/app /app/app

EXPOSE 8080
CMD ["./app"]

最终镜像只包含二进制文件和运行所需内容，不包含编译器、源码和构建缓存。

优点：

镜像更小；
安全风险更低；
启动更快；
部署更稳定。

3. 合理使用缓存挂载

BuildKit 支持构建缓存挂载，例如 Node.js 项目：

RUN --mount=type=cache,target=/root/.npm \
    npm ci

Go 项目：

RUN --mount=type=cache,target=/go/pkg/mod \
    go mod download

这样可以避免每次构建都重新下载依赖，在 CI/CD 中尤其有用。

4. 不要把敏感信息写进镜像

错误示例：

ENV MYSQL_PASSWORD=123456
ENV API_SECRET=abcdefg

这种写法非常危险，因为镜像层中可能永久保留敏感信息。

更推荐使用：

Docker secret；
Kubernetes Secret；
环境变量注入；
CI/CD 密钥管理；
BuildKit secret mount。

BuildKit secret 示例：

RUN --mount=type=secret,id=npmrc,target=/root/.npmrc \
    npm ci

构建命令：

docker build \
  --secret id=npmrc,src=$HOME/.npmrc \
  -t demo-app .

这样密钥不会写入最终镜像层。

七、附源码：一个完整 Node.js + Redis 示例

下面给出一个可以直接运行的 Docker 示例项目，包含：

Node.js API 服务；
Redis 缓存；
Dockerfile；
docker-compose.yml；
.dockerignore；
package.json；
app.js。

项目结构如下：

docker-demo/
├── app.js
├── package.json
├── Dockerfile
├── docker-compose.yml
└── .dockerignore

1. app.js

const express = require("express");
const Redis = require("ioredis");

const app = express();
const port = process.env.PORT || 3000;

const redis = new Redis({
  host: process.env.REDIS_HOST || "redis",
  port: process.env.REDIS_PORT || 6379,
});

app.get("/", async (req, res) => {
  const count = await redis.incr("visit_count");

  res.json({
    message: "Hello Docker!",
    visitCount: count,
    time: new Date().toISOString(),
  });
});

app.get("/health", (req, res) => {
  res.json({
    status: "ok",
  });
});

app.listen(port, () => {
  console.log(`Server is running on port ${port}`);
});

2. package.json

{
  "name": "docker-demo",
  "version": "1.0.0",
  "description": "A simple Docker demo with Node.js and Redis",
  "main": "app.js",
  "scripts": {
    "start": "node app.js",
    "dev": "node --watch app.js"
  },
  "dependencies": {
    "express": "^4.18.3",
    "ioredis": "^5.4.1"
  }
}

3. Dockerfile

# syntax=docker/dockerfile:1.7

FROM node:20-alpine AS deps

WORKDIR /app

COPY package.json package-lock.json* ./

RUN --mount=type=cache,target=/root/.npm \
    npm install --omit=dev

FROM node:20-alpine AS runner

WORKDIR /app

ENV NODE_ENV=production
ENV PORT=3000

COPY --from=deps /app/node_modules ./node_modules
COPY app.js package.json ./

USER node

EXPOSE 3000

CMD ["npm", "start"]

这个 Dockerfile 使用了几个最佳实践：

使用 node:20-alpine 减小镜像体积；
使用多阶段构建；
使用 BuildKit 缓存 npm 依赖；
使用非 root 用户运行；
只复制运行时必要文件。

4. docker-compose.yml

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    image: docker-demo-app:latest
    container_name: docker-demo-app
    ports:
      - "3000:3000"
    environment:
      REDIS_HOST: redis
      REDIS_PORT: 6379
      PORT: 3000
    depends_on:
      - redis
    restart: unless-stopped

    develop:
      watch:
        - action: sync
          path: ./app.js
          target: /app/app.js
        - action: rebuild
          path: ./package.json

  redis:
    image: redis:7-alpine
    container_name: docker-demo-redis
    ports:
      - "6379:6379"
    volumes:
      - redis-data:/data
    restart: unless-stopped

volumes:
  redis-data:

5. .dockerignore

node_modules
npm-debug.log
Dockerfile
docker-compose.yml
.git
.gitignore
README.md
.env
dist
coverage

.dockerignore 的作用非常重要，它可以减少构建上下文大小，避免无关文件进入镜像构建过程。

如果项目很大但没有配置 .dockerignore，会导致：

构建速度变慢；
镜像上下文过大；
敏感文件误传；
CI/CD 构建耗时增加。

八、运行示例项目

在项目目录下执行：

docker compose up -d --build

查看容器状态：

docker compose ps

访问接口：

curl http://localhost:3000

返回结果示例：

{
  "message": "Hello Docker!",
  "visitCount": 1,
  "time": "2026-01-01T12:00:00.000Z"
}

再次访问时，visitCount 会递增，说明 Node.js 服务已经成功连接 Redis。

查看日志：

docker compose logs -f app

停止服务：

docker compose down

如果希望同时删除数据卷：

docker compose down -v

九、常用 Docker 命令汇总

1. 镜像相关

docker images
docker pull nginx:latest
docker build -t demo-app .
docker rmi demo-app

2. 容器相关

docker ps
docker ps -a
docker run -d -p 8080:80 nginx
docker stop container_name
docker rm container_name

3. Compose 相关

docker compose up
docker compose up -d
docker compose down
docker compose logs -f
docker compose restart
docker compose build

4. 构建增强

docker buildx ls
docker buildx create --use
docker buildx build --platform linux/amd64,linux/arm64 -t demo-app .

5. 安全扫描

docker scout cves demo-app:latest
docker scout recommendations demo-app:latest

十、企业团队升级 Docker 的建议

如果团队准备升级 Docker 版本或统一 Docker 开发规范，可以从以下几个方面入手。

1. 统一 Docker Desktop 与 Engine 版本

团队成员本地版本差异太大，容易出现：

Compose 语法不兼容；
构建结果不一致；
网络行为不同；
缓存机制不同；
本地能跑，CI/CD 不能跑。

建议在团队文档中明确推荐版本，并定期更新。

2. 统一使用 Compose V2

新项目建议统一使用：

docker compose

而不是：

docker-compose

同时在 README 中明确说明启动方式，降低沟通成本。

3. 推广多阶段构建

生产镜像不应该包含：

编译器；
源码；
测试文件；
本地配置；
调试工具；
临时缓存。

多阶段构建是减少镜像体积和降低风险的基础手段。

4. 引入镜像安全扫描

至少应在 CI/CD 中加入以下检查：

高危 CVE 扫描；
基础镜像版本检查；
依赖版本检查；
SBOM 生成；
镜像来源校验。

Docker Scout、Trivy、Grype 等工具都可以完成类似工作。

5. 建立基础镜像治理机制

很多安全问题不是业务代码造成的，而是基础镜像过旧造成的。

建议企业内部维护统一基础镜像，例如：

Java 基础镜像；
Node.js 基础镜像；
Python 基础镜像；
Nginx 基础镜像；
Alpine / Debian Slim 基础镜像。

这样可以统一更新系统依赖、CA 证书、时区配置、安全补丁和监控组件。

十一、总结

Docker 的最新更新体现出一个明显趋势：它正在从“容器运行工具”升级为“开发、构建、交付、安全治理一体化平台”。

对于开发者而言，最值得关注的变化包括：

BuildKit 成为核心构建能力；
docker buildx 支持更完善的多平台构建；
Compose V2 成为主流；
Compose Watch 改善本地开发体验；
Docker Init 降低容器化门槛；
Docker Scout 强化镜像安全扫描；
SBOM 和供应链安全越来越重要；
多阶段构建、缓存挂载、非 root 用户运行成为最佳实践。

如果你正在维护一个新项目，建议从一开始就采用现代 Docker 写法：

使用精简基础镜像；
使用多阶段构建；
配置 .dockerignore；
使用 Compose V2；
使用 BuildKit 缓存；
使用非 root 用户运行；
在 CI/CD 中加入安全扫描；
定期升级基础镜像和依赖。

Docker 的价值不仅是“把应用跑起来”，更重要的是让应用以一种稳定、可复制、可交付、可审计的方式运行在不同环境中。对于现代软件工程来说，这正是容器化最核心的意义。

文章标签： Docker BuildKit DockerCompose 安全扫描

上一篇：Docker 近期重要变化与常用命令一次讲清

下一篇：Docker 近期更新梳理：BuildKit、Compose V2 与生产配置一次讲清

更多栏目

新闻动态

文档中心

下载中心

目录结构

全文

产品与服务

新闻帮助

生态合作

了解我们