06-Docker存储与数据持久化

Docker存储与数据持久化

本文是Docker专栏的第六篇文章,将全面深入地讲解Docker存储体系、存储驱动、数据卷、绑定挂载、tmpfs挂载、数据卷进阶操作、Dockerfile存储配置、数据库持久化方案、存储安全与备份策略以及故障排查等全部知识。全文超过3万字,包含大量实战案例与代码示例,适合有一定Docker基础的开发者深入学习和参考。

前言

在Docker的世界里,容器的生命周期通常是短暂的。一个容器可以被创建、启动、停止、删除,而当容器被删除时,容器内部写入的所有数据也会随之消失。这种"临时性"是容器设计的核心特征之一,它使得容器可以随时被重建和替换,但也带来了一个严峻的挑战——如何持久化保存数据?

想象这样一个场景:你运行了一个MySQL容器,业务系统持续写入数据。某天因为配置变更需要删除并重建容器,结果所有数据库数据全部丢失。又或者,你在开发环境中修改了代码,但因为容器的隔离性,修改无法反映到容器内运行的应用中。这些问题都指向同一个核心概念——Docker存储与数据持久化。

Docker提供了多种存储机制来解决这些问题,包括Volume(数据卷)、Bind Mount(绑定挂载)和tmpfs Mount(临时文件系统挂载)。同时,Docker底层还依赖存储驱动(Storage Driver)来管理镜像层和容器可写层。理解这些机制的原理和使用方法,是每一位Docker使用者的必修课。

本文将从底层原理出发,全面讲解Docker存储的方方面面,帮助你在生产环境中正确、高效地管理数据。

第一章 Docker存储体系概览

1.1 容器存储的挑战

1.1.1 容器文件系统的临时性

Docker容器基于镜像运行,而镜像是只读的。当容器启动时,Docker会在镜像的最顶层添加一个可写层(Writable Layer),也称为容器层(Container Layer)。所有的写操作——创建文件、修改文件、删除文件——都发生在这个可写层中。

这个设计带来了一个根本性的问题:当容器被删除时,可写层也会被删除,所有写入的数据都会丢失。

让我们通过一个简单的实验来验证这一点:

# 启动一个Ubuntu容器,在容器内创建一个文件
docker run -d –name test-container ubuntu:22.04 sleep 3600

# 进入容器,创建一个测试文件
docker exec test-container bash -c 'echo "Hello Docker Storage" > /tmp/test.txt'

# 查看文件内容
docker exec test-container cat /tmp/test.txt
# 输出: Hello Docker Storage

# 删除容器
docker rm -f test-container

# 重新启动一个同名容器,尝试查看文件
docker run -d –name test-container ubuntu:22.04 sleep 3600
docker exec test-container cat /tmp/test.txt
# 输出: cat: /tmp/test.txt: No such file or directory

如上所示,文件已经丢失。这是因为新容器拥有全新的可写层,与之前的容器没有任何关联。

1.1.2 数据丢失带来的问题

容器存储的临时性在实际应用中会导致多种问题:

1.1.3 为什么不能直接在容器中存储数据

除了数据丢失的问题外,直接在容器可写层中存储数据还有以下缺点:

• 性能开销:存储驱动使用写时复制(Copy-on-Write)机制,对可写层的写操作有额外的性能开销。
• 存储效率低:可写层与镜像层分离,可能导致存储空间浪费。
• 不可移植:容器内的数据与容器绑定,无法轻松迁移到其他主机或其他容器。
• 难以备份:容器可写层的数据难以单独备份,通常需要借助docker commit生成新镜像,但这不是数据持久化的正确方式。

1.2 Docker存储三大方式: Volume、Bind Mount、tmpfs

为了解决容器存储的临时性问题,Docker提供了三种数据持久化机制:

1.2.1 Volume(数据卷)

Volume是Docker管理的存储方式,由Docker守护进程创建和管理,存储在宿主机的特定目录下(默认为/var/lib/docker/volumes/)。数据卷独立于容器的生命周期,即使容器被删除,数据卷中的数据依然存在。

主要特点:

• 由Docker管理,存储位置固定且可预测
• 支持命名数据卷和匿名数据卷
• 可以在多个容器之间共享
• 支持数据卷驱动,可以扩展到远程存储(NFS、云存储等)
• 不受容器可写层性能影响,读写性能接近宿主机原生文件系统

1.2.2 Bind Mount(绑定挂载)

Bind Mount将宿主机上的一个绝对路径直接挂载到容器中。容器可以直接读写宿主机上的文件,适合开发环境中的代码热重载等场景。

主要特点:

• 依赖宿主机的目录结构,需要指定绝对路径
• 容器可以直接修改宿主机上的文件,反之亦然
• 适合开发环境,如代码挂载、配置文件挂载
• 无法通过docker volume命令管理
• 在不同环境中的行为可能不一致(路径依赖)

1.2.3 tmpfs Mount(临时文件系统挂载)

tmpfs挂载将数据存储在宿主机的内存中,不会写入磁盘。适合存储敏感信息(如密钥)或临时缓存数据。

主要特点:

• 数据存储在内存中,读写速度极快
• 容器停止后数据消失,不会持久化到磁盘
• 适合存储敏感信息,避免敏感数据落盘
• 只能在Linux上使用
• 受可用内存大小限制

1.2.4 三种存储方式对比

1.3 存储驱动(Storage Driver)与数据卷的区别

许多Docker初学者容易混淆"存储驱动"和"数据卷"这两个概念。它们虽然都与存储相关,但在功能和作用层面完全不同。

1.3.1 存储驱动

存储驱动(Storage Driver)负责管理镜像层(Image Layers)和容器可写层(Container Writable Layer)。它处理的是Docker镜像的分层存储、写时复制(Copy-on-Write)等底层机制。

• 作用对象:镜像层和容器可写层
• 关注点:如何高效地存储和叠加镜像层,如何处理容器的读写操作
• 与数据持久化的关系:存储驱动管理的数据是临时的(容器删除即丢失)
• 配置方式:在/etc/docker/daemon.json中通过storage-driver参数配置
• 常见驱动:overlay2、aufs、devicemapper、btrfs、zfs、vfs

1.3.2 数据卷

数据卷(Volume)是Docker提供的数据持久化机制,用于将数据存储在容器可写层之外。

• 作用对象:需要持久化的数据
• 关注点:如何在容器生命周期之外保存数据
• 与存储驱动的关系:数据卷绕过存储驱动,直接写入宿主机文件系统
• 配置方式:在docker run时通过-v或–mount参数指定
• 管理命令:docker volume create/ls/rm/inspect/prune

1.3.3 一图理解两者关系

┌─────────────────────────────────────────────────────┐
│ Docker 容器 │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 容器可写层 (存储驱动管理) │ │
│ │ ┌───────────────────────────────────────────┐ │ │
│ │ │ 镜像层N (只读) │ │ │
│ │ ├───────────────────────────────────────────┤ │ │
│ │ │ 镜像层… (只读) │ │ │
│ │ ├───────────────────────────────────────────┤ │ │
│ │ │ 镜像层1 (只读) │ │ │
│ │ └───────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────┘ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 数据卷挂载点 (绕过存储驱动,直接写入宿主机) │ │
│ └─────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ 宿主机 │
│ /var/lib/docker/volumes/ ← 数据卷存储位置 │
│ /var/lib/docker/overlay2/ ← 存储驱动管理区域 │
└─────────────────────────────────────────────────────┘

简单来说:存储驱动管理"容器的临时数据",数据卷管理"需要持久化的数据"。数据卷绕过了存储驱动,直接在宿主机文件系统上进行读写,因此性能更好且数据更安全。

1.4 Docker存储架构总览

Docker的存储架构可以从多个层面来理解:

1.4.1 整体架构

┌──────────────────────────────────────────────────────────┐
│ Docker 守护进程 (dockerd) │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ 镜像管理模块 │ │ 容器管理模块 │ │ 数据卷管理模块 │ │
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────────────────────────────────────────────────┐│
│ │ 存储驱动 (Storage Driver) ││
│ │ overlay2 / aufs / devicemapper / btrfs / zfs ││
│ └──────────────────────────────────────────────────────┘│
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ /var/lib/ │ │ /var/lib/ │ │ /var/lib/ │ │
│ │ docker/ │ │ docker/ │ │ docker/ │ │
│ │ overlay2/ │ │ containers/ │ │ volumes/ │ │
│ │ (镜像层+可写层)│ │ (容器配置日志) │ │ (数据卷) │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────┐│
│ │ 数据卷驱动 (Volume Driver) ││
│ │ local / nfs / block / 第三方插件 ││
│ └──────────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────┐
│ 宿主机文件系统 │
│ ext4 / xfs / btrfs / zfs / nfs │
└──────────────────────────────────────────────────────────┘

1.4.2 关键目录说明

Docker在宿主机上的默认存储目录为/var/lib/docker/,其中包含以下重要子目录:

可以通过以下命令查看Docker的根目录:

# 查看Docker信息中的根目录
docker info | grep "Docker Root Dir"
# 输出: Docker Root Dir: /var/lib/docker

