实施优化的执行的部署阶段

日期:

2017-09-14 12:00

标签:

优化，生命周期

为了提高易用性、优化执行并提供利用部署中预构建工件的能力，本规范建议实施部署阶段。

问题描述

  • 在具有大量目标主机的生产环境中，有时会出现瞬态故障。当发生这些故障时，部署者被迫重新执行 playbook，这可能会经历许多已经完成且无需再次执行的任务。虽然知识渊博的部署者会利用标签跳过和主机范围来减少执行时间，但这并非新手部署者所具备的技能。为了提高易用性，应该能够让 playbook 简单地跳过每个主机上已经完成的阶段。

  • 在生产环境中，可能需要使用完全工件化的部署，以确保使用完全相同的软件部署多个区域。目前，没有包含用于促进需要构建的完整工件堆栈（apt、git、python、容器）的工具。

  • 部署目前为了获取软件包、密钥和其他工件而执行大量的出站互联网交互。出站访问通常是安全环境较高的部署者的一个问题，因为主机无法直接访问互联网。如果这些工件在部署之前本地暂存，那么访问速度也会更快。

  • 部署目前将工件的构建与其安装和激活混合在一起。这导致部署时间非常长，通常超过可用于操作的维护时间。如果可以在不影响生产环境操作的情况下执行工件构建过程并将工件暂存，那么可以在维护时段之前执行这些过程，并且仅在维护时段内完成使用新工件的更改实施的最后一步。

  • 部署目前由于每个角色中组合的安装/配置任务，而以串行方式执行许多暂存操作。这需要很长时间，而且是不必要的。如果构建和暂存任务与配置更改正确分离，那么构建/暂存任务可以并行执行，并且仅以串行方式执行配置更改，从而显著加快大型部署的速度。

提议的变更

建议的阶段如下

  1. 构建：此阶段准备通用工件。此阶段可以由 CI 流程执行，以便准备适当的工件并将其存储在服务器上，以供跨多个区域使用。或者，它可以内联执行以进行单个构建（使用“developer_mode”）。工件示例包括发行版软件包、容器 rootfs tarball、python venvs 等。如果未内联执行，构建过程应在任何指定的宿主机上执行，并生成可以复制到 Web 服务器的工件。必须有一个明确定义的清单，详细说明生成的工件，以便暂存过程可以轻松地了解要获取哪些项目。

  2. 暂存：此阶段使用构建阶段生成的清单暂存所有工件。暂存是可选的，仅当构建阶段执行以构建所有工件时才会执行。暂存很可能只是一个 playbook，而不是角色中的某些内容，这样可以轻松地允许部署者实施替代暂存机制（如果他们选择这样做）。此阶段将在所有主机/容器上并行执行，以确保其执行速度快。

  3. 安装：此阶段执行使用暂存或构建的工件以及准备好的 OSA 配置来创建容器并安装所有服务的代码路径。此过程不应重新启动容器或服务，也不应对现有环境产生任何破坏性更改。此阶段将在所有主机/容器上并行执行，以确保其执行速度快。

  4. 配置：此阶段执行配置更改的实施，以配置文件并启动/重新启动适用的服务或容器。此阶段将以串行方式执行，以确保最大限度地减少服务中断。

每个阶段的任务将显式地分解为任务文件，例如

  • <service>_build.yml

  • <service>_install.yml

  • <service>_install_apt.yml

  • <service>_install_nginx.yml

  • <service>_configure.yml

  • <service>_configure_nginx.yml

  • <service>_configure_ssl.yml

  • <service>_configure_keys.yml

分解任务文件的总体思路是在适当的情况下实施条件和/或动态包含，以确保仅评估任务，除非满足广泛的条件。这与将许多任务放在单个文件中并为所有任务设置条件不同，因为 Ansible 无需依次评估每个任务，而是评估是否应评估任务块。这可以减少执行时间。

一些示例

  1. 如果角色执行时可用预构建的工件，则跳过构建阶段的任务。

  2. 如果环境中没有仓库服务器，则不要尝试下载任何 python venvs 或其他工件。

  3. 如果 ansible_pkg_mgr == 'apt'，则不要评估任何与 yum 相关的任务。

作为此解决方案的一部分，构建和安装阶段应在阶段完成时将本地 facts 放到目标主机上。本地 fact 将防止通过条件包含再次执行该阶段。这提供了一个检查点重启机制，因此如果部署者执行“setup-everything”，则执行速度会快得多，因为它将跳过整个阶段并从上次停止的地方继续。这也意味着如果使用预构建的工件，这些阶段将被跳过，并且环境中的部署速度会快得多。

丢弃的 facts 将是标签特定的 - 例如，丢弃的 fact 将指示“cinder”服务在主机上安装了“14.2.0”版本，这意味着如果提议的标签和部署的标签相同，则无需运行构建和暂存任务。可以通过另一个变量覆盖此行为，该变量启用强制重建或强制重新安装。

备选方案

  1. 忍受漫长的部署时间。

  2. 更好地记录如何使用软件包镜像、代理等来减少部署时间。

Playbook/Role 影响

将实施新的 playbook，允许部署者执行更具针对性的构建过程并准备工件。现有 playbook 将继续工作，但将进行调整以利用适当的 facts 来跳过先前执行的构建过程（如果该过程已经执行）。

角色将是影响最大的地方，因为许多任务将被重新组织以促进分阶段的过程。

升级影响

能够为环境使用预构建的工件将意味着升级过程可以更轻松地回滚到以前的状态（如果需要）。

安全影响

由于此过程将提高确保一致构建环境的能力，因此可能会提高部署的安全性。

性能影响

希望部署和升级性能比现在好得多。运行部署性能应该没有差异。

最终用户影响

对于已部署的 OpenStack 环境的最终用户而言，不会有任何差异。

部署者影响

部署者将继续拥有相同的入口点，但将获得预构建环境工件的能力，以便确保部署和升级执行得更快、更可靠。

开发人员影响

这些更改应该通过减少实施 AIO 所需的时间来改善开发人员的体验。

依赖项

无

实现

负责人

主要负责人

jesse-pretorius (odyssey4me)

工作项

默认 AIO 中实施的每个角色将按顺序处理，以重新安排和优化基于此工作流程。此处未详细说明工作项，但将在 gerrit 中通过蓝图的主题反映出来，并且在 launchpad 中可见。

测试

我们可能能够为 gate 测试使用预构建的工件，以减少集成测试所需的时间。将为每个分支在 OpenStack Infrastructure 上发布上次成功构建的工件的选项将被探索。这些工件仅用于开发测试，不适用于生产环境。

文档影响

分阶段的部署过程需要记录，并且需要包含有关如何选择使用工件化构建的详细信息。

参考资料

无