Ubuntu 安装 Docker 完整指南：从环境准备到实战部署-代码聚汇网

Ubuntu 安装 Docker 完整指南：从环境准备到实战部署

元宿six·2026-08-29·阅读 21 GEO检测（免费）

DockerUbuntu容器化

|难度：普通|阅读约 51 分钟

1. 为什么大家都在 Ubuntu 上装 Docker

最近收到好几条私信，都是在问 Ubuntu 下装 Docker 的事。有的是刚在 VMware 里装完 Ubuntu 22.04 系统，打算搭个开发环境练手；有的是项目要用 MySQL、Redis 这类中间件，嫌本地一个个装太麻烦；还有的是在 Windows 上被 Docker Desktop 折磨得不行——启动报错、Hyper-V 冲突、虚拟化检测不到，干脆换个思路直接用纯 Linux 环境。

说实话，这个选择挺明智的。Docker 本来就是在 Linux 上诞生的，容器技术依赖 Linux 内核的 namespace 和 cgroups 能力，在 Linux 原生环境里跑，性能和稳定性都比在 macOS 或者 Windows 上靠虚拟机中转要扎实得多。而且 Ubuntu 作为市场占有率最高的桌面发行版之一，文档齐全、社区活跃，遇到问题基本都能搜到答案，对新手非常友好。

这篇指南我会从零开始，覆盖安装前的环境准备、Docker Engine 和 Docker Desktop 两条路线的选型对比、镜像源配置、常用命令实战，以及最常见的坑和排查方法。你在 VMware 里装也好，物理机裸装也好，只要跟着走，基本不会卡壳。所有内容都是我在多台 Ubuntu 20.04/22.04 上实际操作过的经验，不是抄官方文档那种干巴巴的步骤。

先说清楚一个基本概念，Docker 有两个常见的东西容易混：一个是 Docker Engine，就是那个在命令行里跑的容器运行时；另一个是 Docker Desktop，带图形界面，集成了 Docker Engine、Compose、Kubernetes 等一堆工具。在 Ubuntu 上我强烈建议先试 Docker Engine，轻量、干净、和命令行工具链配合得最好，这也是绝大多数服务器环境的标准用法。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 安装前的环境准备：版本选择与系统检查

2.1 Ubuntu 版本怎么选，LTS 和普通版的区别

安装前第一件事是确认系统版本。去终端里执行 lsb_release -a 或者查看 /etc/os-release 就能看到。

bash复制lsb_release -a

如果你看到的是 Ubuntu 22.04 LTS 或者 24.04 LTS，那恭喜，这是目前最省心的两个版本。LTS 全称 Long Term Support，意味着官方会给长达 5 年的安全和维护更新，Docker 官方也会优先保证在 LTS 版本上的兼容性。非 LTS 版本（比如 23.10、24.10 这类）虽然也能装 Docker，但你可能遇到内核版本太新导致的兼容问题，我的建议是别拿生产环境开这种玩笑。

顺带提醒一句，现在很多新机器预装的是 Ubuntu 24.04，apt 源里自带的 docker.io 包版本往往偏旧，所以尽量不要直接 apt install docker.io，要装就用 Docker 官方源，后面我会详细说。

2.2 硬件虚拟化检查：为什么 VMware 里容易翻车

很多人在 VMware 虚拟机里安装 Docker，启动的时候报 Virtualization support not detected。这个问题的根源在于虚拟机的 CPU 虚拟化功能没开。

Docker Desktop 在 Linux 上使用 KVM 虚拟化来跑 Linux 虚拟机，这需要 CPU 支持硬件虚拟化，也就是 Intel 的 VT-x 或 AMD 的 SVM。检查方法很简单：

bash复制egrep -c '(vmx|svm)' /proc/cpuinfo

返回 0 表示没开启，大于 0 说明已开启。如果返回 0，你需要：

关闭虚拟机操作系统（先执行 sudo shutdown now）。
在 VMware 的虚拟机设置里，找到“处理器”选项。
勾选“虚拟化 Intel VT-x/EPT 或 AMD-V/RVI”。
重新启动虚拟机。

这里有个容易忽略的点：VMware Workstation 本身的“虚拟化引擎”里还有一个选项“虚拟化 Intel VT-x/EPT”，如果你宿主机 BIOS 里没开 VT-x，这里勾了也没用。 物理机上也要进 BIOS 把 Intel Virtualization Technology 打开。这个坑在 Windows 上装 Docker Desktop 的时候同样会出现，很多人的报错信息都指向这里。

