Docker容器化实战：从核心原理到部署排坑全指南

很多朋友第一次接触 Docker 的时候，都会被“容器”这个概念搞得很迷糊。有人把它类比成轻量级虚拟机，有人说它就是个进程沙箱，这些说法都对，但都不完整。我在实际项目里用了几年 Docker，从最初的好奇折腾，到后来在公司里推动整个部署流程容器化，中间踩过的坑比踩过的 Bug 还多。今天这篇内容，我就把对 Docker 容器学习的完整心路历程和实操经验整理出来，希望能帮你跳过那些我没能绕开的坑。

这篇内容适合三类朋友：一是刚入门、想知道 Docker 到底是干什么用的新手；二是已经会docker run，但一遇到数据持久化、网络互通就抓瞎的进阶用户；三是想在自己机器上部署 MySQL、Redis 等中间件、却不想把系统环境搞乱的应用开发者。我会把核心原理、安装细节、常用操作、真实部署案例以及常见故障排查一次讲透。

1. Docker 到底是什么？容器和虚拟机的核心区别

先解决一个根本问题：Docker 容器里跑的进程，和宿主机上直接跑的进程，到底有什么不同？

1.1 镜像、容器、仓库的关系

用一个生活化的比喻：Docker 镜像就像是一个“做菜的预制菜包”，里面已经封装好了你需要的所有食材、调料和烹饪步骤，甚至包括锅碗瓢盆这些依赖环境。你可以把这个菜包复制任意多份，每份做出来的菜味道完全一致。而容器就是你把预制菜包拿出来“实际做出来的那道菜”的实例。仓库则是存放这些菜包的地方，想吃什么口味就从中取。

技术上拆开来说，Docker 镜像是一个只读的模板。它包含了运行某个应用所需的全部内容：操作系统的基础库、依赖包、环境变量、配置文件、启动命令等。当你运行一个镜像时，Docker 会在镜像之上加一层可写层，这就是容器。对容器内文件的修改、删除、新增都发生在这一层可写层上，不会影响到底层镜像本体。

graph LR A[镜像仓库] -->|docker pull| B[本地镜像] B -->|docker run| C[容器实例] C -->|docker commit| D[新镜像] D -->|docker push| A

举个例子，mysql:8.0这个镜像里包含了 MySQL 服务器程序、必要的系统库、配置模板、数据目录初始化脚本。你运行docker run mysql:8.0就是在宿主机上基于这个模板创建出一个进程实例。

1.2 容器和虚拟机的本质区别

很多人问：Docker 容器和 VMware 虚拟机有什么区别？最核心的区别在于“虚拟化的层次”。

虚拟机虚拟的是硬件层，每个虚拟机都需要一个完整的客户操作系统（Guest OS）。这意味着每启动一个虚拟机，你可能要占用几 GB 内存和几十 GB 磁盘空间。而 Docker 容器虚拟的是操作系统层，所有容器共享宿主机内核，容器内只有应用本身及其依赖的库和二进制文件。

用一个更具体的例子说明：如果你在一台 8G 内存的服务器上启动 3 个虚拟机（每个虚拟机分配 2G 内存），可用内存就只剩 2G。但如果你在这台服务器上运行 3 个容器，每个容器可能只需要几十 MB 到几百 MB 内存，3 个容器合起来可能还占不到 1.5G。

容器之所以能做到如此轻量，关键在于它对内核名字空间（Namespace）和控制组（Cgroup）的利用：

• 名字空间隔离：让容器内的进程看到的是“独立”的系统视图。每个容器拥有自己的 PID（进程号）、网络栈、文件系统挂载点、用户、主机名。从容器内部看，它就像一个独立的操作系统，但实际上只是宿主机中隔离出来的一个进程组。
• 控制组资源限制：限制一个容器能够使用的 CPU、内存、磁盘 I/O、网络带宽上限。防止单个容器把宿主机资源耗尽，影响其他容器运行。

注意：因为容器共享宿主机内核，所以容器内不能运行与宿主机内核版本不兼容的程序。比如你在一台 Windows 宿主机上没法直接运行 Linux 内核模块，这也是为什么 Docker Desktop 在 Windows 上需要跑一个轻量级虚拟机（默认使用 WSL2）来提供 Linux 环境。

