出品丨Docker公司（ID：docker-cn）
编译丨小东
每周一、三、五晚6点10分 与您不见不散
简 介
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://<ucp_controller>/_ping 的定制 HTTPS 健康检查。
务必为 UCP 主机创建 ucp.example.com 之类的 DNS 条目，并指向负载均衡器。
三个 DTR 从节点的设置与 UCP 控制器的设置类似。在这些节点上同样使用 TCP 透传至端口 443，但健康检查是在 https://<dtr_replica_node>/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 的存储解决方案简介来了解关于选择存储解决方案的更多信息。
点击下列标题，阅读更多干货
如果本文对你有帮助，欢迎分享到朋友圈！获取更多Docker实用技巧，扫描下图二维码！
扫一扫
3172
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
