本文首发自“Docker公司”公众号（ID：docker-cn）
编译丨小东
每周一、三、五 与您不见不散！
Docker 企业版 (Docker EE) 是 Docker Inc 推出的旨在用于整条软件供应链的企业级容器平台。它是一种完全集成的解决方案，用于开发、部署和管理基于容器的应用程序。借助集成的端到端安全性，Docker EE 通过对您的基础架构进行抽象，使应用可以无缝地从开发转入生产，从而实现了应用程序的可移植性。
您将学到的知识
此参考架构描述了一种标准的生产级 Docker EE 部署。它还详细说明了 Docker EE 的各种组件，包括它们如何工作，如何自动化部署，如何管理用户和团队，如何为平台提供高可用性，以及如何管理基础架构。
本文将不会提供某些特定于环境的配置细节。例如，各种云平台和本地部署基础架构上的负载均衡器有很大差异。对于这些类型的组件，提供了对于特定于环境资源的一般指导原则。
了解 Docker 组件
从开发到生产，Docker EE 为本地以及云端的容器化应用程序提供了无缝的平台。Docker EE 分为三个级别，以满足不同的应用需求。Docker EE 标准版（原名 Docker Datacenter）和 Docker EE 高级版都包含下列组件：
- Docker EE 基础版（原名“商业支持版”或“CS”引擎），即商业支持的 Docker 容器运行时和平台；
- Universal Control Plane (UCP)，基于 Web 的统一集群和应用管理解决方案；
- Docker Trusted Registry (DTR)，具有弹性的安全镜像管理仓库；
它们合在一起提供了一套集成解决方案，其设计目的如下：
- 捷性性 — 使用 Docker API 与平台对接，确保可运作的功能不会拖慢应用程序交付速度；
- 可移植性 — 平台将为应用程序的基础架构的详细信息进行抽象；
- 可控性 — 环境在默认情况下是安全的，提供鲁棒的访问控制，以及所有操作的日志记录；
为了实现这些目标，平台必须具备弹性和高度的可用性。此参考架构演示了这种鲁棒的配置。
Docker EE 基础版
Docker EE 平台负责容器级别的操作，与 OS 进行交互，提供 Docker API，并运行 Swarm 集群。该引擎也是包括 OS 资源、联网和存储在内的基础架构的集成点。
Universal Control Plane（UCP）
UCP 通过提供集成的应用管理平台来扩展 Docker EE 基础版。它既是用户的主要交互点，也是应用的集成点。UCP 在集群中的所有节点上运行代理程序来监视它们，并且在控制器节点上运行一组服务。这些服务包括用于管理用户的身份服务，用于用户和集群 PKI 的认证中心 (CA)，提供 Web UI 和 API 的主控制器，用于 UCP 状态的数据存储，以及用于向后兼容的经典 Swarm 服务。
Docker Trusted Registry（DTR）
DTR 是一个由 UCP 管理并与其集成的应用程序，它提供 Docker 镜像分发和安全服务。DTR 使用 UCP 的身份服务提供单点登录 (SSO)，并建立相互信任，从而与其 PKI 集成。它以一组服务的形式运行于一个或多个从节点，其中包括用于存储和分发镜像的镜像库、镜像签名服务、Web UI、API 和用于镜像元数据和 DTR 状态的数据存储。
Swarm Mode
为了提供基于若干节点的无缝集群，DDC 需要依靠 Docker swarm mode 功能。Swarm mode 将节点分为工作节点（运行定义为服务的应用工作负载的节点）和管理节点（负责维护所需状态、管理集群的内部 PKI 和提供 API 的节点）。管理节点也可以运行工作负载。在Docker EE 环境中，它们运行的是 UCP 控制器，而不应该运行其他任何项目。
Swarm mode 服务模型为工作负载提供一种声明式所需状态，可扩展到若干个任务（服务的容器），可以通过稳定的可解析名称访问，而且可以选择暴露端点。可以从任何节点在全集群保留端口上访问暴露的服务，它们通过网格路由（使用 Linux 内核中的高性能交换的快速路由层）与任务通信。这一组功能实现了服务的内部和外部可发现性，UCP 的 HTTP 网格路由 (HRM) 则添加了主机名到服务的映射。
一种标准部署架构
本节演示 Docker EE 的一种标准生产级架构，它使用 10 个节点：3 个 UCP 控制器，3 个用于 DTR 的节点，以及 4 个用于应用工作负载的工作节点。工作节点的数量是任选的，大多数环境会根据应用需求增加工作节点数量，这不会改变架构或集群配置。
对环境的访问是通过 3 个负载均衡器（或 3 个负载均衡器虚拟主机）实现的，它们有与 UCP 控制器、DTR 从节点和集群中运行的应用对应的 DNS 条目。
DTR 从节点使用共享的镜像存储。本节中会论述与 S3 兼容的对象存储（默认）以及 NFS 存储。
节点大小
一个节点就是集群（虚拟或物理）中的一台运行Docker 引擎的机器。在配置每个节点时，都要给它分配一个角色：UCP控制器、DTR 或工作节点，从而使它们受到针对运行中的应用工作负载的保护。
要在 CPU、RAM 和存储资源方面确定节点应有的大小，请考虑下列因素：
- 所有节点都应该至少达到 UCP 2.2 的最低要求：2 GB RAM 和 3 GB 存储空间。更详细的要求请参见 UCP 文档。
- 应该为 UCP 控制器节点提供高于最低要求的资源，但如果这些节点上不运行其他任何项目，则不必分配太多资源。
- 理想的工作节点大小将根据您的工作负载而定，所以定义通用的标准大小是不可能的。
- 其他考虑因素包括目标密度（平均每个节点的容器数量）、需要一种标准节点类型还是多种类型，以及可能影响大小选择的其他运行考虑。
如有可能，应该通过试验和实际工作负载测试来确定节点大小，而且应该通过反复迭代来优化。下列做法是很好的起点：在您的环境中选择一种标准或默认的机器类型，并且仅使用这种机器的大小。如果标准机器类型提供的资源多于 UCP 控制器的需求，那么就应该为这些节点选择更小的节点大小。无论最初的选择是什么，务必监视资源使用情况和成本以改进模型。
两种示例方案：
- 一种标准节点大小：2 个 VCPU，8 GB RAM，20 GB 存储空间；
- 两种节点大小：2 个 VCPU，8 GB RAM，20 GB 存储空间，用于 UCP 控制器；4 个 VCPU，64 GB RAM，40 GB 存储空间，用于工作节点；
根据您选择的 OS，Docker 引擎的存储配置可能需要一些规划。请参阅支持矩阵以了解哪些存储驱动程序被支持用于您的主机 OS。如果您使用 RHEL 或 CentOS，这一点尤其重要，因为它们使用 device mapper 及 direct-lvm。
负载均衡器
负载均衡器的配置应该在安装之前完成，包括 DNS 条目的创建。大多数负载均衡器应该都能与 Docker EE 配合工作。仅有的要求是 TCP 透传和在 HTTPS 端点上执行健康检查的能力。
在我们的示例架构中，三个 UCP 控制器确保了在节点发生故障或控制器重新配置时的 UCP 弹性。通过 GUI 或 API 对 UCP 的访问始终是使用 TLS 完成的。负载均衡器配置为在端口 443 上进行简单的 TCP 透传，并使用位于 https:///_ping 的定制 HTTPS 健康检查。
务必为 UCP 主机创建 ucp.example.com 之类的 DNS 条目，并指向负载均衡器。
三个 DTR 从节点的设置与 UCP 控制器的设置类似。在这些节点上同样使用 TCP 透传至端口 443，但健康检查是在 https:///health。
为 DTP 主机创建 dtr.example.com 之类的 DNS 条目，并指向负载均衡器。务必使该条目尽可能简洁，因为它将是镜像全名的一部分。例如 user_a 的 webserver 镜像将名为 dtr.example.com/user_a/webserver。
通过应用负载均衡器可访问通过 UCP 的 HTTP 网格路由 (HRM) 暴露的服务 HTTP 端点。HRM 提供一个反向代理，将域名映射到暴露端口且连接到ucp-hrm Overlay 网络的服务。例如 voting 应用暴露 vote 服务的端口 80。HRM 将 http://vote.apps.example.com 映射到 ucp-hrm Overlay 网络上的此端口，而应用 LB 本身将 *.apps.example.com 映射到集群中的节点。
有关 UCP 上的应用负载均衡的更多详细信息，请参见 Universal Control Plane 2.0 服务发现与负载均衡。
DTR 存储
DTR 通常需要存储大量镜像。它使用的是外部存储（S3、NFS 等），而不是节点存储，因此可以在 DTR 从节点之间共享。DTR 在从节点之间复制元数据和配置信息，但不在镜像层本身之间复制。要确定存储大小，请以环境中使用的现有镜像的大小为起点进行调整。
最好使用环境中现有的存储解决方案，使镜像存储能够得益于现有的操作经验。如果您必须选择新的解决方案，请考虑使用与 S3 兼容的对象存储，它会更密切地映射到镜像库操作。
请参阅用于 Docker CaaS 的存储解决方案简介来了解关于选择存储解决方案的更多信息。
