Neofonie GmbH是一家德国软件公司，在柏林和汉堡设有办事处。该公司是一家解决方案和全方位服务提供商，专注于门户网站、搜索、社交媒体、电子出版和移动应用。Neofonie拥有一系列客户和服务，在高度复杂、快速变化的环境中工作。NefONIEE使用三级连续输送管道，它使用Cuxl作为基础，在环境之间安全地移动应用程序。你可以在Neofonie的博客上找到这篇文章的德语版节选。»问题是：跨环境升级软件很容易出错负责任的软件发布周期通常需要跨测试、登台和生产环境来提升软件。这一过程在保证安全的同时，很容易出错，也很困难。例如，您可以在本地环境中启动多个服务，但必须更改IP，以便服务可以在此环境中正确地发现彼此。然后，当软件部署到不同的环境时，IP需要再次更改。对数十个相互连接的服务执行此操作将变得不可管理且容易出错。Neofonie最大的项目之一使用三级连续输送管道。以前要在阶段之间移动应用程序，每个阶段都有自己的属性文件，并为该特定阶段提供适当的IP。例如，开发阶段要求您连接到本地主机上的MySQL实例，该实例需要手动配置。然而，在登台和生产中，应用程序必须连接到远程MySQL实例。有时提交了错误的IP，而登台环境试图连接到本地主机上的MySQL。甚至更糟的是，开发环境试图连接到生产MySQL实例。当然，错误是无法完全避免的，但我们需要采取措施，降低连续输送管道所固有的风险。应用程序被打包为Docker容器，从而将它们与其他服务和底层操作系统隔离开来。然而，Docker并不能解决发现依赖服务的问题。依赖的IP可以在初始化时注入Docker容器，但是如果服务停止运行或重新启动会发生什么情况？没有办法通知其他部门新地点。容器的动态特性需要一种新的方法。Neofonie只想启动容器并管理所有依赖项，而不需要手动干预来更新IP。执政官现在是用来实现这一点的。»以consur作为服务注册中心的集装箱服务将consur作为DNS服务器与consur服务注册表结合使用意味着一组Docker映像可以在任何地方启动，而无需更改属性。consur注册表本身限制了服务拓扑的边界。服务拓扑将与底层计算机分离。无论是开发、测试还是生产，查询服务的方式始终保持不变。服务环境由一个特定的consur实例管理，这个实例已被证明是一个非常优雅的解决方案。服务注册中心跟踪特定环境中的所有可用服务。领事注册也被包装在一个容器中，使它很容易在任何环境中提出。环境中的其他容器都包含一个consur代理，并且在启动时知道consur注册表。这是通过使用Docker提供的链接机制在容器之间共享环境变量来实现的。现在，通过查询converapi，服务可以很容易地找到彼此。然而，在系统的某些部分，Neofonie无法控制服务解析，因此需要一种不同的方法。例如，假设您想使用JDBC或类似技术连接到某个服务。不可能动态提供IP和/或适当的故障转移信息。consur也可以在这里提供帮助，因为它可以充当一个功能齐全的DNS服务器。Neofonie配置了它的容器，以便consur充当主DNS服务。它允许在容器中进行简单的挖掘以获取所需服务的IP。执政官以循环方式解决IP。当服务规模扩大时，它将提供更多的IP，反之亦然。前面提到consur注册中心限制服务拓扑本身的边界。这需要更多的解释，如图2所示。通常，连续交付管道中的各个阶段都受到每个阶段中虚拟机的限制。测试有一组用于测试的机器，而staging有一组单独的机器。这里的优势是环境在VM级别上彼此分离。但也有一个缺点：虚拟机大部分时间处于空闲状态。通过使用consur定义服务拓扑的边界，可以在服务发现级别上表示封装。CoreOS集群（由Giant Swarm提供）中的每个节点都运行一个consur注册表，该注册表构成一个仲裁。然后，服务可以部署到集群中的任何地方，它们将通过consur了解它们所处的"阶段"。这实际上实现了与底层虚拟机无关的管道"阶段"。除了服务注册和DNS功能外，consur还提供了更简洁有趣的功能。例如，除了作为键值存储之外，它还执行健康和心跳检查。Neofonie服务拓扑依赖心跳检查来确定服务是否正常。如果服务无法发送心跳信号，它将在consur集群中自动标记为failed。consur然后从健康服务列表中删除IP，这将从使用converapi的任何配置中删除IP。例如，Neofonie基础设施中的负载平衡器将立即更新，不再使用出现故障的IP。»摘要通过使用consur，Neofonie大大简化了其开发和部署过程。开发人员现在只需签出他或她的项目，然后使用Docker Compose在本地计算机上生成生产环境的一部分。consur限制了服务拓扑，这意味着测试和生产阶段之间不再有任何区别。这种方法减少了错误，提高了效率。如上所述，Neofonie将Giant Swarm的微服务基础设施用于Docker容器集群，后者管理底层基础设施。