容器内修改不持久化的根本原因是镜像只读、容器叠加可写层，停止后该层即销毁；需通过挂载（Bind Mount/Named Volume）、ConfigMap/环境变量注入或模板渲染等方式将数据移出容器生命周期。
容器内修改不持久化，根本原因在于镜像与容器的分层设计：镜像是只读模板，容器运行时叠加一层可写层；一旦容器停止或删除，这层可写内容就没了。要让修改留存，必须把数据从“容器生命周期内”转移到“容器生命周期外”。
理解镜像与容器的分层关系
镜像由多层只读层构成（如操作系统基础、软件安装、配置文件），启动容器时 Docker 会自动添加一个可写层（UpperDir）。所有你在容器里做的修改——改 /etc/nginx/nginx.conf、写日志、存数据库文件——都落在这一层。它和容器绑定，容器消失，这层就销毁。
所以，“在容器里直接改配置”本质上是在临时沙盒里操作，不是生产级做法。
用挂载方式把配置/数据移出容器
这是最常用也最推荐的方式，核心是绕过可写层，让文件直接落在宿主机上：
-
Bind Mount（绑定挂载）：适合开发调试或需精细控制路径的场景
例如：docker run -v /host/conf/nginx.conf:/etc/nginx/nginx.conf nginx
宿主机上的配置文件被直接映射进容器，改它就等于改容器里的，且重启不失效。 -
Named Volume（命名卷）：Docker 管理、跨容器共享、更易备份迁移
例如：docker volume create nginx-conf，再用-v nginx-conf:/etc/nginx/conf.d挂载
适用于数据库数据目录、日志目录等需要长期保留的内容。 -
注意避坑：如果挂载的是空目录，会覆盖容器内原有文件；挂载文件时权限要匹配（如用
:ro只读挂载配置，防误改）。
用 ConfigMap 或环境变量注入配置（K8s 或轻量脚本方案）
对于需要动态生成的配置（比如根据环境填入 IP、端口），硬编码挂载静态文件不够灵活：
- Kubernetes 下用 ConfigMap 或 Secret 挂载为文件或环境变量，声明式管理，更新后滚动生效；
- 单机 Docker 可用 envsubst + 模板文件：
准备nginx.conf.template含$DB_HOST占位符，配合--env-file .env启动，用 shell 命令实时渲染后写入目标路径。
避免用 docker commit 保存配置（除非极特殊场景）
虽然 docker commit 能把当前容器状态打成新镜像，但存在明显缺陷：
- 镜像体积膨胀快（每改一次就多一层）；
- 无法复用基础镜像的安全更新；
- 配置和代码耦合，违背“不可变基础设施”原则；
- 不适合 CI/CD 流水线——你没法用 Git 追踪一次
commit产生的二进制镜像差异。
它只适合快速验证或离线环境临时固化，不能作为持久化配置的常规手段。