2.3 网络环境和软件源：先解决装不上的底层问题

Ubuntu 的软件源配置在 /etc/apt/sources.list 或者 /etc/apt/sources.list.d/ 目录里。如果你在国内，直接用默认源安装 Docker 会非常慢，甚至超时。解决办法是换成国内镜像源。目前比较稳定的是阿里云、清华 tuna 的 Ubuntu 镜像源。

bash复制sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak
sudo sed -i 's/archive.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list
sudo apt update

这个步骤不是必须的，但如果你在安装过程中遇到网络超时，大概率就是源的问题。另外安装 Docker 官方源时也需要网络通畅，Docker 的官方源在国内直连速度一般，后面讲到 Docker 镜像源配置的时候我会一起说怎么处理。

3. Docker Engine 完整安装：从官方源到验证

3.1 用官方 apt 仓库安装而不是脚本一键装

现在网上很多教程直接用 curl -fsSL https://get.docker.com | sh 一键脚本安装。这条命令确实快，但它会从 Docker 官方下载脚本并直接以 root 权限执行，存在两个问题：一是你根本不知道脚本里具体做了哪些操作，安全上不透明；二是脚本默认使用官方源，在国内网络环境下经常失败。我个人的建议是把官方仓库加到 apt 源里，一步步来，既安全又可复查。

先安装一些依赖工具：

bash复制sudo apt update
sudo apt install -y ca-certificates curl gnupg lsb-release

然后添加 Docker 的 GPG 密钥，用于验证软件包完整性：

bash复制sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

这里有个细节：不同版本的 Ubuntu 对应的仓库代号不一样。22.04 是 jammy，24.04 是 noble。用 $(. /etc/os-release && echo $VERSION_CODENAME) 可以动态获取，不用手动记：

bash复制echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo $VERSION_CODENAME) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

接着更新源并安装：

bash复制sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

这里我装的是 docker-ce（社区版），同时把 docker-buildx-plugin 和 docker-compose-plugin 也一起装了。新版 Docker 把 Compose 做成了插件形式，命令是 docker compose（中间有空格），和老的 docker-compose 不是同一个命令，很多人会在这里踩坑。

3.2 国内环境加速：把 Docker 官方源替换成可用镜像源

这一步非常关键。即使你顺利装好了 Docker，拉取镜像的时候如果直接走 docker.io 官方仓库，在国内基本是龟速。解决办法是配置 registry mirror，也就是 Docker 镜像加速器。

编辑 /etc/docker/daemon.json（没有就新建）：

json复制{
  "registry-mirrors": [
    "https://docker.m.daocloud.io",
    "https://dockerproxy.com",
    "https://docker.mirrors.ustc.edu.cn"
  ]
}

然后重启 Docker 服务：

bash复制sudo systemctl daemon-reload
sudo systemctl restart docker

关于镜像加速器，我需要多说几句。这些第三方加速服务的稳定性经常变化——有的今天能用明天就挂，有的需要你注册账号才能获得专属地址。上述这几个是我近期实测可用的公共节点，但你不能永远指望它们。更好的思路是后面自己搭一个镜像代理缓存，或者直接用国内云厂商提供的容器镜像服务。配置完成后可以用 docker info 查看 Registry Mirrors 是否生效。

3.3 验证安装并解决权限问题

装完先验证一下版本：

bash复制docker --version
docker compose version

然后跑一个 hello-world 验证能否正常拉取镜像并启动容器：

bash复制sudo docker run hello-world

正常的话会打印一段欢迎信息。但你会发现一个问题：每次都要加 sudo，很烦。Docker 守护进程默认以 root 权限运行，当前用户不在 docker 用户组里，所以要用 sudo。解决办法是把当前用户加入 docker 组：

bash复制sudo usermod -aG docker $USER
newgrp docker

之后就不用 sudo 了。这里有个安全提醒：加入 docker 组的用户等同于拥有了 root 权限，因为你可以通过挂载宿主机目录到容器的方式来读写任意文件。 所以在个人开发机上没问题，但在服务器上要严格控制用户组权限。

4. 备选方案：Docker Desktop 在 Ubuntu 上的安装与折腾记录

4.1 为什么你可能需要 Docker Desktop

