Puppet 模块部署通过 Swift

包含您的 Launchpad 蓝图的 URL

https://blueprints.launchpad.net/tripleo/+spec/puppet-modules-deployment-via-swift

能够使用 OpenStack swift 对象存储服务将本地目录中的 puppet 模块部署到 overcloud。

问题描述

在将 puppet 模块部署到 overcloud 时，目前有三种

选项

  • 预先将 puppet 模块安装到“黄金”镜像中。可以通过 git 源码或使用发行版软件包预先安装模块。

  • 使用“firstboot”脚本从 undercloud（或其他可用的 rsync 服务器）rsync 模块。

  • 通过软件包升级将 puppet 模块后安装到正在运行的 Overcloud 服务器上（使用 RPM、Deb 等）。

以上机制中的任何一种在对 puppet 模块进行微小（临时）更改时都无法提供一个简单的流程，并且只有发行版软件包才能用于向已经部署的 overcloud 提供更新的 puppet 模块。虽然我们有一种方法可以在“firstboot”期间通过 rsync 覆盖更新的模块，但这对于可能希望使用 heat stack-update 部署 puppet 更改而无需为每个版本构建新的 RPM/Deb 包的运维人员来说不是一种有用的机制。

提议的变更

概述

创建一个可选的（选择加入）流程，如果启用，将允许运维人员创建并部署 puppet 模块的本地工件（tarball、发行版软件包等）到新的或现有的 overcloud，通过 heat stack-create 和 stack-update。该机制将使用 OpenStack 对象存储服务（而不是 rsync），该服务我们已经在 undercloud 上可用。新的流程将如下工作

  • puppet 模块工件（tarball、发行版软件包等）将被上传到 swift 容器中。

  • 容器将被配置为可以生成 Swift Temp URL

  • 将为存储在 swift 中的 puppet 模块 URL 生成一个 Swift Temp URL

  • 将生成一个 heat 环境，该环境设置 DeployArtifactURLs 参数为这个 swift URL。（该参数可以是一个列表，以便也可以下载多个 URL。）

  • TripleO Heat 模板将被修改，以便包含一个新的‘script’步骤，如果它检测到自定义 DeployArtifactURLs 参数，将自动从提供的 URL 下载工件，并在部署流程期间在每个 overcloud 角色上本地部署它。通过“本地部署”我们指的是 tarball 将被提取，RPM 将被安装，等等。实际的部署机制将是可插拔的，以便支持 tarball 和发行版软件包，并且将来可以添加更多内容，只要它们也适合通用的 DeployArtifactURLs 抽象。

  • 然后，运维人员可以使用生成的 heat 环境通过 heat stack-create 或 heat stack-update 部署一组新的 puppet 模块。

  • TripleO 客户端可以被修改，以便自动加载在方便位置生成的 heat 环境。这个（可选的）额外步骤将使启用上述流程变得透明，并且只需要运维人员运行一个‘upload-puppet-modules’工具来上传和配置新的 puppet 模块以通过 Swift 进行部署。

替代方案

有很多替代方案我们可以使用来获得类似的流程，该流程允许运维人员从本地目录部署 puppet 模块

  • 设置一个 puppet master 将允许类似的流程。这种方法的缺点是它需要一些开销，并且它是 puppet 特定的（如果以后有其他类型的磁盘上文件需要更新，则需要重新设计部署机制）。

  • Rsync。我们已经支持 rsync 用于 firstboot 脚本。rsync 的缺点是它需要额外的设置，并且没有像 OpenStack swift 这样的 API，允许对 puppet 模块进行本地或远程管理和更新。

安全影响

新的部署将使用通过 HTTP/HTTPS 的 Swift Temp URL。Swift Temp URL 的持续时间可以在通过 swift-temp-url 签名时控制。通过使用 Swift Temp URL，我们避免了将管理员凭据传递到每个 overcloud 节点以供 swiftclient 使用，而是可以简单地使用 curl（或 wget）下载更新的 puppet 模块。鉴于我们已经通过 http/https 使用 undercloud 部署镜像，因此以这种方式使用 Swift 应该不会带来额外的安全风险。

其他最终用户影响

通过 Swift 部署 puppet 模块将是选择加入的，因此对最终用户的影响将是最小的。heat 模板将包含一个新的脚本部署，即使功能未启用，在每个节点上部署也可能需要额外的几秒钟。我们可以通过 noop’ing heat 资源来避免额外的部署时间，用于新的 swift puppet 模块部署。

性能影响

开发人员和运维人员可能能够更快地部署 puppet 模块的更改（无需创建发行版软件包）。通过 swift 部署 puppet 模块（下载和提取 tarball）的实际部署速度可能与 tarball 一样快。

其他部署者影响

无。

开发人员影响

能够更轻松地将更新的 puppet 模块部署到 overcloud 可能会加快 puppet 模块的开发更新和测试周期。

实现

负责人

主要负责人

dan-prince

工作项

  • 在 tripleo-common 中创建一个 upload-puppet-modules 脚本。最初这可能是一个 bash 脚本，如果证明有用，我们最终会将其改进为 Python 版本。

  • 修改 tripleo-heat-templates，以便支持 DeployArtifactURLs 参数（如果设置了该参数），尝试从该参数部署文件列表。文件的实际内容可能是 tarball 或发行版软件包（RPM）。

  • 修改 tripleoclient，以便使用 upload-puppet-modules 的流程可以“透明”。简单地运行 upload-puppet-modules 不仅会上传 puppet 模块，还会生成一个 Heat 环境，然后自动配置 heat stack-update/create 命令以通过自定义 heat 环境使用新的 URL。

  • 更新 tripleo-ci 和/或 tripleo-common 中的 CI 脚本，以便我们使用新的 Puppet 模块部署机制。

  • 更新 tripleo-docs 以记录新功能。

依赖项

无。

测试

我们可能希望切换到使用此功能在我们的 CI 中，因为它允许我们避免为 undercloud 和 overcloud 节点克隆相同的 puppet 模块。只需在我们的部署流程中作为我们部署的一部分在 undercloud 上调用额外的 upload-puppet-modules 脚本，即可启用该功能并允许对其进行测试。

文档影响

我们需要记录与通过 Swift 部署 puppet 模块相关的其他（可选）流程。

参考资料