这是Nomad构建弹性基础架构系列(第1部分，第2部分)中的第三部分。在本系列中，我们将探讨Nomad如何处理意外故障、停机和集群基础架构的日常维护，通常不需要操作员干预。
在本文中，我们将介绍Nomad如何通过提供一个一致的工作流来管理整个作业生命周期，从而为您的计算基础设施增加弹性，包括用于更新和迁移作业的健壮选项，从而帮助最小化甚至消除停机时间。
操作job的工作流
Nomad作业规范允许操作员为运行job的所有方面指定模式。这包括任务、镜像、部署策略、资源、优先级、约束、服务注册、加密和部署工作负载所需的其他信息。
作业操作流程有四个主要步骤:
- 根据作业规范创建或修改作业文件
- 使用Nomad服务端计划和检查更改作业
- 将作业文件提交给Nomad服务端
- (可选)检查作业状态和日志
在更新作业时，有许多内置的更新策略可以在作业文件中定义。更新策略可以帮助操作人员安全地管理新版本的作业。因为作业文件定义了更新策略(蓝/绿、滚动更新等)，所以无论这是初始部署还是对现有作业的更新，工作流都保持不变。
update节指定Nomad在部署任务组的新版本时将使用的更新策略。如果省略，滚动更新和金丝雀部署将被禁用。
滚动和串行更新
在update节中，操作员指定与max_parallel并发地更新多少作业分配。将max_parallel设置为1，告诉Nomad采用串行升级策略，每次最多升级一个分配。将其设置为大于1的值将启用并行升级，从而可以同时升级多个分配。
Nomad在更新下一个集合之前等待更新节点的健康检查通过。使用health_check来指定确定分配健康状况的机制。默认值是检查（checks），它告诉Nomad等待直到所有任务都运行并且Consul健康检查通过。其他选项是task_states(所有任务都在运行，没有失败)和manual(操作员将使用HTTP API手动设置健康状态)。
三个参数指定了在何种情况下分配被认为是健康的以及获得这种状态的最后期限。使用min_healthy_time指定分配在被标记为健康状态之前必须处于健康状态的最小时间，并解除对进一步的分配进行更新的阻塞。使用healthy_deadline来指定分配必须标记为健康的最后期限，超过之后分配将自动转换为不健康。最后，使用progress_deadline来指定分配必须被标记为健康的最后期限。最后期限从创建部署的第一个分配开始，并在部署转换到健康状态时重置分配。如果在进度截止日期之前没有将分配转换为健康状态，则部署将被标记为失败。
如果部署的一部分分配失败，只要没有超过progress_deadline, Nomad就会根据reschedule节中的参数重新调度它。这允许Nomad优雅地处理特定于某个节点的临时错误。Nomad将继续重新安排部署时间，直到progress_deadline被命中时，这个问题可能会随着更新而发生，并且整个部署被标记为失败。
使用auto_revert = true指定作业在部署失败时应该自动恢复到最后的稳定版本。当作业的所有部署分配都标记为健康时，作业被标记为稳定。
下面的update节告诉Nomad每次执行滚动更新3个，直到分配的所有任务都在运行，他们的Consul健康检查通过至少10秒，然后才考虑分配是否健康。它为健康分配设定了5分钟的最后期限，超过5分钟后，Nomad就会标记它为不健康。而且，如果任何一个分配在10分钟后不能恢复健康，整个部署将被标记为失败，Nomad将自动恢复到最后一个已知的稳定部署。
job "example" {
update {
max_parallel = 3
health_check = "checks"
min_healthy_time = "10s"
healthy_deadline = "5m"
progress_deadline = "10m"
auto_revert = true
}
}
对于system作业，只强制执行max_parallel和stagger。作业以max_parallel速度更新，在下一次更新集合之前等待的时间错开了。
金丝雀部署
在开始滚动升级之前，金丝雀更新是测试作业新版本的有用方法。update节支持设置作业操作员在作业通过canary参数更改时希望Nomad创建的canaries的数量。在更新作业规范时，Nomad会创建canaries，而不会停止之前版本的分配。
这种模式允许操作人员对新作业版本有更高的信心，因为他们可以路由流量、检查日志等，以确定新应用程序正在正确地执行。
当canary设置为1或更多时，任何可能导致破坏性更新的作业更改都会导致Nomad创建指定数量的canaries，而不会停止之前的任何分配。一旦操作员确定canaries是健康的，就可以提升它们，Nomad将以max_parallel的速度对剩余的分配进行滚动更新。Canary的提升可以由操作员手动完成，也可以使用api进行自动化。
下面的update节告诉Nomad使用1个canary执行canary的更新，一旦那个canary得到提升，就一次执行滚动更新3个来完成剩余的分配。
job "example" {
update {
canary = 1
max_parallel = 3
}
}蓝绿部署
蓝绿部署有其他几个名称，包括红色/黑色或A/B，但概念通常是相同的。在蓝绿部署中，部署的工作负载有两个版本。每次只有一个版本是活跃的，从一个版本到下一个版本的过渡阶段除外。“活跃的”一词往往意味着“接收流量”或“服务中”。
在Nomad中，可以通过在update节中设置canary的值来匹配组节中的count的值来启用蓝绿部署。当这些值是相同的,而不是做一个滚动升级现有的分配提交新版本的工作时,新版本组部署在现有的组旁边。操作员可以验证组的新版本是稳定的。当他们满意时，组可以被提升，并且组的所有旧版本的分配都将被关闭。蓝绿部署重复了升级过程中所需的资源，但由于组的原始版本未受影响，因此启用了非常安全的部署。
下面的update节告诉Nomad在之前的分配仍在运行时，通过启动3个canary分配(与count相同)来执行一个蓝/绿更新。
group "cache" {
count = 3
update {
canary = 3
}
}Nomad的工作生命周期(包括更新)允许操作人员根据自己的情况使用最佳的更新过程，从而将对基础设施的破坏降到最低，无论是滚动升级、金丝雀还是蓝绿部署。操作人员可以混合、匹配和更改部署类型，而无需更改集群管理工作流。
迁移任务和关闭节点
在本系列的第2部分中，我们讨论了Nomad如何检测客户端节点何时发生故障，并自动重新调度在故障节点上运行的作业。
当你知道某个节点需要退出服务时，你可以退役（decommission），或者使用node drain命令“排干”它。这将切换给定节点的排干模式。当一个节点被标记为draining时，Nomad将不再安排该节点上的任何任务，并开始将所有现有的作业迁移到其他节点。继续执行排干，直到所有的分配都迁移出节点，或者到达最后期限，此时所有的分配都被迫迁移出节点。
job作者可以使用migrate节来指定Nomad的策略，以便将任务从排干节点迁移出去。迁移指令只适用于service类型作业，因为batch作业通常是短期的，system作业在每个客户端节点上运行。对于count 为1的作业，不需要提供migrate节。因为作业只有一个实例，所以它将在启动排干时立即被迁移。
使用max_parallel指定可以同时迁移的分配数。这个数字必须小于组的总数，因为count - max_parallel分配将在迁移期间保持运行。使用health_check指定确定分配健康状态的机制。与update一样，默认值是checks，它告诉Nomad等待直到所有任务都运行并且Consul健康检查通过。另一个选项是task_states(所有正在运行的任务都没有失败)。迁移没有手动（manual）健康检查选项。
直到替换分配达到min_healthy_time或healthy_deadline的健康状态时，节点排干才会继续。这允许大量机器被排干，同时确保这些节点上的作业不会导致任何停机。
下面的migrate节告诉Nomad要一次迁移一个分配，在5分钟的期限内，只有在所有任务都运行并且相关的健康检查持续了10秒或更长时间之后，才标记迁移后的分配是健康的。
job "example" {
migrate {
max_parallel = 1
health_check = "checks"
min_healthy_time = "10s"
healthy_deadline = "5m"
}
}migrate节是job作者用来定义他们的服务应该如何迁移的，而节点排干最后期限是系统操作人员对一个排干时间的严格限制。
节点排干是集群维护的一个常规部分，这是由于服务器维护和操作系统升级等原因造成的。在传统数据中心中，操作人员需要与开发人员协调节点维护，以确保不会导致停机。相反，Nomad允许开发人员控制应用程序的迁移方式，这样操作人员在进行集群维护时就不需要紧密协作。
有关详细信息，请参见停用Nomad客户端节点和使用HashiCorp Nomad的高级节点排干。
总结
在本系列使用Nomad构建弹性基础架构的第三篇文章(第1部分、第2部分)中,我们介绍了Nomad如何增加弹性的计算基础设施提供一个一致的工作流管理整个生命周期的工作,包括可靠的部署选项更新和迁移工作,帮助最小化甚至消除停机时间。
作业的更新策略由作业文件的update节控制。操作人员可以配置许多选项来安全地管理更新，包括:串行和并行更新、金丝雀和蓝/绿部署。Nomad通过自动重新调度失败的分配来优雅地处理部署期间的临时问题，直到满足部署的progress_deadline。
migrate节使job作者可以指定Nomad的策略，以便将任务从排干节点迁移出去。这可以帮助操作人员执行集群维护，而无需紧密协作，并在不导致停机的情况下执行许多节点的排干。
在本系列的下一篇也是最后一篇文章中，我们将了解Nomad如何提供数据丢失的弹性，以及如何从停机中恢复。