很多人是从 Windows 或 macOS 转到 Linux 的，习惯了 Docker Desktop 的图形界面——直观的容器列表、一键启动停止、日志查看器、资源监控面板，确实方便。而且 Docker Desktop 集成 Kubernetes 一键开关，还有 Docker Extensions 生态，这是纯命令行 Docker Engine 给不了的体验。

但如果你工作流里全是命令行操作，或者你的机器配置一般（内存小于 8GB），我建议直接用 Docker Engine 就好。Docker Desktop 在 Ubuntu 上需要启动一个 Linux 虚拟机来工作，底层走 QEMU/KVM，内存占用轻松超过 1.5GB，这在资源有限的 VMware 虚拟机里是个不小的负担。

那有没有办法两个都装？有，但我不建议。Docker Desktop 会接管 containerd 和 Docker CLI 的 socket，和 Docker Engine 同时存在容易冲突，你会看到 Cannot connect to the Docker daemon 这类莫名其妙的错误。我个人的习惯是：开发机用 Docker Desktop 图个方便，生产服务器只装 Docker Engine。

4.2 安装步骤：从 .deb 包到首次启动

Docker Desktop 官方提供了 Ubuntu 专用的 .deb 安装包，下载地址在 Docker 官网的 Desktop 下载页面。安装方式很简单：

bash复制sudo apt update
sudo apt install -y ./docker-desktop-<version>-amd64.deb

但装之前要先确认前置条件：

必须先把 Docker Engine 装好，因为 Docker Desktop 依赖它。
需要 KVM 虚拟化可用，前面说的 VT-x/SVM 检查还得再做一次。
桌面版还需要 GNOME 或 KDE 桌面环境，纯服务器版的 Ubuntu 装不了（没有 GUI 框架）。

安装完成后，在应用菜单里找到 Docker Desktop，点击启动。第一次启动会弹出服务条款确认，接受之后它会自动初始化。

4.3 Docker Desktop 启动失败的常见报错

启动 Docker Desktop 时最经典的就是这个报错：Docker Desktop failed to start because virtualisation support is not detected。虽然我们前面在 VMware 里已经开了 VT-x，但有些情况下 KVM 模块没有加载，Docker Desktop 检测不到。

排查顺序是这样的：

bash复制# 检查 KVM 模块是否加载
lsmod | grep kvm

如果没输出，试着手动加载：

bash复制sudo modprobe kvm_intel   # Intel CPU
# 或者
sudo modprobe kvm_amd     # AMD CPU

加载还失败，检查一下是不是嵌套虚拟化权限的问题。VMware 默认不向虚拟机暴露硬件虚拟化指令，即使你在虚拟机设置里勾了“虚拟化 Intel VT-x”，某些主板配合某些 CPU 型号仍然会失效。这时候只能回宿主机 BIOS 里确认。

另外还有一种情况，Docker Desktop 启动后停在 Docker Engine starting 界面不动，多半是因为它尝试绑定 2375 端口失败，或者和已运行的 Docker Engine 服务冲突。解决方法是在 Docker Desktop 的 Settings → Resources → Advanced 里改一下相关设置，或者干脆先停掉 Docker Engine 的系统服务：

bash复制sudo systemctl stop docker
sudo systemctl stop docker.socket

然后重启 Docker Desktop。注意这样会影响到你命令行里已经装好的 Docker Compose 项目，所以还是那个建议，二选一就好。

5. 镜像加速与业务实战：MySQL 和 Redis 一网打尽

5.1 为什么先讲业务场景而不是命令列表

每次写 Docker 安装教程，最后都会贴一堆 docker ps、docker logs、docker images 这种命令清单。这种内容没多大意义——命令手册随时可以查，但你真正需要的是知道装好了 Docker 之后怎么把它用起来。

所以在安装篇里，我直接放两个最贴近日常开发的实战：用 Docker 装 MySQL 8.0 并让外部客户端能连上，以及用 Docker Compose 搭一套 Redis 主从结构。这两件事几乎是所有后端开发的刚需，也是 Docker 最典型的使用场景。你在热搜词里也能看到大量相关需求——docker安装mysql8.0并使用、docker安装redis主从，说明大家装完 Docker 第一步就是干这个。

5.2 单机 MySQL 8.0 容器化部署

MySQL 的容器化部署要注意几个点：数据持久化、时区、字符集、密码策略、端口映射。