# 查看各目录的磁盘使用情况
sudo du -sh /var/lib/docker/*

1.4.3 数据流向

当容器需要进行文件读写时,数据的流向取决于文件所在的层级:

1.5 容器可写层与数据持久化层的关系

1.5.1 容器可写层的工作机制

每个容器启动时,Docker会为其创建一个可写层。这个可写层叠加在镜像的所有只读层之上,形成一个统一的文件系统视图(通过联合文件系统UnionFS实现)。

# 查看容器的可写层信息(以overlay2为例)
docker inspect <container_id> | grep -A 10 "GraphDriver"

# 输出示例:
# "GraphDriver": {
# "Data": {
# "LowerDir": "/var/lib/docker/overlay2/…/diff",
# "MergedDir": "/var/lib/docker/overlay2/…/merged",
# "UpperDir": "/var/lib/docker/overlay2/…/diff",
# "WorkDir": "/var/lib/docker/overlay2/…/work"
# },
# "Name": "overlay2"
# }

其中:

• LowerDir:镜像层(只读),可能有多个
• UpperDir:容器可写层
• MergedDir:合并后的统一视图
• WorkDir:overlay内部使用的工作目录

1.5.2 写时复制(Copy-on-Write)机制

写时复制是容器存储的核心机制。当容器需要修改一个存在于镜像层中的文件时,Docker不会直接修改镜像层(因为镜像是只读的),而是:

这个机制确保了:

• 镜像层保持不变,多个容器可以共享同一个镜像
• 每个容器有自己的修改副本,互不影响
• 只有被修改的文件才会被复制,节省存储空间

# 演示写时复制
# 启动容器
docker run -d –name cow-test ubuntu:22.04 sleep 3600

# 查看可写层的大小(初始为很小)
sudo du -sh $(docker inspect cow-test –format '{{.GraphDriver.Data.UpperDir}}')
# 输出: 12K /var/lib/docker/overlay2/xxx/diff

# 在容器中修改一个文件
docker exec cow-test bash -c 'echo "modified" >> /etc/hostname'

# 再次查看可写层大小(增大了)
sudo du -sh $(docker inspect cow-test –format '{{.GraphDriver.Data.UpperDir}}')
# 输出: 16K /var/lib/docker/overlay2/xxx/diff

# 清理
docker rm -f cow-test

1.5.3 数据持久化层的角色

数据持久化层(数据卷、绑定挂载)与容器可写层是完全独立的:

# 演示数据卷挂载点覆盖
# 使用nginx镜像,其默认网站根目录为/usr/share/nginx/html
docker run -d –name nginx-test -v nginx-html:/usr/share/nginx/html nginx:latest

# 查看数据卷中的内容(会包含nginx默认的欢迎页面,因为首次挂载时从镜像复制)
docker exec nginx-test ls /usr/share/nginx/html
# 输出: 50x.html index.html

# 修改数据卷中的内容
docker exec nginx-test bash -c 'echo "<h1>Custom Content</h1>" > /usr/share/nginx/html/index.html'

# 删除容器
docker rm -f nginx-test

# 重新创建容器并挂载同一个数据卷
docker run -d –name nginx-test2 -v nginx-html:/usr/share/nginx/html nginx:latest

# 验证数据仍然存在
docker exec nginx-test2 cat /usr/share/nginx/html/index.html
# 输出: <h1>Custom Content</h1>

# 清理
docker rm -f nginx-test2
docker volume rm nginx-html

这个例子清楚地展示了数据卷如何绕过容器可写层,实现数据的持久化存储。

第二章 存储驱动详解

2.1 存储驱动的作用(管理镜像层和容器可写层)

存储驱动是Docker存储架构的核心组件,负责管理镜像层(Image Layers)和容器可写层(Container Writable Layer)。它的主要职责包括:

2.1.1 镜像层管理

Docker镜像由多个只读层(Layer)组成,每一层对应Dockerfile中的一条指令。存储驱动负责:

• 层叠加:将多个只读层叠加成一个统一的文件系统视图
• 层共享:多个镜像可以共享相同的底层,节省存储空间
• 层缓存:构建镜像时利用缓存层加速构建过程

# 每条指令都会创建一个新的镜像层
FROM ubuntu:22.04 # 基础层(来自ubuntu镜像)
RUN apt-get update # 新层
RUN apt-get install -y nginx # 新层
COPY index.html /var/www/html/ # 新层
CMD ["nginx", "-g", "daemon off;"] # 新层(元数据层)

# 查看镜像的分层结构
docker history nginx:latest

# 输出示例:
# IMAGE CREATED CREATED BY SIZE
# 605c77e624dd 2 weeks ago /bin/sh -c #(nop) CMD ["nginx" "g" "daemon… 0B
# 8140c0a4wr2e 2 weeks ago /bin/sh -c #(nop) STOPSIGNAL SIGQUIT 0B
# 41a1a8e923e3 2 weeks ago /bin/sh -c #(nop) EXPOSE 80 0B
# 12ad5138f5b1 2 weeks ago /bin/sh -c #(nop) ENTRYPOINT ["/docker-entr… 0B
# …

2.1.2 容器可写层管理

当容器启动时,存储驱动会在镜像层之上添加一个可写层:

• 写操作处理:所有写操作都记录在可写层中
• 写时复制:修改镜像层文件时,先复制到可写层再修改
• 删除操作处理:在可写层中标记文件为已删除(whiteout文件)

2.1.3 存储驱动必须实现的核心功能

一个完整的存储驱动需要实现以下核心功能:

2.2 overlay2驱动详解

2.2.1 overlay2简介

overlay2是Docker当前推荐的存储驱动,它是OverlayFS的用户空间实现。OverlayFS是Linux内核3.18版本引入的联合文件系统(Union Filesystem),overlay2是其第二代实现,支持多层lowerdir叠加(最多128层),比第一代overlay驱动更高效。

overlay2的优势:

• 内核原生支持,性能优异
• 支持多层叠加(最多128层),无需为每层创建单独的挂载
• 页缓存共享,内存利用率高
• 稳定性好,适合生产环境
• Docker官方推荐

系统要求:

• Linux内核4.0或更高版本(推荐4.0+)
• 文件系统支持:ext4、xfs(需要ftype=1)、btrfs等

2.2.2 overlay2工作原理

overlay2将文件系统分为三层:

此外还有一个WorkDir(工作目录),用于overlayfs内部操作(如原子性操作)。

容器视角(MergedDir)
┌───────────────────────┐
│ /usr/share/nginx/ │
│ /etc/nginx/ │
│ /var/log/nginx/ │
│ … │
└───────────┬───────────┘
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ UpperDir │ │ LowerDir │ │ LowerDir │
│ (可写层) │ │ (镜像层3) │ │ (镜像层2) │
│ 容器修改 │ │ COPY指令 │ │ RUN指令 │
└─────────────┘ └─────────────┘ └─────────────┘
│
▼
┌─────────────┐
│ LowerDir │
│ (镜像层1) │
│ FROM指令 │
└─────────────┘

2.2.3 overlay2的文件操作机制

读取文件:

修改文件(写时复制):

删除文件:

创建目录:

2.2.4 查看overlay2的实际结构

# 启动一个容器
docker run -d –name overlay-test nginx:latest

# 查看容器的存储驱动信息
docker inspect overlay-test –format '{{json .GraphDriver.Data}}' | python3 -m json.tool

# 输出示例:
# {
# "LowerDir": "/var/lib/docker/overlay2/abc…/diff:/var/lib/docker/overlay2/def…/diff:…",
# "MergedDir": "/var/lib/docker/overlay2/xyz…/merged",
# "UpperDir": "/var/lib/docker/overlay2/xyz…/diff",
# "WorkDir": "/var/lib/docker/overlay2/xyz…/work"
# }

# 查看合并后的文件系统视图
sudo ls $(docker inspect overlay-test –format '{{.GraphDriver.Data.MergedDir}}')/

# 查看可写层(初始为空或很小)
sudo ls -la $(docker inspect overlay-test –format '{{.GraphDriver.Data.UpperDir}}')/

# 在容器中修改文件
docker exec overlay-test bash -c 'echo "test" > /tmp/overlay-test.txt'

# 再次查看可写层,可以看到新创建的文件
sudo ls -la $(docker inspect overlay-test –format '{{.GraphDriver.Data.UpperDir}}')/tmp/

# 清理
docker rm -f overlay-test

2.2.5 overlay2的whiteout文件

# 演示whiteout机制
docker run -d –name whiteout-test ubuntu:22.04 sleep 3600

# 获取UpperDir
UPPER=$(docker inspect whiteout-test –format '{{.GraphDriver.Data.UpperDir}}')

# 删除容器中的一个文件(该文件来自镜像层)
docker exec whiteout-test rm /etc/hostname

# 查看UpperDir中的whiteout文件
sudo ls -la $UPPER/etc/
# 可以看到一个名为 hostname 的字符设备文件(whiteout)
# crwxr-xr-x 1 root root 0, 0 … hostname

# 清理
docker rm -f whiteout-test

2.3 aufs驱动详解

2.3.1 aufs简介

aufs(Advanced Multi-Layered Unification Filesystem)是Docker早期使用的存储驱动之一,也是最早被Docker支持的联合文件系统。aufs功能强大,支持多层叠加,但由于未能被Linux内核主线接受,目前使用较少。

aufs的特点:

• 支持多层叠加(最多127层)
• 功能成熟稳定
• 未被Linux内核主线接受,需要额外安装
• 在Ubuntu/Debian上较常见,在其他发行版上可能不可用
• Docker已不再推荐使用aufs

2.3.2 aufs工作原理

aufs的工作原理与overlay2类似,都是通过联合挂载实现多层叠加:

容器视角
┌──────────┐
│ /usr/ │
│ /etc/ │
│ /var/ │
└────┬─────┘
│
┌───────────────┼───────────────┐
│ │ │
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│ 可写层 │ │ 只读层3 │ … │ 只读层1 │
│(container)│ │(image) │ │(base) │
└────────┘ └────────┘ └────────┘

与overlay2不同的是:

• aufs使用aufs挂载类型,而非overlay
• aufs的whiteout实现方式不同(使用.wh.前缀文件)
• aufs支持更多的分支策略(round-robin等)

2.3.3 aufs的目录结构

# aufs驱动下,容器的存储目录
# /var/lib/docker/aufs/diff/<container_id>/ → 可写层
# /var/lib/docker/aufs/diff/<layer_id>/ → 镜像层
# /var/lib/docker/aufs/mnt/<container_id>/ → 合并视图
# /var/lib/docker/aufs/layers/<container_id> → 层依赖关系

2.3.4 为什么aufs逐渐被淘汰

2.4 devicemapper驱动详解

2.4.1 devicemapper简介

devicemapper是Linux内核提供的设备映射框架,Docker利用它实现了基于块设备的存储驱动。与overlay2和aufs基于文件的联合文件系统不同,devicemapper工作在块设备层面。

devicemapper的特点:

• 基于块设备,不依赖文件系统
• 使用精简配置(Thin Provisioning)机制
• 在CentOS/RHEL上曾是默认驱动
• 性能不如overlay2
• 配置复杂,容易出问题
• Docker已不再推荐

2.4.2 devicemapper的两种模式

2.4.3 devicemapper工作原理

┌─────────────────────────────────┐
│ ThinPool(精简池) │
│ ┌───────────┐ ┌───────────┐ │
│ │ Data Device│ │Metadata Dev│ │
│ │ (数据块设备) │ │(元数据设备) │ │
│ └───────────┘ └───────────┘ │
└─────────────────────────────────┘
│
┌─────────┼─────────┐
│ │ │
▼ ▼ ▼
┌────────┐┌────────┐┌────────┐
│容器可写层││镜像层3 ││镜像层1 │
│(Thin Vol)││(Snap) ││(Base) │
└────────┘└────────┘└────────┘

devicemapper使用精简配置(Thin Provisioning)来管理存储空间:

• 基础设备(Base Device):一个精简池(ThinPool),所有镜像层和容器层都从中分配空间
• 镜像层:作为精简池中的基础卷(Base Volume)
• 容器可写层:作为镜像层的快照(Snapshot)
• 写时复制:在块设备层面实现,修改时复制对应的块

2.4.4 配置direct-lvm模式

// /etc/docker/daemon.json
{
"storage-driver": "devicemapper",
"storage-opts": [
"dm.directlvm_device=/dev/sdb",
"dm.thinp_percent=95",
"dm.thinp_metapercent=1",
"dm.thinp_autoextend_threshold=80",
"dm.thinp_autoextend_percent=20",
"dm.directlvm_device_force=false"
]
}

# 配置完成后重启Docker
sudo systemctl restart docker

# 验证配置
docker info | grep -A 10 "Storage Driver"
# 输出应显示:
# Storage Driver: devicemapper
# Pool Name: docker-thinpool
# Pool Blocksize: 65.54kB
# …

2.5 btrfs驱动详解

2.5.1 btrfs简介

btrfs(B-tree file system,通常发音为"Butter FS"或"B-tree FS")是现代的写时复制文件系统,Docker可以利用btrfs的子卷(Subvolume)和快照(Snapshot)功能来实现存储驱动。

btrfs的特点:

• 基于子卷和快照,原生支持写时复制
• 支持透明压缩,节省存储空间
• 支持子卷配额,可以限制容器存储大小
• 适合大量小文件场景
• 稳定性曾受质疑,但在不断改善
• 需要将/var/lib/docker格式化为btrfs文件系统

2.5.2 btrfs工作原理

┌─────────────────────────────────┐
│ btrfs 文件系统 │
│ │
│ ┌───────────────────────────┐ │
│ │ /var/lib/docker/btrfs/ │ │
│ │ │ │
│ │ ┌─────────┐ ┌─────────┐ │ │
│ │ │ 子卷:容器 │ │ 子卷:镜像 │ │ │
│ │ │ (可写) │ │ (只读) │ │ │
│ │ │ (快照) │ │ │ │ │
│ │ └─────────┘ └─────────┘ │ │
│ │ │ │
│ └───────────────────────────┘ │
│ │
│ 透明压缩 │ 快照 │ 配额 │ 去重 │
└─────────────────────────────────┘

• 镜像层:btrfs子卷(只读)
• 容器可写层:镜像层子卷的快照(可读写)
• 写时复制:btrfs原生支持,在文件系统层面实现

2.5.3 配置btrfs驱动

# 1. 格式化设备为btrfs
sudo mkfs.btrfs /dev/sdb

# 2. 挂载到/var/lib/docker
sudo mkdir -p /var/lib/docker
sudo mount /dev/sdb /var/lib/docker

# 3. 配置Docker使用btrfs
# /etc/docker/daemon.json
# {
# "storage-driver": "btrfs"
# }

# 4. 重启Docker
sudo systemctl restart docker

# 5. 验证
docker info | grep "Storage Driver"
# 输出: Storage Driver: btrfs

2.5.4 btrfs的配额管理

# 启用配额
sudo btrfs quota enable /var/lib/docker

# 设置子卷配额(限制为10GB)
sudo btrfs qgroup limit 10G /var/lib/docker/btrfs/subvolumes/<container_id>

# 查看配额使用情况
sudo btrfs qgroup show /var/lib/docker

2.6 zfs驱动详解

2.6.1 zfs简介

ZFS(Zettabyte File System)是由Sun Microsystems开发的高级文件系统,以其数据完整性、快照功能和海量存储支持而闻名。Docker可以利用ZFS的数据集(Dataset)和快照(Snapshot)功能实现存储驱动。

zfs的特点:

• 高级文件系统,支持数据完整性校验
• 原生快照和克隆功能
• 内置压缩和去重
• ARC(Adaptive Replacement Cache)缓存,性能优异
• 内存占用较高
• 许可证(CDDL)与Linux内核(GPL)兼容性存在争议

2.6.2 zfs工作原理

┌─────────────────────────────────┐
│ zfs 存储池 (zpool) │
│ │
│ ┌───────────────────────────┐ │
│ │ docker/zfs (文件系统) │ │
│ │ │ │
│ │ ┌─────────┐ ┌─────────┐ │ │
│ │ │数据集:容器│ │数据集:镜像│ │ │
│ │ │ (快照) │ │ (基础) │ │ │
│ │ └─────────┘ └─────────┘ │ │
│ │ │ │
│ └───────────────────────────┘ │
│ │
│ 数据完整性 │ 快照 │ 压缩 │ 缓存 │
└─────────────────────────────────┘

• 镜像层:ZFS数据集(只读快照)
• 容器可写层:镜像层的克隆(Clone)
• 写时复制:ZFS原生支持

2.6.3 配置zfs驱动

# 1. 安装ZFS
sudo apt-get install zfsutils-linux # Ubuntu/Debian
# 或
sudo yum install zfs # CentOS/RHEL

# 2. 创建zpool
sudo zpool create -f zpool-docker /dev/sdb

# 3. 创建docker数据集
sudo zfs create zpool-docker/docker

# 4. 设置/var/lib/docker挂载点
sudo zfs set mountpoint=/var/lib/docker zpool-docker/docker

# 5. 配置Docker使用zfs
# /etc/docker/daemon.json
# {
# "storage-driver": "zfs"
# }

# 6. 重启Docker
sudo systemctl restart docker

# 7. 验证
docker info | grep "Storage Driver"
# 输出: Storage Driver: zfs

2.6.4 zfs配额和压缩

# 设置容器数据集配额
sudo zfs set quota=10G zpool-docker/docker/<container_id>

# 启用压缩
sudo zfs set compression=lz4 zpool-docker/docker

# 查看压缩效果
sudo zfs get compressratio zpool-docker/docker

2.7 vfs驱动详解

2.7.1 vfs简介

vfs(Virtual File System)是Docker最简单的存储驱动,它不使用任何联合文件系统技术,而是通过简单的文件复制来实现层的叠加。

vfs的特点:

• 实现简单,兼容性最好
• 没有任何写时复制优化,每个层都是完整的文件复制
• 磁盘空间占用极大
• 性能最差
• 不推荐在生产环境使用
• 适合测试环境或不支持其他驱动的系统

2.7.2 vfs工作原理

容器视角
┌──────────┐
│ /usr/ │
│ /etc/ │
│ /var/ │
└────┬─────┘
│
┌────┴────┐
│ 可写层 │ ← 完整复制镜像层的所有文件
└────┬────┘
┌────┴────┐
│ 镜像层3 │ ← 完整复制前一层的所有文件
└────┬────┘
┌────┴────┐
│ 镜像层2 │ ← 完整复制前一层的所有文件
└────┬────┘
┌────┴────┐
│ 镜像层1 │ ← 基础层
└─────────┘

在vfs驱动中,每一层都是完整复制前一层的所有文件,然后在其基础上进行修改。这意味着:

• 创建容器时会复制整个镜像的所有文件
• 磁盘空间占用是叠加的(不是共享的)
• 没有层共享机制

2.7.3 何时使用vfs

# vfs驱动通常在不支持其他驱动的环境中使用
# 例如某些NAS环境或受限的容器运行时

# 配置vfs驱动
# /etc/docker/daemon.json
# {
# "storage-driver": "vfs"
# }

# 重启Docker
sudo systemctl restart docker

2.8 存储驱动对比表

2.9 如何选择和切换存储驱动

2.9.1 选择存储驱动的原则

2.9.2 查看当前存储驱动

# 查看Docker信息
docker info | grep -i "storage"

# 输出示例:
# Storage Driver: overlay2
# Backing Filesystem: extfs
# Supports d_type: true
# Native Overlay Diff: true
# userxattr: false

2.9.3 切换存储驱动

重要警告:切换存储驱动会导致已有的镜像和容器无法使用!切换前请备份所有重要数据!

# 1. 停止Docker服务
sudo systemctl stop docker

# 2. 备份现有数据(可选但强烈推荐)
sudo cp -au /var/lib/docker /var/lib/docker.backup

# 3. 编辑Docker配置
sudo tee /etc/docker/daemon.json <<'EOF'
{
"storage-driver": "overlay2"
}
EOF

# 4. 删除旧数据(谨慎操作!)
# 如果是全新切换,可以删除旧数据
# sudo rm -rf /var/lib/docker

# 5. 启动Docker服务
sudo systemctl start docker

# 6. 验证新的存储驱动
docker info | grep "Storage Driver"

# 7. 重新拉取镜像(因为旧镜像在新驱动下不可用)
docker pull nginx:latest

2.9.4 各发行版默认存储驱动

2.10 存储驱动配置

2.10.1 daemon.json中的存储驱动配置

// /etc/docker/daemon.json 完整配置示例
{
"storage-driver": "overlay2",
"storage-opts": [
"overlay2.override_kernel_check=true"
],
"data-root": "/var/lib/docker",
"max-concurrent-downloads": 10,
"max-concurrent-uploads": 5,
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}

2.10.2 验证存储驱动支持

# 检查内核是否支持overlay
grep overlay /proc/filesystems
# 输出: nodev overlay

# 检查文件系统是否支持d_type(overlay2需要)
sudo xfs_info / | grep ftype
# 输出: ftype=1 (需要为1)

# 检查内核版本
uname -r
# 输出应 >= 4.0

2.10.3 修改数据根目录

在某些情况下,系统盘空间不足,需要将Docker数据目录迁移到其他磁盘:

# 1. 停止Docker
sudo systemctl stop docker

# 2. 创建新目录
sudo mkdir -p /data/docker

# 3. 修改配置
sudo tee /etc/docker/daemon.json <<'EOF'
{
"data-root": "/data/docker",
"storage-driver": "overlay2"
}
EOF

# 4. 迁移现有数据
sudo rsync -aP /var/lib/docker/ /data/docker/

# 5. 启动Docker
sudo systemctl start docker

# 6. 验证
docker info | grep "Docker Root Dir"
# 输出: Docker Root Dir: /data/docker

# 7. 确认无误后删除旧目录
sudo rm -rf /var/lib/docker

2.10.4 存储驱动相关的故障排查

# 查看Docker守护进程日志
sudo journalctl -u docker.service –no-pager | tail -50

# 常见存储驱动错误及解决方法:

# 错误1: "overlay2 not supported"
# 原因: 内核版本过低或文件系统不支持
# 解决: 升级内核(>=4.0)或更换文件系统(使用ext4/xfs并设置ftype=1)

# 错误2: "Failed to start Docker Container Engine"
# 原因: 存储驱动配置错误或数据损坏
# 解决: 检查daemon.json配置,必要时清除/var/lib/docker重新初始化

# 错误3: "no space left on device"
# 原因: 磁盘空间不足
# 解决: 清理无用镜像和容器(docker system prune),或迁移数据根目录

第三章 Docker Volume(数据卷)

3.1 数据卷的概念与特点

3.1.1 什么是数据卷

数据卷(Volume)是Docker原生提供的数据持久化机制。它是一个由Docker守护进程管理的特殊目录,存在于宿主机上,可以被一个或多个容器挂载使用。数据卷完全独立于容器的生命周期——即使所有使用它的容器都被删除,数据卷及其数据依然存在。

3.1.2 数据卷的核心特点

3.1.3 数据卷的存储位置

数据卷默认存储在宿主机的/var/lib/docker/volumes/目录下:

/var/lib/docker/volumes/
├── my-volume/ # 命名数据卷
│ ├── _data/ # 实际数据存储目录
│ │ ├── file1.txt
│ │ └── subdir/
│ │ └── file2.txt
│ └── metadata.json # 数据卷元数据? (实际不存在此文件)
├── f3b4…45e/ # 匿名数据卷(使用哈希值命名)
│ └── _data/
│ └── …
└── backingFsBlockDev # 系统文件

在不同平台上,数据卷的存储位置有所不同:

3.2 docker volume create创建数据卷

3.2.1 基本创建命令

# 创建一个命名数据卷
docker volume create my-data-volume

# 输出: my-data-volume

创建后,Docker会在/var/lib/docker/volumes/my-data-volume/_data/目录下创建实际的数据存储目录。

3.2.2 创建时指定选项

# 创建数据卷时指定标签(label)
docker volume create –label environment=production –label app=web my-labeled-volume

# 创建数据卷时指定驱动(默认为local)
docker volume create –driver local my-local-volume

# 创建数据卷时指定驱动选项
# 例如:创建一个NFS数据卷
docker volume create \\
–driver local \\
–opt type=nfs \\
–opt o=addr=192.168.1.100,rw \\
–opt device=:/path/to/nfs/share \\
my-nfs-volume

# 创建一个tmpfs类型的数据卷(存储在内存中)
docker volume create \\
–driver local \\
–opt type=tmpfs \\
–opt device=tmpfs \\
–opt o=size=100m,mode=0755 \\
my-tmpfs-volume

# 创建一个btrfs子卷
docker volume create \\
–driver local \\
–opt type=btrfs \\
–opt device=/dev/sdb \\
–opt o=subvol=/docker-volumes/my-subvol \\
my-btrfs-volume

3.2.3 查看创建结果

# 查看数据卷详细信息
docker volume inspect my-data-volume

# 输出:
# [
# {
# "CreatedAt": "2024-01-15T10:30:00Z",
# "Driver": "local",
# "Labels": {},
# "Mountpoint": "/var/lib/docker/volumes/my-data-volume/_data",
# "Name": "my-data-volume",
# "Options": {},
# "Scope": "local"
# }
# ]

# 在宿主机上查看数据卷目录
sudo ls -la /var/lib/docker/volumes/my-data-volume/
# 输出:
# total 4
# drwxr-xr-x 3 root root 4096 Jan 15 10:30 .
# drwxr-xr-x 3 root root 4096 Jan 15 10:30 ..
# drwxr-xr-x 2 root root 40 Jan 15 10:30 _data

3.3 docker volume ls/rm/inspect/prune管理数据卷

3.3.1 docker volume ls – 列出数据卷

# 列出所有数据卷
docker volume ls

# 输出示例:
# DRIVER VOLUME NAME
# local my-data-volume
# local my-labeled-volume
# local nginx-html
# local f3b4a2c5e8d1… # 匿名数据卷(哈希命名)

# 按名称过滤
docker volume ls –filter name=my

# 输出:
# DRIVER VOLUME NAME
# local my-data-volume
# local my-labeled-volume

# 按标签过滤
docker volume ls –filter label=environment=production

# 输出:
# DRIVER VOLUME NAME
# local my-labeled-volume

# 只显示数据卷名称(不显示DRIVER列)
docker volume ls -q

# 输出:
# my-data-volume
# my-labeled-volume

3.3.2 docker volume inspect – 查看详情

# 查看单个数据卷详情
docker volume inspect my-data-volume

# 查看多个数据卷详情
docker volume inspect my-data-volume my-labeled-volume

# 只查看挂载点路径
docker volume inspect my-data-volume –format '{{.Mountpoint}}'
# 输出: /var/lib/docker/volumes/my-data-volume/_data

# 只查看驱动名称
docker volume inspect my-data-volume –format '{{.Driver}}'
# 输出: local

# 查看标签
docker volume inspect my-labeled-volume –format '{{.Labels}}'
# 输出: map[app:web environment:production]

3.3.3 docker volume rm – 删除数据卷

# 删除单个数据卷
docker volume rm my-data-volume

# 删除多个数据卷
docker volume rm volume1 volume2 volume3

# 注意:正在被容器使用的数据卷无法删除
docker volume rm my-data-volume
# 报错: Error response from daemon: unable to remove volume:
# remove my-data-volume: volume is in use

# 强制删除使用中的数据卷(需要先删除使用它的容器)
docker rm -f container_using_volume
docker volume rm my-data-volume

3.3.4 docker volume prune – 清理无用数据卷

# 删除所有未被容器使用的数据卷
docker volume prune

# 输出:
# WARNING! This will remove all local volumes not used by at least one container.
# Are you sure you want to continue? [y/N] y
# Deleted Volumes:
# unused-volume-1
# unused-volume-2
# Total reclaimed space: 1.2GB

# 跳过确认提示
docker volume prune -f

# 按标签过滤删除
docker volume prune –filter label!=keep=true

# 删除超过24小时未使用的数据卷
docker volume prune –filter "until=24h"

3.3.5 数据卷管理最佳实践

# 1. 为数据卷添加描述性标签
docker volume create –label app=mysql –label env=prod –label backup=daily mysql-data

# 2. 使用有意义的名称
docker volume create mysql_prod_data # 好的命名
# docker volume create vol1 # 不好的命名

# 3. 定期检查无用数据卷
docker volume ls -f dangling=true

# 4. 定期清理
docker volume prune -f # 谨慎使用,确保没有正在使用的匿名卷

# 5. 备份重要的数据卷(后续章节详细讲解)

3.4 在docker run中使用数据卷

3.4.1 基本用法(-v参数)

# 使用命名数据卷
docker run -d \\
–name web-server \\
-v web-data:/usr/share/nginx/html \\
nginx:latest

# 参数说明:
# -v web-data:/usr/share/nginx/html
# web-data: 数据卷名称(Docker会自动创建如果不存在)
# /usr/share/nginx/html: 容器内的挂载路径

3.4.2 使用–mount参数(推荐)

# 使用–mount参数(语法更明确,推荐使用)
docker run -d \\
–name web-server \\
–mount type=volume,src=web-data,dst=/usr/share/nginx/html \\
nginx:latest

# 参数说明:
# –mount type=volume: 指定挂载类型为数据卷
# src=web-data: 源数据卷名称(也可以用source=)
# dst=/usr/share/nginx/html: 目标路径(也可以用destination=或target=)

# 等价于:
# docker run -d –name web-server -v web-data:/usr/share/nginx/html nginx:latest

3.4.3 -v与–mount的对比

# -v 参数: 简洁但不够明确
# 格式: -v <volume_name>:<container_path>[:<options>]
docker run -d -v web-data:/data:ro nginx:latest

# –mount 参数: 语法明确,功能更丰富
# 格式: –mount type=volume,src=<name>,dst=<path>[,<options>]
docker run -d \\
–mount type=volume,src=web-data,dst=/data,readonly \\
nginx:latest

# –mount 的优势:
# 1. 语法更明确,每个参数都有键名
# 2. 更容易阅读和理解
# 3. 支持更多选项(如volume-nocopy)
# 4. 适用于Swarm服务

3.4.4 挂载多个数据卷

# 一个容器可以挂载多个数据卷
docker run -d \\
–name app-server \\
-v app-data:/app/data \\
-v app-logs:/app/logs \\
-v app-config:/app/config \\
my-app:latest

# 使用–mount语法
docker run -d \\
–name app-server \\
–mount type=volume,src=app-data,dst=/app/data \\
–mount type=volume,src=app-logs,dst=/app/logs \\
–mount type=volume,src=app-config,dst=/app/config \\
my-app:latest

3.4.5 volume-nocopy选项

默认情况下,当命名数据卷首次挂载到一个非空目录时,Docker会将容器镜像中该目录的内容复制到数据卷中。可以使用volume-nocopy选项禁用此行为:

# 默认行为:复制镜像内容到数据卷
docker run -d \\
–name web1 \\
–mount type=volume,src=web-data,dst=/usr/share/nginx/html \\
nginx:latest
# web-data会包含nginx默认的index.html和50x.html

# 禁止复制:不复制镜像内容
docker run -d \\
–name web2 \\
–mount type=volume,src=web-data2,dst=/usr/share/nginx/html,volume-nocopy \\
nginx:latest
# web-data2为空,不会包含nginx默认文件

3.5 数据卷的自动创建行为

3.5.1 自动创建命名数据卷

# 如果指定的命名数据卷不存在,Docker会自动创建
docker run -d \\
–name auto-create-test \\
-v non-existent-volume:/data \\
alpine:latest sleep 3600

# 查看是否自动创建了数据卷
docker volume ls | grep non-existent-volume
# 输出: local non-existent-volume

# 自动创建的数据卷没有任何特殊标签
docker volume inspect non-existent-volume

3.5.2 自动创建匿名数据卷

# 如果只指定容器路径而不指定数据卷名称,Docker会创建匿名数据卷
docker run -d \\
–name anonymous-volume-test \\
-v /data \\
alpine:latest sleep 3600

# 查看创建的匿名数据卷(名称为长哈希值)
docker volume ls
# 输出包含:
# DRIVER VOLUME NAME
# local f3b4a2c5e8d1234567890abcdef1234567890abcdef1234567890abcdef1234

# 查看匿名数据卷的详细信息
docker inspect anonymous-volume-test –format '{{json .Mounts}}' | python3 -m json.tool
# 输出:
# [
# {
# "Type": "volume",
# "Name": "f3b4a2c5…",
# "Source": "/var/lib/docker/volumes/f3b4a2c5…/_data",
# "Destination": "/data",
# "Driver": "local",
# "Mode": "",
# "RW": true,
# "Propagation": ""
# }
# ]

3.5.3 自动创建的风险与注意事项

匿名数据卷的自动创建可能导致"数据卷泄漏"问题——容器删除后,匿名数据卷不会被自动删除,长期积累会占用大量磁盘空间。

# 演示数据卷泄漏
for i in $(seq 1 10); do
docker run –rm -v /tmp/data alpine echo "creating anonymous volume $i"
done

# 查看
docker volume ls
# 会发现有10个匿名数据卷残留

# 清理
docker volume prune -f

最佳实践:始终使用命名数据卷,避免匿名数据卷。

# 不推荐:匿名数据卷
docker run -v /data alpine sleep 3600

# 推荐:命名数据卷
docker run -v my-data:/data alpine sleep 3600

3.6 数据卷在宿主机上的存储位置

3.6.1 默认存储位置

# 数据卷默认存储在
# /var/lib/docker/volumes/<volume_name>/_data/

# 查看数据卷的存储路径
docker volume inspect my-data-volume –format '{{.Mountpoint}}'
# 输出: /var/lib/docker/volumes/my-data-volume/_data

# 直接在宿主机上操作数据卷内容
sudo ls -la /var/lib/docker/volumes/my-data-volume/_data/

# 在宿主机上创建文件(会反映到容器中)
sudo echo "Hello from host" > /var/lib/docker/volumes/my-data-volume/_data/host-created.txt

# 在容器中验证
docker run –rm -v my-data-volume:/data alpine cat /data/host-created.txt
# 输出: Hello from host

3.6.2 修改数据卷存储位置

// /etc/docker/daemon.json
{
"data-root": "/data/docker"
}

修改后数据卷将存储在/data/docker/volumes/目录下。

3.6.3 数据卷的文件系统权限

# 数据卷在宿主机上默认由root拥有
sudo ls -la /var/lib/docker/volumes/
# drwxr-xr-x root root …
# drwxr-xr-x root root …

# 如果容器内以非root用户运行,可能遇到权限问题
# 解决方法1:在Dockerfile中调整权限
# Dockerfile:
# RUN mkdir -p /data && chown 1000:1000 /data
# USER 1000

# 解决方法2:在宿主机上修改数据卷权限
sudo chown -R 1000:1000 /var/lib/docker/volumes/my-data-volume/_data/

# 解决方法3:使用初始化容器设置权限
docker run –rm -v my-data-volume:/data alpine chown -R 1000:1000 /data

3.7 只读数据卷

3.7.1 创建只读数据卷

# 使用-v参数创建只读数据卷
docker run -d \\
–name readonly-test \\
-v readonly-data:/data:ro \\
alpine:latest sleep 3600

# 使用–mount参数创建只读数据卷
docker run -d \\
–name readonly-test2 \\
–mount type=volume,src=readonly-data,dst=/data,readonly \\
alpine:latest sleep 3600

# :ro 或 readonly 表示只读

3.7.2 验证只读属性

# 读取数据卷中的文件(正常)
docker exec readonly-test cat /data/somefile.txt

# 写入数据卷(会失败)
docker exec readonly-test sh -c 'echo "test" > /data/newfile.txt'
# 报错: sh: can't create /data/newfile.txt: Read-only file system

# 创建子目录(也会失败)
docker exec readonly-test mkdir /data/newdir
# 报错: mkdir: can't create directory '/data/newdir': Read-only file system

3.7.3 只读数据卷的应用场景

# 场景1:配置文件只读挂载(防止应用意外修改配置)
docker run -d \\
–name config-server \\
-v app-config:/etc/app/config:ro \\
my-app:latest

# 场景2:静态资源只读挂载
docker run -d \\
–name static-server \\
-v static-assets:/var/www/static:ro \\
nginx:latest

# 场景3:只读数据 + 可写日志(一个只读,一个可写)
docker run -d \\
–name mixed-server \\
-v app-data:/app/data:ro \\
-v app-logs:/app/logs \\
my-app:latest

3.8 数据卷的权限与所有权

3.8.1 权限问题分析

当容器内以非root用户运行时,可能会遇到数据卷权限问题。这是因为数据卷在宿主机上由root创建,容器内的非root用户可能没有读写权限。

# 示例:以非root用户运行的容器遇到权限问题
docker run -d \\
–name permission-test \\
–user 1000:1000 \\
-v perm-data:/data \\
alpine:latest sleep 3600

# 尝试写入文件
docker exec permission-test sh -c 'echo "test" > /data/test.txt'
# 可能报错: sh: can't create /data/test.txt: Permission denied

3.8.2 解决权限问题的方法

方法1:在Dockerfile中预设权限

# Dockerfile
FROM alpine:latest

# 创建目录并设置权限
RUN mkdir -p /data && chown 1000:1000 /data

# 切换到非root用户
USER 1000:1000

CMD ["sleep", "3600"]

方法2:使用初始化容器

# 步骤1:使用root用户初始化数据卷权限
docker run –rm \\
-v perm-data:/data \\
alpine:latest chown -R 1000:1000 /data

# 步骤2:以非root用户运行应用
docker run -d \\
–name app \\
–user 1000:1000 \\
-v perm-data:/data \\
my-app:latest

方法3:在宿主机上直接修改权限

# 获取数据卷路径
VOLUME_PATH=$(docker volume inspect perm-data –format '{{.Mountpoint}}')

# 修改所有权
sudo chown -R 1000:1000 $VOLUME_PATH

# 修改权限
sudo chmod -R 755 $VOLUME_PATH

方法4:使用Docker Compose的init容器

# docker-compose.yml
version: '3.8'

services:
init-permissions:
image: alpine:latest
volumes:
– app–data:/data
command: chown –R 1000:1000 /data
user: root

app:
image: my–app:latest
depends_on:
– init–permissions
user: "1000:1000"
volumes:
– app–data:/data

volumes:
app-data:

3.9 命名数据卷 vs 匿名数据卷

3.9.1 命名数据卷(Named Volume)

# 命名数据卷:有明确的名称
docker run -d \\
–name app \\
-v my-app-data:/data \\
my-app:latest

# 特点:
# 1. 有明确的、可读的名称
# 2. 可以通过名称引用和管理
# 3. 适合生产环境
# 4. 便于备份、迁移和共享

3.9.2 匿名数据卷(Anonymous Volume)

# 匿名数据卷:只指定容器路径,不指定数据卷名称
docker run -d \\
–name app \\
-v /data \\
my-app:latest

# 特点:
# 1. 名称是随机生成的哈希值
# 2. 难以管理和识别
# 3. 容器删除后容易成为"孤儿"数据卷
# 4. 不推荐在生产环境使用

3.9.3 对比

3.9.4 Dockerfile中的VOLUME指令产生的匿名卷

# Dockerfile中使用VOLUME指令会创建匿名数据卷
FROM nginx:latest
VOLUME /data

# 构建并运行
docker build -t my-volume-image .
docker run -d –name vol-test my-volume-image

# 查看挂载信息,会发现一个匿名数据卷
docker inspect vol-test –format '{{json .Mounts}}' | python3 -m json.tool

3.10 数据卷实战: MySQL数据持久化

3.10.1 需求分析

我们需要运行一个MySQL容器,要求:

3.10.2 完整实现

# 步骤1:创建数据卷
docker volume create mysql_data
docker volume create mysql_logs
docker volume create mysql_config

# 步骤2:创建配置文件
mkdir -p /opt/mysql/conf
cat > /opt/mysql/conf/my.cnf << 'EOF'
[mysqld]
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci
max_connections=500
innodb_buffer_pool_size=256M
slow_query_log=1
long_query_time=2
EOF

# 步骤3:创建初始化SQL脚本
mkdir -p /opt/mysql/init
cat > /opt/mysql/init/init.sql << 'EOF'
CREATE DATABASE IF NOT EXISTS appdb DEFAULT CHARACTER SET utf8mb4;
CREATE USER IF NOT EXISTS 'appuser'@'%' IDENTIFIED BY 'apppass123';
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'%';
FLUSH PRIVILEGES;
EOF

# 步骤4:启动MySQL容器
docker run -d \\
–name mysql-prod \\
–restart unless-stopped \\
-p 3306:3306 \\
-e MYSQL_ROOT_PASSWORD=RootPass123! \\
-e MYSQL_DATABASE=appdb \\
-e MYSQL_USER=appuser \\
-e MYSQL_PASSWORD=apppass123 \\
-v mysql_data:/var/lib/mysql \\
-v mysql_logs:/var/log/mysql \\
-v /opt/mysql/conf/my.cnf:/etc/mysql/conf.d/my.cnf:ro \\
-v /opt/mysql/init:/docker-entrypoint-initdb.d:ro \\
mysql:8.0

# 步骤5:验证MySQL运行状态
docker exec mysql-prod mysql -uroot -pRootPass123! -e "SHOW DATABASES;"
# 输出:
# +——————–+
# | Database |
# +——————–+
# | appdb |
# | information_schema |
# | mysql |
# | performance_schema |
# | sys |
# +——————–+

# 步骤6:写入测试数据
docker exec mysql-prod mysql -uroot -pRootPass123! appdb -e "
CREATE TABLE users (
id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(100) NOT NULL,
email VARCHAR(100) UNIQUE NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
INSERT INTO users (name, email) VALUES ('张三', 'zhangsan@example.com');
INSERT INTO users (name, email) VALUES ('李四', 'lisi@example.com');
SELECT * FROM users;
"

# 步骤7:模拟容器故障 – 删除并重建容器
docker rm -f mysql-prod

# 重新启动容器(使用相同的数据卷)
docker run -d \\
–name mysql-prod \\
–restart unless-stopped \\
-p 3306:3306 \\
-e MYSQL_ROOT_PASSWORD=RootPass123! \\
-v mysql_data:/var/lib/mysql \\
-v mysql_logs:/var/log/mysql \\
-v /opt/mysql/conf/my.cnf:/etc/mysql/conf.d/my.cnf:ro \\
mysql:8.0

# 步骤8:验证数据依然存在
docker exec mysql-prod mysql -uroot -pRootPass123! appdb -e "SELECT * FROM users;"
# 输出:
# +—-+——–+———————-+———————+
# | id | name | email | created_at |
# +—-+——–+———————-+———————+
# | 1 | 张三 | zhangsan@example.com | 2024-01-15 10:30:00 |
# | 2 | 李四 | lisi@example.com | 2024-01-15 10:30:00 |
# +—-+——–+———————-+———————+

# 数据完好无损!这就是数据卷持久化的威力。

3.10.3 使用Docker Compose管理

# docker-compose.yml
version: '3.8'

services:
mysql:
image: mysql:8.0
container_name: mysql–prod
restart: unless–stopped
ports:
– "3306:3306"
environment:
MYSQL_ROOT_PASSWORD: RootPass123!
MYSQL_DATABASE: appdb
MYSQL_USER: appuser
MYSQL_PASSWORD: apppass123
volumes:
– mysql_data:/var/lib/mysql
– mysql_logs:/var/log/mysql
– ./conf/my.cnf:/etc/mysql/conf.d/my.cnf:ro
– ./init:/docker–entrypoint–initdb.d:ro
healthcheck:
test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-uroot", "-pRootPass123!"]
interval: 10s
timeout: 5s
retries: 5

volumes:
mysql_data:
name: mysql_data
mysql_logs:
name: mysql_logs

# 启动
docker-compose up -d

# 查看状态
docker-compose ps

# 查看日志
docker-compose logs -f mysql

# 停止
docker-compose down
# 注意:down不会删除数据卷,但down -v会删除数据卷!
# docker-compose down -v # 危险!会删除所有数据!

第四章 Bind Mount(绑定挂载)

4.1 绑定挂载的概念与特点

4.1.1 什么是绑定挂载

绑定挂载(Bind Mount)是Docker提供的另一种数据持久化机制。与数据卷不同,绑定挂载将宿主机上的一个绝对路径直接挂载到容器中。容器对该路径下文件的读写操作直接作用于宿主机的文件系统,两者之间是"双向同步"的。

绑定挂载在Docker的早期版本中就已经存在,可以说是最古老的数据持久化方式之一。它的概念来源于Linux的mount –bind命令,即将一个目录树挂载到另一个目录树上。

4.1.2 绑定挂载的核心特点

4.1.3 绑定挂载的工作原理

┌─────────────────────────────────────┐
│ 宿主机 │
│ │
│ /home/user/project/ │
│ ├── src/ │
│ │ ├── app.py │
│ │ └── utils.py │
│ ├── config/ │
│ │ └── settings.json │
│ └── requirements.txt │
│ │
│ ┌─────────────────────────────────┐│
│ │ Docker 容器 ││
│ │ ││
│ │ /app/ ← 绑定挂载点 ││
│ │ ├── src/ ← 同步 ││
│ │ │ ├── app.py ← 同步 ││
│ │ │ └── utils.py ← 同步 ││
│ │ ├── config/ ← 同步 ││
│ │ │ └── settings.json ← 同步 ││
│ │ └── requirements.txt ← 同步 ││
│ │ ││
│ └─────────────────────────────────┘│
└─────────────────────────────────────┘

当绑定挂载生效时,容器内挂载点路径上的内容会被宿主机路径的内容"覆盖"。即使镜像中该路径下有文件,这些文件也会被隐藏。

4.2 在docker run中使用绑定挂载

4.2.1 基本用法(-v参数)

# 使用-v参数创建绑定挂载
docker run -d \\
–name dev-server \\
-v /home/user/project:/app \\
node:18-alpine

# 参数说明:
# -v /home/user/project:/app
# /home/user/project: 宿主机绝对路径
# /app: 容器内挂载路径
# 注意:宿主机路径以 / 开头表示绑定挂载(不是以/开头表示数据卷名称)

4.2.2 区分绑定挂载和数据卷

# 绑定挂载:宿主机路径以/开头(或./、~/等绝对/相对路径)
docker run -v /home/user/data:/data alpine sleep 3600 # 绑定挂载
docker run -v ./data:/data alpine sleep 3600 # 绑定挂载(相对路径)
docker run -v ~/data:/data alpine sleep 3600 # 绑定挂载(家目录)

# 数据卷:不以/开头的是数据卷名称
docker run -v my-volume:/data alpine sleep 3600 # 命名数据卷
docker run -v /data alpine sleep 3600 # 匿名数据卷(只有容器路径)

4.2.3 挂载单个文件

# 绑定挂载也可以挂载单个文件(而不仅仅是目录)
docker run -d \\
–name nginx-custom \\
-v /opt/nginx/nginx.conf:/etc/nginx/nginx.conf:ro \\
nginx:latest

# 注意:挂载单个文件时,宿主机上该文件必须存在
# 如果文件不存在,Docker会将其创建为一个目录!

# 演示文件挂载的错误情况
# 如果文件不存在,Docker会创建目录
docker run –rm -v /tmp/nonexist.conf:/etc/config.conf alpine ls -la /etc/config.conf
# /etc/config.conf 实际上是一个目录!

# 正确做法:先创建文件
touch /tmp/config.conf
docker run –rm -v /tmp/config.conf:/etc/config.conf alpine cat /etc/config.conf
# 正常工作

4.2.4 挂载多个绑定挂载

docker run -d \\
–name full-dev-env \\
-v /home/user/project/src:/app/src \\
-v /home/user/project/config:/app/config:ro \\
-v /home/user/project/logs:/app/logs \\
-v /home/user/.ssh:/root/.ssh:ro \\
node:18-alpine

4.3 使用–mount参数(更明确的语法)

4.3.1 –mount语法

# 使用–mount参数创建绑定挂载
docker run -d \\
–name dev-server \\
–mount type=bind,src=/home/user/project,dst=/app \\
node:18-alpine

# 参数说明:
# type=bind: 指定挂载类型为绑定挂载
# src=/home/user/project: 宿主机源路径(也可以用source=)
# dst=/app: 容器内目标路径(也可以用destination=或target=)

4.3.2 –mount的完整选项

docker run -d \\
–name dev-server \\
–mount \\
type=bind,\\
src=/home/user/project,\\
dst=/app,\\
readonly,\\
bind-propagation=rprivate \\
node:18-alpine

# 选项说明:
# type=bind: 绑定挂载类型
# src: 宿主机源路径
# dst: 容器目标路径
# readonly: 只读挂载
# bind-propagation: 绑定传播模式(rprivate/private/rslave/slave/rshared/shared)

4.3.3 绑定传播(Bind Propagation)

绑定传播控制当挂载点下又有其他挂载时,这些挂载如何传播:

# 演示绑定传播
# 准备目录结构
mkdir -p /tmp/propagation/source
mkdir -p /tmp/propagation/dest
echo "source content" > /tmp/propagation/source/file.txt

# rprivate(默认): 不会传播任何挂载
docker run –rm \\
–mount type=bind,src=/tmp/propagation/source,dst=/tmp/propagation/dest,bind-propagation=rprivate \\
alpine ls /tmp/propagation/dest

# shared: 挂载点中的挂载会传播到原挂载,反之亦然
# slave: 只接收原挂载的传播,不反向传播
# rshared: 递归shared
# rslave: 递归slave
# private: 不传播
# rprivate: 递归private(默认)

4.4 绑定挂载的绝对路径要求

4.4.1 绝对路径规则

# 绑定挂载的宿主机路径必须是绝对路径
# 正确:绝对路径
docker run -v /home/user/data:/data alpine sleep 3600

# 正确:使用$(pwd)展开为绝对路径
docker run -v $(pwd)/data:/data alpine sleep 3600

# 错误:相对路径(不以/开头会被当作数据卷名称)
docker run -v data:/data alpine sleep 3600
# Docker会创建一个名为"data"的数据卷,而不是绑定挂载!

# 正确:使用相对路径展开
docker run -v "$(pwd)/data":/data alpine sleep 3600

4.4.2 使用相对路径的正确方式

# 在项目目录中使用绑定挂载
cd /home/user/myproject

# 使用$(pwd)获取当前目录的绝对路径
docker run -d \\
–name dev \\
-v "$(pwd)":/app \\
node:18-alpine

# 或者使用–mount语法(同样需要绝对路径)
docker run -d \\
–name dev \\
–mount type=bind,src=$(pwd),dst=/app \\
node:18-alpine

# 在Windows上使用PowerShell
docker run -d `
–name dev `
-v "${PWD}:/app" `
node:18-alpine

# 在Windows上使用CMD
docker run -d ^
–name dev ^
-v "%cd%:/app" ^
node:18-alpine

4.4.3 路径不存在时的行为

# 如果宿主机路径不存在,Docker会自动创建一个目录
docker run –rm -v /tmp/nonexistent-dir:/data alpine ls -la /data
# /data目录会被创建(为空)

# 但如果挂载的是文件且文件不存在,Docker会创建一个目录(而非文件)
docker run –rm -v /tmp/nonexistent-file.txt:/config.txt alpine ls -la /config.txt
# /config.txt实际上是一个目录,而非文件!
# 这可能导致应用报错

# 解决方法:先在宿主机上创建文件
touch /tmp/config.txt
docker run –rm -v /tmp/config.txt:/config.txt alpine cat /config.txt

4.5 只读绑定挂载

4.5.1 创建只读绑定挂载

# 使用-v参数
docker run -d \\
–name config-server \\
-v /opt/app/config:/app/config:ro \\
my-app:latest

# 使用–mount参数
docker run -d \\
–name config-server \\
–mount type=bind,src=/opt/app/config,dst=/app/config,readonly \\
my-app:latest

4.5.2 只读绑定挂载的应用场景

# 场景1:只读配置文件
docker run -d \\
–name nginx-server \\
-v /opt/nginx/nginx.conf:/etc/nginx/nginx.conf:ro \\
-v /opt/nginx/conf.d:/etc/nginx/conf.d:ro \\
nginx:latest

# 场景2:只读静态资源
docker run -d \\
–name static-server \\
-v /opt/static:/usr/share/nginx/html:ro \\
nginx:latest

# 场景3:只读SSL证书
docker run -d \\
–name https-server \\
-v /opt/ssl/certs:/etc/ssl/certs:ro \\
-v /opt/ssl/private:/etc/ssl/private:ro \\
nginx:latest

# 场景4:可读写的代码目录 + 只读的配置目录
docker run -d \\
–name dev-server \\
-v /home/user/project/src:/app/src \\
-v /opt/app/config:/app/config:ro \\
node:18-alpine

4.6 绑定挂载与文件同步

4.6.1 实时双向同步

绑定挂载的最大优势之一是宿主机与容器之间的文件实时双向同步:

# 启动一个绑定挂载的容器
mkdir -p /tmp/sync-test
docker run -d \\
–name sync-test \\
-v /tmp/sync-test:/data \\
alpine:latest sleep 3600

# 在宿主机创建文件
echo "Hello from host" > /tmp/sync-test/host-file.txt

# 在容器中查看(立即可见)
docker exec sync-test cat /data/host-file.txt
# 输出: Hello from host

# 在容器中创建文件
docker exec sync-test sh -c 'echo "Hello from container" > /data/container-file.txt'

# 在宿主机查看(立即可见)
cat /tmp/sync-test/container-file.txt
# 输出: Hello from container

# 清理
docker rm -f sync-test
rm -rf /tmp/sync-test

4.6.2 inotify事件传播

绑定挂载支持文件系统事件(inotify)的传播,这使得文件监听工具(如nodemon、webpack-dev-server等)可以在容器内正常运行:

# 在开发环境中使用nodemon监听文件变化
docker run -d \\
–name node-dev \\
-v $(pwd):/app \\
-w /app \\
node:18-alpine \\
npx nodemon app.js

# 当你在宿主机上修改app.js时,nodemon会检测到变化并自动重启

4.7 绑定挂载在开发环境中的应用

4.7.1 代码热重载(Node.js)

# 项目结构
# /home/user/myapp/
# ├── package.json
# ├── src/
# │ ├── index.js
# │ └── routes.js
# ├── node_modules/
# └── Dockerfile

# Dockerfile
# FROM node:18-alpine
# WORKDIR /app
# COPY package.json .
# RUN npm install
# EXPOSE 3000
# CMD ["npm", "start"]

# 使用绑定挂载实现热重载
docker run -d \\
–name node-dev \\
-p 3000:3000 \\
-v /home/user/myapp:/app \\
-w /app \\
node:18-alpine \\
npx nodemon –watch src src/index.js

# 修改宿主机上的src/index.js,容器内的应用会自动重启

4.7.2 Python Flask热重载

# 使用Flask的debug模式实现热重载
docker run -d \\
–name flask-dev \\
-p 5000:5000 \\
-v $(pwd):/app \\
-w /app \\
python:3.11-slim \\
bash -c "pip install flask && flask –app app run –host=0.0.0.0 –debug –reload"

# 修改app.py,Flask会自动重载

4.7.3 避免node_modules覆盖问题

# 问题:绑定挂载会覆盖容器内的node_modules
# 解决方法:使用匿名数据卷保护node_modules

docker run -d \\
–name node-dev \\
-p 3000:3000 \\
-v $(pwd):/app \\
-v /app/node_modules \\
-w /app \\
node:18-alpine \\
npm start

# 说明:
# -v $(pwd):/app: 绑定挂载项目目录
# -v /app/node_modules: 匿名数据卷,保护容器内的node_modules不被宿主机覆盖
# Docker会先处理绑定挂载,再处理匿名卷,所以node_modules会被单独挂载

4.8 绑定挂载的权限问题

4.8.1 Linux上的权限问题

# 在Linux上,绑定挂载直接使用宿主机的UID/GID
# 如果容器内以非root用户运行,需要确保UID匹配

# 查看宿主机当前用户的UID
id -u # 例如:1000

# 方法1:Dockerfile中创建相同UID的用户
# Dockerfile:
# FROM node:18-alpine
# RUN addgroup -g 1000 appgroup && adduser -u 1000 -G appgroup -s /bin/sh -D appuser
# USER appuser

# 方法2:运行时指定用户
docker run -d \\
–name dev \\
–user $(id -u):$(id -g) \\
-v $(pwd):/app \\
node:18-alpine

4.8.2 macOS上的特殊处理

在macOS上使用Docker Desktop时,绑定挂载通过一个Linux虚拟机中转,存在以下特点:

# macOS上Docker Desktop使用VirtioFS或osxfs进行文件共享
# 1. 文件权限自动转换
# 2. 性能比Linux原生绑定挂载稍差
# 3. 可以通过Docker Desktop设置配置文件共享路径

# 在Docker Desktop中设置:
# Settings → Resources → File Sharing
# 确保绑定的路径在共享列表中

# 性能优化:使用缓存选项(仅macOS)
# 在docker-compose.yml中:
# volumes:
# – type: bind
# source: ./src
# target: /app/src
# consistency: cached # macOS专用,提高读取性能
# # consistency: delegated # 容器内的修改延迟同步到宿主机
# # consistency: consistent # 默认,完全一致

4.8.3 Windows上的特殊处理

# 在Windows上,路径格式不同
# 使用PowerShell:
docker run –d `
—name dev `
–v "${PWD}\\src:/app/src" `
node:18-alpine

# 或者使用正斜杠(推荐):
docker run –d `
—name dev `
–v "${PWD}/src:/app/src" `
node:18-alpine

# Windows路径的特殊处理:
# 1. 盘符路径(C:\\…)会被转换为Linux路径
# 2. 使用Docker Desktop的WSL2后端性能更好
# 3. 需要在Docker Desktop设置中开启文件共享

# 注意Windows上的换行符问题(CRLF vs LF)
# 建议:.gitattributes中设置 * text=auto eol=lf

4.9 Bind Mount vs Volume对比

选择建议:

• 生产环境:优先使用数据卷(Volume),便于管理、备份和迁移。
• 开发环境:使用绑定挂载(Bind Mount),方便代码热重载。
• 配置文件:两种都可以,绑定挂载更直观。
• 数据库数据:必须使用数据卷,不要使用绑定挂载。

4.10 绑定挂载实战: 开发环境代码热更新

4.10.1 项目结构

my-webapp/
├── docker-compose.yml
├── Dockerfile
├── package.json
├── src/
│ ├── index.js
│ ├── routes/
│ │ ├── users.js
│ │ └── products.js
│ └── public/
│ ├── index.html
│ └── styles.css
└── config/
└── config.json

4.10.2 Dockerfile

# Dockerfile
FROM node:18-alpine

# 设置工作目录
WORKDIR /app

# 复制package.json并安装依赖
COPY package.json package-lock.json ./
RUN npm ci –only=production

# 安装开发依赖
RUN npm install –only=dev

# 暴露端口
EXPOSE 3000

# 使用nodemon启动(支持热重载)
CMD ["npx", "nodemon", "–watch", "src", "src/index.js"]

4.10.3 docker-compose.yml

# docker-compose.yml
version: '3.8'

services:
webapp:
build: .
container_name: webapp–dev
ports:
– "3000:3000"
volumes:
# 绑定挂载:源代码目录(支持热重载)
– ./src:/app/src
# 绑定挂载:配置文件(只读)
– ./config:/app/config:ro
# 匿名数据卷:保护node_modules不被覆盖
– /app/node_modules
environment:
– NODE_ENV=development
– CHOKIDAR_USEPOLLING=true # 确保文件变化检测在所有平台上正常工作
restart: unless–stopped

4.10.4 运行与验证

# 启动开发环境
docker-compose up -d

# 查看日志
docker-compose logs -f webapp

# 修改src/index.js(在宿主机上)
echo 'app.get("/health", (req, res) => res.json({status: "ok"}));' >> src/index.js

# nodemon会自动检测到变化并重启应用
# 日志中会出现: [nodemon] restarting due to changes…

# 测试新添加的路由
curl http://localhost:3000/health
# 输出: {"status":"ok"}

# 修改配置文件
echo '{"debug": true}' > config/config.json

# 应用可以读取最新的配置文件内容(因为绑定挂载是实时的)

4.10.5 开发环境的最佳实践

# 1. 使用.dockerignore避免不必要的文件被COPY
# .dockerignore:
# node_modules
# .git
# *.md
# .env

# 2. 使用docker-compose.override.yml覆盖开发配置
# docker-compose.yml(基础配置)
# docker-compose.override.yml(开发覆盖配置,自动加载)

# 3. 使用环境变量管理配置
# .env文件:
# NODE_ENV=development
# PORT=3000

# 4. 开发工具集成
# VS Code的Dev Containers扩展可以直接在容器内开发
# 使用.devcontainer/devcontainer.json配置

// .devcontainer/devcontainer.json
{
"name": "Node.js Dev",
"build": {
"dockerfile": "../Dockerfile"
},
"forwardPorts": [3000],
"mounts": [
"source=${localWorkspaceFolder}/src,target=/app/src,type=bind,consistency=cached",
"source=${localWorkspaceFolder}/config,target=/app/config,type=bind"
],
"remoteEnv": {
"NODE_ENV": "development"
},
"postCreateCommand": "npm install"
}

第五章 tmpfs Mount(临时文件系统)

5.1 tmpfs挂载的概念与特点

5.1.1 什么是tmpfs挂载

tmpfs挂载是Docker提供的第三种存储方式。与数据卷和绑定挂载不同,tmpfs将数据存储在宿主机的**内存(RAM)**中,而不是磁盘上。这意味着tmpfs中的数据读写速度极快,但容器停止后数据就会消失,不会持久化到磁盘。

tmpfs是Linux内核提供的临时文件系统,它将一部分内存作为文件系统使用。Docker利用这一机制,允许容器将特定路径挂载为tmpfs,实现高速临时存储。

5.1.2 tmpfs挂载的核心特点

5.1.3 tmpfs vs Volume vs Bind Mount

┌────────────────────────────────────────────────────┐
│ 存储位置对比 │
│ │
│ Volume: 磁盘(/var/lib/docker/volumes/) │
│ Bind Mount: 磁盘(宿主机任意路径) │
│ tmpfs: 内存(RAM) │
│ │
│ 持久性: Volume > Bind Mount > tmpfs │
│ 性能: tmpfs > Volume ≈ Bind Mount │
│ 安全性: tmpfs > Volume > Bind Mount │
│ 可共享: Volume = Bind Mount > tmpfs(不可共享) │
└────────────────────────────────────────────────────┘

5.2 使用tmpfs挂载

5.2.1 使用–tmpfs参数

# 使用–tmpfs参数创建tmpfs挂载
docker run -d \\
–name tmpfs-test \\
–tmpfs /app/temp \\
alpine:latest sleep 3600

# 参数说明:
# –tmpfs /app/temp: 在容器内的/app/temp路径挂载tmpfs

# 验证tmpfs
docker exec tmpfs-test df -h /app/temp
# 输出:
# Filesystem Size Used Available Use% Mounted on
# tmpfs 64.0M 0 64.0M 0% /app/temp

# 写入数据
docker exec tmpfs-test sh -c 'echo "temp data" > /app/temp/test.txt'
docker exec tmpfs-test cat /app/temp/test.txt
# 输出: temp data

5.2.2 使用–mount参数

# 使用–mount参数创建tmpfs挂载(语法更明确)
docker run -d \\
–name tmpfs-test2 \\
–mount type=tmpfs,dst=/app/temp \\
alpine:latest sleep 3600

# 带选项的tmpfs挂载
docker run -d \\
–name tmpfs-test3 \\
–mount type=tmpfs,dst=/app/temp,tmpfs-size=100m,tmpfs-mode=1777 \\
alpine:latest sleep 3600

# 参数说明:
# type=tmpfs: 指定挂载类型为tmpfs
# dst=/app/temp: 容器内目标路径
# tmpfs-size=100m: tmpfs大小限制为100MB
# tmpfs-mode=1777: tmpfs的权限模式

5.2.3 –tmpfs与–mount的区别

5.3 tmpfs挂载的选项

5.3.1 tmpfs-size(大小限制)

# 设置tmpfs大小为64MB
docker run -d \\
–name tmpfs-sized \\
–mount type=tmpfs,dst=/app/temp,tmpfs-size=64m \\
alpine:latest sleep 3600

# 验证大小限制
docker exec tmpfs-sized df -h /app/temp
# 输出:
# Filesystem Size Used Available Use% Mounted on
# tmpfs 64.0M 0 64.0M 0% /app/temp

# 测试写入超过限制的数据(会失败)
docker exec tmpfs-sized sh -c 'dd if=/dev/zero of=/app/temp/bigfile bs=1M count=100'
# 报错: dd: writing '/app/temp/bigfile': No space left on device

# 注意:如果不设置tmpfs-size,默认大小为宿主机内存的一半

5.3.2 tmpfs-mode(权限模式)

# 设置tmpfs权限为1777(所有用户可读写执行)
docker run -d \\
–name tmpfs-mode-test \\
–mount type=tmpfs,dst=/app/temp,tmpfs-mode=1777 \\
alpine:latest sleep 3600

# 验证权限
docker exec tmpfs-mode-test ls -ld /app/temp
# 输出: drwxrwxrwt 2 root root 40 Jan 15 10:30 /app/temp

# 设置权限为700(仅root可访问)
docker run -d \\
–name tmpfs-private \\
–mount type=tmpfs,dst=/app/temp,tmpfs-mode=1700 \\
alpine:latest sleep 3600

docker exec tmpfs-private ls -ld /app/temp
# 输出: drwx—— 2 root root 40 Jan 15 10:30 /app/temp

5.3.3 完整选项列表

5.4 tmpfs的内存使用

5.4.1 内存消耗机制

tmpfs使用宿主机的内存来存储数据。需要注意的是:

# 查看宿主机内存使用情况
free -h

# 启动使用tmpfs的容器
docker run -d \\
–name mem-test \\
–mount type=tmpfs,dst=/app/temp,tmpfs-size=512m \\
alpine:latest sleep 3600

# 在容器中写入数据
docker exec mem-test sh -c 'dd if=/dev/zero of=/app/temp/bigfile bs=1M count=200'

# 查看宿主机内存变化
free -h
# 可以看到可用内存减少了约200MB

# 清理
docker rm -f mem-test

5.4.2 与容器内存限制的关系

# 如果容器设置了内存限制,tmpfs的内存使用也计入限制
docker run -d \\
–name mem-limited \\
–memory=256m \\
–mount type=tmpfs,dst=/app/temp,tmpfs-size=512m \\
alpine:latest sleep 3600

# 尝试写入超过内存限制的数据
docker exec mem-limited sh -c 'dd if=/dev/zero of=/app/temp/bigfile bs=1M count=200'
# 可能会触发OOM Killer,导致进程被杀

# 查看容器是否因OOM被杀
docker inspect mem-limited –format '{{.State.OOMKilled}}'
# 输出: true (如果被OOM杀掉)

5.5 tmpfs适用场景

5.5.1 存储敏感信息

# 场景:临时存储API密钥或令牌
docker run -d \\
–name secure-app \\
–mount type=tmpfs,dst=/app/secrets,tmpfs-mode=1700 \\
my-app:latest

# 应用将敏感信息写入/app/secrets,容器停止后信息消失
# 不会在磁盘上留下任何痕迹

5.5.2 高速临时缓存

# 场景:应用缓存目录
docker run -d \\
–name cache-app \\
–mount type=tmpfs,dst=/app/cache,tmpfs-size=256m \\
my-app:latest

# 缓存数据存储在内存中,读写速度极快
# 容器重启后缓存自动清空(从后端重新加载)

5.5.3 减少磁盘I/O

# 场景:临时文件处理
docker run -d \\
–name file-processor \\
–mount type=tmpfs,dst=/tmp/processing,tmpfs-size=512m \\
my-app:latest

# 临时文件在内存中处理,减少磁盘I/O
# 处理完成后,结果写入持久化存储(数据卷)

5.5.4 不适合tmpfs的场景

# 不适合:需要持久化的数据
# 数据库数据 → 使用Volume
# 应用日志 → 使用Volume或日志驱动
# 用户上传文件 → 使用Volume

# 不适合:大量数据
# tmpfs受内存限制,不适合存储大量数据

# 不适合:需要多容器共享的数据
# tmpfs是容器私有的,无法共享

5.6 tmpfs实战: 安全存储临时密钥

5.6.1 需求场景

在一个微服务应用中,需要临时存储数据库密码、API密钥等敏感信息。这些信息不应该持久化到磁盘,仅在应用运行期间存在于内存中。

5.6.2 完整实现

# 步骤1:创建应用镜像
mkdir -p /tmp/secure-app
cat > /tmp/secure-app/Dockerfile << 'EOF'
FROM python:3.11-slim

WORKDIR /app

RUN pip install flask

COPY app.py .

EXPOSE 5000

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

cat > /tmp/secure-app/app.py << 'PYEOF'
import os
import json
from flask import Flask, request, jsonify

app = Flask(__name__)

SECRETS_DIR = '/app/secrets'

@app.route('/secret', methods=['POST'])
def store_secret():
"""临时存储密钥(仅存在于内存中)"""
data = request.json
key = data.get('key')
value = data.get('value')

if not key or not value:
return jsonify({'error': 'key and value required'}), 400

# 写入tmpfs(内存中)
with open(f'{SECRETS_DIR}/{key}.txt', 'w') as f:
f.write(value)

return jsonify({'message': f'Secret "{key}" stored in memory'}), 200

@app.route('/secret/<key>', methods=['GET'])
def get_secret(key):
"""读取临时密钥"""
try:
with open(f'{SECRETS_DIR}/{key}.txt', 'r') as f:
value = f.read()
return jsonify({'key': key, 'value': value}), 200
except FileNotFoundError:
return jsonify({'error': 'Secret not found'}), 404

@app.route('/secrets', methods=['GET'])
def list_secrets():
"""列出所有临时密钥"""
files = os.listdir(SECRETS_DIR)
return jsonify({'secrets': files}), 200

@app.route('/health', methods=['GET'])
def health():
return jsonify({'status': 'healthy'}), 200

if __name__ == '__main__':
# 确保密钥目录存在
os.makedirs(SECRETS_DIR, exist_ok=True)
app.run(host='0.0.0.0', port=5000)
PYEOF

# 步骤2:构建镜像
docker build -t secure-app /tmp/secure-app/

# 步骤3:使用tmpfs启动容器
docker run -d \\
–name secure-service \\
-p 5000:5000 \\
–mount type=tmpfs,dst=/app/secrets,tmpfs-size=64m,tmpfs-mode=1700 \\
–memory=256m \\
secure-app

# 步骤4:存储密钥
curl -X POST http://localhost:5000/secret \\
-H "Content-Type: application/json" \\
-d '{"key": "db_password", "value": "SuperSecret123!"}'
# 输出: {"message":"Secret \\"db_password\\" stored in memory"}

curl -X POST http://localhost:5000/secret \\
-H "Content-Type: application/json" \\
-d '{"key": "api_key", "value": "ak_1234567890abcdef"}'
# 输出: {"message":"Secret \\"api_key\\" stored in memory"}

# 步骤5:读取密钥
curl http://localhost:5000/secret/db_password
# 输出: {"key":"db_password","value":"SuperSecret123!"}

# 步骤6:列出所有密钥
curl http://localhost:5000/secrets
# 输出: {"secrets":["db_password.txt","api_key.txt"]}

# 步骤7:验证密钥不在磁盘上
# 查看容器挂载信息
docker inspect secure-service –format '{{json .Mounts}}' | python3 -m json.tool
# 输出显示tmpfs挂载,没有磁盘路径

# 步骤8:重启容器,验证密钥消失
docker restart secure-service
sleep 3

curl http://localhost:5000/secrets
# 输出: {"secrets":[]}
# 密钥已消失!因为tmpfs数据在容器重启后清除

# 清理
docker rm -f secure-service
rm -rf /tmp/secure-app

5.6.3 使用Docker Compose

# docker-compose.yml
version: '3.8'

services:
secure-service:
build: .
container_name: secure–service
ports:
– "5000:5000"
tmpfs:
– /app/secrets:size=64m,mode=1700
mem_limit: 256m
restart: unless–stopped
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:5000/health"]
interval: 30s
timeout: 5s
retries: 3

# 启动
docker-compose up -d

# 查看tmpfs挂载
docker exec secure-service df -h /app/secrets
# 输出:
# Filesystem Size Used Available Use% Mounted on
# tmpfs 64.0M 0 64.0M 0% /app/secrets

5.6.4 tmpfs安全注意事项

# 1. tmpfs数据可能被交换到swap分区
# 如果需要确保数据绝不落盘,需要禁用swap
docker run -d \\
–name ultra-secure \\
–mount type=tmpfs,dst=/app/secrets \\
–memory=256m \\
–memory-swap=0 \\
secure-app
# –memory-swap=0: 禁止内存交换,确保tmpfs数据不被写入swap

# 2. 使用tmpfs时注意内存监控
# tmpfs占用的内存会影响容器和宿主机的可用内存

# 3. tmpfs不适合长期存储大量数据
# 仅适合临时、少量的敏感数据

第六章 数据卷进阶操作

6.1 数据卷驱动与远程数据卷

6.1.1 数据卷驱动概述

数据卷驱动(Volume Driver)是Docker数据卷系统的扩展机制。默认的数据卷驱动是local,它将数据存储在宿主机的本地文件系统上。通过安装第三方数据卷驱动插件,可以将数据卷存储在各种远程存储系统上,如NFS、Amazon EBS、Google Persistent Disk、Azure File Storage等。

数据卷驱动的作用:

• 抽象底层存储:为Docker提供统一的存储接口,屏蔽底层存储差异
• 支持远程存储:将数据存储在网络存储上,实现跨主机数据共享
• 支持云存储:与云厂商的块存储、文件存储服务集成
• 支持高级特性:如加密、压缩、快照等

6.1.2 内置数据卷驱动

Docker内置了local驱动,它支持几种存储类型:

# 1. 默认本地目录(最常见)
docker volume create my-local-volume
# 存储: /var/lib/docker/volumes/my-local-volume/_data/

# 2. NFS类型
docker volume create \\
–driver local \\
–opt type=nfs \\
–opt o=addr=192.168.1.100,nfsvers=4,rw \\
–opt device=:/path/to/nfs/share \\
my-nfs-volume

# 3. CIFS/SMB类型(Windows共享)
docker volume create \\
–driver local \\
–opt type=cifs \\
–opt o=addr=192.168.1.200,username=user,password=pass,rw \\
–opt device=/sharename \\
my-smb-volume

# 4. tmpfs类型
docker volume create \\
–driver local \\
–opt type=tmpfs \\
–opt device=tmpfs \\
–opt o=size=100m,mode=0755 \\
my-tmpfs-volume

# 5. btrfs子卷
docker volume create \\
–driver local \\
–opt type=btrfs \\
–opt device=/dev/sdb \\
–opt o=subvol=/docker-volumes/my-subvol \\
my-btrfs-volume

# 6. 指定已有的块设备
docker volume create \\
–driver local \\
–opt type=ext4 \\
–opt device=/dev/sdc1 \\
my-block-volume

6.1.3 第三方数据卷驱动插件

# 查看已安装的插件
docker plugin ls

# 安装插件示例(以Docker NFS插件为例)
docker plugin install leapbit/docker-nfs:latest

# 使用插件创建数据卷
docker volume create \\
–driver leapbit/docker-nfs:latest \\
–opt nfsserver=192.168.1.100 \\
–opt nfspath=/shared/data \\
–opt nfsoptions=nfsvers=4 \\
my-remote-volume

6.2 使用数据卷插件(local、nfs、block)

6.2.1 local驱动详解

local驱动是Docker默认的数据卷驱动,它支持多种存储后端:

# 查看local驱动支持的选项
docker volume create –driver local –help

# local驱动支持的–opt选项:
# type: 文件系统类型(nfs, cifs, tmpfs, ext4, btrfs等)
# device: 设备路径或远程共享路径
# o: 挂载选项(对应mount命令的-o参数)

# 示例:创建一个基于ext4文件系统的数据卷
# 前提:/dev/sdb1已经格式化为ext4
docker volume create \\
–driver local \\
–opt type=ext4 \\
–opt device=/dev/sdb1 \\
my-ext4-volume

# 使用该数据卷
docker run -d \\
–name db \\
-v my-ext4-volume:/var/lib/mysql \\
mysql:8.0

6.2.2 NFS数据卷插件

NFS(Network File System)是常用的网络文件系统协议,适合多主机共享数据:

# 方法1:使用local驱动创建NFS数据卷(推荐)
docker volume create \\
–driver local \\
–opt type=nfs \\
–opt o=addr=192.168.1.100,nfsvers=4,soft,timeo=60,retrans=2 \\
–opt device=:/data/shared \\
–name nfs-shared-data

# 参数说明:
# type=nfs: 使用NFS文件系统
# o=addr=192.168.1.100: NFS服务器地址
# nfsvers=4: NFS版本4
# soft: 软挂载(NFS不可用时返回错误而非挂起)
# timeo=60: 超时时间(60秒)
# retrans=2: 重试次数
# device=:/data/shared: NFS服务器上的共享路径

# 使用NFS数据卷
docker run -d \\
–name shared-app \\
-v nfs-shared-data:/app/data \\
my-app:latest

# 在多台主机上创建同名NFS数据卷,实现跨主机数据共享
# 主机A:
docker volume create –driver local –opt type=nfs –opt o=addr=nfs-server-ip,nfsvers=4 –opt device=:/data/shared nfs-shared-data
# 主机B:
docker volume create –driver local –opt type=nfs –opt o=addr=nfs-server-ip,nfsvers=4 –opt device=:/data/shared nfs-shared-data
# 两台主机上的容器挂载同一个NFS数据卷,数据实时共享

6.2.3 block设备数据卷

# 使用块设备创建数据卷
# 前提:块设备已格式化
sudo mkfs.ext4 /dev/sdb1

# 创建基于块设备的数据卷
docker volume create \\
–driver local \\
–opt type=ext4 \\
–opt device=/dev/sdb1 \\
block-data-volume

# 使用块设备数据卷(适合高性能数据库场景)
docker run -d \\
–name high-perf-db \\
-v block-data-volume:/var/lib/postgresql/data \\
postgres:15

# 查看数据卷信息
docker volume inspect block-data-volume
# 输出:
# [
# {
# "CreatedAt": "2024-01-15T10:30:00Z",
# "Driver": "local",
# "Labels": null,
# "Mountpoint": "/var/lib/docker/volumes/block-data-volume/_data",
# "Name": "block-data-volume",
# "Options": {
# "device": "/dev/sdb1",
# "type": "ext4"
# },
# "Scope": "local"
# }
# ]

6.3 创建NFS数据卷

6.3.1 完整NFS数据卷配置

# ============================================
# 步骤1:在NFS服务器上配置共享(假设IP:192.168.1.100)
# ============================================

# 安装NFS服务
sudo apt-get install nfs-kernel-server # Ubuntu/Debian
# 或
sudo yum install nfs-utils # CentOS/RHEL

# 创建共享目录
sudo mkdir -p /data/docker-shared
sudo chown -R nobody:nogroup /data/docker-shared
sudo chmod 777 /data/docker-shared

# 配置NFS共享
sudo tee -a /etc/exports << 'EOF'
/data/docker-shared 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
EOF

# 启动NFS服务
sudo exportfs -ra
sudo systemctl restart nfs-kernel-server
sudo systemctl enable nfs-kernel-server

# 验证共享
showmount -e localhost
# 输出: /data/docker-shared 192.168.1.0/24

# ============================================
# 步骤2:在Docker主机上创建NFS数据卷
# ============================================

# 安装NFS客户端
sudo apt-get install nfs-common # Ubuntu/Debian
# 或
sudo yum install nfs-utils # CentOS/RHEL

# 创建NFS数据卷
docker volume create \\
–driver local \\
–opt type=nfs \\
–opt o=addr=192.168.1.100,nfsvers=4,soft,timeo=60,retrans=2 \\
–opt device=:/data/docker-shared \\
nfs-docker-data

# ============================================
# 步骤3:使用NFS数据卷运行容器
# ============================================

# 运行一个web应用,数据存储在NFS上
docker run -d \\
–name web-app-1 \\
-p 8080:80 \\
-v nfs-docker-data:/usr/share/nginx/html \\
nginx:latest

# 在容器中创建文件
docker exec web-app-1 sh -c 'echo "<h1>Hello from NFS</h1>" > /usr/share/nginx/html/index.html'

# 在另一台Docker主机上运行容器,挂载同一个NFS数据卷
# (需要在另一台主机上也创建同名的NFS数据卷)
docker run -d \\
–name web-app-2 \\
-p 8080:80 \\
-v nfs-docker-data:/usr/share/nginx/html \\
nginx:latest

# 验证:web-app-2也能看到web-app-1创建的文件
docker exec web-app-2 cat /usr/share/nginx/html/index.html
# 输出: <h1>Hello from NFS</h1>

6.3.2 NFS数据卷在Docker Compose中的使用

# docker-compose.yml
version: '3.8'

services:
web:
image: nginx:latest
ports:
– "8080:80"
volumes:
– nfs–data:/usr/share/nginx/html
deploy:
replicas: 3 # 在Swarm集群中运行3个副本,共享同一NFS数据

volumes:
nfs-data:
driver: local
driver_opts:
type: nfs
o: addr=192.168.1.100,nfsvers=4,soft,timeo=60,retrans=2
device: :/data/docker–shared

6.4 数据卷共享与多容器同时挂载

6.4.1 多容器共享同一个数据卷

# 创建共享数据卷
docker volume create shared-data

# 容器1:写入数据
docker run -d \\
–name writer \\
-v shared-data:/data \\
alpine:latest \\
sh -c 'while true; do echo "$(date): writer" >> /data/log.txt; sleep 5; done'

# 容器2:读取数据
docker run -d \\
–name reader \\
-v shared-data:/data:ro \\
alpine:latest \\
sh -c 'while true; do tail -1 /data/log.txt; sleep 5; done'

# 容器3:同时读写
docker run -d \\
–name processor \\
-v shared-data:/data \\
alpine:latest \\
sh -c 'while true; do echo "$(date): processor" >> /data/log.txt; sleep 10; done'

# 查看日志
docker logs -f reader
# 输出:
# Wed Jan 15 10:30:05 UTC 2024: writer
# Wed Jan 15 10:30:10 UTC 2024: writer
# Wed Jan 15 10:30:10 UTC 2024: processor
# …

6.4.2 并发写入的注意事项

# 多个容器同时写入同一个数据卷时,需要注意并发问题
# Docker不提供文件锁机制,需要应用层面处理并发

# 场景:多个容器写入同一个文件
# 问题:可能导致数据交错或丢失

# 解决方法1:每个容器写入不同的文件
docker run -d –name app1 -v shared-data:/data alpine sh -c 'while true; do echo "$(date)" >> /data/app1.log; sleep 5; done'
docker run -d –name app2 -v shared-data:/data alpine sh -c 'while true; do echo "$(date)" >> /data/app2.log; sleep 5; done'

# 解决方法2:使用文件锁(flock)
docker run -d –name app1 -v shared-data:/data alpine sh -c '
while true; do
(
flock -x 200
echo "$(date): app1" >> /data/shared.log
) 200>/data/.lock
sleep 5
done
'

# 解决方法3:使用消息队列或数据库处理并发

6.5 数据卷容器模式(–volumes-from)

6.5.1 数据卷容器概念

数据卷容器(Data Volume Container)是一种特殊的容器,它本身不运行应用服务,仅用于提供数据卷给其他容器挂载。其他容器通过–volumes-from参数来挂载数据卷容器中的所有数据卷。

虽然在新版本的Docker中,直接使用命名数据卷是更推荐的做法,但数据卷容器模式在某些场景下仍然有用。

6.5.2 创建和使用数据卷容器

# 步骤1:创建数据卷容器(不运行实际应用)
docker create \\
–name data-container \\
-v /app/data \\
-v /app/config \\
-v /app/logs \\
busybox:latest

# 注意:使用docker create而非docker run,容器创建但不启动

# 步骤2:其他容器通过–volumes-from挂载数据卷容器的卷
docker run -d \\
–name app1 \\
–volumes-from data-container \\
my-app:latest

docker run -d \\
–name app2 \\
–volumes-from data-container \\
my-app:latest

# app1和app2都挂载了/app/data、/app/config、/app/logs
# 它们共享这些路径的数据

# 步骤3:验证共享
docker exec app1 sh -c 'echo "data from app1" > /app/data/test.txt'
docker exec app2 cat /app/data/test.txt
# 输出: data from app1

6.5.3 –volumes-from的权限继承

# –volumes-from会继承数据卷的读写权限
# 如果数据卷容器中是只读挂载,继承的也是只读

# 创建只读数据卷容器
docker create \\
–name readonly-data-container \\
-v /app/config:ro \\
busybox:latest

# 继承的容器也是只读
docker run -d \\
–name app-readonly \\
–volumes-from readonly-data-container \\
my-app:latest

# app-readonly无法写入/app/config
docker exec app-readonly sh -c 'echo "test" > /app/config/test.txt'
# 报错: Read-only file system

6.5.4 链式继承

# –volumes-from支持链式继承
docker create –name base-data -v /data busybox:latest
docker run -d –name mid-data –volumes-from base-data -v /logs busybox:latest sleep 3600
docker run -d –name app –volumes-from mid-data my-app:latest

# app同时挂载了/data(来自base-data)和/logs(来自mid-data)

6.5.5 数据卷容器模式的优缺点

# 优点:
# 1. 集中管理数据卷定义
# 2. 多个容器共享同一组数据卷
# 3. 可以方便地添加新的共享容器

# 缺点:
# 1. 数据卷容器本身不运行,容易被遗忘和误删
# 2. 匿名数据卷难以管理
# 3. Docker官方更推荐使用命名数据卷

# 推荐的现代做法:直接使用命名数据卷
docker volume create app-data
docker volume create app-logs

docker run -d –name app1 -v app-data:/app/data -v app-logs:/app/logs my-app:latest
docker run -d –name app2 -v app-data:/app/data -v app-logs:/app/logs my-app:latest

6.6 数据卷的备份(docker run + tar)

6.6.1 备份原理

数据卷虽然存储在宿主机上,但Docker推荐通过容器来操作数据卷内容。备份数据卷的标准方法是:启动一个新容器,同时挂载要备份的数据卷和宿主机上的备份目录,然后使用tar命令将数据卷内容打包到备份目录中。

6.6.2 基本备份操作

# 假设有一个名为mysql-data的数据卷需要备份

# 方法1:备份到宿主机目录
mkdir -p /backup

docker run –rm \\
-v mysql-data:/data:ro \\
-v /backup:/backup \\
alpine:latest \\
tar czf /backup/mysql-data-$(date +%Y%m%d-%H%M%S).tar.gz -C /data .

# 参数说明:
# –rm: 容器退出后自动删除
# -v mysql-data:/data:ro: 以只读方式挂载要备份的数据卷
# -v /backup:/backup: 挂载宿主机的备份目录
# tar czf: 创建gzip压缩的tar包
# -C /data .: 切换到/data目录并打包当前目录下的所有内容

# 查看备份文件
ls -lh /backup/
# 输出: -rw-r–r– 1 root root 50M Jan 15 10:30 mysql-data-20240115-103000.tar.gz

6.6.3 备份脚本

#!/bin/bash
# backup-volume.sh – 数据卷备份脚本

# 参数
VOLUME_NAME=$1
BACKUP_DIR=${2:-/backup}
RETENTION_DAYS=${3:-7}

# 检查参数
if [ -z "$VOLUME_NAME" ]; then
echo "Usage: $0 <volume_name> [backup_dir] [retention_days]"
exit 1
fi

# 创建备份目录
mkdir -p "$BACKUP_DIR"

# 生成备份文件名
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
BACKUP_FILE="$BACKUP_DIR/${VOLUME_NAME}–${TIMESTAMP}.tar.gz"

echo "[$(date)] Backing up volume: $VOLUME_NAME"
echo " Backup file: $BACKUP_FILE"

# 执行备份
docker run –rm \\
-v "$VOLUME_NAME":/data:ro \\
-v "$BACKUP_DIR":/backup \\
alpine:latest \\
tar czf "/backup/${VOLUME_NAME}–${TIMESTAMP}.tar.gz" -C /data .

# 检查备份结果
if [ $? -eq 0 ]; then
BACKUP_SIZE=$(du -h "$BACKUP_FILE" | cut -f1)
echo "[$(date)] Backup completed successfully"
echo " Size: $BACKUP_SIZE"
else
echo "[$(date)] Backup FAILED!"
exit 1
fi

# 清理过期备份
echo "[$(date)] Cleaning up backups older than $RETENTION_DAYS days…"
find "$BACKUP_DIR" -name "${VOLUME_NAME}-*.tar.gz" -mtime +$RETENTION_DAYS -delete

echo "[$(date)] Done."

# 使用备份脚本
chmod +x backup-volume.sh
./backup-volume.sh mysql-data /backup 7

6.7 数据卷的恢复

6.7.1 从备份恢复数据卷

# 方法1:恢复到新数据卷
# 步骤1:创建新数据卷
docker volume create mysql-data-restored

# 步骤2:从备份恢复
docker run –rm \\
-v mysql-data-restored:/data \\
-v /backup:/backup:ro \\
alpine:latest \\
sh -c 'tar xzf /backup/mysql-data-20240115-103000.tar.gz -C /data'

# 步骤3:验证恢复
docker run –rm -v mysql-data-restored:/data alpine ls -la /data

# 步骤4:使用恢复的数据卷启动容器
docker run -d \\
–name mysql-restored \\
-v mysql-data-restored:/var/lib/mysql \\
-e MYSQL_ROOT_PASSWORD=RootPass123! \\
mysql:8.0

6.7.2 恢复脚本

#!/bin/bash
# restore-volume.sh – 数据卷恢复脚本

VOLUME_NAME=$1
BACKUP_FILE=$2

if [ -z "$VOLUME_NAME" ] || [ -z "$BACKUP_FILE" ]; then
echo "Usage: $0 <volume_name> <backup_file>"
echo "Example: $0 mysql-data /backup/mysql-data-20240115-103000.tar.gz"
exit 1
fi

if [ ! -f "$BACKUP_FILE" ]; then
echo "Error: Backup file not found: $BACKUP_FILE"
exit 1
fi

BACKUP_DIR=$(dirname "$BACKUP_FILE")
BACKUP_FILENAME=$(basename "$BACKUP_FILE")

echo "[$(date)] Restoring volume: $VOLUME_NAME"
echo " From: $BACKUP_FILE"

# 检查数据卷是否存在,不存在则创建
if ! docker volume inspect "$VOLUME_NAME" > /dev/null 2>&1; then
echo "[$(date)] Creating new volume: $VOLUME_NAME"
docker volume create "$VOLUME_NAME"
fi

# 执行恢复
docker run –rm \\
-v "$VOLUME_NAME":/data \\
-v "$BACKUP_DIR":/backup:ro \\
alpine:latest \\
sh -c "tar xzf /backup/$BACKUP_FILENAME -C /data"

if [ $? -eq 0 ]; then
echo "[$(date)] Restore completed successfully"
else
echo "[$(date)] Restore FAILED!"
exit 1
fi

# 使用恢复脚本
chmod +x restore-volume.sh
./restore-volume.sh mysql-data-restored /backup/mysql-data-20240115-103000.tar.gz

6.8 数据卷迁移

6.8.1 同主机迁移

# 场景:将数据从旧数据卷迁移到新数据卷(可能使用不同的驱动)

# 步骤1:创建新数据卷(例如使用NFS驱动)
docker volume create \\
–driver local \\
–opt type=nfs \\
–opt o=addr=192.168.1.100,nfsvers=4 \\
–opt device=:/data/new-storage \\
new-data-volume

# 步骤2:迁移数据
docker run –rm \\
-v old-data-volume:/source:ro \\
-v new-data-volume:/target \\
alpine:latest \\
sh -c 'cp -a /source/. /target/'

# 步骤3:验证数据
docker run –rm -v new-data-volume:/data alpine ls -la /data

# 步骤4:更新容器使用新数据卷
docker rm -f my-app
docker run -d –name my-app -v new-data-volume:/app/data my-app:latest

# 步骤5:确认无误后删除旧数据卷
docker volume rm old-data-volume

6.8.2 跨主机迁移

# 场景:将数据卷从主机A迁移到主机B

# 主机A:导出数据卷
docker run –rm \\
-v source-volume:/data:ro \\
-v /tmp:/backup \\
alpine:latest \\
tar czf /backup/source-volume-backup.tar.gz -C /data .

# 将备份文件传输到主机B
scp /tmp/source-volume-backup.tar.gz user@hostB:/tmp/

# 主机B:创建新数据卷并恢复
docker volume create source-volume
docker run –rm \\
-v source-volume:/data \\
-v /tmp:/backup:ro \\
alpine:latest \\
sh -c 'tar xzf /backup/source-volume-backup.tar.gz -C /data'

# 验证
docker run –rm -v source-volume:/data alpine ls -la /data

6.8.3 使用rsync增量迁移

# 对于大数据卷,使用rsync进行增量迁移更高效
# 需要在两端都支持rsync

# 步骤1:在目标主机创建数据卷
docker volume create migrated-data

# 步骤2:使用rsync迁移数据
# 方法:在源主机上临时启动rsync服务端
docker run -d \\
–name rsync-server \\
-v source-volume:/data \\
-p 873:873 \\
alpine:latest \\
sh -c 'apk add rsync && rsync –daemon –no-detach'

# 在目标主机上拉取数据
docker run –rm \\
-v migrated-data:/data \\
alpine:latest \\
sh -c 'apk add rsync && rsync -avz rsync://source-host:/data/ /data/'

# 步骤3:清理rsync服务端
# 在源主机上
docker rm -f rsync-server

6.9 数据卷大小限制

6.9.1 使用配额限制数据卷大小

Docker本身不直接支持为数据卷设置大小限制,但可以通过以下方法实现:

# 方法1:使用btrfs配额(需要Docker使用btrfs存储驱动)
# 前提:/var/lib/docker在btrfs文件系统上
sudo btrfs quota enable /var/lib/docker
sudo btrfs qgroup limit 10G /var/lib/docker/volumes/my-volume/_data

# 方法2:使用LVM创建指定大小的逻辑卷
# 创建一个10GB的逻辑卷
sudo lvcreate -L 10G -n docker-volume-data vg0
sudo mkfs.ext4 /dev/vg0/docker-volume-data

# 创建基于该逻辑卷的数据卷
docker volume create \\
–driver local \\
–opt type=ext4 \\
–opt device=/dev/vg0/docker-volume-data \\
size-limited-volume

# 方法3:使用loop设备创建固定大小的文件系统
# 创建一个10GB的文件
sudo dd if=/dev/zero of=/tmp/volume-image.img bs=1M count=10240
sudo mkfs.ext4 /tmp/volume-image.img
sudo mount -o loop /tmp/volume-image.img /mnt/volume-mount

# 创建数据卷时指向挂载点
docker volume create \\
–driver local \\
–opt type=none \\
–opt device=/mnt/volume-mount \\
–opt o=bind \\
loop-volume

# 方法4:使用XFS配额
# 挂载XFS时启用配额
sudo mount -o prjquota /dev/sdb1 /var/lib/docker
# 设置项目配额
sudo xfs_quota -x -c 'project -s -p /var/lib/docker/volumes/my-volume/_data 1'
sudo xfs_quota -x -c 'limit -p bhard=10g 1'

6.9.2 监控数据卷使用量

# 方法1:使用docker system df
docker system df -v
# 会显示每个数据卷的大小

# 方法2:直接检查宿主机上的数据卷目录
sudo du -sh /var/lib/docker/volumes/*/