1.3 为什么开发环境、测试环境、生产环境不一致的问题被解决了

我团队里有一个困扰了很久的老大难问题：开发说“我这边跑得好好的”，测试说“我这边怎么报错”，运维说“生产环境哪有时间给你调”。根本原因是三个环境之间存在差异：操作系统补丁版本不同、依赖库版本不同、环境变量配置不同。

引入 Docker 之后，开发在代码仓库里提交一份Dockerfile或docker-compose.yml，这张“配方表”定义了应用运行所需的精确环境。测试、生产都基于同一个镜像构建，这一层环境差异就消失了。

2. 环境搭建：Windows、macOS、Linux 下的安装与踩坑

在讲具体操作之前，先解决“怎么把 Docker 装起来”这个实际问题。当前主流系统都有各自的安装路径，但都有一些需要注意的坑。

2.1 在 Windows 上安装 Docker Desktop

Windows 上的 Docker 使用有两种方案：老一代的 Docker Toolbox（基于 Oracle VM VirtualBox）已经基本淘汰，现在的标准方案是 Docker Desktop，它同时支持基于 Hyper-V 和基于 WSL2 两种后端。

我强烈建议优先选择 WSL2 后端。相比老的 Hyper-V 方案，WSL2 的启动速度更快、内存占用更少、文件访问性能也更好。在多数情况下，WSL2 也是 Docker Desktop 默认预设的。

安装步骤如下：

1. 先在 Windows 功能中启用“适用于 Windows 的 Linux 子系统”和“虚拟机平台”。这一步可以通过管理员 PowerShell 执行：dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart，接着执行dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart。完成后重启系统。
2. 安装 WSL2 内核更新包。这一步容易被漏掉，不更新内核的话，后续启动 WSL2 可能报旧版内核相关错误。
3. 到 Docker 官网注册账号并下载 Docker Desktop for Windows 安装包。这是一个图形化的安装程序，一路下一步即可。
4. 安装完成后重启系统，打开 Docker Desktop，等待右下角鲸鱼图标稳定，表示 Docker 引擎已经启动。

一个常见问题是Docker Desktop failed to start because virtualisation support wasn't detected。排查步骤也很套路：先确认 BIOS 中英特尔 VT-x 或 AMD-V 虚拟化技术已开启；再确认 Windows 的“虚拟机平台”功能已启用；如果电脑是品牌机，还要看是否在“内核隔离”相关的安全策略中把虚拟化给禁了。

2.2 在 Ubuntu/Linux 服务器上安装 Docker Engine

Linux 服务器的安装路径和 Windows 不同，Docker Desktop 只支持个人桌面后缀。服务器推荐安装 Docker Engine：

# 安装基础依赖 sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common # 添加 Docker 官方 GPG 密钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - # 添加 Docker 仓库 sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" # 安装 Docker Engine sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io # 启动并设置开机自启 sudo systemctl enable docker sudo systemctl start docker

如果你用的是 CentOS 7，Docker 20.10 版本之后就不再支持旧版docker-ce的安装流程，需要把系统先升级，或者沿用较老的yum install docker-ce --norestart路径。建议优先考虑升级到 CentOS Stream 或者迁移到 Rockey Linux。

提示：Linux 环境下安装完 Docker 后，执行docker ps可能会遇到permission denied while trying to connect to the Docker daemon socket。这是因为 Docker 需要 root 权限，而当前用户不在docker用户组中。执行sudo usermod -aG docker $USER后重新登录用户组权限即可，务必重新登录或newgrp docker生效。

2.3 镜像下载慢？配置国内加速器

镜像仓库默认是从海外拉取的，在国内网络环境下速度通常惨不忍睹。给 Docker 配置国内镜像加速器能极大缓解这个问题。不同系统的配置路径差不多，本质都是修改 Docker daemon 的配置文件，即 Linux 下的/etc/docker/daemon.json，或者 Docker Desktop 的 Settings > Docker Engine 中配置 JSON。

官方推荐的国内加速器有：阿里云容器镜像服务地址、腾讯云加速器、网易云镜像等。这里以阿里云为例说明：

{ "registry-mirrors": ["https://your-code.mirror.aliyuncs.com"] }

需要注意，每个阿里云用户分配到的加速地址不同，需要登录阿里云容器镜像服务控制台，在镜像仓库页面中查看专属地址。