先建目录：

bash复制mkdir -p ~/docker/mysql/{data,conf,logs}

然后起容器：

bash复制docker run -d \
  --name mysql8 \
  -p 3306:3306 \
  -e MYSQL_ROOT_PASSWORD=YourPassword123 \
  -e TZ=Asia/Shanghai \
  -v ~/docker/mysql/data:/var/lib/mysql \
  -v ~/docker/mysql/conf:/etc/mysql/conf.d \
  -v ~/docker/mysql/logs:/logs \
  mysql:8.0 \
  --character-set-server=utf8mb4 \
  --collation-server=utf8mb4_unicode_ci

说一下几个关键参数的用意：

-p 3306:3306：把容器的 3306 端口映射到宿主机 3306，这样宿主机外的客户端才能连上。前面那个 3306 是宿主机端口，后面那个是容器端口，别搞反。
-e MYSQL_ROOT_PASSWORD：初始化 root 密码。注意这只是初始化时的环境变量，如果 data 目录已经有了旧数据，这个变量不会生效。
-v 挂载：把容器的数据目录映射到宿主机，容器删了数据还在，这是容器部署的基础修养，不挂载数据卷的 MySQL 容器就是个一次性玩具。
utf8mb4：MySQL 8.0 默认字符集其实是 utf8mb4，但我还是习惯显式指定，防止某些客户端工具连接时乱码。

启动后等十几秒，让它完成初始化，然后测试连接：

bash复制docker exec -it mysql8 mysql -uroot -p

docker exec -it 的核心用法就是进入一个正在运行的容器内部执行命令。-it 两个参数一个是交互模式，一个是分配伪终端，合在一起你才能像在本地终端里一样输命令。

外面要连的话，记得确认宿主机防火墙放行 3306 端口。Ubuntu 上如果你启用了 ufw：

bash复制sudo ufw allow 3306/tcp

5.3 Redis 主从集群的 Docker Compose 方案

单容器用 docker run 还行，一旦涉及多个容器协调，用 docker compose 更合适。Redis 主从结构就是一个典型场景。

先在项目目录创建 docker-compose.yml：

yaml复制services:
  redis-master:
    image: redis:7
    container_name: redis-master
    ports:
      - "6379:6379"
    command: redis-server --requirepass masterpass --appendonly yes
    volumes:
      - ./master-data:/data

  redis-slave:
    image: redis:7
    container_name: redis-slave
    ports:
      - "6380:6379"
    command: redis-server --slaveof redis-master 6379 --masterauth masterpass --requirepass masterpass --appendonly yes
    depends_on:
      - redis-master
    volumes:
      - ./slave-data:/data

然后启动：

bash复制docker compose up -d

验证主从是否连通：

bash复制docker exec -it redis-slave redis-cli -a masterpass info replication

看到 master_link_status:up 就说明主从已经握手成功。depends_on 的作用是保证先启动主节点再启动从节点，但要注意它只保证启动顺序，不保证主节点已经完全就绪，如果出现连接不上，等两秒重试一下就行。

Redis 的 command 里直接写启动参数的方式，本质上是覆盖镜像默认的 CMD。也可以写进 redis.conf 挂载进去，适合参数很多的情况。

6. 把 Docker 当日常工具：常用命令和资源管理技巧

6.1 命令速查：新手最容易弄混的几个操作

Docker 的命令体系不长，但有几个非常容易搞混，我第一次用也踩过坑：

docker ps 列出正在运行的容器，docker ps -a 列出所有容器（包括已停止的）。很多新手看不到容器，就是因为忘了加 -a。
docker start <容器名> 是启动已存在的容器，docker run 是创建并启动新容器。run 每次都创建新容器，这也是为什么你看到“重复启动”的容器越来越多。
docker exec 是进入运行中的容器执行命令，docker attach 是直接连接容器的主进程。日常操作基本只用 exec，attach 在某些镜像里会直接把终端挂死。
docker logs -f <容器名> 是跟踪实时日志，排查问题必备。
docker rm 删除容器，docker rmi 删除镜像。很多新手 rm 和 rmi 分不清，删错之后才发现镜像还在，又占空间。

还有个常用技巧，清理所有不再使用的资源：

bash复制docker system prune -a

注意 -a 会把没有被容器使用的镜像全部删掉，如果你只是想清理悬空镜像（dangling images），去掉 -a 就行：