# 方法3:通过容器检查
docker run –rm -v my-volume:/data alpine du -sh /data

# 方法4:监控脚本
#!/bin/bash
# monitor-volumes.sh
for vol in $(docker volume ls -q); do
SIZE=$(docker run –rm -v "$vol":/data alpine du -sh /data 2>/dev/null | cut -f1)
echo "$vol: $SIZE"
done

6.10 数据卷生命周期管理策略

6.10.1 生命周期阶段

创建 → 使用(挂载到容器) → 备份 → 迁移(可选) → 归档 → 清理/删除

6.10.2 生命周期管理最佳实践

# 1. 使用标签管理数据卷
docker volume create \\
–label app=mysql \\
–label env=production \\
–label backup=daily \\
–label retention=30d \\
–label owner=dba-team \\
mysql-prod-data

# 2. 定期备份脚本(crontab)
# /etc/crontab
# 0 2 * * * root /opt/scripts/backup-all-volumes.sh >> /var/log/volume-backup.log 2>&1

#!/bin/bash
# backup-all-volumes.sh – 备份所有标记了backup=daily的数据卷
BACKUP_DIR="/backup/volumes/$(date +%Y%m%d)"
mkdir -p "$BACKUP_DIR"

for vol in $(docker volume ls –filter label=backup=daily -q); do
echo "Backing up $vol…"
docker run –rm \\
-v "$vol":/data:ro \\
-v "$BACKUP_DIR":/backup \\
alpine:latest \\
tar czf "/backup/${vol}.tar.gz" -C /data .
done

