在Hashiconf EU 2019大会上，我们宣布Nomad的native consult Connect集成将在技术预览版中提供。nomad0.10的beta版候选版本包括consulconnect集成。这篇博客文章概括介绍了服务细分，以及如何使用Nomad中的特性，通过consulconnect在服务之间实现端到端的mtl。»背景向云环境和微服务架构的过渡对IT来说是一个新的挑战。这种转变意味着从私有数据中心的主要专用服务器转移到按需可用的计算容量池。网络层从严重依赖于服务和应用程序的物理位置和IP地址过渡到使用服务的动态注册表进行发现、分段和组合。企业IT团队对网络或计算资源的物理位置没有相同的控制权，必须考虑基于服务的连接性。运行时层从部署构件到静态应用服务器，再到将应用程序部署到按需配置的资源集群。HashiCorp Nomad专注于易用性、灵活性和性能，使运营商能够在云本地环境中混合部署微服务、批处理、容器化和非容器化应用程序。Nomad已经与HashiCorp consur集成，以提供动态服务注册和服务配置功能。另一个核心挑战是服务细分。东西方防火墙使用基于IP的规则来保护进出流量。但是，在一个动态的世界中，服务在机器之间移动，并且机器经常被创建和销毁，这种基于外围设备的方法很难扩展，因为它会导致复杂的网络拓扑结构和大量短期的防火墙规则和代理配置。consur Connect使用相互传输层安全性（mTLS）提供服务到服务的连接授权和加密。应用程序可以在服务网格配置中使用sidecar代理来自动为入站和出站连接建立TLS连接，而根本不需要知道连接。从应用程序的角度来看，它使用本地主机连接来发送出站流量，TLS终止和转发到正确目标服务的详细信息由Connect处理。nomad0.10将扩展Nomad的consur集成功能，以包括本地连接集成。这使得Nomad管理的服务能够在服务之间轻松地选择mtl，而不必对其应用程序进行额外的代码更改。微服务的开发人员可以继续专注于他们的核心业务逻辑，同时在云计算环境中运行并实现服务分段的安全好处。在nomad0.10之前，作业规范的作者必须直接运行和管理连接代理，并且不能在任务之间获得网络级别的隔离。nomad0.10为Nomad的作业规范connect和sidecar_服务引入了两个新的小节。这篇博客文章的其余部分展示了如何利用consulconnect与一个与API服务通信的示例仪表板应用程序。»先决条件»执政官与Nomad的Connect集成需要Consul 1.6或更高版本。consur代理可以使用以下命令在dev模式下运行：$CONSUR代理-开发»游牧民族Nomad必须调度到可路由的接口上，以便代理相互连接。以下步骤显示如何启动为Connect配置的Nomad dev代理：$sudo nomad代理-dev connect»CNI插件Nomad使用CNI插件来配置任务组网络，这些插件需要下载到Nomad客户端节点上的/opt/CNI/bin。»特使Nomad启动并管理enjor，它与选择连接集成的应用程序一起运行。特使就像一个代理，提供与群集中其他应用程序的安全通信。Nomad将使用其官方码头集装箱发射特使。另外，请注意，0.10中的Connect集成仅适用于Linux环境。»示例概述本博客文章中的示例支持web应用程序和API服务之间的安全通信。web应用程序和API服务由Nomad运行和管理。Nomad还配置了特使代理以与这些应用程序一起运行。API服务是一个简单的微服务，每次调用它时都会增加一个计数。然后将当前计数作为JSON返回。web应用程序是显示计数值的仪表板。»体系结构图下面的Nomad架构图说明了dashboard web应用程序和API微服务之间的网络流量流。如下图所示，从仪表板到API的流量通过特使进行代理，并通过mTLS进行保护。»联网模式在nomad0.10之前，Nomad的网络模型通过在主机网络模式下运行所有应用程序来简化。这意味着在同一主机上运行的应用程序可以看到彼此并通过本地主机相互通信。为了支持consurconnect中的安全特性，nomad0.10引入了网络名称空间支持。这是Nomad中的一个新的网络模型，任务组是一个单一的网络端点，共享一个网络名称空间。这类似于Kubernetes吊舱。在这个模型中，在同一个任务组中启动的任务共享一个网络堆栈，尽可能与主机隔离。这意味着任务的本地IP将不同于客户端节点的IP。如果需要，用户还可以配置端口映射，以便通过主机公开端口。»配置网络节除了任务的resources节之外，Nomad的network节将在任务组级别生效。network节将获得一个附加的"mode"选项，该选项告诉客户机在什么网络模式下运行。以下网络模式可用："无"-任务组将有一个没有任何网络接口的独立网络。"网桥"-任务组将具有一个独立的网络命名空间，该命名空间具有与主机桥接的接口"主机"-每个任务都将加入主机网络命名空间，并且不会创建共享网络命名空间。这与nomad0.9中的当前行为匹配此外，Nomad的port节现在包含了一个新的"to"字段。此字段允许配置要映射到分配或任务内部的端口。在网桥网络模式下，任务组级别的网络节，同一任务组中的所有任务共享网络堆栈，包括接口、路由和防火墙规则。这允许启用连接的应用程序仅绑定到共享网络堆栈中的本地主机，并使用代理进行进出流量。下面是API服务的最小网络节，以便选择连接。网络{mode="网桥"}下面是web仪表板应用程序的网络节，说明端口映射的使用。网络{mode="网桥"端口"http"{静态=9002至=9002}}»在API服务中配置连接为了在API服务中启用Connect，我们需要在组级别指定一个network节，并在服务定义中使用Connect节。下面的片段说明了这一点"api"组{网络{mode="网桥"}服务{name="计数api"端口="9001"连接{侧车服务{}}}任务"web"{driver="docker"配置{image="hashicorpnomad/计数器-api:v1版"}}Nomad将在与API服务相同的网络名称空间中运行enjont，并将其注册为consulconnect的代理。»配置上游为了在web应用程序中启用Connect，我们需要在任务组级别配置network节。我们还需要提供它与之通信的上游服务（即API服务）的详细信息。更一般地说，应该为该应用程序所依赖的任何其他服务配置上游。下面的片段说明了这一点。"仪表板"组{网络{mode="网桥"端口"http"{静态=9002至=9002}}服务{name="计数仪表板"端口="9002"连接{侧车服务{代理人{上游{destination_name="计数api"本地连接端口=8080}}}}}任务"仪表板"{driver="docker"环境{COUNTING_SERVICE_URL="http://${NOMAD_UPSTREAM_ADDR\u count_api}"}配置{image="hashicorpnomad/计数器-仪表板：v1"}}}在上面的示例中，static=9002参数请求主机网络接口上的Nomad调度程序保留端口9002。to=9002参数将该主机端口转发到网络命名空间内的端口9002。这允许您通过访问：9002在浏览器中连接到web前端。web前端通过consur Connect连接到API服务。upstreams节定义要访问的远程服务（count api）以及在网络名称空间内公开该服务的端口（8080）。web前端配置为使用环境变量$COUNTING\u service_URL与API服务通信。上游的地址被插入到该环境变量中。在本例中，$COUNTING_SERVICE_URL将设置为"本地主机：8080".通过此设置，仪表板应用程序通过localhost与代理的上游本地绑定端口通信，以便与API服务通信。代理使用consur处理mTLS通信，将流量路由到API服务运行的正确目的IP。另一端的特使代理终止TLS并将通信量转发给监听本地主机的API服务。»工作规范以下作业规范同时包含API服务和web仪表板。你可以用nomad run运行这个connect.nomad连接将内容保存到