Docker镜像瘦身之从GB到MB的优化实践教程

更新时间：2026年04月21日 08:39:16 作者：眷蓝天

一个未经优化的 Node.js 应用镜像可能达到 900MB 以上,而实际上运行该应用只需要几十MB的资源,这时我们就需要瘦身 Docker 镜像,下面小编就和大家详细介绍一下优化Docker镜像大小的技巧吧

为什么要瘦身 Docker 镜像

减少存储空间

一个未经优化的 Node.js 应用镜像可能达到 900MB 以上，而实际上运行该应用只需要几十MB的资源。一个 500MB 的镜像与一个 50MB 的镜像在存储成本上的差异是显而易见的——在大型集群环境中，这可能意味着数十GB甚至数TB的存储节省。

加快镜像拉取和部署速度

在 CI/CD 流水线中，镜像拉取往往是部署耗时的主要瓶颈。使用较小的镜像可以将拉取时间从数分钟缩短到数秒，对于需要频繁部署的微服务架构尤为重要。在 Kubernetes 环境中，节点启动时需要拉取镜像，更小的镜像意味着更快的服务响应。

提升安全性（减少攻击面）

镜像中包含的每一个二进制文件都可能是潜在的攻击向量。完整的 Ubuntu 镜像包含数百个系统工具和包，而很多应用根本不需要它们。通过精简镜像，可以移除不必要的工具、文档和库文件，从而显著减小攻击面。研究表明，多阶段构建优化后的镜像漏洞数量可能从数十个减少到个位数。

镜像瘦身的核心方法

选择合适的基础镜像

基础镜像是镜像体积的"起点"，选择合适的基础镜像往往能带来最显著的效果提升。

常见基础镜像体积对比

基础镜像	体积	适用场景
ubuntu:latest	~70MB	需要完整系统工具的场景
debian:slim	~30MB	平衡体积与兼容性
alpine:latest	~5MB	轻量应用，依赖少的场景
distroless/static	~2MB	极致精简，高安全场景
scratch	0MB	Go/Rust 等静态编译产物

各类语言推荐的精简镜像

# Python
python:3.11          # ~900MB（完整版）
python:3.11-slim     # ~180MB（推荐，glibc 兼容）
python:3.11-alpine   # ~40MB（需注意 musl libc 兼容性）

# Node.js
node:18              # ~900MB（完整版）
node:18-slim         # ~180MB（推荐）
node:18-alpine       # ~50MB

# Java
openjdk:17-jdk        # ~300MB（完整 JDK）
eclipse-temurin:17-jre # ~180MB（仅 JRE）
amazoncorretto:17-alpine # ~180MB（轻量版）

注意事项：Alpine 的 libc 兼容性问题

Alpine Linux 使用 musl libc 而非大多数 Linux 发行版默认的 glibc，这可能导致以下兼容性问题：

部分依赖 glibc 特性的应用可能无法正常运行
某些 C 语言编译的二进制文件可能出现动态链接错误
一些 Java 库的性能调优参数在 musl 上可能失效

建议：对于大多数应用，优先选择 -slim 镜像（基于 Debian/Ubuntu 的精简版，使用 glibc）。如果应用确实不需要 glibc 的高级特性，或对体积有极致要求，再考虑 Alpine。

多阶段构建（Multi-stage Build）

多阶段构建是 Docker 17.05 引入的核心特性，被公认为镜像瘦身的"杀手锏"。它的核心思想是：将构建过程和运行环境分离，只将最终的构建产物复制到精简的运行镜像中。

工作原理

# 阶段 1：构建阶段
FROM 完整镜像 AS builder
... 编译/打包 ...

# 阶段 2：运行阶段
FROM 精简镜像
COPY --from=builder /app/构建产物 ./

典型示例：Go 应用

Go 应用天然适合多阶段构建，因为编译后只生成一个静态链接的二进制文件：

# 构建阶段
FROM golang:1.21-alpine AS builder
WORKDIR /app

# 设置 Go 模块代理（加速依赖下载）
ENV GOPROXY=https://goproxy.cn,direct

