介绍
容器为那些寻求大规模设计和部署应用程序的用户提供了一个优雅的解决方案。 虽然Docker提供了实际的容器化技术，但是许多其他项目有助于开发在部署环境中进行适当引导和通信所需的工具。
许多Docker环境依赖的核心技术之一是服务发现。 服务发现允许应用程序或组件发现关于其环境和邻居的信息。 这通常被实现为分布式键值存储，其也可以用作指示配置细节的更一般的位置。 配置服务发现工具允许您将运行时配置与实际容器分离，这允许您在多个环境中重复使用相同的映像。
在本指南中，我们将讨论在群集Docker环境中的服务发现的好处。 我们将主要集中于一般概念，但在适当时提供更具体的例子。
服务发现和全球可访问的配置存储
服务发现的基本思想是应用程序的任何新实例都应该能够以编程方式识别其当前环境的细节。 这是必需的，以便新实例能够在没有手动干预的情况下“插入”现有应用环境。 服务发现工具通常被实现为存储关于当前正在操作的实例或服务的信息的全局可访问注册表。 大多数时候，为了使此配置容错和可扩展，注册表分布在基础架构中的可用主机之间。
虽然服务发现平台的主要目的是提供连接细节以将组件链接在一起，但是它们可以更一般地用于存储任何类型的配置。 许多部署通过将其配置数据写入发现工具来利用此功能。 如果容器被配置为使得他们知道寻找这些细节，他们可以基于他们发现修改他们的行为。
服务发现如何工作？
每个服务发现工具提供组件可用于设置或检索数据的API。 因此，对于每个组件，服务发现地址必须硬编码到应用程序/容器本身中，或在运行时作为选项提供。 通常，发现服务被实现为使用标准http方法可访问的键值存储。
服务发现门户的工作方式是，每个服务在联机时向发现工具注册自身。 它记录相关组件可能需要的任何信息，以便使用它提供的服务。 例如，MySQL数据库可以注册运行守护程序的IP地址和端口，以及可选地登录所需的用户名和凭证。
当该服务的消费者上线时，它能够在预定义端点处查询服务发现注册表的信息。 然后它可以基于它找到的信息与它所需的组件交互。 一个很好的例子是负载均衡器。 它可以通过查询服务发现门户并相应地调整其配置来查找其需要提供流量的每个后端服务器。
这需要容器本身的配置细节。 其中的一个好处是，它使组件容器更灵活，更少绑定到特定的配置。 另一个好处是，它使您的组件能够简单地对相关服务的新实例做出反应，从而允许动态重新配置。
配置存储如何关联？
全局分布式服务发现系统的一个主要优点是它可以存储组件在运行时可能需要的任何其他类型的配置数据。 这意味着您可以从容器中抽取更多的配置并进入更大的执行环境。
通常，为了使其最有效地工作，应该使用合理的默认值设计应用程序，可以在运行时通过查询配置存储来覆盖它。 这允许您使用类似于使用命令行标志的方式的配置存储。 区别在于，通过使用全局可访问的存储，您可以为组件的每个实例提供相同的选项，无需额外的工作。
配置存储如何帮助群集管理？
Docker部署中的分布式键值存储的一个功能可能不是最初显而易见的是集群成员资格的存储和管理。 配置存储是保持跟踪主机成员资格的完美环境，以便管理工具。
可以在分布式键值存储中关于各个主机存储的一些信息是：
- 主机IP地址
- 主机本身的连接信息
- 可作为调度决策的目标的任意元数据和标签
- 集群中的角色（如果使用领导者/跟随者模型）
这些细节可能不是您在正常情况下使用服务发现平台时需要关注的问题，但它们为管理工具提供查询或修改有关集群本身的信息的位置。
什么是故障检测？
故障检测可以以多种方式实现。 关注的是，如果一个组件失败，发现服务将被更新以反映它不再可用的事实。 这种类型的信息对于最小化应用或服务故障至关重要。
许多服务发现平台允许使用可配置的超时设置值。 组件可以使用超时设置值，并定期ping发现服务以重置超时。 如果组件失败并且超时，该实例的连接信息将从存储中删除。 超时的长度主要是应用程序需要响应组件故障的速度的函数。
这也可以通过将一个裸骨“助手”容器与每个组件相关联来完成，其唯一的职责是定期检查组件的运行状况，并在组件关闭时更新注册表。 对这种类型的架构的关注是帮助容器可能下降，导致存储中的不正确的信息。 某些系统通过在服务发现工具中定义运行状况检查来解决此问题。 这样，发现平台本身可以周期性地检查所注册的组件是否仍然可用。
当详细信息更改时重新配置服务？
基本服务发现模型的一个关键改进是动态重新配置。 虽然正常的服务发现允许您通过在启动时检查发现信息来影响组件的初始配置，但动态重新配置涉及配置组件以对配置存储中的新信息做出反应。 例如，如果实现负载均衡器，则后端服务器上的运行状况检查可能表明池中的一个成员已关闭。 负载平衡器的运行实例需要被通知，并且需要能够调整其配置和重新加载以解决这个问题。
这可以以多种方式实现。 由于负载均衡示例是此功能的主要用例之一，因此存在多个项目，专注于在检测到配置更改时重新配置负载均衡器。 HAProxy配置调整是常见的，因为它在负载平衡空间中无所不在。
某些项目更灵活，因为它们可用于触发任何类型软件的更改。 这些工具定期查询发现服务，并且在检测到更改时，使用模板系统生成包含在发现端点处找到的值的配置文件。 生成新的配置文件后，将重新装入受影响的服务。
这种类型的动态重新配置需要在构建过程中进行更多的规划和配置，因为所有这些机制必须存在于组件的容器中。 这使得组件容器本身负责调整其配置。 确定写入发现服务和设计合适的数据结构以便于使用的必要值是该系统所需要的另一个挑战，但其优点和灵活性可以是很大的。
什么是安全？
许多人在第一次了解全局可访问的配置存储时所关心的一个问题是安全性。 将连接信息存储到全球可访问的位置真的好吗？
这个问题的答案在很大程度上取决于你选择放在商店，以及你认为需要多少安全层来保护你的数据。 几乎每个服务发现平台都允许使用SSL / TLS加密连接。 对于某些服务，隐私可能不是非常重要，将发现服务放在专用网络上可能证明是令人满意的。 然而，大多数应用程序可能会从额外的安全性中受益。
有许多不同的方法来解决这个问题，并且各种项目提供自己的解决方案。 一个项目的解决方案是继续允许开放式访问发现平台本身，但是加密写入它的数据。 应用程序使用者必须具有关联的密钥才能解密在存储中找到的数据。 其他方将无法访问未加密的数据。
对于不同的方法，一些服务发现工具实现访问控制列表以便将密钥空间划分成单独的区域。 然后，他们可以基于由特定密钥空间定义的访问要求来指定对区域的所有权或访问权。 这建立了一种为某些方提供信息的简单方法，同时保持其他方的私密性。 每个组件可以配置为只能访问其明确需要的信息。
一些常见的服务发现工具是什么？
现在我们已经讨论了服务发现工具和全球分布式键值存储库的一些一般功能，我们可以提到一些与这些概念相关的项目。
一些最常见的服务发现工具是：
- ETCD：此工具是由CoreOS的制造商为了提供服务发现和分布在全球各地配置容器和主机系统本身。 它实现http API并且在每个主机上都有一个命令行客户端。
- 领事 ：该服务发现平台有许多先进的功能，使它脱颖而出，包括可配置的健康检查，ACL功能，HAProxy的配置等。
- 饲养员 ：这个例子是比前两个大一点，在一些较新的功能为代价提供了更成熟的平台。
扩展基本服务发现的其他一些项目包括：
- 地穴 ：地穴允许组件以保护他们编写使用公钥加密的信息。 可以向意图读取数据的组件给出解密密钥。 所有其他方将无法读取数据。
- confd：Confd是一个旨在允许基于服务发现门户的变化任意应用程序动态重新配置的项目。 该系统包括一个用于查看相关端点以进行更改的工具，一个模板系统根据收集的信息构建新的配置文件，以及重新加载受影响的应用程序的能力。
- vulcand：Vulcand作为负载平衡器组件组。 它是etcd感知和修改其配置基于在商店中检测到的更改。
- 马拉松 ：虽然马拉松比赛主要是调度程序（稍后介绍），它也实现了重装HAProxy的更改时它之间应平衡提供的服务提出了基本能力。
- 领跑者 ：这个项目挂钩到马拉松提供更新HAProxy的一个更强大的解决方案。
- 突触 ：该项目引入了嵌入式HAProxy的情况下，可以将流量路由到组件。
- 神经 ：神经是配合使用突触提供个别组件实例的健康检查。 如果组件变得不可用，神经更新突触以使组件不旋转。
结论
服务发现和全局配置存储允许Docker容器适应其当前环境并插入现有组件。 这是通过允许组件跟踪和响应其环境中的更改来提供简单，免提的可扩展性和部署的一个重要先决条件。
在接下来的指南中，我们将讨论Docker容器和主机可以定制网络配置方式沟通。