# 清理30天前的备份
find /backup/volumes/ -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \\;

# 3. 清理无用数据卷
# 谨慎使用!先检查再清理
docker volume ls -f dangling=true
# 确认后清理
docker volume prune -f

# 4. 数据卷归档
# 将不再使用但需要保留的数据卷归档
docker run –rm \\
-v old-data-volume:/data:ro \\
-v /archive:/archive \\
alpine:latest \\
tar czf /archive/old-data-volume-$(date +%Y%m%d).tar.gz -C /data .

# 归档后删除数据卷
docker volume rm old-data-volume

# 5. 定期完整性检查
#!/bin/bash
# check-volumes.sh – 检查数据卷完整性
for vol in $(docker volume ls -q); do
echo "Checking $vol…"
docker run –rm -v "$vol":/data alpine sh -c '
if [ -d /data ]; then
FILE_COUNT=$(find /data -type f | wc -l)
SIZE=$(du -sh /data | cut -f1)
echo " Files: $FILE_COUNT, Size: $SIZE"
else
echo " ERROR: /data directory not found!"
fi
'
done

第七章 Dockerfile中的存储配置

7.1 VOLUME指令详解

7.1.1 VOLUME指令语法

VOLUME指令在Dockerfile中用于声明数据卷挂载点。当容器启动时,如果用户没有通过-v参数指定数据卷,Docker会自动为这些路径创建匿名数据卷。