注意：镜像加速器只解决拉取 Docker Hub 公开镜像的速度问题，如果你要拉取私有仓库镜像，加速器不生效，需要通过认证或内网代理。

3. 镜像与容器：从拉取到运行的关键操作

环境搭好了，接下来是真正把“容器”跑起来。这一步会涉及几个最常用的命令，也是后续一切操作的基础。

3.1 拉取镜像与运行容器的完整流程

以一个简单的 Nginx 为例：

# 1. 从 Docker Hub 拉取 Nginx 官方镜像 docker pull nginx:latest # 2. 查看本地已有的镜像 docker images # 3. 在前台运行一个 Nginx 容器并映射端口 docker run --name my-nginx -p 8080:80 -d nginx:latest # 4. 查看正在运行的容器 docker ps # 5. 访问测试 curl http://localhost:8080

这一条命令里藏着好几个关键参数，拆开讲：

• --name my-nginx：给容器起一个固定名字，方便后续管理。如果你不指定，Docker 会随机生成一个类似温柔小狗这种风格的名字。
• -p 8080:80：宿主机端口 8080 映射到容器端口 80。容器内运行的 Nginx 默认监听 80，宿主机通过 8080 访问。端口映射方向很关键，别写反了。
• -d：以后台守护模式运行，让 Nginx 在后台默默服务，释放你的终端。如果不加-d，容器会在前台运行，日志会直接打在终端上，Ctrl+C 会关掉容器。
• -v：挂载数据卷，把宿主机目录映射到容器目录，这一点后续单独展开。

如果 Nginx 更新了版本，你想重启后使用最新镜像，需要先用docker rm -f my-nginx删除旧容器，再用docker run重新创建。这不像进程那样可以直接原地升级。理解这一点对容器化思维的建立很重要：容器是“宠物”，还是“牲畜”？容器应该是“牲畜”，不配置化，不手工修改容器内文件，需要更新就是销毁重建。

3.2 进入容器与文件传输

如果需要调试容器内部：

# 交互方式进入容器 Bash docker exec -it my-nginx /bin/bash # 如果不确定容器里有 Bash 还是只有 sh，可以先尝试 docker exec -it my-nginx sh # 拷贝文件进出容器 docker cp ./game.txt my-nginx:/usr/share/nginx/html/game.txt docker cp my-nginx:/etc/nginx/nginx.conf ./nginx.conf

我实际碰到过一个场景：容器内运行的镜像没有安装 Vim、没有 Bash，只有精简的 BusyBox。这时候docker exec进入后交互体验极差。建议日常操作把重点放在外部文件挂载上，而不是在容器内东改西改。容器一旦被删除重建，内部改动就全部丢失，这是容器设计的哲学。

3.3 构建镜像：Dockerfile 的语法与顺序问题

如果你只会docker run官方镜像，那只能算 Docker 的消费者。真正让 Docker 发挥价值的是自己写 Dockerfile 构建镜像。

# 基础镜像 FROM python:3.11-slim # 设置工作目录 WORKDIR /app # 复制应用代码 COPY requirements.txt . RUN pip install -r requirements.txt COPY . . # 容器监听端口 EXPOSE 8000 # 启动命令 CMD ["python", "app.py"]

Dockerfile 里的每一行都会生成一个镜像层，这些层是缓存的基本单位。构建顺序很重要：先把变动频率低的内容（如依赖声明）放在前面，把变动频率高的内容（如应用代码）放在后面。这样每次代码改动时，Docker 可以复用已有层缓存，构建速度会快一个数量级。

以刚才的文件为例，如果我把COPY . .写在了RUN pip install之前，那么每一次代码修改都会导致 pip install 重新执行，慢得怀疑人生。

注意：写 Dockerfile 时尽量把多条 RUN 命令合并成一条，用&&连接。因为每条 RUN 都会产生一个额外的镜像层，镜像层越多，存储占用越大，构建推送时也越慢。

3.4 镜像安全与容器安全的基础意识

热搜词里有“镜像安全和容器安全”，这说明安全是评估容器化方案时绕不开的主题。基础的实践有两层：

