在上一篇文章中，我们研究了HashiCorp consur如何使用云元数据发现其他代理来引导集群。这篇文章介绍了HashiCorp Nomad的自动连接功能，以及我们如何使用Terraform创建一个自动缩放的集群。与consur不同，Nomad的自动引导功能不使用云元数据，因为当Nomad与consur配对时，我们将继承该功能。consur的服务发现和健康检查是引导Nomad的完美平台。Nomad服务器或代理的启动过程如下：实例引导并安装Nomad和consur代理init系统启动consur代理consur代理使用AWS元数据发现consur集群init系统使用本地运行的consur代理的位置启动Nomad开始时，Nomad在consur中查询服务目录以发现其他实例Nomad加入发现的实例对于服务器，我们仍然需要引导过程中预期的初始实例数，以确保在开始计划工作之前拥有一个健康的集群。初始集群大小的要求是确保集群能够选出一个领导者并建立一个法定人数。»设置Nomad群集存储库位于https://github.com/hashicorp/nomad-auto-join包括一个示例Terraform配置来演示此功能。将此存储库克隆到本地文件系统：$git克隆https://github.com/hashicorp/nomad-auto-join要启动和引导集群，首先使用AWS凭据设置以下环境变量。$export AWS_REGION="[AWS_区域]"$export AWS_ACCESS_KEY="[AWS_ACCESS_KEY]"$export AWS_SECRET_ACCESS_KEY="[AWS_SECRET_ACCESS_KEY]"有很多方法可以使用Terraform对AWS进行身份验证，有关所有身份验证选项的详细信息，请参阅Terraform AWS提供者文档以获取更多信息。一旦我们设置了环境变量，我们就可以使用terraform get命令初始化terraform模块。在我们的设置中使用模块可以让我们的代码保持干燥。有关此功能的更多信息，请参阅Terraform文档：https://www.terraform.io/docs/modules/usage.html$terraform获取然后，我们可以在运行apply创建资源之前运行plan to create检查配置$地形图正在刷新计划前内存中的地形状态。。。刷新的状态将用于计算此计划，但不会保存到本地或远程状态存储。#...计划：添加30个，更改0个，销毁0个。运行terraform apply将创建5个t2.micro实例、3个服务器组成仲裁和2个运行作业的代理。这些设置可在中配置地形.tfvars如果您想更改它们，请归档。$terraform应用一旦这些都启动并运行，Terraform输出将显示所创建的服务器和客户机的详细信息。申请完成！资源：添加30个，更改0个，销毁0个。基础结构的状态已保存到路径下面。修改和销毁基础设施，所以要保证安全。检查完整状态使用"terraform show"命令。状态路径：输出：平均值=arn:aws公司：弹性负载平衡：eu-west-1：773674589724:负载平衡器/app/nomad consur external/3cca7be97ab6d28dalb_dns=nomad-consur-external-723193890.eu-west-1。亚马逊网站ssh主机=34.251.93.86由于nomadapi没有公开，所以需要登录到同一个VPC上的SSH主机。ssh ubuntu@$（terraform output ssh\u主机）然后我们可以运行nomad服务器成员来查看集群中的服务器列表。ubuntu@ip-10-1-1-216：~$nomad服务器成员名称地址端口状态引导协议生成数据中心区域ip-10-1-1-99.global 10.1.1.99 4648活动假2 0.5.6 dc1全局ip-10-1-2-107.全局10.1.2.107 4648活动假2 0.5.6 dc1全局ip-10-1-2-48.global 10.1.2.48 4648活动真2 0.5.6 dc1全局此外，我们可以运行nomad node status来查看客户机列表。ubuntu ip-10-1@131：~$nomad节点状态ID DC名称类排出状态ec268e26 dc1 ip-10-1-2-5假准备ec21954b dc1 ip-10-1-1-44假准备»在Nomad上运行作业要在Nomad上运行作业，我们需要创建一个定义模式的作业规范。作业文件使用HashiCorp配置语言（HCL），该语言旨在在人类可读和可编辑以及机器友好的格式之间取得平衡。作业文件的总体层次结构如下：工作组任务每个文件只有一个作业。但是，一个作业可以有多个组，每个组可能有多个任务。当一个组包含多个任务时，Nomad在同一个客户机上共同定位这些任务。此层次结构允许您灵活地配置在一个文件中定义应用程序的单个或多个服务组。让我们看看文件作业/系统日志.hcl它定义了运行syslog ng的系统。作业"系统实用程序"{数据中心=dc1"]type="系统"# ..."系统实用程序"组{约束{不同的主机=真}# ...任务"syslog"{driver="docker"# ...}}}}»工作节job节是作业规范中最顶层的配置，在我们的作业中，我们分配的名称是"system-utils"，这个名称在整个集群中必须是全局唯一的。作业"系统实用程序"{数据中心=eu-west-1，"eu-west-2"]type="系统"更新{参差="10秒"最大平行=1}# ...然后我们设置数据中心，这是一个必需的选项，没有默认值。我们还可以指定区域，这是另一个用于工作安排的属性。datacenters和region属性允许对作业的运行位置进行细粒度控制。例如，您可能部署了以下群集：地区：欧洲AWS数据中心：eu-west-1数据中心：eu-east-1作业定义允许您将三种不同的作业类型设置为：服务-不应停止的长期服务批处理-短期或周期性作业系统-在满足作业约束的所有客户机上调度作业https://www.nomadproject.io/docs/runtime/schedulers.htmlupdate节配置我们希望如何更新作业，例如当我们想要部署一个新版本时。在我们的例子中，设置使我们能够进行滚动部署：max_parallel配置一次更新的任务组数指定更新集之间的延迟https://www.nomadproject.io/docs/job-specification/update.html»组节下一级是group节，group节定义了一系列应该位于同一Nomad客户机上的任务。为了确定任务放置在哪个客户机上，我们可以指定一些约束条件。约束过滤属性和元数据，在我们的示例中，我们只设置了约束distinct\U host，这意味着我们永远不会将多个组调度到同一个主机上。约束也可以应用于任务和职务级别；这为您提供了在位置上的完全灵活性，所有约束都在从职务级别开始并向下过滤的分层级别上进行评估。有关此功能的详细信息，请参阅Nomad文档：https://www.nomadproject.io/docs/job-specification/constraint.html»任务节任务节是一个单独的工作单元，例如运行Docker容器或应用程序。如果我们看一下我们的例子，我们将运行docker image syslog ng。任务"syslog"{driver="docker"配置{image="balabit/syslog ng:最新"港口地图{udp=514tcp=601}}// ..}本节中的第一个属性是驱动程序；我们使用值docker，因为我们希望运行docker容器，但是可能有许多不同的值：docker-运行docker容器执行一个特定的命令，隔离操作系统的原语来限制任务对资源的访问java—运行打包到Jar文件中的java应用程序lxc-运行lxc应用程序容器qemu-执行任何常规的qemu映像raw_nuexec-不隔离地执行特定命令，以与Nomad进程相同的用户身份运行该命令。默认禁用rkt-运行CoreOS-rkt应用程序容器最后，我们将设置任务的配置，这对每个驱动程序都是唯一的。对于我们的任务，我们使用的是Docker驱动程序，我们可以指定的最小值是image属性来选择Docker image。但是，驱动程序支持大多数可以通过Docker run命令直接传递给Docker的参数。https://www.nomadproject.io/docs/drivers/docker.html»资源为了确保Nomad正确地将任务分配给客户机，我们需要指定它使用的资源。resources节允许我们为任务可以使用的CPU和内存以及网络设置限制。通过限制资源，我们可以将更多的任务打包到单个实例上。但是，任务会被限制到这些限制，如果我们将它们设置得太小，我们可能会无意中降低正在运行的应用程序的性能。资源{cpu=500#500兆赫内存=256Ť256MB网络{兆比特=10端口"udp"{static="514"}端口"tcp"{static="601"}}network节的port部分允许我们动态或静态地分配端口；我们引用前面在config节中定义的端口。在本例中，我们静态地分配http和admin端口，因为我们希望将它们映射到负载平衡器，但是如果我们只需要可供内部使用的端口，那么我们可以从配置中省略static="514"，并使用dynamicallo