# 复制依赖文件（利用 Docker 层缓存）
COPY go.mod go.sum ./
RUN go mod download

# 复制源代码并编译
COPY . .
# 静态编译：CGO_ENABLED=0 表示不依赖 C 库
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-w -s" -o myapp .

# 运行阶段：使用极简镜像
FROM alpine:3.19

# 安装时区数据（很多应用需要）
RUN apk --no-cache add tzdata

WORKDIR /app

# 仅复制二进制文件
COPY --from=builder /app/myapp .

EXPOSE 8080
CMD ["./myapp"]

效果对比：构建镜像 ~800MB → 最终镜像 ~15MB（减少约 98%）

典型示例：前端应用（Vue/React + Nginx）

# 构建阶段
FROM node:18-alpine AS builder
WORKDIR /app

# 先复制依赖文件（变化频率低，优先利用缓存）
COPY package*.json ./
RUN npm ci

# 复制源代码
COPY . .
RUN npm run build

# 运行阶段：仅使用 Nginx
FROM nginx:alpine

# 复制自定义 Nginx 配置
COPY nginx.conf /etc/nginx/conf.d/default.conf

# 复制前端构建产物
COPY --from=builder /app/dist /usr/share/nginx/html

EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

效果对比：单阶段 ~500MB → 最终镜像 ~30MB（减少约 94%）

减少镜像层数

Docker 镜像是分层存储的，每一条 RUN、COPY、ADD 指令都会生成一个只读层。层数过多会增加：

镜像体积（元数据开销）
镜像拉取时间
联合文件系统复杂度

合并 RUN 指令

反面示例（不推荐）：

RUN apt-get update
RUN apt-get install -y nginx
RUN apt-get install -y curl
RUN apt-get clean

正面示例（推荐）：

RUN apt-get update && \
    apt-get install -y --no-install-recommends nginx curl && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

Alpine 系统的正确清理方式

# 方式 1：使用 --no-cache
RUN apk add --no-cache nginx

# 方式 2：标记并删除构建依赖
RUN apk add --virtual .build-deps gcc musl-dev && \
    pip install -r requirements.txt && \
    apk del .build-deps

清理不必要的文件

安装依赖后残留的缓存和临时文件是镜像臃肿的常见原因。

常见需要清理的位置