bash复制docker system prune

6.2 容器资源占用怎么看

docker stats 可以实时显示所有容器的 CPU、内存、网络 IO，有点像 Linux 的 top。这个命令在排查“哪个容器把宿主机内存吃满了”的时候特别好用。

bash复制docker stats

如果看到某个容器内存异常飙升，可以进一步看：

bash复制docker inspect <容器名> | grep -i memory

docker inspect 输出的是容器的完整 JSON 配置，信息量大到离谱——网络、挂载卷、环境变量、重启策略全在里面。新手不需要全看懂，但要知道有这个东西，排查问题的时候能救急。

6.3 限制容器资源的正确姿势

不限制资源的容器就是个无底洞。一个代码有 bug 的容器可以瞬间吃掉宿主机所有内存。所以 docker run 的时候养成加资源限制的习惯：

bash复制docker run -d --name myapp --memory="512m" --cpus="1.0" nginx

--memory 限制最大内存，--cpus 限制 CPU 核心数。容器超过内存限制会被 OOM kill，这是保护机制，不是 bug。如果你的容器被杀掉了，docker logs 里会看到 Killed 字样。

写 Compose 文件时也可以加：

yaml复制services:
  app:
    image: nginx
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 256M

不过这里有个坑：docker compose 默认走的是 Docker Engine 的 swarm 模式资源限制逻辑，如果你是用 docker compose up 而不是 docker stack deploy，deploy 段的部分配置可能不生效。更稳妥的方式是在 Compose 文件顶层写 mem_limit 和 cpus（这是 Docker 兼容 Compose v2 的旧字段），或者干脆在 command 里用 --memory 参数指定。这个细节我查过很多遍，不同版本行为有差异，建议你自己在目标版本上验证一下。

7. 常见问题排查：从启动失败到网络异常的完整手册

7.1 启动类问题

问题一：Docker 服务起不来

bash复制sudo systemctl start docker

半天没反应，或者提示 start job failed。先看错误日志：

bash复制journalctl -u docker --no-pager -n 50

最常见的两个原因：

/etc/docker/daemon.json 里 JSON 格式写错了，某个逗号多了或者少了。用 docker run 的时候它会报 error parsing daemon.json。这个问题我犯过不下三次，每次都是因为手写 JSON 不够仔细。解决办法是用 Python 的 json.tool 校验：

bash复制python3 -m json.tool /etc/docker/daemon.json

iptables 规则冲突。Docker 默认会修改 iptables 来实现容器网络，如果你的系统里装了别的防火墙管理工具（比如 ufw 配置有问题），Docker 启动时会报 Failed to program NAT chain。清理一下 ufw 规则再启动 Docker 就好：

bash复制sudo ufw disable
sudo systemctl start docker
sudo ufw enable

问题二：拉取镜像超级慢或者卡住不动

前面说了配置 registry mirror。但如果你配置了镜像加速之后还是慢，可能是用的镜像源本身不稳定。这时候可以用 docker info 看看当前生效的 mirror 列表，然后用 curl 直接测试镜像源连通性。

另外提一个容易忽视的坑：daemon.json 里多个 mirror 是“依次尝试”的关系，不是“并行加速”的关系。 如果第一个 mirror 响应很慢但不报错，Docker 会一直等到它超时再去下一个。所以配置 mirror 的时候，把最稳定的放第一个。

7.2 网络与连接类问题

问题三：容器内应用连不上外网，但宿主机正常

这是典型的 DNS 问题。容器默认用的是 Docker 内置 DNS（127.0.0.11），它会转发到宿主机配置的 DNS。如果宿主机 DNS 配置有问题（比如你在 /etc/resolv.conf 里配了一个内网 DNS 地址，而这个内网 DNS 解析不了公网域名），容器就会断网。

排查方法：

bash复制docker exec <容器名> cat /etc/resolv.conf
docker exec <容器名> ping 8.8.8.8   # 通不通
docker exec <容器名> nslookup baidu.com  # DNS 解析正不正常

如果 IP 能通但域名解析不了，可以在启动容器时显式指定 DNS：

bash复制docker run -d --dns 223.5.5.5 --name myapp nginx

阿里云的 223.5.5.5 是国内比较稳定的公共 DNS。

问题四：端口映射后外部还是访问不到

端口映射正常，但 curl 宿主机IP:端口 不通。排查顺序：

