Docker 基础模型：镜像、容器、网络与数据卷

动手前先知道

这篇文章对应的真实任务是：用一张运行对象模型讲清镜像、容器、仓库、网络、端口映射和数据卷之间的关系。

第一次阅读先弄清“为什么需要这一步、它改变了哪个运行对象、失败时去哪里检查”，再执行命令。命令可以查，运行模型和排障路径才是长期能力。

这一章先把 Docker 的基础模型打牢。只要理解镜像、容器、仓库、网络、数据卷这几个对象，后面的 Dockerfile 和 Compose 就不会乱。

Docker 最容易学糊的地方是：把镜像和容器混在一起，把数据写进容器，把网络端口和容器端口混在一起。这些问题在个人项目上线时都会变成真实故障。

Docker 基础对象关系

它从哪里来

早期服务器部署通常直接在主机安装依赖，不同应用容易互相影响。虚拟机通过完整客体操作系统提供强隔离，但启动和资源成本较高。Linux 容器共享宿主机内核，只隔离进程看到的环境；镜像、容器、网络与数据卷正是这种模型的主要对象。

镜像是什么

镜像可以理解成“应用运行环境的模板”。

比如一个 Go 后端镜像里可能包含：

编译好的 Go 二进制文件。
运行时需要的证书、时区、系统库。
容器启动时执行的命令。
暴露的服务端口。

镜像本身不运行，它只是一个只读模板。真正运行起来的是容器。

容器是什么

容器是镜像启动后的一个运行实例。

同一个镜像可以启动多个容器，就像同一个安装包可以安装多次。但容器里的文件系统通常是临时的，容器删掉后，写在容器内部的数据也可能丢失。

所以生产环境不要把重要数据只放在容器内部。

仓库是什么

仓库用于保存和分发镜像。

常见流程是：

本地构建镜像
  ↓
打版本标签
  ↓
推送到镜像仓库
  ↓
服务器拉取指定版本
  ↓
重启服务

个人项目早期可以先在服务器本地构建镜像，等上线流程稳定后，再接入镜像仓库。

网络是什么

Docker 网络解决容器之间如何互相访问。

在 Compose 里，服务之间通常可以直接用服务名访问：

api 访问 mysql:3306
nginx 访问 web:3000
nginx 访问 api:8080

这里的 mysql、web、api 不是公网域名，而是 Compose 内部网络里的服务名。

数据卷是什么

数据卷用于保存需要跨容器重建仍然存在的数据。

适合放进数据卷的内容：

MySQL 数据目录。
Redis 持久化文件。
上传到本机磁盘的文件。
Nginx 证书目录。

不适合放进数据卷的内容：

应用代码。
构建产物。
临时缓存。
可以重新生成的文件。

对小艾知行录来说，生产环境如果使用服务器本机 MySQL，就必须给 MySQL 配置 volume。否则容器删除后，数据库数据就危险了。

端口映射怎么理解

容器内部端口和宿主机端口是两回事。

例如：

ports:
  - "8088:80"

意思是：

宿主机访问 8088。
Docker 转发到容器内的 80。

公网真正暴露的是宿主机端口。生产环境一般只暴露 Nginx 的 80/443，不直接暴露 MySQL、Redis、后端 API 的内部端口。

这一章的结论

你可以把 Docker 看成一套运行对象模型：

Dockerfile 负责描述镜像怎么构建
镜像负责封装应用运行环境
容器负责运行镜像实例
网络负责容器之间通信
数据卷负责保存持久数据
Compose 负责把多个容器组织成一个系统

把这几个关系想清楚，Docker 后面的内容就顺了。