# Dockerfile中使用VOLUME指令

# 语法1:JSON数组形式(推荐)
VOLUME ["/data", "/var/log/app"]

# 语法2:空格分隔的字符串形式
VOLUME /data /var/log/app

7.1.2 VOLUME指令的作用

# 示例Dockerfile
FROM ubuntu:22.04

# 创建目录
RUN mkdir -p /app/data /app/logs

# 声明数据卷
VOLUME ["/app/data", "/app/logs"]

# 设置默认命令
CMD ["sleep", "3600"]

# 构建镜像
docker build -t volume-test .

# 运行容器(不指定-v参数)
docker run -d –name auto-volume volume-test

# 查看自动创建的匿名数据卷
docker inspect auto-volume –format '{{json .Mounts}}' | python3 -m json.tool
# 输出:
# [
# {
# "Type": "volume",
# "Name": "abc123def456…", # 匿名数据卷(哈希命名)
# "Source": "/var/lib/docker/volumes/abc123def456…/_data",
# "Destination": "/app/data",
# "Driver": "local",
# "Mode": "",
# "RW": true,
# "Propagation": ""
# },
# {
# "Type": "volume",
# "Name": "xyz789ghi012…",
# "Source": "/var/lib/docker/volumes/xyz789ghi012…/_data",
# "Destination": "/app/logs",
# "Driver": "local",
# "Mode": "",
# "RW": true,
# "Propagation": ""
# }
# ]

