Docker 教程

Docker 数据卷

容器在便携性和隔离性方面提供了无与伦比的优势，使得应用程序能够在各种环境中保持一致地运行。在前面的章节中，我们已经详细探讨了如何将应用程序打包成 Docker 镜像并将其部署为容器，充分利用了 Docker 强大的运行时特性。

然而，容器在默认情况下有一个极其关键的特性：易失性（Ephemerality）。这意味着，一旦容器被删除，写入其可写层的所有数据都将永久丢失。

对于无状态（Stateless）应用来说，这完全不是问题；但对于几乎任何需要存储数据的现实世界应用——数据库、日志服务、内容管理系统 (CMS) 甚至简单的用户偏好设置——这种易失性构成了一个巨大的挑战。

为了解决这个问题，Docker 提供了持久化数据存储的机制，其中最常见也是官方最推荐的方法就是使用 Docker 数据卷 (Docker Volumes)。

1. 容器数据易失性的挑战

为了真正理解 Docker Volumes 的重要性，我们首先需要回顾一下容器默认是如何处理数据的，以及为什么这经常给有状态应用带来麻烦。

1.1 容器文件系统与“阅后即焚”

当你运行一个 Docker 容器时，它基于镜像启动一个只读的文件系统层。在这个只读层之上，Docker 会添加一个薄薄的、可写的容器层。 运行中的容器所做的任何更改——安装软件、创建文件、修改配置、写入日志或存储用户数据——都发生在这个可写层中。

这个可写层最致命的特征就是它的易失性。如果你只是停止 (stop) 一个容器，它的状态（包括可写层中的任何数据）会被保留，你稍后可以重新启动它。但是，如果你使用 docker rm 命令删除 (remove) 了这个容器，那个可写层就会被彻底抹除。在该容器文件系统内创建或修改的所有数据都将永远消失。

这种行为并非设计缺陷，而是刻意为之，它推崇了“不可变基础设施 (Immutable Infrastructure)”的理念，即容器是消耗品，可以被轻易替换，而无需担心其内部状态。

1.2 数据丢失的灾难性后果

考虑一下这种易失性对不同类型应用程序的后果：

  • 数据库 (例如 PostgreSQL, MySQL): 数据库将其所有数据（表、索引、用户记录）存储在文件系统中。如果一个数据库容器在没有做持久化配置的情况下被删除，你应用的所有数据都将无可挽回地丢失。在任何生产环境中，这都是绝对无法接受的事故。
  • 带有用户上传功能的 Web 服务器 (例如 Nginx 或跑着 WordPress 的 Apache): 如果用户将头像、图片或文档上传到运行在容器中的 Web 应用，一旦该容器被删除，所有上传的内容都会灰飞烟灭。
  • 日志和监控系统: 应用程序通常会生成日志。如果这些日志直接写入容器的文件系统且容器被删除，宝贵的诊断信息就会丢失。
  • 配置文件: 虽然配置通常可以在启动时提供给容器，但如果应用允许管理员通过 UI 修改设置，并将这些设置保存到容器内部的文件中，那么在容器被删除时，这些更改也会丢失。

1.3 假设场景：一个简单的计数器应用

想象你有一个简单的 Web 服务，它维护着一个单一的整数计数器。每次用户访问特定接口时，计数器加 1，并显示当前值。这个计数器的值存储在容器内的一个文件中。

  1. 你启动一个运行此服务的容器。
  2. 用户与它交互，计数器增加到了，比如 10。
  3. 然后你停止并删除了该容器。
  4. 当你从同一个镜像启动一个新容器时，计数器将重置为其初始值（例如 0 或 1），之前的状态 10 完全丢失了。

这凸显了一个根本问题：对于任何需要维护状态或在其直接生命周期之外存储数据的应用程序来说，容器默认的易失性是一个巨大的跨栏。

2. 什么是 Docker 数据卷 (Volumes)？

Docker Volumes（数据卷）是首选的机制，用于持久化 Docker 容器生成和使用的数据。与容器转瞬即逝的可写层不同，Volume 是宿主机文件系统上一个独立的、特殊的目录，由 Docker 统一管理。

