第5章 泊位与堆场：网络与数据
第5章 · 泊位与堆场：网络与数据
章节摘要：本章跟着一条线走——把一只孤箱变成系统的一员：给它接航道（网络模式与容器互联），给它配仓库（数据卷与绑定挂载），最后用一套持久化策略保证"箱子可以沉没，货物必须永存"。
一条主线
值班手册毕业，你接到的第一个系统级任务：把一个 Web 应用和它的数据库组建成一支小船队。任务书上有两条硬指标——应用要能访问到数据库（通信），数据库的数据要能扛住任何一只箱子的拆除（持久化）。本章五节就是这项工程的全套技术。
先看工程全景：航道与仓库如何撑起一支船队。
这张图里藏着本章的认知主线：对外走泊位（端口映射），对内走航道（容器网络），长期货物进仓库（数据卷）。三句话分别对应 5.1、5.2 与 5.3。
分工的内在逻辑也值得说一句：泊位与航道解决"路"的问题——路通了，箱子之间才能协作；仓库解决"命"的问题——命续上了，协作才有意义。两半知识合起来，才撑得起下一章的编队编排：Compose 声明文件里写的网络与卷，正是本章概念的自动化版本。所以本章的每个实验都值得亲手做——它们是第 6 章每行声明的实体注脚。
沿途站点
5.1 容器网络模式：四种泊位类型
航道系统的总览：bridge（默认内港）、host（贴岸直靠）、none（封闭泊位）、overlay（跨港航线）四种模式的机制与适用场景。这一站讲清容器网络与宿主机网络的边界，是理解一切互联问题的基础。
5.2 自定义网络与容器间通信
组建船队的核心手艺：自定义桥接网络里，容器名就是域名——用名字互访，不用记 IP。这一站完成主线任务的通信半场，并讲清为什么默认桥接网络不该拿来跑业务互联。
5.3 数据卷与绑定挂载
持久化的两种形态：数据卷（引擎管理的标准仓库，首选）与绑定挂载（把宿主机目录直接搬上船）。这一站用实验验证卷的生命周期独立于容器，并给出两者的选型规则。
5.4 数据持久化策略与备份
仓库管理的运营篇：数据库箱子怎么配卷、备份怎么做（临时箱子加卷的旁路备份法）、迁移怎么搬（卷数据打包过船）。这一站把 4.5 的配额纪律与本章的卷纪律合成一套上生产的标准动作。
五节分工可以再压缩成一张时刻表：5.1 看地图、5.2 修航道、5.3 建仓库、5.4 定运营纪律。前两节是网络半场，后两节是数据半场，两半可以分两次上机；但 5.2 与 5.3 的实验建议同一天做完——主线任务的验收（应用连得上数据库、且数据不丢）要两条线同时通才算数。演习留下的容器、卷与网络也别忘清理，各节末尾都有收尾命令，养成"演习完毕现场归零"的习惯——第 6 章的编队练习要从干净现场出发，这是它起航前的既定前提。
拐点与结论
本章最重要的认知转折在 5.1 到 5.2 之间：容器互联的钥匙是"网络边界"而不是 IP 地址。默认桥接网络里容器只能靠 IP 互访（还会随重启漂移），自定义网络里容器名就是稳定域名——这是引擎内建的域名解析在工作。理解了"同一个自定义网络 = 一个局域泊位区"，多容器通信从碰运气变成确定性设计。
第二个转折在 5.3：数据的生命与容器的生命必须解耦。可写层随箱焚毁（第 3 章的实验），卷的生命独立记账——容器可以随时重建，卷里的数据库文件原地不动。想通"容器是牲口，数据是家产"，你对有状态应用的部署设计会自然长出一套纪律。
本章落点一句话：泊位管进出的路，航道管箱与箱的路，仓库管数据的路。三条路各自设计好，你的船队才配叫系统。
读完你应该
- 说出四种网络模式的机制差异，并为"隔离跑批任务"选对模式（none）并说明理由。
- 建自定义网络、把两只容器接入并用容器名互访，解释默认桥接网络为何不适合业务互联。
- 区分数据卷与绑定挂载的机制与适用场景，说出生产数据选卷的两条理由。
- 为数据库容器完成"卷挂载加配额加重启策略"的完整配置。
- 独立完成一次卷数据备份与恢复演练。
下一章的接力
航道与仓库齐备，船队的规模却在膨胀：手工逐只起吊、逐条配网络的作业方式开始出错。下一章引入 Compose——把整支船队的配置写成一份声明文件，一键起航、一键收港，多容器应用从此工程化。