7.2 VOLUME指令的注意事项

7.2.1 匿名数据卷问题

# Dockerfile
FROM nginx:latest
VOLUME /usr/share/nginx/html

# 每次运行容器都会创建一个匿名数据卷
docker run -d –name web1 volume-nginx # 创建匿名卷1
docker run -d –name web2 volume-nginx # 创建匿名卷2
docker run -d –name web3 volume-nginx # 创建匿名卷3

# 删除容器后,匿名数据卷不会被自动删除
docker rm -f web1 web2 web3

# 查看遗留的匿名数据卷
docker volume ls
# 会看到3个哈希命名的匿名数据卷

# 清理
docker volume prune -f

7.2.2 VOLUME指令后的RUN指令

# 重要:VOLUME指令后的RUN指令对VOLUME声明的路径无效!
# 因为VOLUME声明后,Docker知道该路径将使用外部存储,
# 所以不会将RUN指令对该路径的修改保存到镜像中

# 错误示例:
FROM ubuntu:22.04
VOLUME /app/data
RUN echo "initial data" > /app/data/initial.txt # 这行不会被保存到镜像!
# 原因:VOLUME声明后,/app/data被认为是外部挂载点,
# RUN指令中的修改只会影响临时容器的可写层,不会写入镜像层

# 正确示例:先写入数据,再声明VOLUME
FROM ubuntu:22.04
RUN mkdir -p /app/data && echo "initial data" > /app/data/initial.txt
VOLUME /app/data
# 这样initial.txt会被包含在镜像中,首次挂载时会被复制到数据卷