镜像安全：不要随意从第三方渠道拉取来路不明的镜像。Docker Hub 官方库中的带“官方”标记的镜像（如nginx、mysql、redis）通常安全性较高。非官方用户上传的镜像可能存在恶意代码，因为它们本质上只是别人打包后上传到公开仓库的文件，没有人强制审查。

容器安全：容器默认以 root 用户运行，这其实是不安全的。如果一个攻击者攻破了容器进程，就相当于直接拿到了宿主机 root 的部分能力。建议在 Dockerfile 中显式指定普通用户运行：

RUN useradd -m appuser USER appuser

或者运行时指定：

docker run --user 1000:1000 -it my-image

提示：镜像是不可变的文件系统快照，容器是运行态实例。即使容器出现问题，也可以从同一个镜像快速启动新实例，避免人工排查污染镜像内容。

4. 数据持久化与网络通联：实战中的两个硬骨头

纯跑一个容器很容易，但真实项目里，数据不能丢、服务之间要通信，这就要深入容器卷和容器网络的了解了。

4.1 为什么容器删了数据就没了？数据卷的挂载方式

容器内部的文件系统是临时的，容器一旦被删除，容器层中的一切写入都会消失。所以 MySQL 这类需要持久化存储的中间件，必须把数据挂载到宿主机目录或卷中。

核心操作是-v参数或volumes配置：

方式一：绑定挂载（bind mount），即宿主机目录到容器目录。

docker run -d \ --name mysql-container \ -v /my/own/datadir:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD=my-secret-pw \ mysql:8.0

这行命令把宿主机目录/my/own/datadir挂载到容器内的 MySQL 数据目录。宿主机上存放的就是 MySQL 真实的数据库文件，哪怕容器被删除重建，只要宿主机上的目录还在，数据就能恢复。

方式二：命名卷（named volume）。

docker volume create mysql_data docker run -d \ -v mysql_data:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORD=my-secret-pw \ mysql:8.0

命名卷是由 Docker 管理存储的生命周期，实际文件位置在 Docker 的管理目录下，你不容易直接找到原始文件，但数据持久化效果和绑定挂载一致。

注意：绑定挂载时，宿主机的目录路径要写绝对路径。写成相对路径，Docker 会感觉困惑。另外，宿主机目录与容器目录之间的文件权限差异也是常见坑点。如果容器内进程以 UID 999 运行，宿主机挂载目录不但要是它，还需要给这个 UID 开放读写权限，否则会报Permission denied。

4.2 使用 Docker Compose 编排多容器服务

在真实项目中，一个完整的业务往往由多个服务组成：后端、数据库、缓存、消息队列。一个个docker run命令不高效，还容易在参数上出错。这是 Docker Compose 发挥价值的场景。

以部署一个带 MySQL 和 Redis 的小型 Web 应用为例：

version: '3.8' services: mysql: image: mysql:8.0 container_name: my-mysql environment: MYSQL_ROOT_PASSWORD: root_pass MYSQL_DATABASE: app_db MYSQL_USER: app_user MYSQL_PASSWORD: app_pass ports: - "3306:3306" volumes: - mysql_data:/var/lib/mysql networks: - app_network redis: image: redis:7-alpine container_name: my-redis ports: - "6379:6379" volumes: - redis_data:/data networks: - app_network app: build: ./app container_name: my-app depends_on: - mysql - redis ports: - "8080:8080" environment: DB_HOST: mysql REDIS_HOST: redis networks: - app_network volumes: mysql_data: redis_data: networks: app_network: driver: bridge

这里教你一个关键配置：DB_HOST: mysql。在同一个 Docker Compose 网络中，服务可以通过服务名互相访问。应用代码里连接数据库的主机名就是mysql，而不是localhost或127.0.0.1。因为容器间的网络隔离，应用容器里的localhost指向的是它自己，而不是 MySQL 容器。

启动整个环境只要一个命令：

docker compose up -d

查看日志、停止服务、删除服务：

docker compose logs -f docker compose down

docker compose down默认不会删除数据卷，如果你希望连数据卷一起清理，需要显式加-v。执行docker compose down -v会万劫不复，把所有数据一块清掉，慎用。

4.3 容器网络不通？先看这三层原因

热搜词里“docker网络不通”出现频率很高，这是新手最容易崩溃的环节。日志连连看，基本上可以归为三类问题：

