Docker 与容器：优势、运维成本及平台选择

镜像、容器与虚拟机

应用可能在测试中正常，却因运行时版本、缺少库或未被注意的本地设置，在服务器上失败。容器通过让可追溯的软件包贯穿开发、测试与生产，减少这些差异。它不能替代合适的架构或责任明确的运维。

镜像是带版本的应用包和运行时文件，容器是其运行实例。配置和凭据应单独提供，持久数据应独立存储。Linux 容器共享运行环境的内核，而虚拟机具有自己的客户操作系统。容器常在虚拟机中运行，因此两种方案可以相互补充。

“处处完全相同”的说法过于宽泛：处理器架构、操作系统、权限、外部服务和内存仍会影响行为。镜像可能很大，应用也可能因加载数据而启动缓慢。应衡量真实的发布改进，而不是假设部署一定更小或更快。

依据实际情况选择平台

Docker 文档介绍了使用生产专属配置，在单台生产服务器上运行 Compose 的方式。Compose 并不限于开发，但它本身不会建立高可用的多服务器环境。

当独立发布、大量工作负载和自动调度能够解决反复发生的运维工作时，再考虑 Kubernetes。重启需要可用容量、数据和依赖。低中断发布需要足够的运行实例，以及过渡期间相互兼容的版本。

• 小型内部门户、单一团队：使用虚拟机、Compose 和有文档的部署流程，并接受单主机共同故障风险。
• 公共应用、平台人员较少：考虑托管容器服务，同时评估平台限制、使用成本与数据导出。
• 多个团队、独立服务：考虑编排，可能包括 Kubernetes，并明确集群、网络、策略和平台更新的责任。

示例：带夜间导入的客户门户

假设门户由 Web 应用、数据库和导入进程组成，由小团队一起发布。可以把应用和导入器构建成分别可识别的镜像，同时让数据库保留在已经管理良好的现有平台。可复现的应用发布并不要求同时迁移全部数据。

测试将用于生产的同一组镜像，但使用独立凭据和测试数据。依据测量为导入器设置内存上限，避免大文件不可预测地挤占门户资源。扩展到多主机之前，应明确准备共享文件、会话和导入状态，以适应该设计。

可复现构建仍然需要更新

多阶段构建将构建工具与运行时镜像分开。固定依赖和可识别的基础镜像使发布可复现，但也冻结了当时的软件版本。已有镜像不会自动收到新软件包。应安排重新构建并测试镜像。

记录镜像标识、源码修订、配置变更和数据库迁移。latest 这类可变标签本身并不足够。秘密应保存在环境的凭据管理系统中；将它们写进镜像，会随每次下载扩散，也会增加轮换难度。

数据与回退才是更困难的部分

重启容器可以替换应用进程，却不能恢复被意外修改的客户数据。持久卷和数据库需要经过测试的备份。只有旧镜像能够理解当前数据结构时，它才是有效回退选择；必要时应将变更分成相互兼容的阶段。

选择平台前，应约定可容忍停机时间、发布支持，以及休假或病假时的替岗。成本包括镜像仓库、日志、监控、备份和人员时间。一台需要大量手动支持的低价服务器，总成本可能高于托管服务。

以现有问题衡量试点

记录谁负责构建应用、哪些发布步骤是手动的，以及测试与生产的差异。选择边界明确、依赖已知、故障后果可控的应用。缺少文档的关键核心系统，通常不适合同时承担学习新运行平台的任务。

设定可验证目标：第二个人能够仅依据文档，将已批准版本部署到空白测试环境。衡量实际操作时间、总耗时和手动修正次数。再用另一版本重复验证；一个容器成功启动，不能构成充分证据。

真实地测试资源与故障

使用有代表性的工作负载：并发登录、一次搜索，以及通常可能出现的最大导入。观察响应时间、内存、CPU 和可用磁盘空间。只有清楚到达边界后的行为，资源限制才有价值；限制过紧本身也可能引发事故。

在测试中演练重启、依赖暂时不可用，以及后台任务失败。预期结果应是错误清晰、不悄悄重复工作，并且日志能够识别发布版本。目标是形成可控的故障处理过程，而不是随意收集故障场景。

第二次发布检验可运维性

验收应包含一次镜像更新和一项较小、兼容的数据变更。发布前后检查约定的用户流程。记录何时可以返回旧镜像、何时必须先协调新数据，而不是等到中断时才决定。

交接应分配基础镜像、主机、运行时、镜像仓库和应用维护的责任，即使这些工作全部由同一供应商承担。明确镜像保留、日志容量和增长告警。只有更新与替岗都能正常执行时，才应把试点作为可复用标准。