7.2.3 VOLUME指令与镜像层的关系

# VOLUME指令本身不创建新层,它只是在镜像元数据中添加声明
# 但VOLUME指令会影响后续指令的行为

FROM ubuntu:22.04

# 这一层会包含文件
RUN mkdir -p /app/data && echo "content" > /app/data/file.txt

# VOLUME声明(不影响已有的镜像层)
VOLUME /app/data

# 这一层不会影响/app/data(因为VOLUME已声明)
RUN echo "new content" > /app/data/newfile.txt
# newfile.txt不会被保存到镜像中!

# 构建并验证
# docker build -t test .
# docker run –rm test ls /app/data/
# 输出: file.txt (没有newfile.txt!)

7.3 VOLUME与docker run -v的交互

7.3.1 -v覆盖VOLUME声明的路径

# Dockerfile
FROM nginx:latest
VOLUME ["/usr/share/nginx/html"]

# 情况1:不指定-v,Docker创建匿名数据卷(包含镜像内容)
docker run -d –name web1 volume-nginx
docker exec web1 ls /usr/share/nginx/html
# 输出: 50x.html index.html (从镜像复制)

# 情况2:指定命名数据卷
docker run -d –name web2 -v my-html:/usr/share/nginx/html volume-nginx
docker exec web2 ls /usr/share/nginx/html
# 输出: 50x.html index.html (首次挂载时从镜像复制)

