容器

Docker：被后来者不断模仿的容器引擎

作者 Kinetikatech Operations Team · 更新于 2026-09-24

Docker 让容器成为通用语言：镜像、仓库和 CLI 把“在我机器上能跑”变成了打包问题。它仍是大多数托管环境默认的引擎，而镜像卫生、守护进程安全和 Compose 工作流决定容器是降低还是只是转移运维风险。

要点

心智模型是镜像加层：每个镜像由缓存层堆叠而成，每条 Dockerfile 指令生成一层，构建顺序决定缓存命中；多阶段构建让最终镜像更小，构建工具链不会进入生产。
守护进程是高权限面：以 root 运行的 Docker 守护进程和 API socket 在主机上等同 root；把 socket 暴露给容器（经典的 -v /var/run/docker.sock）等于交出整台机器。2026 年的做法是无根模式、用户命名空间和 socket 审计。
Compose 是小型环境的标准：用代码声明多服务栈、卷、网络和健康检查；大多数托管负载不需要编排器，声明依赖、健康检查和重启策略才能让小环境稳定。
资源治理交给 cgroups：共享主机上必须为每个容器设置内存和 CPU 限制，否则一次泄漏的构建或失控的 cron 会吃光主机；日志默认写成巨大的 JSON 文件，不配置轮转就会撑满磁盘。
镜像卫生就是供应链卫生：做 CVE 扫描（如 Trivy）、用 digest 固定镜像而不是可变 tag、绝不把密钥烤进层（构建参数会泄漏，挂载不会），需要时使用带签名验证的私有仓库。
诚实边界：Docker Swarm 仍在，但行业势头在 Kubernetes；仓库、存储驱动和网络模型都增加学习面。对托管业务而言，最佳区间仍是少数监控良好的主机上运行 Compose 栈。

让我们写下资源限制规则的那次事故：一个没有限制的构建容器吃光了主机内存，顺带拖垮了旁边的数据库。那一周所有东西都加了限制，之后又遇到三次失控构建，都没有再报警。

有了 Podman，Docker 是否已经过时？

没有。Docker 仍是几乎所有人都支持的默认引擎，Podman 也明确追求 CLI 兼容。选择更多是守护进程与无守护进程的安全姿态，以及操作系统环境（RHEL 常带 Podman，Ubuntu 生态多用 Docker）。

Docker 主机上最先做的五个安全动作是什么？

无根或 userns-remap 模式；不把 socket 绑定进容器；所有容器都设资源上限；CI 中自动扫描镜像；在第一次磁盘写满之前配置日志轮转。

有了容器就不需要给主机打补丁了吗？

绝对不是。主机内核、引擎和存储栈仍要打补丁；容器只是把应用层的补丁节奏变成重建镜像，只有真正触发重建才有收益。

什么时候 Docker 属于过度设计？

单服务、单运行时的机器（例如一台 PostgreSQL 或一个 WordPress 主站），打补丁良好的原生安装暴露面更小、监控更简单；只有当镜像可移植或多服务隔离带来实际价值时，容器才划算。

这类问题我们已处理过数百次：生产环境中容器的管理、编排与安全。通过服务器管理和Linux 服务器安全，您将获得完整闭环：我们评估、实施、全天候值守，并在关键时刻 30 分钟内响应。