2.1 核心特性与优势

  • 持久性 (Persistence): Volume 独立于任何特定的容器存在。即使你停止、移除或删除了所有使用该 Volume 的容器，Volume 及其数据依然安全地保存在宿主机上。你可以随后将这个 Volume 挂载到一个新容器上，数据将完好无损地可用。
  • 由 Docker 管理的存储: Docker 负责 Volume 的创建、挂载和管理。你不需要（通常也不应该）去关心 Volume 数据所在的具体宿主机物理路径（虽然如果需要的话你可以找到它）；Docker 把这些底层细节抽象化了。这使得 Volume 在不同的 Docker 宿主机之间具有极高的便携性，这与 Bind Mounts（绑定挂载，需要指定精确的宿主机路径）不同。
  • 数据共享 (Data Sharing): 多个容器可以安全地挂载并共享同一个 Volume。这对于不同服务需要访问同一数据集的场景非常有用，例如，一个 Web 服务器访问静态资源，而另一个独立的后台工作进程负责处理这些资源。
  • 备份与恢复 (Backup and Restore): 因为 Volumes 由 Docker 管理并且最终存在于宿主机上，备份它们的数据非常直接。你可以使用标准的宿主机系统备份工具，甚至用一个专门的容器来打包备份 Volume 的内容。
  • 性能 (Performance): Volumes 可以存储在各种存储后端上，通常比直接写入容器的可写层提供更好的性能，因为容器的写时复制 (Copy-on-Write) 文件系统会带来额外的开销。

2.2 Docker Volumes 的真实应用场景

  • 生产环境中的数据库: 这可以说是最关键的用例。在 Docker 容器中运行 MySQL、PostgreSQL、MongoDB 或 Redis 等数据库时，它的整个数据目录（MySQL 的 /var/lib/mysql，PostgreSQL 的 /var/lib/postgresql/data 等）必须挂载到一个 Docker Volume。这确保了：
    1. 如果数据库容器崩溃或需要更新版本，可以使用同一个 Volume 启动一个新容器，所有数据将立即恢复。
    2. 即使容器被有意删除，数据依然持久化存在。
    3. 数据库通过 Volume 直接访问宿主机文件系统，获得了极佳的 I/O 性能。
# 示例: 运行一个带有数据卷的 PostgreSQL 数据库
docker volume create pg_data
docker run -d \
  --name my_postgres \
  -e POSTGRES_PASSWORD=mysecretpassword \
  -v pg_data:/var/lib/postgresql/data \
  postgres:13

在这个例子中，pg_data 是由 Docker 管理的命名卷 (named volume)，而 /var/lib/postgresql/data 是 PostgreSQL 在容器内部存储数据的路径。

  • 内容管理系统 (CMS) 和用户生成的内容: 对于像 WordPress、Joomla 或允许用户上传（图片、文档、媒体文件）的自定义 Web 应用，这些文件必须被持久化。 WordPress 中的 wp-content 目录（包含主题、插件和上传的文件）应该被挂载到一个 Volume。
# 示例: 运行一个把内容目录挂载到数据卷的 WordPress
docker volume create wordpress_content
docker run -d \
  --name my_wordpress \
  -e WORDPRESS_DB_HOST=db_host \
  -e WORDPRESS_DB_USER=wordpress \
  -e WORDPRESS_DB_PASSWORD=secret \
  -e WORDPRESS_DB_NAME=wordpress \
  -v wordpress_content:/var/www/html/wp-content \
  wordpress:latest

在这里，wordpress_content 卷确保了即使用户频繁替换 WordPress 容器实例，他们上传的文章配图、安装的主题和插件也绝对不会丢失。

3. 玩转 Docker Volume 的生命周期

了解如何创建、检查、使用和删除 Docker Volumes 是管理持久化数据的基础。

3.1 创建 Volume

你可以使用 docker volume create 命令显式地创建一个命名卷。Docker 会在宿主机上找个好地方来管理这个卷的实际物理存储。

