这是使用Nomad构建弹性基础设施系列文章的第三部分（第1部分，第2部分）。在本系列中，我们将探讨Nomad如何处理意外的故障、停机和集群基础设施的日常维护，通常不需要操作员干预。在这篇文章中，我们将了解Nomad如何通过提供一个管理整个作业生命周期的一致工作流来为您的计算基础设施添加弹性，包括用于更新和迁移作业的强大选项，这些选项有助于最小化甚至消除停机时间。»作业操作工作流Nomad作业规范允许操作员为运行作业的所有方面指定模式。这包括任务、映像、部署策略、资源、优先级、约束、服务注册、机密以及部署工作负载所需的其他信息。作业的工作流有四个主要步骤：根据作业规范创建或修改作业文件使用Nomad服务器计划和检查更改将作业文件提交到Nomad服务器（可选）查看作业状态和日志更新作业时，可以在作业文件中定义许多内置更新策略。更新策略有助于操作员安全地管理新版本作业的推出。因为作业文件定义了更新策略（蓝色/绿色、滚动更新等），所以无论这是初始部署还是对现有作业的更新，工作流都保持不变。update节指定Nomad在部署该任务组的新版本时将采用的更新策略。如果省略，滚动更新和金丝雀将被禁用。»滚动和串行更新在update节中，运算符指定要与max_parallel同时更新的作业分配数。将max_parallel设置为1告诉Nomad采用串行升级策略，这样一次最多升级一个分配。将其设置为大于1的值将启用并行升级，从而可以同时升级多个分配。更新时，Nomad停止max_parallel number of old allocations，然后启动相同数量的新分配。然后Nomad等待更新节点上的运行状况检查通过，然后再更新下一组max_并行分配。使用health_check指定确定分配运行状况的机制。默认值是checks，它告诉Nomad等待所有任务都在运行，consur健康检查通过。其他选项包括任务状态（所有任务正在运行且未失败）和手动（操作员将使用httpapi手动设置运行状况）。有三个参数指定了分配被认为是正常的条件以及它们获取该状态的截止日期。使用min_healthy_time指定在将分配标记为正常并取消阻止更新进一步分配之前，分配必须处于正常状态的最短时间。使用healthy_deadline指定必须将分配标记为正常的截止时间，在此期限之后，分配将自动转换为不正常。最后，使用progress_deadline指定必须将分配标记为正常的截止日期。截止日期从创建部署的第一个分配时开始，并在作为部署的一部分的分配过渡到正常状态时重置。如果在进度截止日期之前没有分配转换到正常状态，则部署将标记为失败。如果作为部署一部分的分配失败，只要没有超过progress_deadline，Nomad就会根据reschedule节中的参数重新安排它。这允许Nomad优雅地处理特定于特定节点的瞬时错误。Nomad将继续重新安排，直到progress_截止日期到达，此时更新本身可能出现问题，整个部署被标记为失败。使用auto_revert=true指定作业在部署失败时应自动还原为上一个稳定版本。当作业的所有部署分配都标记为正常时，该作业被标记为稳定。下面的更新节告诉Nomad一次执行滚动更新3，并等待分配的所有任务都在运行，并且它们的consur健康检查通过至少10秒，然后才认为分配正常。它设定了一个5分钟的最后期限，让分配变得健康，之后Nomad会将其标记为不健康。而且，如果任何一个分配在10分钟后没有恢复正常，整个部署将被标记为失败，Nomad将自动恢复到最后一个已知的稳定部署。工作"例子"{更新{最大平行=3health_check="检查"min_healthy_time="10秒"health_deadline="5百万"progress_deadline="10米"自动恢复=真}}对于系统作业，仅强制执行max_parallel和stagger。作业以max_parallel的速率更新，在下一组更新之前等待错开的时间量。»金丝雀部署在开始滚动升级之前，金丝雀更新是测试作业的新版本的有用方法。update节支持设置作业操作员希望Nomad在作业通过canary参数更改时创建的金丝雀数量。当作业规范更新时，Nomad会创建金丝雀，而不会停止作业先前版本的任何分配。此模式允许操作员对新作业版本获得更高的信心，因为他们可以路由流量、检查日志等，以确定新应用程序是否正常运行。当canary设置为1或更多时，对作业的任何更改将导致破坏性更新，这将导致Nomad创建指定数量的canaris，而不停止任何先前的分配。一旦操作员确定金丝雀是健康的，它们就可以被提升，Nomad将以max_parallel的速率对剩余的分配进行滚动更新。Canary提升可以由操作员手动完成，也可以使用API自动完成。下面的更新节告诉Nomad使用1个canary执行canary更新，一旦canary被提升，则对剩余的分配一次执行3次滚动更新。工作"例子"{更新{金丝雀=1最大平行=3}}»蓝色/绿色部署蓝/绿部署有几个其他名称，包括红/黑或A/B，但概念通常是相同的。在蓝色/绿色部署中，部署了两个版本的工作负载。一次只有一个版本处于活动状态，除非在从一个版本到下一个版本的转换阶段。术语"活跃"往往意味着"接收流量"或"在服务中"通过在update节中设置canary的值以匹配group节中的count值，Nomad中启用了蓝色/绿色部署。当这些值相同时，在提交作业的新版本时，不会对现有分配进行滚动升级，而是在现有集的旁边部署新版本的组。然后操作员可以验证组的新版本是否稳定。当他们满意时，可以升级组，并且组的旧版本的所有分配都将关闭。蓝绿色部署复制了升级过程中所需的资源，但启用非常安全的部署，因为组的原始版本未被更改。下面的更新节告诉Nomad在前面的分配仍在运行时启动3个canary分配（数量与count相同），从而执行蓝/绿更新。组"缓存"{计数=3更新{金丝雀=3}}Nomad的工作生命周期（包括更新）允许运营商根据自己的情况采用最佳更新程序（无论是滚动升级、金丝雀还是蓝/绿部署），最大限度地减少对基础设施的干扰。操作员可以混合、匹配和更改部署类型，而不必更改其群集管理工作流。»迁移任务和解除节点的使用在本系列的第2部分中，我们讨论了Nomad如何检测客户机节点发生故障并自动重新安排在发生故障的节点上运行的作业。当您知道一个节点需要停止服务时，您可以停用它，或者使用node drain命令"排出"它。这将切换给定节点的排水模式。当一个节点被标记为排出时，Nomad将不再计划该节点上的任何任务，而是开始将所有现有作业迁移到其他节点。排水将继续进行，直到所有分配都已从节点迁移出去，或者到了将所有分配强制迁移出节点的截止日期。作业作者可以使用migrate节指定Nomad从排出节点迁移任务的策略。迁移指令只适用于服务类型的作业，因为批处理作业通常是短期的，系统作业在每个客户机节点上运行。对于计数为1的作业，不需要提供migrate节。由于作业只有一个实例，因此在启动排出时将立即迁移该实例。使用max_parallel指定可以同时迁移的分配数。此数字必须小于组的总计数，因为count-max_并行分配将在迁移过程中保持运行。使用health_check指定确定分配运行状况的机制。与update一样，默认值是checks，它告诉Nomad等到所有任务都在运行并且consur健康检查通过。另一个选项是task_states（所有任务都在运行并且没有失败）。迁移没有手动运行状况检查选项。在替换分配的min_health_time或health_deadline达到正常状态之前，节点排出将不会继续。这允许大量的机器被清空，同时确保这些节点上的作业不会导致任何停机时间。下面的migrate节告诉Nomad一次迁移一个分配，只有当迁移的分配的所有任务都在运行并且相关联的运行状况检查通过10次时，才将迁移的分配标记为正常