# 情况3:指定绑定挂载(不会复制镜像内容)
docker run -d –name web3 -v /tmp/empty:/usr/share/nginx/html volume-nginx
docker exec web3 ls /usr/share/nginx/html
# 输出: (空,绑定挂载不复制镜像内容)

# 情况4:挂载已有内容的数据卷(不复制镜像内容)
docker volume create pre-filled-volume
docker run –rm -v pre-filled-volume:/data alpine sh -c 'echo "existing" > /data/existing.txt'
docker run -d –name web4 -v pre-filled-volume:/usr/share/nginx/html volume-nginx
docker exec web4 ls /usr/share/nginx/html
# 输出: existing.txt (已有内容,不复制镜像内容)

7.3.2 行为总结

7.4 在Dockerfile中定义数据卷的最佳实践

7.4.1 最佳实践建议

# ============================================
# 最佳实践1:谨慎使用VOLUME指令
# ============================================

# 不推荐:在基础镜像中使用VOLUME
# 这会导致所有继承的镜像都被强制创建匿名数据卷
# FROM ubuntu:22.04
# VOLUME /data # 不推荐

# 推荐:让用户在docker run时通过-v指定
# 在文档中说明需要持久化的路径即可

# ============================================
# 最佳实践2:对于数据库镜像,声明VOLUME是合理的
# ============================================

# MySQL官方Dockerfile中声明了VOLUME
# FROM mysql:8.0
# VOLUME /var/lib/mysql
# 这样即使用户忘记指定-v,数据也会保存在匿名数据卷中
# 虽然匿名卷难以管理,但至少不会因容器删除而丢失

# ============================================
# 最佳实践3:在VOLUME之前准备初始数据
# ============================================

FROM ubuntu:22.04

# 先创建目录和初始数据
RUN mkdir -p /app/data && \\
echo '{"initialized": true}' > /app/data/config.json && \\
echo '#!/bin/sh' > /app/data/init.sh && \\
chmod +x /app/data/init.sh

# 然后声明VOLUME
VOLUME ["/app/data"]

# 这样config.json和init.sh会被包含在镜像中
# 首次挂载时会复制到数据卷

CMD ["sleep", "3600"]

7.4.2 避免在VOLUME路径下执行写操作

# 不推荐
FROM node:18-alpine
WORKDIR /app
VOLUME ["/app"] # 整个/app目录声明为VOLUME
COPY . . # COPY操作发生在VOLUME声明之后,可能有问题
RUN npm install # npm install的结果可能不被保存

# 推荐
FROM node:18-alpine
WORKDIR /app
COPY . . # 先COPY
RUN npm install # 先安装依赖
# 不声明VOLUME,让用户决定如何持久化
# 或者只声明需要持久化的子目录
VOLUME ["/app/data"] # 只持久化数据目录

7.5 多阶段构建中的数据卷处理

7.5.1 多阶段构建与VOLUME

# 多阶段构建中,VOLUME指令只在最终阶段生效

# 阶段1:构建阶段
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# 阶段2:运行阶段
FROM nginx:alpine
# 从构建阶段复制产物
COPY –from=builder /app/dist /usr/share/nginx/html
# 声明数据卷(仅在此阶段生效)
VOLUME ["/var/log/nginx"]
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

7.5.2 多阶段构建中的数据传递

# 在多阶段构建中,数据卷声明不会跨阶段传递
# 每个阶段是独立的

# 阶段1:数据准备阶段
FROM alpine AS data-prep
RUN mkdir -p /data && \\
echo "prepared data" > /data/ready.txt

# 阶段2:运行阶段
FROM alpine
# 从阶段1复制数据(这不是数据卷,是镜像层复制)
COPY –from=data-prep /data /app/data
# 声明数据卷
VOLUME ["/app/data"]
CMD ["cat", "/app/data/ready.txt"]

7.6 镜像中预填充数据卷内容

7.6.1 预填充机制

当命名数据卷首次挂载到一个非空目录时(目录中有镜像层的内容),Docker会将这些内容复制到数据卷中。这被称为"预填充"。

# Dockerfile – 预填充数据卷内容
FROM ubuntu:22.04

# 创建目录并填充初始数据
RUN mkdir -p /app/data /app/config /app/templates

# 填充初始数据文件
RUN echo '{"version": "1.0", "initialized": false}' > /app/data/default.json

# 填充配置文件
RUN echo 'server.port=8080' > /app/config/application.properties

# 填充模板文件
RUN echo '<html><body>Hello {{name}}</body></html>' > /app/templates/index.html

# 声明数据卷
VOLUME ["/app/data", "/app/config", "/app/templates"]

CMD ["sleep", "3600"]

# 构建镜像
docker build -t pre-filled-app .

# 创建命名数据卷(首次挂载会复制镜像内容)
docker volume create app-data
docker volume create app-config

# 运行容器
docker run -d –name app \\
-v app-data:/app/data \\
-v app-config:/app/config \\
pre-filled-app

# 验证数据卷中包含了镜像的初始内容
docker exec app cat /app/data/default.json
# 输出: {"version": "1.0", "initialized": false}

docker exec app cat /app/config/application.properties
# 输出: server.port=8080

# 用户可以修改数据卷中的内容
docker exec app sh -c 'echo "{\\"version\\": \\"1.0\\", \\"initialized\\": true}" > /app/data/default.json'

# 下次创建容器时,数据卷中是修改后的内容(不再复制镜像内容)
docker rm -f app
docker run -d –name app2 \\
-v app-data:/app/data \\
-v app-config:/app/config \\
pre-filled-app

docker exec app2 cat /app/data/default.json
# 输出: {"version": "1.0", "initialized": true}

7.6.2 初始化脚本模式

# Dockerfile – 使用初始化脚本填充数据卷
FROM ubuntu:22.04

# 复制初始化脚本
COPY init-data.sh /docker-entrypoint-initdb.d/
RUN chmod +x /docker-entrypoint-initdb.d/init-data.sh

# 声明数据卷
VOLUME ["/app/data"]

# 自定义entrypoint
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
CMD ["sleep", "3600"]

#!/bin/bash
# entrypoint.sh – 自定义入口脚本
set -e

# 如果数据卷为空,执行初始化
if [ -z "$(ls -A /app/data 2>/dev/null)" ]; then
echo "Initializing data volume…"
/docker-entrypoint-initdb.d/init-data.sh
fi

# 执行主命令
exec "$@"

#!/bin/bash
# init-data.sh – 初始化脚本
mkdir -p /app/data
echo '{"initialized": true, "timestamp": "'$(date -Iseconds)'"}' > /app/data/init.json
echo "Data volume initialized at $(date)"

# 构建并运行
docker build -t init-app .
docker volume create app-fresh-data
docker run -d –name app -v app-fresh-data:/app/data init-app

# 验证初始化
docker exec app cat /app/data/init.json
# 输出: {"initialized": true, "timestamp": "2024-01-15T10:30:00+00:00"}

# 重启容器,不会重复初始化(因为数据卷不为空)
docker restart app
docker logs app | grep "Initializing"
# 只在首次启动时出现

第八章 常见数据库的存储方案

数据库是容器化部署中最需要数据持久化的应用类型。本章将详细讲解MySQL、PostgreSQL、MongoDB、Redis和Elasticsearch五种常见数据库在Docker中的完整持久化方案,包括数据卷配置、配置文件挂载、日志管理、备份恢复和性能优化。

8.1 MySQL数据持久化方案(完整配置)

8.1.1 需求分析

MySQL是使用最广泛的关系型数据库之一。在Docker中部署MySQL,需要考虑以下持久化需求:

• 数据文件(/var/lib/mysql):存储所有数据库和表数据
• 配置文件(/etc/mysql):存储MySQL服务器配置
• 日志文件:包括错误日志、慢查询日志、二进制日志
• 初始化脚本:首次启动时自动执行SQL脚本

8.1.2 完整Docker Compose配置

# docker-compose.yml – MySQL完整持久化方案
version: '3.8'

services:
mysql:
image: mysql:8.0
container_name: mysql–prod
restart: unless–stopped
ports:
– "3306:3306"
environment:
MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD:–RootPass123!}
MYSQL_DATABASE: ${MYSQL_DATABASE:–appdb}
MYSQL_USER: ${MYSQL_USER:–appuser}
MYSQL_PASSWORD: ${MYSQL_PASSWORD:–apppass123}
TZ: Asia/Shanghai
volumes:
# 数据持久化 – 核心数据卷
– mysql_data:/var/lib/mysql
# 配置文件挂载
– ./mysql/conf/my.cnf:/etc/mysql/conf.d/my.cnf:ro
# 初始化SQL脚本(仅首次启动时执行)
– ./mysql/init:/docker–entrypoint–initdb.d:ro
# 日志持久化
– mysql_logs:/var/log/mysql
# 二进制日志(用于主从复制)
– mysql_binlog:/var/lib/mysql–bin
command: >
–default-authentication-plugin=mysql_native_password
–character-set-server=utf8mb4
–collation-server=utf8mb4_unicode_ci
–max_connections=500
–innodb_buffer_pool_size=512M
–slow_query_log=1
–long_query_time=2
–slow_query_log_file=/var/log/mysql/slow.log
–log_error=/var/log/mysql/error.log
–binlog_expire_logs_seconds=604800
healthcheck:
test: ["CMD-SHELL", "mysqladmin ping -h localhost -uroot -p$${MYSQL_ROOT_PASSWORD} –silent"]
interval: 10s
timeout: 5s
retries: 5
start_period: 30s
deploy:
resources:
limits:
memory: 2G
cpus: '2.0'
reservations:
memory: 1G
cpus: '0.5'
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "3"

# 备份服务(定时备份)
mysql-backup:
image: alpine:latest
container_name: mysql–backup
depends_on:
mysql:
condition: service_healthy
volumes:
– mysql_data:/var/lib/mysql:ro
– ./backup:/backup
– ./scripts/backup–mysql.sh:/backup.sh:ro
environment:
MYSQL_HOST: mysql
MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD:–RootPass123!}
BACKUP_RETENTION_DAYS: 7
entrypoint: ["/bin/sh", "-c"]
command: ["crond -f -l 2"]
# 在实际使用中,需要先安装crond或使用其他调度方式
restart: unless–stopped

volumes:
mysql_data:
name: mysql_data
labels:
app: mysql
env: production
mysql_logs:
name: mysql_logs
mysql_binlog:
name: mysql_binlog

8.1.3 MySQL配置文件

# mysql/conf/my.cnf – MySQL配置文件

[mysqld]
# 基本设置
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
default-storage-engine = InnoDB
skip-name-resolve

# 连接设置
max_connections = 500
max_connect_errors = 1000
wait_timeout = 28800
interactive_timeout = 28800

# InnoDB设置
innodb_buffer_pool_size = 512M
innodb_buffer_pool_instances = 4
innodb_log_file_size = 128M
innodb_log_buffer_size = 16M
innodb_flush_log_at_trx_commit = 1
innodb_file_per_table = 1
innodb_flush_method = O_DIRECT

# 日志设置
slow_query_log = 1
long_query_time = 2
slow_query_log_file = /var/log/mysql/slow.log
log_error = /var/log/mysql/error.log

# 二进制日志设置(用于主从复制和数据恢复)
log_bin = /var/lib/mysql-bin/mysql-bin
binlog_format = ROW
binlog_expire_logs_seconds = 604800
server_id = 1

# 安全设置
local_infile = 0
sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

[client]
default-character-set = utf8mb4

[mysql]
default-character-set = utf8mb4

8.1.4 初始化脚本

— mysql/init/01-create-databases.sql
— 创建应用数据库
CREATE DATABASE IF NOT EXISTS appdb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE DATABASE IF NOT EXISTS logdb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

— 创建应用用户
CREATE USER IF NOT EXISTS 'appuser'@'%' IDENTIFIED WITH mysql_native_password BY 'apppass123';
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'%';
GRANT INSERT, SELECT ON logdb.* TO 'appuser'@'%';

— 创建只读用户
CREATE USER IF NOT EXISTS 'readonly'@'%' IDENTIFIED WITH mysql_native_password BY 'readonly123';
GRANT SELECT ON appdb.* TO 'readonly'@'%';

— 刷新权限
FLUSH PRIVILEGES;

— mysql/init/02-create-tables.sql
USE appdb;

— 用户表
CREATE TABLE IF NOT EXISTS users (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
username VARCHAR(50) NOT NULL UNIQUE,
email VARCHAR(100) NOT NULL UNIQUE,
password_hash VARCHAR(255) NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
INDEX idx_email (email)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

— 商品表
CREATE TABLE IF NOT EXISTS products (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(200) NOT NULL,
price DECIMAL(10,2) NOT NULL,
stock INT NOT NULL DEFAULT 0,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
INDEX idx_name (name)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

8.1.5 备份与恢复

#!/bin/bash
# scripts/backup-mysql.sh – MySQL备份脚本

BACKUP_DIR="/backup/mysql/$(date +%Y%m%d)"
mkdir -p "$BACKUP_DIR"

# 1. 逻辑备份(mysqldump)
echo "[$(date)] Starting mysqldump backup…"
docker exec mysql-prod \\
mysqldump -uroot -p"$MYSQL_ROOT_PASSWORD" \\
–all-databases \\
–single-transaction \\
–routines \\
–triggers \\
–events \\
–set-gtid-purged=OFF \\
> "$BACKUP_DIR/alldatabases-$(date +%H%M%S).sql"

# 2. 单独备份每个数据库
for db in appdb logdb; do
echo "[$(date)] Backing up database: $db"
docker exec mysql-prod \\
mysqldump -uroot -p"$MYSQL_ROOT_PASSWORD" \\
–single-transaction \\
–routines \\
–triggers \\
"$db" > "$BACKUP_DIR/${db}–$(date +%H%M%S).sql"
done