# 语法: docker volume create <卷名称>
docker volume create myapp_data

如果你在运行容器时指定了一个不存在的卷，Docker 会自动为你创建它。但在生产环境中，显式地提前创建卷是最佳实践，这能带来更好的控制和清晰度。

3.2 列出所有 Volumes

要查看你的系统上所有由 Docker 管理的卷，使用 docker volume ls。

docker volume ls

此命令将显示一个表格，列出 DRIVER（通常是 local）和 VOLUME NAME。

DRIVER    VOLUME NAME
local     myapp_data
local     pg_data
local     wordpress_content

3.3 检查 Volume 详情

要获取特定卷的详细信息，请使用 docker volume inspect <卷名称>。这个命令非常有用，特别是当你想知道这个卷的数据在宿主机物理磁盘上的具体位置时。

docker volume inspect myapp_data

输出将是一个 JSON 数组，包含创建时间、驱动程序等细节，其中最重要的是 Mountpoint。Mountpoint 就是卷的数据驻留在宿主机物理机器上的绝对路径。

[
    {
        "CreatedAt": "2023-10-27T10:00:00Z",
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/var/lib/docker/volumes/myapp_data/_data",
        "Name": "myapp_data",
        "Options": {},
        "Scope": "local"
    }
]

3.4 在容器中使用 Volume

要将 Volume 挂载到容器中，可以在 docker run 命令中使用 -v 或 --mount 标志。命名卷的基本语法是 卷名称:容器内路径。

# 语法: docker run -v <卷名称>:<容器内部路径> <镜像名称>
docker run -d \
  --name my_data_processor \
  -v myapp_data:/app/data \
  ubuntu:latest sleep infinity

在这个命令中：

  • myapp_data 指的是我们创建的命名卷（如果不存在，Docker 会自动创建）。
  • /app/data 是 容器内部 的路径，myapp_data 的内容将挂载到这里。
  • my_data_processor 容器写入 /app/data 的任何数据，都将被安全、持久地保存在宿主机的 myapp_data 卷中。

3.5 删除 Volume

当不再需要某个卷时，你可以使用 docker volume rm <卷名称> 将其删除。

极度危险： 删除卷是一个不可逆的破坏性操作。存储在该卷内的所有数据都将永久丢失。在删除卷之前，请务必确保你已经备份了所有关键数据！
# 删除特定的卷
docker volume rm myapp_data

要清理所有未使用的卷（即当前没有挂载到任何容器的卷），你可以使用 docker volume prune。这是一个释放磁盘空间的神器，但同样，使用时必须极其谨慎。

# 删除所有未使用的卷
docker volume prune

在执行清理之前，Docker 会提示你确认操作。

4. 综合实战演练

让我们通过两个具体的例子，直观地感受数据丢失的痛点以及 Volume 是如何力挽狂澜的。

实战一：拯救丢失的计数器应用

我们将创建一个简单的 Python 应用，它把计数器的值存进一个文件里。我们将先不使用 Volume 运行它看看数据是如何丢失的，然后使用 Volume 运行它来见证持久化。

1. 准备代码文件：
创建一个名为 counter_app 的目录。在里面创建 app.py:

# counter_app/app.py
import os
import time

COUNTER_FILE = "counter.txt" # 计数器存放的文件名

def read_counter():
    """从文件中读取当前计数器值"""
    if os.path.exists(COUNTER_FILE):
        with open(COUNTER_FILE, 'r') as f:
            try:
                return int(f.read().strip())
            except ValueError:
                return 0 
    return 0 

def write_counter(value):
    """将计数器值写入文件"""
    with open(COUNTER_FILE, 'w') as f:
        f.write(str(value))

def main():
    current_counter = read_counter()
    print(f"[{time.ctime()}] 启动，当前计数器为: {current_counter}")
    current_counter += 1
    write_counter(current_counter)
    print(f"[{time.ctime()}] 计数器加 1，变为: {current_counter}")
    print(f"[{time.ctime()}] 计数器值已保存至 {COUNTER_FILE}")
    time.sleep(5) # 模拟一点工作量，保持容器存活几秒