包管理器	缓存位置	清理命令
apt (Debian/Ubuntu)	/var/lib/apt/lists/*	rm -rf /var/lib/apt/lists/*
yum (CentOS/RHEL)	/var/cache/yum/*	yum clean all
apk (Alpine)	/var/cache/apk/*	apk cache clean
pip (Python)	~/.cache/pip	pip cache purge
npm (Node.js)	node_modules/.cache	npm cache clean --force

关键原则

必须在同一层完成安装和清理！如果分开写，清理操作无法减小镜像体积：

# 错误写法：清理操作在新的层，之前层的数据仍会残留
RUN apt-get update && apt-get install -y nginx
RUN rm -rf /var/lib/apt/lists/*

# 正确写法：安装和清理在同一层
RUN apt-get update && \
    apt-get install -y nginx && \
    rm -rf /var/lib/apt/lists/*

使用 .dockerignore 文件

构建镜像时，Docker 会将当前目录（构建上下文）的所有文件发送到 Docker 引擎。.dockerignore 文件可以排除无关文件，减少构建上下文的体积。

推荐的 .dockerignore 配置

# 版本控制
.git
.gitignore
.svn

# 依赖目录（不应打入镜像）
node_modules/
__pycache__/
*.pyc
venv/
.venv/
env/

# 日志和临时文件
*.log
logs/
*.tmp
*.swp
*~
.DS_Store

# IDE 配置
.idea/
.vscode/
*.sublime-*
.project
.settings/

# 测试文件
test/
tests/
coverage/
*.test.js
*_test.go

# 文档
README.md
docs/
*.md

# 环境配置文件（敏感信息）
.env
.env.*
!.env.example

# 构建产物（重新构建即可）
dist/
build/
target/
*.o
*.class

# Docker 相关文件（防止递归）
Dockerfile
docker-compose.yml
.dockerignore

优化 COPY/ADD 指令

合理的文件顺序

将变化频率低的文件放在前面，充分利用 Docker 层缓存：

# 好的顺序：先复制依赖文件
COPY package.json package-lock.json ./
RUN npm ci

# 后复制代码（变化频繁）
COPY src/ ./src/

# 坏的顺序：每次代码变更都会导致依赖重新安装
COPY . .
RUN npm ci

仅复制必需文件

避免使用 COPY . ./ 全量复制，明确指定需要的文件和目录：

# 指定性复制（推荐）
COPY --from=builder /app/myapp .
COPY --from=builder /app/config.json .

# 全量复制（不推荐）
COPY --from=builder /app/ .

最佳实践与示例

Python 应用：从 1.2GB 到 150MB

优化前（臃肿镜像）

FROM python:3.11
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]

构建后体积：约 1.2GB

优化后（精简镜像）

# 构建阶段
FROM python:3.11-slim AS builder
WORKDIR /app

# 安装编译工具（Alpine 风格，但使用 Debian slim）
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
        gcc \
        musl-dev \
    && rm -rf /var/lib/apt/lists/*

COPY requirements.txt .
# 生成优化的 wheel 包
RUN pip install --no-cache-dir --wheel-dir=/wheels -r requirements.txt

# 运行阶段
FROM python:3.11-slim
WORKDIR /app

# 仅安装 wheel 包，不包含 pip 缓存
COPY --from=builder /wheels /wheels
RUN pip install --no-cache-dir --prefix=/app /wheels/*.whl

# 清理 Python 缓存
RUN find /app -type d -name __pycache__ -exec rm -rf {} + || true

COPY app.py .
CMD ["python", "app.py"]

构建后体积：约 150MB（减少 87.5%）

Node.js 应用：从 900MB 到 50MB

单阶段构建（优化前）

FROM node:18
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["node", "server.js"]

多阶段构建（优化后）

# 构建阶段
FROM node:18-alpine AS builder
WORKDIR /app

# 先复制依赖定义文件
COPY package*.json ./

# 仅安装生产依赖
RUN npm ci --only=production

# 复制源代码
COPY src/ ./src/

# 运行阶段
FROM node:18-alpine
WORKDIR /app

# 使用非 root 用户运行
RUN addgroup -g 1001 -S nodejs && adduser -S nodeuser -u 1001

# 仅复制生产依赖和代码
COPY --from=builder --chown=nodeuser:nodejs /app/node_modules ./node_modules
COPY --chown=nodeuser:nodejs src/ ./src/

USER nodeuser
EXPOSE 3000
CMD ["node", "src/server.js"]

构建后体积：约 50MB（减少 94%）

Java 应用：从 300MB 到 80MB

使用多阶段构建 + JLink

# 构建阶段
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline -B

COPY src ./src
RUN mvn package -DskipTests

# 运行阶段：使用 JRE 镜像
FROM eclipse-temurin:17-jre

WORKDIR /app

# 创建非 root 用户
RUN groupadd -r appgroup && useradd -r -g appgroup appuser

COPY --from=builder /app/target/*.jar app.jar

USER appuser
EXPOSE 8080

# JVM 优化参数
ENTRYPOINT ["java", "-XX:+UseContainerSupport", "-XX:MaxRAMPercentage=75.0", "-jar", "app.jar"]

进阶优化：使用 JLink 生成自定义最小化 JRE

# 在 JDK 镜像中生成最小化 JRE
FROM eclipse-temurin:17-jdk AS jre

RUN $JAVA_HOME/bin/jlink \
    --module-path $JAVA_HOME/jmods \
    --add-modules java.base,java.logging,java.sql,java.naming,java.desktop,java.management,java.security.jgss \
    --output /jre \
    --strip-debug \
    --no-header-files \
    --no-man-pages \
    --compress=2

# 运行阶段使用自定义 JRE
FROM alpine:3.19
COPY --from=jre /jre /opt/java
ENV JAVA_HOME=/opt/java
COPY --from=builder /app/target/*.jar app.jar
CMD ["/opt/java/bin/java", "-jar", "app.jar"]

构建后体积：约 80MB（使用 JRE）或 50MB（使用 JLink）

Go 应用：从 800MB 到 5MB

Go 语言的静态编译特性使其成为多阶段构建的最佳案例：

# 构建阶段
FROM golang:1.21-alpine AS builder
WORKDIR /app

# 设置 Go 模块代理
ENV GOPROXY=https://goproxy.cn,direct

# 利用层缓存：先复制 go.mod
COPY go.mod go.sum ./
RUN go mod download

# 复制代码并编译
COPY . .
# -ldflags="-w -s"：去除调试信息和符号表
RUN CGO_ENABLED=0 GOOS=linux go build \
    -ldflags="-w -s" \
    -o myapp .

# 运行阶段：使用 scratch 镜像（完全空白，仅包含二进制文件）
FROM scratch

# 从系统调用角度，scratch 镜像没有时区数据，需要显式复制
COPY --from=builder /usr/share/zoneinfo /usr/share/zoneinfo
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
COPY --from=builder /app/myapp /myapp

WORKDIR /myapp
EXPOSE 8080

ENTRYPOINT ["./myapp"]

构建后体积：约 5-15MB（取决于应用复杂度）

高安全场景：使用 Distroless

Google 的 Distroless 镜像是专为安全设计的，包含最小的攻击面：

# 构建阶段
FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -ldflags="-w -s" -o myapp .

# 运行阶段：使用 Distroless
FROM gcr.io/distroless/static-debian12

COPY --from=builder /app/myapp /myapp
COPY --from=builder /app/config.yaml /config.yaml

# 注意：distroless 镜像没有 shell
ENTRYPOINT ["/myapp"]

Distroless 特点：

不包含 shell、包管理器
不包含非必要的工具
最小化的 CVE 攻击面
仅包含应用运行必需的库

工具推荐

Dive：镜像层分析工具

Dive 是一款强大的镜像分析工具，可以直观地查看每一层的内容和大小分布。

安装方法

# Linux
curl -L https://github.com/wagoodman/dive/releases/download/v0.10.0/dive_0.10.0_linux_amd64.tar.gz | tar xz && sudo install dive /usr/local/bin/

# macOS
brew install dive

# Docker 方式
docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive:latest <image-name>

常用命令

# 分析镜像
dive <image-name>

# 边构建边分析
dive build -t <image-name> .

# CI 模式（自动验证）
CI=true dive <image-name>

# 对比两个镜像
dive <image-v1> <image-v2>

界面说明

启动 Dive 后，界面分为左右两部分：

左侧：镜像层结构，显示每层的大小和指令
右侧：该层的文件系统变更（新增/修改/删除）

关键快捷键：

↑/↓：切换层
Tab：切换视图
Ctrl+A：显示所有层的聚合变化
Ctrl+L：仅显示当前层的变化
Ctrl+F：搜索文件
Space：折叠/展开目录

关注点

使用 Dive 时，重点关注：

Layer Size：异常大的层（可能有未清理的缓存）
Efficiency 分数：目标 > 90%
重复文件：同一文件在多层出现
未使用文件：构建产物中的临时文件

docker-slim：自动瘦身工具

docker-slim（原名 DockerSlim，现已加入 CNCF）通过运行时分析自动识别应用依赖，实现智能裁剪。

安装方法

# 官方脚本（Linux/macOS）
curl -sL https://raw.githubusercontent.com/slimtoolkit/slim/master/scripts/install-slim.sh | sudo -E bash -

# Homebrew (macOS)
brew install docker-slim

# 手动下载
curl -fsSL https://downloads.dockerslim.com/releases/latest/dist_linux.tar.gz | tar xz -C /tmp
sudo mv /tmp/dist_linux/slim /usr/local/bin/

核心命令

# 基本用法（自动探测 HTTP 服务）
docker-slim build --target <original-image>

# 指定标签
docker-slim build --target <original-image> --tag <image>:slim

# 禁用 HTTP 探针（CLI 应用）
docker-slim build --http-probe=false --exec "./myapp" --target <image>

# 自定义探针命令
docker-slim build --http-probe-cmd GET:/health --target <image>

# 保留特定路径（防止误删）
docker-slim build --include-path /etc/myapp --include-path /var/log/myapp --target <image>

# 分析镜像（不修改）
docker-slim xray --target <image>

压缩效果参考

原始镜像	压缩后	压缩比
node:16 (900MB)	35MB	25x
python:3.9 (950MB)	28MB	34x
golang:1.18 (980MB)	1.5MB	653x
rust:1.56 (2GB)	14MB	143x
java:openjdk (743MB)	100MB	7x

CI/CD 集成示例

# GitHub Actions
- name: Build and slim Docker image
  uses: docker/build-push-action@v5
  with:
    push: false
    tags: myapp:${{ github.sha }}
- name: Optimize with docker-slim
  uses: kitabisa/docker-slim-action@v1
  with:
    target: myapp:${{ github.sha }}
    tag: myapp:slim-${{ github.sha }}

其他辅助工具

Docker Scout

Docker 官方安全分析工具（集成在 Docker CLI 中）：

# 启用 Docker Scout
docker scout enable

# 分析镜像漏洞
docker scout cves <image>

# 快速比较两个镜像
docker scout compare <image1> <image2>

kaniko

Google 开发的 Kubernetes 原生镜像构建工具，支持多阶段构建：

apiVersion: v1
kind: Pod
metadata:
  name: kaniko
spec:
  containers:
  - name: kaniko
    image: gcr.io/kaniko-project/executor:latest
    args:
      - "--context=git://..."
      - "--destination=gcr.io/my-project/my-app:latest"
    volumeMounts:
    - name: kaniko-secret
      mountPath: /secret
  restartPolicy: Never
  volumes:
  - name: kaniko-secret
    secret:
      secretName: docker-config

常见问题与注意事项

Q1：Alpine 镜像导致应用崩溃怎么办？

问题：部分应用在 Alpine 上运行时出现 libc 相关错误。

解决方案：

切换到 -slim 镜像（使用 glibc）
如果必须使用 Alpine，检查应用是否依赖 glibc 特性
对于 Java 应用，考虑使用 Amazon Corretto Alpine 版本

Q2：多阶段构建后应用无法启动

可能原因：

缺少运行时依赖（如时区数据、CA 证书）
动态链接库缺失（使用 ldd 检查）
文件权限问题

排查步骤：

# 先在完整镜像中检查依赖
docker run --rm -it <full-image> ldd /path/to/binary

# 复制必要的依赖到精简镜像
COPY --from=builder /lib/x86_64-linux-gnu/libssl.so.* /lib/x86_64-linux-gnu/

Q3：构建缓存失效导致构建变慢

优化策略：

合理安排文件顺序（依赖文件在前，源码在后）
使用 .dockerignore 减少上下文大小
利用 COPY --from=previous-stage 共享依赖

# 阶段 0：共享依赖
FROM node:18-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci

# 阶段 1：构建
FROM node:18-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

# 阶段 2：运行
FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html

Q4：如何在镜像中保留调试能力？

对于需要保留调试工具的场景：

# 运行阶段使用 slim
FROM python:3.11-slim
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
        curl \
        iputils-ping \
        procps \
    && rm -rf /var/lib/apt/lists/*

# 但在运行时通过环境变量控制
ENV DEBUG_MODE=${DEBUG_MODE:-false}

Q5：如何确保镜像的可重复构建？

锁定基础镜像版本：

# 使用具体版本，而非 latest
FROM python:3.11.8-alpine3.19

# 或锁定到 digest（最高确定性）
FROM python@sha256:abc123...

使用 BuildKit 的确定性构建：

DOCKER_BUILDKIT=1 docker build --progress=plain ...

创建 reproducible 标志的层：

# 在构建时设置 SOURCE_DATE_EPOCH
ARG SOURCE_DATE_EPOCH=$(date +%s)
RUN ...

镜像瘦身的检查清单

在提交 Dockerfile 之前，逐项检查：

是否选择了合适的基础镜像（优先 -slim，而非完整镜像）
是否使用了多阶段构建（构建阶段和运行阶段分离）
RUN 指令是否合并且包含清理操作
是否配置了 .dockerignore 文件
COPY 指令顺序是否合理（依赖在前，源码在后）
是否使用了 --no-cache-dir 或 --no-install-recommends 参数
是否移除了非必要的开发工具和调试符号
是否使用了非 root 用户运行
镜像是否经过 Dive 分析，效率分数 > 90%
生产依赖和开发依赖是否分离

总结

Docker 镜像瘦身不是单一技巧，而是系统工程。通过合理组合以下方法，通常可以将镜像体积减少 70%-95%：

选择合适的基础镜像（节省 50%+ 体积）
多阶段构建（节省 80%-95% 体积）
合并指令并清理缓存（节省 10%-20% 体积）
配置 .dockerignore（减少上下文体积）
使用分析工具定位问题（持续优化）

在实际项目中，建议：

建立团队的 Dockerfile 编写规范
使用 CI 集成 Dive 或 docker-slim 进行自动化检查
定期审计现有镜像，跟踪优化效果
权衡体积、兼容性和安全性，选择最适合的方案

以上就是Docker镜像瘦身之从GB到MB的优化实践教程的详细内容，更多关于Docker镜像大小优化的资料请关注脚本之家其它相关文章！

您可能感兴趣的文章:

docker测试时候命令无法补全的解决方法
因为最近在学习使用Docker,所以出现了好多的问题，昨天遇到的一个问题是在docker测试时候发现命令无法补全，通过查找资料最后解决了，现在将方法分享给有需要的人，大家可以参考学习。
2016-11-11
通过Docker为本地DeepSeek-r1部署WebUI界面的完整教程
本文详细介绍了如何通过Docker安装并配置OpenWebUI,一个功能丰富的自托管Web用户界面,用于与大型语言模型交互,文章步骤包括安装Docker、配置WSL2、使用dockerrun命令部署OpenWebUI,并提供了详细的命令解释和部署结果,需要的朋友可以参考下
2025-02-02
Docker Nginx反向代理实现过程
本文介绍了如何使用Nginx实现反向代理,并与网关的代理功能进行对比,通过Docker安装Nginx,解决了容器中缺少vim编辑器的问题,详细记录了修改Nginx配置、启动微服务、验证反向代理的步骤
2025-12-12
Docker rocketmq部署的实现示例
最近学习使用 rocketmq，需要搭建 rocketmq 服务端，本文主要记录 rocketmq 搭建过程以及这个过程踩到的一些坑，感兴趣的可以了解一下
2021-12-12
关于docker部署的jenkins跑git上的程序的问题
这篇文章主要介绍了docker部署的jenkins跑git上的程序的相关知识，本文给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
2020-11-11
部署安装docker及项目搭建所需要的基础环境实践(mysql、redis、nginx、nacos)
本文介绍通过docker-run.sh和docker-compose.yml实现一键部署Docker及Web服务,解决环境不一致问题,包含MySQL、Nacos、Nginx等配置,并提供GitHub代码链接便于直接使用
2025-07-07
通过Dockerfile构建Docker镜像的方法步骤
这篇文章主要介绍了通过Dockerfile构建Docker镜像的方法步骤，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
2021-02-02
在Docker中部署Confluence和jira-software的方法步骤
这篇文章主要介绍了在Docker中部署Confluence和jira-software的方法步骤，小编觉得挺不错的，现在分享给大家，也给大家做个参考。一起跟随小编过来看看吧
2019-06-06
docker自定义网桥docker0及docker的开启,关闭,重启命令操作
这篇文章主要介绍了docker自定义网桥docker0及docker的开启,关闭,重启命令操作，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧
2021-03-03
Docker 常用命令整理及使用注意事项总结
这篇文章主要介绍了Docker 常用命令整理及使用注意事项总结的相关资料,这里整理了Docker 的常用命令，说明这些命令是什么意思及使用方法，需要的朋友可以参考下
2016-12-12