最佳实践系列丨Docker EE 大规模部署指南（二）

本文首发自“Docker公司”公众号（ID：docker-cn）
编译丨小东
每周1、3、五 与您不见不散！

前情回顾

此参考架构将帮助您规划大规模 Docker 企业版部署。它涉及核心 Docker EE 平台、Universal Control Plane 以及 Docker Trusted Registry。请使用本指南来帮助肯定 Docker EE 部署的硬件和基础架构规模，并肯定针对您的具体工做负载的最佳配置。点击如下标题，回顾第一部份内容：

• 最佳实践系列丨Docker EE 大规模部署指南（一）

Docker Trusted Registry

本节论述用于实现扩展和性能的 Docker Trusted Registry 配置。

----

存储驱动

Docker Trusted Registry 支持种类繁多的存储后端。就扩展而言，后端类型能够分为基于文件系统（NFS、绑定式挂载、存储卷）和基于云/blob（AWS S三、Swift、Azure Blob Storage、Google Cloud Storage）。

对于某些用途而言，基于云/blob 的存储比基于文件系统的存储更有利于提升性能。这是由于 DTR 能够将层 GET 请求从客户端直接重定向到后备存储。经过这一操做，由 Docker 客户端拉取的实际镜像内容就没必要经过 DTR 传输，而是可由 Docker 客户端从后备存储直接获取（只要 DTR 已经获取元数据并检查凭证）。

在使用基于文件系统的存储（例如 NFS）时，要确保 DTR 性能不受基础架构约束。常见的瓶颈包括主机网络接口卡、随 DTR 部署的负载均衡器、后端存储系统的吞吐量 (IOPS) 和延迟，以及 DTR 从节点主机的 CPU/内存。

Docker 已经测试过 DTR 性能，肯定它能够使用带有 3 个从节点的 NFS 后备存储，处理 1 GB 容器镜像的 1400 多个并发拉取。

总计存储

了解将来镜像存储总计要求的最佳办法是收集和分析下列数据：

• 镜像平均大小
• 镜像更新/推送的频率
• 镜像更新大小的平均大小（要考虑许多镜像可能共享通用基础层）
• 存储旧镜像工件的保留策略和要求

使用 Docker Trusted Registry 垃圾回收结合（使用 DTR API）删除旧镜像的脚本或其余自动化工具，保持对存储使用的控制。