if __name__ == "__main__":
    main()

创建对应的 Dockerfile:

# counter_app/Dockerfile
FROM python:3.9-slim-buster
WORKDIR /app
COPY app.py .
CMD ["python", "app.py"]

2. 构建镜像：
在终端进入 counter_app 目录执行：

docker build -t persistent-counter-app .

3. 反面教材：不使用 Volume（眼睁睁看着数据丢失）：

# 运行第一个容器
docker run --name counter1 persistent-counter-app
# 你会看到输出: 启动，当前计数器为: 0  =>  计数器加 1，变为: 1

# 删除容器（模拟服务升级或故障重启）
docker rm counter1

# 从同一镜像启动一个 *新* 容器
docker run --name counter2 persistent-counter-app
# 你会看到输出又变回了: 启动，当前计数器为: 0  =>  计数器加 1，变为: 1
# 悲剧发生了，之前的计数器值 (1) 因为容器被删而永远消失了！

4. 成功示范：使用 Volume（见证持久化的力量）：

首先，创建一个 Volume。

docker volume create counter_volume

现在，运行应用，并将 counter_volume 挂载到容器内的 /app 目录。这意味着 Python 脚本在 /app 下创建的 counter.txt 文件实际上会写到 Volume 里。

# 第一次携带 Volume 运行容器
docker run --name counter_persistent_1 -v counter_volume:/app persistent-counter-app
# 输出: 启动，当前计数器为: 0  =>  计数器加 1，变为: 1

# 删除这个容器 (但不用担心，Volume 和里面的数据安然无恙！)
docker rm counter_persistent_1

# 启动一个 *新* 容器，挂载 *同一个* Volume
docker run --name counter_persistent_2 -v counter_volume:/app persistent-counter-app
# 魔法出现！输出显示: 启动，当前计数器为: 1  =>  计数器加 1，变为: 2
# 成功了！数据跨越了容器的生死，存活了下来。

# 再来一次
docker rm counter_persistent_2
docker run --name counter_persistent_3 -v counter_volume:/app persistent-counter-app
# 输出: 启动，当前计数器为: 2  =>  计数器加 1，变为: 3

你可以通过 inspect 找到这笔数据的藏身之处：

docker volume inspect counter_volume
# 找到 "Mountpoint" 字段。
# 例如: /var/lib/docker/volumes/counter_volume/_data
# 在你的宿主机上（Linux/macOS）使用 cat 命令查看：
# cat /var/lib/docker/volumes/counter_volume/_data/counter.txt
# 你会亲眼看到里面赫然写着 "3"。

实战二：持久化 Nginx 访问日志

Nginx Web 服务器会源源不断地生成访问日志 (access.log) 和错误日志。让我们确保即使 Nginx 容器被扬了，日志也完好无损。

1. 为日志创建一个 Volume:

docker volume create nginx_logs

2. 带着 Volume 运行 Nginx:
把 nginx_logs 卷挂载到 Nginx 容器内专门存放日志的 /var/log/nginx 目录下。

docker run -d \
  --name my_nginx_server \
  -p 8080:80 \
  -v nginx_logs:/var/log/nginx \
  nginx:latest

3. 制造点日志数据:
打开浏览器狂刷几次 http://localhost:8080，看到 Nginx 欢迎页就意味着访问日志已经生成了。

4. 在宿主机上“偷窥”日志:
先找到 nginx_logs 的物理挂载点：

docker volume inspect nginx_logs
# 记下 Mountpoint 路径

直接在宿主机上查看文件：

# cd 刚才记下的 Mountpoint 路径
# cat access.log
# 你会看到你刚才用浏览器访问留下的记录！

5. “杀”掉容器，验证持久化:

docker rm -f my_nginx_server

即使 my_nginx_server 灰飞烟灭，nginx_logs 卷和里面的 access.log 依然静静躺在你的宿主机硬盘上。下一次你启动一个新的 Nginx 容器并挂上这个卷，新的日志会继续追加在旧日志后面。