第16章：企业版工具
Docker 企业版（Enterprise Edition，EE）：企业需要 Docker 能实现私有化部署。这通常意味着 Docker 需要一个本地化部署方案，并且由企业自己掌控和维护。这还意味着角色和安全功能需要满足企业内部的组织结构，并且在安全部门的监管之下。同时还需要一份重要的售后支持协议。DockerEE 其内部包括了上百个引擎、操作界面以及私有安全注册。用户可以本地化部署，并且其中包括了一份支持协议。上层架构如下图所示。
Docker 引擎提供 Docker 全部核心功能。核心功能包括镜像、容器管理、网络、卷、集群、安全等。目前包括两个版本：社区版（CE）和企业版（EE）。两个版本最大的不同是发布周期和相应支持。Docker EE 是按季度发布，采用基于时间版本的方案。例如，2018 年 6 月发布的 Docker EE 叫作 18.06.x-ee。Docker 公司提供持续一年的支持，并且为每个版本打补丁。安装 Docker EE 很简单。但是，不同平台的安装方式略有不同。Docker EE 是基于订阅模式的服务，所以用户需要一个 Docker ID 并且激活订阅。然后就可以获得专享 Docker EE 仓库。UCP 是企业级的容器即服务平台的图形化操作界面。UCP 使用 Docker 引擎，并添加了各种企业喜欢以及需要的功能。例如 RBAC、可配置、认证、高可用控制平面以及简单界面。在 UCP 内部，是一个容器化的微服务应用，以多个容器的形式运行。
Docker UCP图形化操作界面：架构层面上讲，UCP 是基于 Swarm 模式下的 Docker EE 构建的。如下图所示，UCP 控制平面运行在 Swarm 管理节点上，应用则部署在 Swarm 工作节点上。
UCP 管理节点必须是 Linux。工作节点既可以 Windows，也可以是 Linux。规划 UCP 安装：在规划 UCP 安装的时候，合理设置集群大小和规格十分重要。下面介绍该过程中需要考虑的一些方面。集群中全部节点的时钟需要同步（例如 NTP）。如果没有同步，可能导致一些很难定位的问题。全部节点都要有自己的静态 IP 地址和固定的 DNS 名称。默认情况下，UCP 管理节点不运行用户工作负载。推荐使用这种最佳实践，并建议用户在生产环境中强制使用。该方式使得管理节点只需关注控制平面职责。同时也能简化问题定位。用户需要保证管理节点数量为奇数。这样就能避免出现脑裂等类似场景时，会导致管理节点不可用，或者与集群割裂的现象。理想数量为 3、5 或者 7，3 或者 5 是较常用的。多于 7 的话，可能导致后台 Raft 算法或者集群一致性的问题。如果不能提供 3 个管理节点，1 个要好于 2 个！如果配置了后台计划（用户应当配置）并进行日常备份，可能需要部署 5 个管理节点。这是因为 Swarm 和 UCP 的备份操作需要停止 Docker 和 UCP 服务。5 个管理节点可以保证在执行类似操作时集群的弹性。管理节点应当根据数据中心可用域进行部署。用户最不想见到的场景，就是全部 UCP 管理节点所在的域都不可用。但是，管理节点之间的通信必须经由高速可靠的网络完成。因此如果数据中心可用域之间网络状况不佳，最好还是将所有管理节点部署在相同域之中。有件事已经约定成俗，即在公有云上部署时，需要将管理节点部署在同区域内的可用域中。跨区域通常会受到低可靠性和高延迟网络的影响。工作节点的数量可以根据需求设置，因为它们并不会参与到集群 Raft 操作当中，所以就不会影响控制平面操作。规划工作节点的规格和数量，需要理解计划部署在集群上的应用需求。例如，理解之后能帮助用户确定需要多少 Windows 节点和 Linux 节点。同时还需要知道应用是否有特殊需求，需要工作节点的定制化来支持，例如 PCI 类工作负载。
此外，虽然 Docker 引擎是轻量级的，但其上运行的容器化应用不一定也是。出于这样的考虑，根据应用的 CPU、RAM、网络以及磁盘 I/O 需求规划节点数目就很重要了。安装 Docker UCP（略去）
UCP 的访问控制：所有对 UCP 的访问，都经由身份管理子系统。这意味着用户在集群上执行任何操作前，首先需要通过用户名和密码进行认证。这些操作包括集群的管理，以及服务的部署和管理。用户使用 UI 界面的时候已经体验过了，必须使用用户名和密码才能登录。在 CLI 中也是一样的，用户不能在未登录的情况下通过 UCP 执行命令！这是因为 UCP 集群中本地 Docker Socket 受到 ucp-proxy 服务的保护，不会接受未认证命令。
UCP 备份：首先并且最重要的是，高可用（HA）并不等价于备份，思考下面的例子。有一个包含 5 个管理节点的 UCP 集群。所有管理节点都处于健康状态，并且控制平面开启了复制功能。某个心怀怨恨的员工对集群进行破坏（或者删除了全部用户账户）。破坏操作会复制到全部 5 个管理节点，导致集群被破坏。这种场景下 HA 没有丝毫帮助。此时需要的，是备份！一个 UCP 集群主要由 3 个部分构成，也是需要分别备份的内容：Swarm、UCP 和 Docker 可信镜像仓库服务（DTR）。恢复 UCP：从备份进行恢复是最后的手段，只能在整个集群都宕机或者全部管理节点都丢失的情况下使用，如果 HA 集群下仅丢失某个管理节点，并不需要从备份进行恢复。该情况下，很容易就能创建新管理节点并加入集群。
Docker可信镜像仓库服务，是安全、高可用并且支持本地部署的 Docker 服务，通常使用 DTR 代指。如果知道 Docker Hub 是什么，可以将 DTR 理解为私有的 Docker Hub，可以在本地部署，并且自行管理。如果条件允许，使用专用节点来运行 DTR。在 DTR 生产环境节点中绝对不要运行用户工作负载。
第17章：企业及特性
DockerEE 具备这两个特性：基于角色的权限控制（RBAC）和对活动目录（AD）的集成。 1）RBAC：UCP 通过一种称为授权（Grant）的东西实现了 RBAC。大体上，一个授权有以下 3 个概念构成。1）主体（Subject）。2）角色（Role）。3）集合（Collection）。主体即一个或多个用户，或一个团队。角色是一系列权限的组合，而集合则是权限作用的资源，如下图所示。
创建一个授权包含如下步骤。1）创建用户和团队。2）创建一个自定义的角色。3）创建一个集合。4）创建一个授权。只有 UCP 管理员才可以创建和管理用户、团队、角色、集合和授权。因此读者需要以UCP管理员的身份登录才能进行更多得操作。节点 RBAC：为了调度将集群中的工作节点进行分组是可行的。例如，有时会为开发、测试和 QA 负载运行一个集群——用一个集群可能会减少管理开销，并且可以轻松地将节点分配给 3 个不同的环境。但此时仍然希望能够对工作节点进行区分，从而实现诸如仅 dev 团队的用户才可以对 dev 集合中的节点进行调度的效果。这同样可以基于授权来实现。首先，需要将 UCP 工作节点分配给自定义的集合。然后，基于该集合、内置的 Scheduler 角色以及希望为其分配权限的团队，来创建授权。
Docker内容信任机制（DCT）：Docker 镜像的发布者可以在将镜像推送到库中时对其进行签名。使用者可以在拉取镜像时进行校验，或进行构建或运行等操作。长话短说，DCT 确保使用者能够得到他们想要的镜像。下图展示了其总体架构。
DCT 实现的是客户端的签名和验证，意味着由 Docker 客户端执行它们。显然类似这样的密码机制，对于确保在互联网上拉取和推送的软件的可信性是非常重要的，其在整个技术栈的各个层次，以及软件交付流水线的各个环节都在发挥越来越重要的作用。在不久的将来，这种加密信任机制将有望在交付链的各个方面发挥作用。DCT 可以通过环境变量 DOCKER_CONTENT_TRUST 来启用或关闭。将该环境变量的值设置为“1”的话将会在当前会话开启 DCT；将其设置为其他值的话则会关闭 DCT。下面的命令用于在 Linux 主机的 Docker 中开启 DCT。$ export DOCKER_CONTENT_TRUST，后续的 docker push 命令会在推送镜像时自动对镜像进行签名。因此，所有的 pull、 build 和 run 命令只会对已签名的镜像起作用。
Docker HTTP路由网格（HRM）：Docker Swarm 内置有四层路由网格的功能，称为 Swarm 路由网格（Swarm Routing Mesh）。这一功能可以使 Swarm 服务暴露给集群中的所有节点，并且能够在服务的各个副本之间实现对入站流量的负载均衡。其效果就是可以基本实现流量均衡到达服务的所有副本。不过，该负载均衡并不作用于应用层。例如，它无法根据 HTTP 头部数据进行七层路由。为了弥补这一点，UCP 实现了七层路由网格，称为 HTTP 路由网格（HTTP Routing Mesh，HRM）。这一功能以 Swarm 路由网格为基础。HRM 使得多个 Swarm 服务可以发布在同一个 Swarm 端口上，并根据 HTTP 请求头中的主机名将流量路由到正确的服务中。下图展示的是包含两个服务的简单示例。
在上图中，笔记本客户端向 mustang.internal 的 80 端口发出了一个 HTTP 请求。UCP 集群中有两个监听 80 端口的服务。mustang 服务在 80 端口监听发送给 mustang.internal 主机的流量。camero 服务也监听 80 端口，不过它被配置为接收到达 camero.internal 的流量。其实还有第三个称为 HRM 的服务，用来维护主机名与 UCP 服务之间的映射关系。HRM 会接收所有到达 80 端口的流量，查看 HTTP 请求头，并决定将其路由到哪个服务。
Docker daemon通信与安全客户端：Docker使用了客户端—服务端模型。客户端使用 CLI，同时服务端（daemon）实现功能，并对外提供 REST API。客户端叫作 docker（在 Windows 上是 docker.exe），daemon 叫作 dockerd（在 Windows 上是 dockerd.exe）。默认安装方式将客户端和服务端安装在同一台主机上，并且配置通过本地安全 PIC Socket 进行通信。不过，也可以配置客户端和服务端通过网络进行通信。但是 daemon 默认网络配置使用不安全的 HTTP Socket，端口是 2375/tcp，如下图所示
默认使用 2375 作为客户端和服务端之间未加密通信方式的端口，而 2376 则用于加密通信。在实验室这样还可以，但是生产环境却是不能接受的。TLS 就是解决之道！Docker 允许用户配置客户端和 daemon 间只接收安全的 TLS 方式连接。生产环境中推荐这种配置，即使在可信内部网络中，也建议如此配置！Docker 为客户端与 daemon 间使用基于 TLS 的安全通信提供了两种模式。1）daemon 模式：Docker daemon 只接收认证客户端的链接。2）客户端模式：Docker 客户端只接收拥有证书的 Docker daemon 发起的链接，其中证书需要由可信 CA 签发。同时使用两种模式能提供最高的安全等级。Docker 支持两种 TLS 模式。daemon模式、客户端模式。daemon 模式保证 daemon 只处理来自拥有有效证书的客户端发起的连接，客户端模式使得客户端只能连接到拥有有效证书的 daemon。
Docker整体架构：
distribution 负责与docker registry交互，上传镜像以及v2 registry 有关的源数据。registry负责docker registry有关的身份认证、镜像查找、镜像验证以及管理registry mirror等交互操作。image 负责与镜像源数据有关的存储、查找，镜像层的索引、查找以及镜像tar包有关的导入、导出操作。reference负责存储本地所有镜像的repository和tag名，并维护与镜像id之间的映射关系。layer模块负责与镜像层和容器层源数据有关的增删改查，并负责将镜像层的增删改查映射到实际存储镜像层文件的graphdriver模块。graghdriver是所有与容器镜像相关操作的执行者。
架构2
用户使用Docker Client与Docker Daemon建立通信，并发送请求给后者。而Docker Daemon作为Docker架构中的主体部分，首先提供Server的功能使其可以接受Docker Client的请求；而后Engine执行Docker内部的一系列工作，每一项工作都是以一个Job的形式的存在。Job的运行过程中，当需要容器镜像时，则从Docker Registry中下载镜像，并通过镜像管理驱动graphdriver将下载镜像以Graph的形式存储；当需要为Docker创建网络环境时，通过网络管理驱动networkdriver创建并配置Docker容器网络环境；当需要限制Docker容器运行资源或执行用户指令等操作时，则通过execdriver来完成。而libcontainer是一项独立的容器管理包，networkdriver以及execdriver都是通过libcontainer来实现具体对容器进行的操作。当执行完运行容器的命令后，一个实际的Docker容器就处于运行状态，该容器拥有独立的文件系统，独立并且安全的运行环境等。
架构3
这个个架构就简单清晰指明了server/client交互，容器和镜像、数据之间的一些联系。docker daemon就是docker的守护进程即server端，可以是远程的，也可以是本地的，这个不是C/S架构吗，客户端Docker client 是通过rest api进行通信。docker cli 用来管理容器和镜像，客户端提供一个只读镜像，然后通过镜像可以创建多个容器，这些容器可以只是一个RFS（Root file system根文件系统），也可以ishi一个包含了用户应用的RFS，容器再docker client中只是要给进程，两个进程之间互不可见。用户不能与server直接交互，但可以通过与容器这个桥梁来交互，由于是操作系统级别的虚拟技术，中间的损耗几乎可以不计。
