如何在裸机基础设施上托管容器镜像仓库

容器镜像仓库会为开发、测试及生产环境存储和提供容器镜像，以及其他符合 OCI 标准的工件。在裸机上托管镜像仓库，可以为服务提供专用的物理基础，但单靠服务器规格并不足以令服务达到生产要求。

可靠的设计需要把存储、网络容量、身份验证、镜像生命周期、备份及集群访问连接起来。应先了解镜像如何构建及使用，再按推送与拉取并发量、保留要求、恢复目标及团队能够维持的运营模式规划裸机环境。

界定生产镜像仓库的范围

先列出镜像仓库需要存储的内容及使用者，包括应用程序镜像、多架构清单、构建工件、安全资料、CI/CD 系统、Kubernetes 集群、开发人员及外部部署环境。

• 选择符合所需控制程度的受支持的镜像仓库平台。CNCF Distribution 适合需要镜像仓库服务及存储控制的团队；如果运营模式需要更完整的项目管理及生命周期管理，也可以评估 Harbor 等平台。
• 规划时应以推送及拉取的并发量，而不是平均流量作为基础。镜像层可能很大，多个构建可能同时完成，而集群重启也可能在短时间内产生大量拉取请求。在决定服务器是否有足够容量前，应测试从构建执行器到镜像仓库，再到部署节点的完整路径。

不要把镜像仓库视为临时文件共享服务。在正式部署镜像依赖镜像仓库前，应先界定支持的 OCI 或 Docker 客户端版本、镜像命名规则、保留策略、访问边界、维护时段及服务负责人。

提示：即使镜像仓库服务本身是无状态的，也应把镜像仓库视为生产环境的依赖服务。

选择配合工作负载的架构

对于小型内部团队而言，如果具备经过测试的备份及清晰的恢复流程，在独立服务器上使用单个镜像仓库节点可以是实际的起点。这样可以简化网络路径，并让团队直接控制 CPU、内存、磁盘及操作系统维护。

• 当可用性及流量要求提高，便应把镜像仓库服务与持久存储分开，并置于负载均衡器之后。多个镜像仓库节点、共享或复制存储及经过测试的故障转移设计，可以减少单个服务器故障的影响，但也会增加运营依赖。
• 同时应界定故障范围：决定部署期间镜像仓库是否可以暂时不可用、持久存储放在哪里，以及客户端如何切换至恢复后的端点。

Dataplugs 关于不同行业的独立服务器基础设施的指南也说明，基础设施模式应配合工作负载的应用程序、行业情境及运营责任。

仔细设计存储及网络容量

裸机可以为镜像传输提供较可预测的磁盘及网络资源，但设计仍需要预留容量。应按当前镜像层、标签数量、构建频率、保留时间，以及临时上传及恢复操作所需空间计算存储需求。

• 采用能够避免操作系统受镜像仓库增长影响的存储配置。选择受支持的文件系统或存储后端，监测磁盘延迟及容量，并决定如何在不影响重要推送与拉取的情况下执行垃圾回收。
• 为 CI 执行器及部署集群提供快速、适当时采用私有网络，而且容易监测的网络路径。TLS 终止、DNS、防火墙规则、MTU 设置及带宽限制，都应在并发镜像层传输下测试，而不应只按端口速度推断。

对于需要扩展构建及部署活动的团队，Dataplugs 关于扩展 SaaS 平台的指南也重申同一原则：基础设施应配合应用程序的流量模式、部署方式及运营纪律。

保护镜像仓库访问及镜像供应链

镜像仓库流量应使用 TLS，并在读取或修改私有仓库前要求身份验证。应分开管理管理员、开发人员、CI 及部署权限，避免构建凭证被入侵后可以直接管理整个镜像仓库。

• 使用权限范围有限的机器人或服务账户，定期轮换凭证，并禁止匿名推送。镜像仓库凭证不应存放在镜像或源代码中，同时应记录身份验证、仓库及管理活动，方便日后检查。
• Kubernetes 部署应使用集群支持的私有镜像仓库凭证方式，例如 imagePullSecrets，并把凭证范围限制在需要使用的命名空间及工作负载。应测试正常拉取及凭证过期时的失败情况，让问题在部署前暴露。

镜像扫描、签名、固定摘要及准入控制可以加强供应链，但每项控制都需要受支持的集成方式及负责人。镜像仓库应被视为应用程序安全边界的一部分，而不是独立的存储服务器。

规划备份、保留及恢复

镜像仓库恢复计划不应只涵盖镜像目录。应确认所选平台所需的镜像仓库配置、证书、身份验证设置、仓库数据、存储后端，以及任何数据库或外部服务。

• 为支持生产环境的镜像订立恢复点及恢复时间目标。至少保留一份与镜像仓库主机分开的备份，保护敏感备份数据，并清晰制定保留规则，避免需要回滚的镜像被意外删除。
• 快照可以缩短恢复时间，但不应是唯一备份。应使用独立备份或复制路径，记录服务及存储的恢复顺序，并以接近生产环境的客户端测试从恢复镜像仓库拉取镜像。

完成恢复后，应使用与生产环境相同类型的客户端，验证身份验证、仓库列表、镜像清单拉取、镜像层拉取、镜像推送及回滚流程。

把镜像仓库作为生产服务运营

监测 CPU、内存、磁盘延迟、存储容量、网络吞吐量、推送及拉取延迟、请求错误、身份验证失败、证书到期、上传失败及其他关键指标。警报应协助团队分辨问题来自镜像仓库、存储、网络、客户端还是部署平台。

• 应按构建及部署活动安排垃圾回收、镜像仓库升级、证书轮换及存储维护。为镜像仓库配置回滚路径，并使用具有代表性的镜像测试升级，包括多架构镜像及大型镜像层。
• 当流量增长时，应按实际限制服务的组件进行扩展，可能是存储吞吐量、镜像仓库节点、网络容量、身份验证，或拉取镜像的部署集群。只有在衡量显示需要时才加入缓存或复制，并记录新增的故障模式。

如需提高可用性，Dataplugs 关于多站点托管架构的指南说明，复制、网络设计、故障责任及恢复测试应一并规划，而不是在事故后才补充。

实用的部署检查清单

可以问六个问题：需要存储哪些镜像及工件？推送及拉取的高峰并发量是多少？在保留及恢复预留空间后，需要多少存储？谁可以推送、拉取、管理及恢复？镜像仓库无法使用时会发生什么？团队如何测试及证明恢复能力？

如果镜像仓库只供内部使用而工作负载较小，具备严格访问控制、独立备份、监控及经过测试恢复流程的单个独立服务器可能已经足够。如果镜像仓库支持多个集群或重要业务部署，便应规划多个节点、具韧性的存储、受控复制及清晰的故障转移程序。

应在 CI/CD 及部署操作手册中保持镜像仓库地址、镜像命名、凭证、备份流程及回滚步骤一致。当物理、网络、软件及责任边界清晰，裸机镜像仓库会更容易运营。

总结

在裸机基础设施上托管容器镜像仓库，可以提供较可预测的物理资源、对镜像存储的控制，以及连接构建与部署系统的私有网络路径。实际效益取决于正确规划容量、安全访问、生命周期管理及恢复测试。

Dataplugs 的独立服务器为团队建立符合工作负载的镜像仓库环境提供稳定的物理基础。应先确认镜像及流量要求，验证完整的推送与拉取路径，再选择团队能够长期保护、运营及恢复的平台。

如需了解更多信息，请浏览 Dataplugs 网站或联系 sales@dataplugs.com。