第一类是应用连接数据库失败，报错类似Connection refused。这时候先检查最基础的问题：docker exec进入应用容器，尝试 ping MySQL 容器的服务名。如果 ping 不通，说明两个容器不在同一个 Docker 网络里。解决办法是复查 Compose 配置中两个服务是否使用了同一个 networks，或者用docker network connect手动把容器接入对应网络。

第二类是端口映射不生效，宿主机访问不到容器服务。优先检查docker ps -a中容器状态是不是 Exited（异常退出）或 Restarting（一直重启）。如果容器没起来，再查容器日志：docker logs my-container。如果容器在运行但访问不通，确认宿主机防火墙是否放行了对应端口。

第三类是不同宿主机上的容器无法互通。跨主机的容器通信需要额外配置，如 overlay 网络或路由方案，不是 Docker 默认安装后就能直接前置的。

5. 典型场景复现：用 Docker 快速部署 MySQL 8.0 与 Redis 主从

说太多理论不如来一次完整的真实部署。这一部分把搜索热词里的几个高频场景连起来做一套演示。

5.1 部署 MySQL 8.0 并解决中文编码问题

很多朋友用 Docker 安装 MySQL，之后发现写入中文会变成问号。这通常是因为 MySQL 容器的默认字符集不是 utf8mb4。

docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=root_pass \ -v mysql_data:/var/lib/mysql \ mysql:8.0 \ --character-set-server=utf8mb4 \ --collation-server=utf8mb4_unicode_ci \ --default-authentication-plugin=mysql_native_password

MYSQL_ROOT_PASSWORD环境变量是初始化时指定的 root 密码。同时可以在镜像启动参数里直接附加 mysqld 的配置参数，而不用专门去找配置文件挂载。

用 MySQL 客户端测试：

docker exec -it mysql8 mysql -uroot -p

在容器内执行：

CREATE DATABASE app_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

这样建出来的数据库就支持中文了。

注意：MySQL 8.0 的默认认证插件是caching_sha2_password。老版本的客户端（比如 PHP 7.x 自带的 mysqlnd）连接可能报认证协议不支持。如果团队里还在用老客户端，需要加--default-authentication-plugin=mysql_native_password或者为应用所属账号单独设置认证方式。

5.2 构建 Redis 主从架构

Redis 数据价值不如业务数据库高，但它也是容器化的重度用户。用 Docker 搭建主从复制节点很简单：

# 创建 Redis 网络 docker network create redis-net # 启动主节点 docker run -d --name redis-master \ --network redis-net \ -p 6379:6379 \ redis:7-alpine \ redis-server --appendonly yes # 启动从节点 docker run -d --name redis-slave \ --network redis-net \ -p 6380:6379 \ redis:7-alpine \ redis-server --appendonly yes --replicaof redis-master 6379

主从之间通过 Docker 网络内的服务名redis-master通信。务必确认从节点和主节点在同一个自定义网络中；如果没有指定网络，直接落到默认 bridge 网络也不是不行，只要从节点能解析主节点的主机名即可，实际用自定义网络管理起来更清晰。

验证主从状态：

docker exec -it redis-master redis-cli 127.0.0.1:6379> INFO replication

看到connected_slaves:1，表示从节点连接成功。

5.3 访问容器内的 MySQL，为什么连不上？

这是新老手都会碰到的高频问题：容器明明启动了，端口映射也正常，但宿主机的 MySQL 客户端就是连不上。

大概率故障清单：

1. 容器状态问题：docker ps -a看 Exited 状态，再用docker logs mysql8看有没有报错，比如初始化时没给MYSQL_ROOT_PASSWORD导致这是一个问题。
2. 端口被占用：宿主机上已有别的 MySQL 占用了 3306 端口，容器里-p 3306:3306不能生效。换一个宿主端口，比如-p 3307:3306，然后客户端连接该地址和端口访问。
3. 防火墙问题：宿主机的防火墙（firewalld / ufw）没有放行 3306 端口。
4. 环境变量问题：MySQL 容器首次初始化时如果没有按要求设置MYSQL_ROOT_PASSWORD，容器不会自动为 root 用户设置密码，直接拒绝密码登录会报Access denied。
5. MySQL 配置问题：MySQL 8.0 默认只监听 3306 端口，如果容器里改了配置成了只监听 127.0.0.1，外部也连不进来。这个可以通过执行docker exec -it mysql8 mysqladmin variables | grep listen查看。

