Debian 环境下 Docker 的常见误区与规避
一 镜像与构建
- 把应用“打进运行中的容器”或直接用 docker commit 生成镜像，导致不可复现与难以版本化；应使用 Dockerfile/S2I 构建，保证一致性与可审计。
- 使用过大的镜像或单层镜像，分发慢、缓存失效；应仅保留运行必需文件，采用多阶段构建、合理分层，优先 Debian slim/Alpine 等轻量基础镜像。
- 依赖 latest 标签或随意浮动基础镜像，上线后易出现不兼容；应显式指定版本标签，并在构建时使用 –pull 拉取最新基础镜像，必要时 –no-cache 重建。
- 在镜像内硬编码密钥/密码；应通过 环境变量/Secret 管理外部注入。
- 在 Dockerfile 中执行 apt update && apt upgrade 产生“脏层”，且缓存导致更新滞后；应在同一 RUN 中更新并清理缓存，配合 –pull 与定期重建策略。
二 运行与安全
- 以 root 在容器内运行进程，扩大攻击面；应在 Dockerfile 中创建并切换到非 root 用户（USER）。
- 过度授予能力或直接 –privileged；应默认 –cap-drop=ALL，仅按需添加最小必要能力，降低被提权风险。
- 依赖容器 IP 进行服务发现；IP 随启停变化，应使用 Docker 网络/服务名/环境变量进行通信。
- 在容器内存储业务数据；容器可随时被替换，应使用 Volume/Bind Mount 持久化，并注意多容器写冲突。
- 单容器跑多进程，导致日志、升级、信号难以管理；应坚持一容器一主进程模型。
三 网络与端口
- 直接依赖容器 IP 或假设端口不变；应通过自定义网络/别名或编排系统的服务发现来连接。
- 在容器内监听 1–1024 端口并以非 root 运行；非 root 无法绑定低位端口，需改用 >1024 端口或通过反向代理/网关转发。
四 Debian 与版本管理
- 忽视 Debian 基础镜像的安全补丁节奏，镜像更新滞后；应在构建时执行 apt-get update && apt-get -y upgrade，并使用 –pull 确保基础镜像为最新。
- 客户端/服务端 API 版本不匹配（如 client too old）；应统一 Docker 版本，或在 CI 中固定版本矩阵。
- 首次运行或升级后 Docker 服务未启动导致命令失败；应确认 docker.service 处于 active 状态。
- 端口冲突导致容器启动失败；应检查并释放占用端口或更改映射。
五 快速自检清单
- 镜像是否：使用显式版本标签、采用 多阶段构建、层尽可能少且可复用、无硬编码密钥、基础镜像定期更新（含 –pull）。
- 运行是否：以非 root运行、最小能力集（必要时再加）、数据走 Volume、只映射必要端口、通过服务名/网络别名通信。
- 运维是否：固定 Docker 版本避免 API 不兼容、变更前后做镜像与配置版本化、上线前做端口与资源冲突检查。