bash复制# 1. 容器里服务本身通不通
docker exec <容器名> curl localhost:端口

# 2. 宿主机上访问容器 IP 通不通
curl 172.17.0.2:端口

# 3. 防火墙有没有放行
sudo ufw status
sudo iptables -L -n | grep 端口

大部分情况是第三层——Ubuntu 默认的 ufw 规则拦了端口。放行就行：

bash复制sudo ufw allow 端口/tcp

7.3 常见问题速查表

现象	可能原因	快速处理
`Cannot connect to the Docker daemon`	守护进程没启动或权限不够	`sudo systemctl start docker`，并把自己加入 docker 组
`Got permission denied`	当前用户不在 docker 组	`sudo usermod -aG docker $USER && newgrp docker`
`port is already allocated`	宿主机端口被占用	`sudo lsof -i :3306` 看进程，换端口或杀掉占用进程
镜像拉取超时	未配置镜像加速或加速源失效	修改 `/etc/docker/daemon.json` 的 registry-mirrors
容器一启动就退出	应用入口失败或资源不足	`docker logs <容器名>` 看错误日志
`no space left on device`	Docker 数据目录满了	`docker system prune -a`，或者迁移 Docker 数据目录到更大的磁盘
WSL2 环境下 Docker Desktop 无法启动	虚拟化未启用或内核太旧	`wsl --update`，BIOS 开启 VT-x

8. 容器数据管理和备份：别让你的数据随容器一起消失

8.1 理解 Docker 的层和卷

docker run 创建的容器，所有写入都会保存在容器的可写层里。容器删除后，这一层就没了。这就是为什么前面 MySQL 部署时必须挂载数据卷——数据卷是独立于容器生命周期的存储区域。

Docker 有三种常见的数据管理方式：

绑定挂载（bind mount）：把宿主机的某个目录挂到容器里。好处是路径直观，容器删了数据还在，你随时可以用编辑器直接看容器产生的文件。缺点是把宿主机目录和容器耦合在了一起。
命名卷（named volume）：由 Docker 管理的卷，路径在 /var/lib/docker/volumes/ 下。好处是不用关心具体路径，适合数据库这种不需要直接访问文件的场景。
tmpfs 挂载：数据存储在内存里，容器停止就清空，适合存放临时文件。

日常开发中，配置文件用绑定挂载（方便改动），数据库数据用命名卷（安全省心）。

8.2 备份与恢复的正确做法

MySQL 容器的备份，最靠谱的还是用 mysqldump：

bash复制docker exec mysql8 sh -c 'exec mysqldump -uroot -p"$MYSQL_ROOT_PASSWORD" --all-databases' > backup.sql

恢复：

bash复制cat backup.sql | docker exec -i mysql8 sh -c 'exec mysql -uroot -p"$MYSQL_ROOT_PASSWORD"'

注意恢复时 docker exec 必须带 -i（交互模式），因为要从标准输入读取 SQL 内容。这个细节很多人会漏，然后恢复的数据库是空的。

整体的备份策略：每天定时 mysqldump 到宿主机，再把 SQL 文件同步到远程存储。容器本身可以随时重建，真正的资产是数据。

9. 进阶：自定义 Dockerfile 和私有镜像仓库

9.1 一个 Nginx + Node.js 应用的 Dockerfile 示例

装好 Docker 之后，下一步自然是尝试构建自己的镜像。写一个最简单的 Node.js 应用 Dockerfile：

dockerfile复制FROM node:20-alpine

WORKDIR /app

COPY package*.json ./
RUN npm install --registry=https://registry.npm.taobao.org

COPY . .

EXPOSE 3000

CMD ["node", "server.js"]

构建：

bash复制docker build -t myapp:1.0 .

运行：

bash复制docker run -d -p 3000:3000 --name myapp myapp:1.0

这里有几个经验点：

基础镜像优先选 alpine 变体，体积只有标准镜像的几分之一，构建和拉取都快得多。
COPY 的顺序有讲究。把 package.json 单独复制再 npm install，可以利用 Docker 的层缓存机制——只要 package.json 没变，后面的 npm install 就不会重新执行，构建速度快很多。如果把 COPY . . 放在 npm install 之前，任何源码改动都会导致依赖重新安装。
.dockerignore 文件一定要写，把 node_modules、logs、.git 排除掉，否则它们会被一遍遍复制进构建上下文，拖慢构建效率。