5.4 用 IDEA 直接打包 Docker 镜像

对 Java 开发者来说，把 Spring Boot 项目打包成 Docker 镜像再用容器跑起来，是容器化落地第一步。IntelliJ IDEA 的 Docker 插件可以直接完成这个操作。

先安装并开启 Docker 插件（Settings > Plugins 搜索 Docker），在 Settings > Build, Execution, Deployment > Docker 中配置到 Docker Desktop 的连接。如果是远程服务器，配置 TCP 连接：tcp://服务器IP:2375。

在 IDEA 中创建一个 Dockerfile，运行配置类型选择 “Docker”，构建镜像时选择 Dockerfile 上下文：

FROM eclipse-temurin:17-jdk-alpine WORKDIR /app COPY target/*.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]

构建完成后，在 IDEA 的 Docker 面板中可以直接右键镜像运行容器，并配置端口映射。如果你不想依赖 IDE，也可以直接命令行构建：

mvn clean package docker build -t my-demo-app . docker run -d --name my-demo-app -p 8080:8080 my-demo-app

注意：构建镜像的基础镜像选型会影响镜像安全性和体积。JRE 类基础镜像（如eclipse-temurin:17-jdk-alpine）比完整 JDK 镜像小很多。如果你用到了一些系统级工具（如 curl），则可以用完整基础镜像，但体积会大得多。

6. 常见问题排查：权限、网络与镜像拉取速查表

最后做一个像工具书一样的常见问题速查表，把前面散落在各处的排查思路整理成清单，方便你遇到问题时直接定位问题类型和排查方向。

6.1 权限错误与 Docker 守护进程连接失败

最典型的错误是：

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock

原因基本有两种。一种是当前用户不在docker用户组，执行sudo usermod -aG docker $USER，重新登录。另一种是 Docker 守护进程没启动，Linux 下执行sudo systemctl start docker，Windows/macOS 下重新启动 Docker Desktop。

如果你在 macOS 上遇到了类似错误，检查 Docker Desktop 是否在系统菜单栏正常启动，以及是否在 Docker Engine 高级设置中启用了 TCP socket 监听。

6.2 容器一直重启（Restarting 状态）

原因几乎都是容器内部启动命令失败退出。排查路径：

1. 查看日志：docker logs <container_name>，看最后报错信息。
2. 确认启动命令本身是否正确。比如你把 Dockerfile 的 CMD 写错了路径，镜像里没有这个文件，容器启动就会直接退出。
3. 确认端口或存储卷是否冲突，比如两个容器同时把/var/lib/mysql挂载到了同一个宿主目录。
4. 检查资源限制：Docker 容器跨宿主机运行可能因为 cgroup 配置问题导致 OOM。

6.3 镜像拉取速度慢或拉取失败

这个问题本质上是网络受限。用镜像加速器能缓解，但加速器有时也不稳定，原因可能包括加速器本身服务波动、镜像体积过大等。遇到这种情况：

1. 确认daemon.json配置正确后重启 Docker。
2. 用docker system prune -a清理掉不用的镜像和构建缓存，给新镜像腾出空间。
3. 极个别情况下，某些镜像仓库（如自建 GitLab）的镜像内容需要经过特殊认证，此时需要先docker login <registry_url>。

6.4 容器网络 DNS 解析失败

docker run默认网络跑在 bridge 网络上，容器内部通常有 DNS 解析能力。但如果配置了自定义网络并且手动设置了dns参数，可能导致容器内域名解析失败。

如果容器所在的网络需要访问外网（比如从容器里拉取依赖包），但一直没有响应，尝试用docker run --dns 8.8.8.8指定外部 DNS，根据实际环境调整宿主机可用的 DNS 地址（例如公网 DNS 或公司内网 DNS）。

6.5 Docker Desktop 启动失败与 WSL2 内核问题

Windows 下最常见的一个错误是：

Docker Desktop failed to start because virtualisation support wasn't detected

这个问题不一定真的是虚拟化未开启，也可能是 BIOS 被重置、Hyper-V 被禁用了。常规处理顺序：

1. 重启电脑。
2. 确认「启用 Windows 功能」里「虚拟机平台」和「适用于 Linux 的 Windows 子系统」都勾选了。
3. wsl --update更新 WSL2 内核。
4. 删除%USERPROFILE%\AppData\Local\Docker下的临时文件（仅在确认安装配置无误解时操作，否则可能影响配置）。

6.6 Windows 防火墙把 Docker 容器网络挡掉了

Windows 上的 Docker 网络有个特性：如果 Docker Desktop 使用的 WSL2 虚拟机的 IP 地址段和宿主机防火墙上已有一条拒绝访问规则冲突，容器端口映射后，外部访问可能失败。

通常的处理办法是：在 Windows 防火墙的入站规则中，为 WSL2 虚拟网卡所在网段（可以用wsl hostname -I查到）放行端口，或者直接关闭（只是平时开发调试用）防火墙对应规则中的“阻止”选项。

7. 一份可以直接抄作业的后台管理命令合集

前面几部分讲述的都有点“大而全”，最后总结一份应急相比，日常操作最为频繁、用途最广的命令清单。

7.1 容器生命周期管理

# 查看运行中容器（含刚退出但没删的） docker ps -a # 启动已存在的容器 docker start <container_id> # 重启 docker restart <container_id> # 停止 docker stop <container_id> # 删除 docker rm <container_id> # 强制删除 docker rm -f <container_id> # 删除所有停止的容器 docker container prune

7.2 镜像操作

# 列出所有本地镜像 docker images # 删除镜像 docker rmi <image_id> # 删除悬空镜像 docker image prune # 查看镜像的分层结构 docker history <image_id> # 查看镜像细节 docker inspect <image_id>

7.3 系统资源观察

# 查看容器资源占用 docker stats # 查看容器日志并跟随输出 docker logs -f <container_name> # 查看容器进程列表 docker top <container_name> # 检查磁盘占用 docker system df

经验技巧：包含日志这一项，Docker 容器的标准输出和错误输出都会重定向到docker logs。如果应用是 Java 技术栈，日志大文件会让docker logs变得很慢，这时候要么在应用层把日志写到文件再挂载到宿主，要么定期用docker logs --max-size 10m --max-file 5限制 Docker 自身日志大小（需要配置守护进程）。

8. 后续可以这样扩展你的 Docker 实战

当你把单机容器用熟了，以后可以尝试的方向还很多。这里根据我自己的实际经验接下来三条建议：

扩展方向一：学习 Docker Compose 之外的容器编排工具。

如果只有两三台机器，用docker compose完全足够。但如果规模上去到几十台、上百台，就需要学 Kubernetes（K8s）或者 Docker Swarm。两者的核心思想都是：在多个服务器之间调度容器、自动发现问题并替换实例。但 K8s 是当前行业标准，学习曲线也相对陡峭。

扩展方向二：把 CI/CD 和 Docker 结合。

容器最大的用处是给出一个可复现的构建环境。在 CI 流水线中，先构建 Docker 镜像，再测试，再推送到镜像仓库，最后在目标服务器上拉取并运行。这个流程一旦跑通，版本发布就从“手工替换代码”变成了“同一个镜像在不同环境流转”。

扩展方向三：自己搭建镜像仓库。

团队规模扩大后，Docker Hub 的公共镜像仓库明显不够用，可以考虑搭建 Harbor 或者用云服务商的镜像仓库。私有仓库的好处是，镜像只在内网流通，安全性和拉取速度都有改善，镜像加速器的作用也可以相辅相成。

我在实际使用中的体会是，Docker 的价值远不止于“把一个应用塞进一个独立环境跑起来”。它的核心价值是让环境不再成为问题，让软件交付从“代码包”变成“可运行的环境快照”。当你在本地能跑起来，在测试环境能跑起来，在生产环境也能跑起来，很多以前一堆人吵来吵去的部署问题就会慢慢消失。

最后分享一个小技巧：如果你刚开始练习，可以把自己常用的工具链都容器化，比如 MySQL、Redis、Nginx，甚至用 GitLab CI 时也可以顺手把 Runner 容器化。当你习惯容器化之后，你会慢慢发现，之前以为“只可能在这个机器上跑起来”的事，很多时候都能换一台机器照样完美运行。这就是容器化带给你的自由度。