9.2 用 Registry 做私有镜像管理

平时从 Docker Hub 拉镜像用 docker pull，但公司内部或者个人项目通常不想把镜像推到公网。这时候可以用 Docker Registry 或者 Harbor 搭私有仓库。

Docker Registry 是最轻量的方案：

bash复制docker run -d -p 5000:5000 --name registry --restart=always -v /data/registry:/var/lib/registry registry:2

打标签并推送：

bash复制docker tag myapp:1.0 localhost:5000/myapp:1.0
docker push localhost:5000/myapp:1.0

从另一台机器拉取时需要修改 /etc/docker/daemon.json 加入 insecure-registries（因为默认走 HTTPS 而私有仓库是 HTTP）：

json复制{
  "insecure-registries": ["192.168.1.100:5000"]
}

重启 Docker 后就能正常使用了。需要注意的是 localhost:5000 只在本机有效，跨机器访问一定用 IP 或域名。

10. Docker Compose 编排：从单容器到多服务协作

10.1 Compose 文件的核心结构

Compose 的核心价值在于把多个容器的启动逻辑写进一个 YAML 文件。前面 Redis 主从的例子已经展示了基本用法，这里再展开讲一下结构。

一个标准的 docker-compose.yml 分成几大块：services（定义哪些服务要启动）、networks（定义容器间的网络）、volumes（定义命名卷）。最核心的是 services 部分。

yaml复制services:
  web:
    build: .
    ports:
      - "8080:80"
    depends_on:
      - db
    environment:
      DB_HOST: db
      DB_PORT: 3306
    networks:
      - frontend

  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: rootpass
      MYSQL_DATABASE: mydb
    volumes:
      - dbdata:/var/lib/mysql
    networks:
      - backend

networks:
  frontend:
  backend:

volumes:
  dbdata:

这个例子展示了 Compose 的一个核心好设计：服务名可以直接当主机名用。 web 服务里通过 DB_HOST: db 就能连到 db 容器，因为 Compose 会自动在同一个默认网络中创建 DNS 记录。你不必再手动查容器 IP 了。

10.2 生命周期管理

日常最常用的 Compose 命令：

bash复制docker compose up -d          # 启动所有服务，-d 后台运行
docker compose ps             # 查看服务状态
docker compose logs -f        # 跟踪所有服务的日志
docker compose down           # 停止并删除所有容器（默认保留数据卷）
docker compose down -v        # 停止并删除容器，顺便把数据卷也删了（慎用！）
docker compose restart        # 重启所有服务

down -v 这一条我必须单独提醒：-v 会把数据卷一起删除，如果你在 Compose 里定义了 MySQL 数据卷，执行这条命令等于格式化数据库。我见过不止一个同事在测试环境执行 down -v 把线上数据删了的事故。 所以写进脚本里的时候，这条命令一定要加上人工确认。

10.3 Compose 和 Docker Engine 的关系

最后把关系理一遍：Docker Engine 是最底层的容器运行时，负责管理镜像、容器、网络；Docker Compose 是基于 Engine 的编排工具，让你用 YAML 声明多个容器之间的关系。新版 Docker 把 Compose 以插件形式集成进 Docker CLI，所以 docker compose 是当前推荐的用法。而独立的 docker-compose 二进制是旧版方案，如果你的系统里同时存在两个版本，以 docker compose version 输出的版本为准。

在 Ubuntu 上安装 Docker Engine 时，前面我特意加了 docker-compose-plugin 这个包，就是为了确保 docker compose 子命令可用。

写在最后

安装 Docker 本身不是难事，难的是理解它解决了什么问题、怎么把它嵌入你的工作流。我在多台 Ubuntu 机器上反复操作过，最大的体会是：Docker 的价值不在于炫技，而在于让环境复现这件事变得无比简单——同一个镜像，在任何机器上跑出来的行为是一致的，这才是我推荐大家都去学它的核心理由。

如果你是按照这篇指南装的，大概率能顺利跑起来。如果中途遇到什么奇怪的问题，不妨先看看 Docker 日志、确认内核模块、检查防火墙规则，大部分问题都能在这个链条里找到答案。等 Docker 用得顺手了，建议下一步好好研究 Compose 和 Dockerfile 的层缓存机制，这两个东西能让你从“会装”进阶到“会写”。