合作伙伴集成

Red Hat OpenStack Platform 16.1

在 Red Hat OpenStack Platform 环境中集成经认证的第三方软件和硬件

摘要

本指南提供有关将认证第三方组件集成到 Red Hat OpenStack Platform 环境中的指导信息。这包括将这些组件添加到 overcloud 镜像,并使用 director 创建用于部署的配置。

前言

使开源包含更多

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息

对红帽文档提供反馈

我们感谢您对文档提供反馈信息。与我们分享您的成功秘诀。

使用直接文档反馈(DDF)功能

使用 添加反馈 DDF 功能,用于特定句子、段落或代码块上的直接注释。

  1. Multi-page HTML 格式查看文档。
  2. 请确定您看到文档右上角的 反馈 按钮。
  3. 用鼠标指针高亮显示您想评论的文本部分。
  4. 添加反馈
  5. 添加反馈项中输入您的意见。
  6. 可选:添加您的电子邮件地址,以便文档团队可以联系您以讨论您的问题。
  7. Submit

第 1 章 集成第三方 componenet 的原因

您可以使用 Red Hat OpenStack Platform (RHOSP)将解决方案与 RHOSP director 集成。使用 RHOSP director 安装和管理 RHOSP 环境的部署生命周期。您可以优化资源,缩短部署时间并降低生命周期管理成本。

RHOSP director 集成提供与现有企业管理系统和流程的集成。红帽产品(如 CloudForms)应该能够了解与 director 集成,并为管理服务部署提供更广泛的风险。

1.1. 合作伙伴集成先决条件

在使用 director 执行操作前必须满足几个先决条件。合作伙伴集成的目标是创建共享了解整个集成,作为红帽工程、合作伙伴经理和支持资源以促进技术协同工作的基础。

要包括 Red Hat OpenStack Platform director 的第三方组件,您必须使用 Red Hat OpenStack Platform 认证合作伙伴解决方案。

第 2 章 director 架构

Red Hat OpenStack Platform director 使用 OpenStack API 配置、部署和管理 Red Hat OpenStack Platform (RHOSP)环境。这意味着,与 director 集成需要您与这些 OpenStack API 和支持组件集成。这些 API 的优势是它们经过良好记录,上游进行了广泛的集成测试,并且了解 director 如何为具有 RHOSP 基础知识的用户更容易工作。director 会自动继承核心 OpenStack 功能增强、安全补丁和程序错误修复。

director 是一个用于安装和管理完整的 RHOSP 环境的工具组。它主要基于 OpenStack project TripleO,它是"OpenStack-On-OpenStack"的缩写。此项目使用 RHOSP 组件来安装完全可操作的 RHOSP 环境。这包括置备和控制裸机系统用作 OpenStack 节点的新 OpenStack 组件。这为安装精益可靠的完整 RHOSP 环境提供了一个简单方法。

director 使用两个主要概念:undercloud 和 overcloud。director 是组成单一系统的 OpenStack 环境(也称为 undercloud)的 OpenStack 组件的子集。undercloud 充当一个管理系统,可为工作负载创建生产级云。此生产级云是 overcloud。有关 overcloud 和 undercloud 的更多信息,请参阅 Director 安装和使用 指南。

图 2.1. undercloud 和 overcloud 的架构

director 包括可用于创建 overcloud 配置的工具、实用程序和示例模板。director 捕获配置数据、参数和网络拓扑信息,并将这些信息与 ironic、heat 和 Puppet 等组件结合使用,以编排 overcloud 安装。

2.1. 核心组件和 overcloud

下列组件是 Red Hat OpenStack Platform director 的核心,并致力于创建 overcloud:

  • OpenStack Bare Metal Provisioning 服务(ironic)
  • OpenStack 编排服务(heat)
  • Puppet
  • tripleo 和 TripleO heat 模板
  • 可组合的服务
  • 容器化服务和 Kolla
  • Ansible

2.2. OpenStack Bare Metal Provisioning 服务(ironic)

裸机恢复调配服务通过自助服务配置为最终用户提供专用裸机主机。director 使用裸机置备来管理 overcloud 中裸机硬件的生命周期。裸机置备使用自己的 API 定义裸机节点。

要将 OpenStack 环境置备 director,您必须使用特定的驱动程序将节点注册到裸机置备。支持的主要驱动是智能平台管理接口(IPMI),因为大多数硬件包括对 IPMI 电源管理功能的一些支持。但是,裸机置备还包括特定于供应商的产品,如 HP iLO、Cisco UCS 或 Dell DRAC。

裸机置备控制节点的电源管理,并使用内省机制收集硬件信息或事实。director 使用内省过程中的信息将节点与各种 OpenStack 环境角色匹配,如 Controller 节点、计算节点和存储节点。例如,一个包含 10 个磁盘的发现节点通常置备为 Storage 节点。

图 2.2. 使用裸机置备服务来控制节点的电源管理

如果要让 director 支持您的硬件,必须在裸机置备服务中拥有驱动程序覆盖。

2.3. Heat

Heat 是一种应用堆栈编排引擎。在将应用部署到云之前,您可以使用 heat 为应用程序定义元素。创建包括多个基础架构资源(如实例、网络、存储卷和弹性 IP)的堆栈模板,以及一组用于配置的参数。使用 heat 创建基于给定依赖项链的这些资源,监控资源的可用性,并在需要时扩展资源。您可以使用这些模板使应用堆栈可移植,并实现可重复的结果。

图 2.3. 在将应用部署到云之前,使用 heat 服务定义应用程序的元素

director 使用原生 OpenStack heat API 来置备和管理与 overcloud 部署关联的资源。这包括精确的详细信息,如定义每个节点角色要调配的节点数量、为每个节点配置的软件组件,以及 director 配置这些组件和节点类型的顺序。director 还使用 heat 来对部署后进行故障排除并进行更改。

以下示例是从 heat 模板的一个片段,定义 Controller 节点的参数:

NeutronExternalNetworkBridge:
    description: Name of bridge used for external network traffic.
    type: string
    default: 'br-ex'
NeutronBridgeMappings:
    description: >
      The OVS logical->physical bridge mappings to use. See the Neutron
      documentation for details. Defaults to mapping br-ex - the external
      bridge on hosts - to a physical name 'datacentre' which can be used
      to create provider networks (and we use this for the default floating
      network) - if changing this either use different post-install network
      scripts or be sure to keep 'datacentre' as a mapping network name.
    type: string
    default: "datacentre:br-ex"

Heat 会消耗 director 中包含的模板,以协助创建 overcloud,其中包括调用 ironic 以为节点提供电源。您可以使用标准 heat 工具查看中 overcloud 的资源和状态。例如,您可以使用 heat 工具将 overcloud 作为嵌套应用堆栈显示。使用 heat 模板的语法来声明和创建生产 OpenStack 云。由于每个合作伙伴集成用例都需要 heat 模板,因此您必须对合作伙伴集成有先理解和熟练程度。

2.4. Puppet

Puppet 是一种配置管理和实施工具,可用于描述和维护机器的最终状态。您可以在 Puppet 清单中定义此最终状态。Puppet 支持两种模型:

  • 您以清单格式在本地运行指令的独立模式
  • Puppet 从中央服务器检索其清单的服务器模式,称为 Puppet 宿主

您可以通过两种方式进行更改:

  • 将新清单上传到节点,并在本地执行它们。
  • 在 Puppet 宿主上的客户端/服务器模型中进行修改。

director 在以下区域中使用 Puppet:

  • 在 undercloud 主机上,以根据 undercloud.conf 文件中的配置来安装和配置软件包。
  • 通过将 openstack-puppet-modules 软件包注入到基础 overcloud 镜像中,Puppet 模块已准备好进行部署后配置。默认情况下,您将创建一个包含每个节点的所有 OpenStack 服务的镜像。
  • 为节点提供额外的 Puppet 清单和 heat 参数,并在 overcloud 部署后应用配置。这包括根据节点类型启用和启动配置的服务。
  • 为节点提供 Puppet hieradata。Puppet 模块和清单可从站点或特定于节点的参数自由,以保持清单一致。hieradata 充当一系列参数化值,您可以推送到 Puppet 模块并在其他区域中的引用。例如,若要在清单中引用 MySQL 密码,请将此信息保存为 hieradata,并在清单中引用。

    要查看 hieradata,请输入以下命令:

    [root@localhost ~]# grep mysql_root_password hieradata.yaml # View the data in the hieradata file
    openstack::controller::mysql_root_password: ‘redhat123'

    要引用 Puppet 清单中的 hieradata,请输入以下命令:

    [root@localhost ~]# grep mysql_root_password example.pp # Now referenced in the Puppet manifest
    mysql_root_password  => hiera(‘openstack::controller::mysql_root_password')

需要软件包安装和服务启用的合作伙伴集成服务可以创建 Puppet 模块来满足其要求。

2.5. tripleo 和 TripleO heat 模板

director 基于上游 TripleO 项目。此项目将一组 OpenStack 服务与以下目标相结合:

  • 使用镜像服务(glance)存储 overcloud 镜像。
  • 使用编排服务(heat)编配 overcloud
  • 使用裸机置备(ironic)和计算(nova)服务置备裸机

TripleO 还包括定义红帽支持的 overcloud 环境的 heat 模板集合。使用 heat,读取此模板集合并编配 overcloud 堆栈。

2.6. 可组合的服务

Red Hat OpenStack Platform 的每个方面被分为可组合服务。这意味着您可以定义使用不同服务组合的不同角色。例如,您可以将网络代理从默认 Controller 节点移到独立的 Networker 节点。

2.7. 容器化服务和 Kolla

每个主 Red Hat OpenStack Platform (RHOSP)服务都在容器中运行。这提供了一种将每个服务保持在与主机分离的隔离命名空间内的方法。这样做有以下影响:

  • 在部署过程中,RHOSP 从红帽客户门户网站中提取并运行容器镜像。
  • podman 命令运行管理功能,如启动和停止服务。
  • 要升级容器,您必须拉取新的容器镜像,并使用更新的版本替换现有的容器。

Red Hat OpenStack Platform 使用了通过 Kolla 工具集来构建和管理的一组容器。

2.8. Ansible

Red Hat OpenStack Platform 使用 Ansible 来促进可组合服务升级的某些功能。这包括启动和停止服务和执行数据库升级等功能。这些升级任务在可组合的服务模板中定义。

第 3 章 使用 overcloud 镜像

Red Hat OpenStack Platform (RHOSP) director 为 overcloud 提供镜像。此集合中的 QCOW 镜像包含一系列基本软件组件,它们集成形成各种 overcloud 角色,如计算、控制器和存储节点。在某些情况下,您可能需要修改 overcloud 镜像的某些方面以满足您的需要,如将其他组件安装到节点。

您可以使用 virt-customize 工具修改现有 overcloud 镜像,以增加现有的 Controller 节点。例如,使用以下步骤安装不随初始镜像提供的其他 ml2 插件、Cinder 后端或监控代理。

重要

如果您修改 overcloud 镜像以包括第三方软件并报告问题,红帽可能会要求根据我们的通用支持政策,以未经修改的镜像重现问题 :https://access.redhat.com/articles/1067。

3.1. 获取 overcloud 镜像

director 需要几个磁盘镜像用于置备 overcloud 节点:

  • 一个内省内核和 ramdisk - 用于通过 PXE 引导进行裸机系统内省。
  • 一个部署内核和 ramdisk - 用于系统置备和部署。
  • overcloud 内核、ramdisk 和完整镜像 - director 写入节点硬盘的基本 overcloud 系统。

流程

  1. 要获取这些镜像,请安装 rhosp-director-imagesrhosp-director-images-ipa 软件包:

    $ sudo dnf install rhosp-director-images rhosp-director-images-ipa
  2. 将存档提取到 stack 用户的主目录的 images 中,/home/stack/images

    $ cd ~/images
    $ for i in /usr/share/rhosp-director-images/overcloud-full-latest-16.1.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-16.1.tar; do tar -xvf $i; done

3.2. initrd:修改初始 ramdisk

有些情况可能需要您修改初始 ramdisk。例如,您可能需要在内省或置备过程中引导节点时特定的驱动程序可用。在 overcloud 上下文中,这包括以下 ramdisk:

  • ironic-python-agent.initramfs :内省和置备 ramdisk。
注意

如果计算机网络启动到实际实例,则只使用 overcloud-full.initrd ramdisk。

此流程将额外的 RPM 软件包添加到 ironic-python-agent.initramfs ramdisk 中作为示例。

前提条件

  • 已安装 pax 工具:

    $ sudo dnf install -y spax

流程

  1. root 用户身份登录,再为 ramdisk 创建临时目录:

    # mkdir ~/ipa-tmp
    # cd ~/ipa-tmp
  2. 使用 skipcpiocpio 命令,将 ramdisk 提取到临时目录:

    # /usr/lib/dracut/skipcpio /home/stack/images/ironic-python-agent.initramfs | zcat | cpio -ivd | pax -r
  3. 将 RPM 软件包安装到提取的内容:

    # rpm2cpio ~/RPMs/python-proliantutils-2.1.7-1.el7ost.noarch.rpm | pax -r
  4. 重新创建新的 ramdisk:

    # find . 2>/dev/null | cpio --quiet -c -o | gzip -8  > /home/stack/images/ironic-python-agent.initramfs
    # chown stack: /home/stack/images/ironic-python-agent.initramfs
  5. 验证新软件包现在存在于 ramdisk 中:

    # lsinitrd /home/stack/images/ironic-python-agent.initramfs | grep proliant

3.3. QCOW:安装 virt-customize 到 director

libguestfs-tools 软件包包含 virt-customize 工具。

流程

  • rhel-8-for-x86_64-appstream-eus-rpms 存储库安装 libguestfs-tools

    $ sudo dnf install libguestfs-tools
重要

如果在 undercloud 上安装 libguestfs-tools 软件包,请禁用 iscsid.socket 以避免与 undercloud 上的 tripleo_iscsid 服务冲突:

$ sudo systemctl disable --now iscsid.socket

3.4. QCOW:检查 overcloud 镜像

在查看 overcloud-full.qcow2 镜像的内容前,您必须创建使用此镜像的虚拟机。

流程

  1. 要创建使用 overcloud-full.qcow2 镜像的虚拟机实例,请使用 guestmount 命令:

    $ mkdir ~/overcloud-full
    $ guestmount -a overcloud-full.qcow2 -i --ro ~/overcloud-full

    您可以查看 ~/overcloud-full 中的 QCOW2 镜像内容。

3.5. QCOW:设置 root 密码

设置 root 密码,以通过控制台为您的节点提供管理员级别的访问。

注意

--delete /etc/machine-id 应该是传递给 virt-* 命令 的最最后一次操作。否则,/etc/machine-id 会在 --run-command 之前删除,从而导致意外行为。

流程

  • 在镜像中设置 root 用户的密码:

    $ export LIBGUESTFS_BACKEND=direct
    $ virt-customize --selinux-relabel -a overcloud-full.qcow2 --root-password password:test --delete /etc/machine-id
    [  0.0] Examining the guest ...
    [ 18.0] Setting a random seed
    [ 18.0] Setting passwords
    [ 19.0] Finishing off

3.6. QCOW:注册镜像

将 overcloud 镜像注册到 Red Hat Content Delivery Network。

流程

  1. 临时注册您的镜像,以启用与您的自定义相关的红帽软件仓库:

    $ export LIBGUESTFS_BACKEND=direct
    $ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager register --username=[username] --password=[password]' --delete /etc/machine-id
    [  0.0] Examining the guest ...
    [ 10.0] Setting a random seed
    [ 10.0] Running: subscription-manager register --username=[username] --password=[password]
    [ 24.0] Finishing off
  2. [username][password] 替换为您的红帽客户帐户详情。这会在镜像中运行以下命令:

    subscription-manager register --username=[username] --password=[password]

3.7. QCOW:附加订阅并启用红帽软件仓库

流程

  1. 从您的帐户订阅中查找池 ID 列表:

    $ sudo subscription-manager list
  2. 选择订阅池 ID 并将其附加到镜像:

    $ export LIBGUESTFS_BACKEND=direct
    $ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager attach --pool [subscription-pool]' --delete /etc/machine-id
    [  0.0] Examining the guest ...
    [ 12.0] Setting a random seed
    [ 12.0] Running: subscription-manager attach --pool [subscription-pool]
    [ 52.0] Finishing off
  3. [subscription-pool] 替换为您选择的订阅池 ID:

    subscription-manager attach --pool [subscription-pool]

    这会将池添加到镜像中,以便您可以启用存储库。

  4. 启用红帽软件仓库:

    $ subscription-manager repos --enable=[repo-id]

3.8. QCOW:复制自定义存储库文件

将第三方软件添加到镜像需要额外存储库。以下是一个存储库文件示例,其中包含使用 OpenDaylight 存储库内容的配置:

流程

  1. 列出 opendaylight.repo 文件的内容:

    $ cat opendaylight.repo
    
    [opendaylight]
    name=OpenDaylight Repository
    baseurl=https://nexus.opendaylight.org/content/repositories/opendaylight-yum-epel-8-x86_64/
    gpgcheck=0
  2. 将 上的存储库文件复制到镜像中:

    $ virt-customize --selinux-relabel -a overcloud-full.qcow2 --upload opendaylight.repo:/etc/yum.repos.d/ --delete /etc/machine-id
    [  0.0] Examining the guest ...
    [ 12.0] Setting a random seed
    [ 12.0] Copying: opendaylight.repo to /etc/yum.repos.d/
    [ 13.0] Finishing off

    upload 选项会将 存储库文件复制到 overcloud 镜像的 /etc/yum.repos.d/ 中。

重要

红帽对非认证供应商的软件不提供支持。请咨询您的红帽支持代表,其中要安装的软件受支持。

3.9. QCOW:安装 RPM

流程

  • 使用 virt-customize 命令将软件包安装到镜像中:

    $ export LIBGUESTFS_BACKEND=direct
    $ virt-customize --selinux-relabel -a overcloud-full.qcow2 --install opendaylight --delete /etc/machine-id
    [  0.0] Examining the guest ...
    [ 11.0] Setting a random seed
    [ 11.0] Installing packages: opendaylight
    [ 91.0] Finishing off

    使用 --install 选项指定要安装的软件包。

3.10. QCOW:清理订阅池

流程

  • 安装必要的软件包以自定义镜像后,删除订阅池并取消注册镜像:

    $ export LIBGUESTFS_BACKEND=direct
    $ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager remove --all' --delete /etc/machine-id
    [  0.0] Examining the guest ...
    [ 12.0] Setting a random seed
    [ 12.0] Running: subscription-manager remove --all
    [ 18.0] Finishing off

3.11. QCOW:取消注册镜像

流程

  • 取消注册镜像,以便 overcloud 部署过程可以将镜像部署到您的节点上,并单独注册每个镜像:

    $ export LIBGUESTFS_BACKEND=direct
    $ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager unregister' --delete /etc/machine-id
    [  0.0] Examining the guest ...
    [ 11.0] Setting a random seed
    [ 11.0] Running: subscription-manager unregister
    [ 17.0] Finishing off

3.12. QCOW:重置机器 ID

流程

  • 为镜像重置机器 ID,以便使用这个镜像的机器不使用重复的机器 ID:

    $ virt-sysprep --operation machine-id -a overcloud-full.qcow2

3.13. 将镜像上传到 director

修改镜像后,您需要将其上传到 director。

流程

  1. 查找 stackrc 文件,以便您可以从命令行访问 director:

    $ source stackrc
  2. 上传用于部署 overcloud 的默认 director 镜像:

    $ openstack overcloud image upload --image-path /home/stack/images/

    这会将下列镜像上传到 director:

    • bm-deploy-kernel
    • bm-deploy-ramdisk
    • overcloud-full
    • overcloud-full-initrd
    • overcloud-full-vmlinuz

      该脚本还会在 director 的 PXE 服务器上安装内省镜像。

  3. 在 CLI 中查看镜像列表:

    $ openstack image list
    +--------------------------------------+------------------------+
    | ID                                   | Name                   |
    +--------------------------------------+------------------------+
    | 765a46af-4417-4592-91e5-a300ead3faf6 | bm-deploy-ramdisk      |
    | 09b40e3d-0382-4925-a356-3a4b4f36b514 | bm-deploy-kernel       |
    | ef793cd0-e65c-456a-a675-63cd57610bd5 | overcloud-full         |
    | 9a51a6cb-4670-40de-b64b-b70f4dd44152 | overcloud-full-initrd  |
    | 4f7e33f4-d617-47c1-b36f-cbe90f132e5d | overcloud-full-vmlinuz |
    +--------------------------------------+------------------------+

    此列表不显示内省 PXE 镜像(agent.*)。director 将这些文件复制到 /var/lib/ironic/httpboot

    [stack@host1 ~]$ ls /var/lib/ironic/httpboot -l
    total 151636
    -rw-r--r--. 1 ironic ironic       269 Sep 19 02:43 boot.ipxe
    -rw-r--r--. 1 root   root         252 Sep 10 15:35 inspector.ipxe
    -rwxr-xr-x. 1 root   root     5027584 Sep 10 16:32 agent.kernel
    -rw-r--r--. 1 root   root   150230861 Sep 10 16:32 agent.ramdisk
    drwxr-xr-x. 2 ironic ironic      4096 Sep 19 02:45 pxelinux.cfg

第 4 章 配置 OpenStack Puppet 模块的添加

本章介绍了如何为 OpenStack Puppet 模块提供添加的内容。其中包括一些有关开发 Puppet 模块的基本指南。

4.1. Puppet 模块分析

在贡献 OpenStack 模块前,您必须了解创建 Puppet 模块的组件。

⁠manifests

清单是包含用于定义一组资源及其属性的代码的文件。资源是系统的任何可配置部分。资源示例包括软件包、服务、文件、用户和组、SELinux 配置、SSH 密钥身份验证、cron 作业等。清单使用一组键值对来定义每个所需的资源。

  package { 'httpd':
    ensure => installed,
  }

例如,此声明将检查是否安装了 httpd 软件包。如果没有,则清单将执行 dnf 并安装它。清单位于模块的 清单目录中。Puppet 模块也使用测试目录进行测试清单。这些清单用于测试官方清单中某些类。

类统一清单中的多个资源。例如,如果您安装并配置 HTTP 服务器,您可以创建一个以下三个资源的类:一个用于安装 HTTP 服务器软件包,一个用于配置 HTTP 服务器,另一个用于启动或停止服务器。您还可以引用来自其他模块的类,以应用其配置。例如,如果要配置还需要 webserver 的应用,您可以引用前面提到的 HTTP 服务器类。
附录文件

模块可以包含静态文件,供 Puppet 复制到系统上的特定位置。通过使用清单中的 file 资源声明来定义位置和其他属性(如权限)。

静态文件位于模块的文件目录中。

⁠templates

有时,配置文件需要自定义内容。在这种情况下,用户会创建一个模板而不是静态文件。与静态文件一样,模板在清单中定义,并复制到系统上的位置。区别在于,模板允许 Ruby 表达式定义自定义内容和变量输入。例如,如果要使用自定义端口配置 httpd,那么配置文件的模板包括:

Listen <%= @httpd_port %>

此例中的 httpd_port 变量在引用此模板的清单中定义。

模板位于模块的 templates 目录中。

⁠Plugins

对超出 Puppet 核心功能的核心功能,使用插件。例如,您可以使用插件来定义自定义事实、自定义资源或新功能。例如,数据库管理员可能需要 PostgreSQL 数据库的资源类型。这有助于在数据库管理员安装 PostgreSQL 后使用一组新的数据库来填充 PostgreSQL。因此,数据库管理员必须仅创建一个 Puppet 清单,以确保 PostgreSQL 安装以及之后创建数据库。

插件位于模块的 lib 目录中。根据插件类型,这包括一组子目录:

  • /lib/facter - 自定义事实的位置。
  • /lib/puppet/type - Location 用于自定义资源定义,用于概述属性的键值对。
  • /lib/puppet/provider - 用于自定义资源提供程序的 Location,它们与资源类型定义结合使用来控制资源。
  • /lib/puppet/parser/functions - 自定义功能的 Location。

4.2. 安装服务

有些软件需要软件包安装。这是 Puppet 模块可以执行的一个功能。这需要一个定义特定软件包配置的资源定义。

流程

  • 要通过 mymodule 模块安装 httpd 软件包,请将以下内容添加到 mymodule 模块中的 Puppet 清单中:

    class mymodule::httpd {
      package { 'httpd':
        ensure => installed,
      }
    }

    此代码定义了名为 httpdmymodule 的子类,然后为 httpd 软件包定义软件包资源声明。ensure => installed 属性告知 Puppet 检查是否安装了该软件包。如果没有安装,Puppet 将执行 dnf 进行安装。

4.3. 启动和启用服务

安装软件包后,您可能需要启动服务。使用另一个名为 service 的资源声明。

流程

  • 使用以下内容编辑清单:

    class mymodule::httpd {
      package { 'httpd':
        ensure => installed,
      }
      service { 'httpd':
        ensure => running,
        enable => true,
        require => Package["httpd"],
      }
    }
    • ensure => running 属性检查该服务是否正在运行。如果没有,Puppet 会启用它。
    • enable => true 属性将服务设置为在系统启动时运行。
    • require => Package["httpd"] 属性定义一个资源声明和其他资源声明间的顺序关系。在本例中,它会确保 httpd 服务在安装 httpd 软件包后启动。这会在服务及其对应的软件包之间创建一个依赖项。

4.4. 配置服务

HTTP 服务器在 /etc/httpd/conf/httpd.conf 中提供了一些默认配置,该配置在端口 80 上提供 Web 主机。但是,您可以添加额外配置,以在用户指定的端口上提供额外的 web 主机。

流程

  1. 您必须使用模板文件来存储 HTTP 配置文件,因为用户定义的端口需要变量输入。在模块模板目录中,添加名为 myserver.conf.erb 的文件,其内容如下:

    Listen <%= @httpd_port %>
    NameVirtualHost *:<%= @httpd_port %>
    <VirtualHost *:<%= @httpd_port %>>
      DocumentRoot /var/www/myserver/
      ServerName *:<%= @fqdn %>>
      <Directory "/var/www/myserver/">
        Options All Indexes FollowSymLinks
        Order allow,deny
        Allow from all
      </Directory>
    </VirtualHost>

    此模板遵循 Apache Web 服务器配置的标准语法。唯一的区别是包含 Ruby 转义字符来注入模块的变量。例如,httpd_port 用于指定 Web 服务器端口。

    包含 fqdn 是一个存储系统完全限定域名的变量。这称为 系统事实。系统事实从每个系统收集,然后生成系统的每一目录。Puppet 使用 facter 命令收集这些系统事实,您也可以运行 facter 来查看这些事实的列表。

  2. 保存 myserver.conf.erb
  3. 将资源添加到模块的 Puppet 清单:

    class mymodule::httpd {
      package { 'httpd':
        ensure => installed,
      }
      service { 'httpd':
        ensure => running,
        enable => true,
        require => Package["httpd"],
      }
      file {'/etc/httpd/conf.d/myserver.conf':
      notify => Service["httpd"],
        ensure => file,
        require => Package["httpd"],
        content => template("mymodule/myserver.conf.erb"),
      }
      file { "/var/www/myserver":
        ensure => "directory",
      }
    }
    • 您可以为服务器配置文件 (/etc/httpd/conf.d/myserver.conf )添加 file 资源声明。此文件的内容是您创建的 myserver.conf.erb 模板。
    • 您可在添加此文件前检查 httpd 软件包。
    • 为您的 web 服务器添加第二个文件资源声明,用于创建目录 /var/www/myserver
    • 您可以使用 notify => Service["httpd"] 属性在配置文件和 httpd 服务间添加关系。这将检查您的配置文件是否有更改。如果文件已更改,Puppet 会重新启动该服务。

4.5. 获取 OpenStack Puppet 模块

Red Hat OpenStack Platform 使用官方的 OpenStack Puppet 模块。要获取 OpenStack Puppet 模块,请参阅 Github 上的 openstack 组。

流程

  1. 在您的浏览器中,访问 https://github.com/openstack
  2. 在过滤器部分中,搜索 Puppet。所有 Puppet 模块都使用前缀 puppet-
  3. 克隆您想要的 Puppet 模块。例如,官方 OpenStack Block Storage (cinder)模块:

    $ git clone https://github.com/openstack/puppet-cinder.git

4.6. Puppet 模块配置示例

OpenStack 模块主要旨在配置核心服务。大多数模块还包含额外的清单来配置其他服务,有时也称为 backends(后端), agents(代理), 或 plugins(插件)。例如,cinder 模块包含一个名为 backends 的目录,它包含用于不同存储设备的配置选项,包括 NFS、iSCSI、Red Hat Ceph Storage 等。

例如,manifests/backends/nfs.pp 文件包含以下配置:

define cinder::backend::nfs (
  $volume_backend_name  = $name,
  $nfs_servers          = [],
  $nfs_mount_options    = undef,
  $nfs_disk_util        = undef,
  $nfs_sparsed_volumes  = undef,
  $nfs_mount_point_base = undef,
  $nfs_shares_config    = '/etc/cinder/shares.conf',
  $nfs_used_ratio       = '0.95',
  $nfs_oversub_ratio    = '1.0',
  $extra_options        = {},
) {

  file {$nfs_shares_config:
    content => join($nfs_servers, "\n"),
    require => Package['cinder'],
    notify  => Service['cinder-volume']
  }

  cinder_config {
    "${name}/volume_backend_name":  value => $volume_backend_name;
    "${name}/volume_driver":        value =>
      'cinder.volume.drivers.nfs.NfsDriver';
    "${name}/nfs_shares_config":    value => $nfs_shares_config;
    "${name}/nfs_mount_options":    value => $nfs_mount_options;
    "${name}/nfs_disk_util":        value => $nfs_disk_util;
    "${name}/nfs_sparsed_volumes":  value => $nfs_sparsed_volumes;
    "${name}/nfs_mount_point_base": value => $nfs_mount_point_base;
    "${name}/nfs_used_ratio":       value => $nfs_used_ratio;
    "${name}/nfs_oversub_ratio":    value => $nfs_oversub_ratio;
  }

  create_resources('cinder_config', $extra_options)

}
  • 定义 语句创建一个名为 cinder::backend::nfs 的定义的类型。一个定义的类型与类类似,主要区别是 Puppet 多次评估定义的类型。例如,您可能需要多个 NFS 后端,因此配置为每个 NFS 共享需要多个评估。
  • 接下来几行在这一配置中定义参数及其默认值。如果用户将新值传递给定义的 cinder::backend::nfs,则默认值会被覆盖。
  • 文件 函数是调用创建文件的资源声明。此文件包含 NFS 共享的列表,此文件的名称在参数 $nfs_shares_config = '/etc/cinder/shares.conf 中定义。请注意附加属性:

    • content 属性使用 $nfs_servers 参数创建一个列表。
    • require 属性确保已安装 cinder 软件包。
    • notify 属性告知 cinder-volume 服务要重置。
  • cinder_config 函数是一个资源声明,它使用来自模块 lib/puppet/ 目录中的插件。此插件将配置添加到 /etc/cinder/cinder.conf 文件。此资源的每一行在 cinder.conf 文件中的相关部分中添加配置选项。例如,如果 $name 参数是 mynfs,则以下属性:

      "${name}/volume_backend_name":  value => $volume_backend_name;
      "${name}/volume_driver":        value =>
        'cinder.volume.drivers.nfs.NfsDriver';
      "${name}/nfs_shares_config":    value => $nfs_shares_config;

    将以下代码片段保存到 cinder.conf 文件中:

    [mynfs]
    volume_backend_name=mynfs
    volume_driver=cinder.volume.drivers.nfs.NfsDriver
    nfs_shares_config=/etc/cinder/shares.conf
  • create_resources 函数将哈希转换为一组资源。在本例中,清单会将 $extra_options 哈希转换为后端的一组附加配置选项。这提供了一种灵活的方法来添加未包含在清单的内核参数中的更多配置选项。

这显示了包含配置硬件的 OpenStack 驱动程序的清单的重要性。清单为 director 提供了一个包含与您的硬件相关的配置选项的方法。这充当 director 以将 overcloud 配置为使用硬件的主要集成点。

4.7. 将 hiera 数据添加到 Puppet 配置示例

Puppet 包含一个名为 hiera 的工具,它充当一个提供节点特定配置的键值系统。这些密钥及其值通常存储在位于 /etc/puppet/hieradata 的文件中。/etc/puppet/hiera.yaml 文件定义 Puppet 读取 hieradata 目录中的文件的顺序。

在 overcloud 配置期间,Puppet 使用 hiera 数据覆盖某些 Puppet 类的默认值。例如,puppet-cinder 中的 cinder::backend::nfs 的默认 NFS 挂载选项未定义:

  $nfs_mount_options    = undef,

但是,您可以创建自己的清单来调用 cinder::backend::nfs 定义的类型,并将此选项替换为 hiera 数据:

  cinder::backend::nfs { $cinder_nfs_backend:
    nfs_mount_options   => hiera('cinder_nfs_mount_options'),
  }

这意味着 nfs_mount_options 参数使用 cinder_nfs_mount_options 键中的 hiera data 值:

cinder_nfs_mount_options: rsize=8192,wsize=8192

或者,您可以使用 hiera 数据覆盖 cinder::backend::nfs::nfs_mount_options 参数,使其适用于 NFS 配置的所有评估:

cinder::backend::nfs::nfs_mount_options: rsize=8192,wsize=8192

以上 hiera 数据会覆盖对 cinder::backend::nfs 的每个评估的这个参数。

第 5 章 编配

director 使用 Heat 编配模板(HOT)作为 overcloud 部署计划的模板格式。HOT 格式的模板通常以 YAML 格式表示。模板的目的是定义和创建堆栈,它是 OpenStack Orchestration (heat)创建的资源集合,以及资源的配置。资源是 Red Hat OpenStack Platform (RHOSP)中的对象,可以包含计算资源、网络配置、安全组、扩展规则和自定义资源。

注意

要使 RHOSP 使用 heat 模板文件作为自定义模板资源,文件扩展必须是 .yaml 或 .template。

5.1. 了解 heat 模板

heat 模板有三个主要部分:

parameters
这些是传递给 heat 的设置,它提供了一种自定义堆栈的方法,以及没有传递值的参数的任何默认值。这些设置在模板的 parameter 部分中定义。
资源
使用 resources 部分定义资源,如计算实例、网络和存储卷,您可以使用此模板部署堆栈时创建它们。Red Hat OpenStack Platform (RHOSP)包含跨越所有组件的一组核心资源。这些是作为堆栈一部分创建和配置的具体对象。RHOSP 包含跨越所有组件的一组核心资源。它们在模板的 resources 部分中定义。
输出
使用 outputs 部分声明云用户在创建堆栈后可以访问的输出参数。您的云用户可以使用这些参数来请求有关堆栈的详细信息,如所部署实例的 IP 地址,或部署为堆栈一部分的 Web 应用的 URL。

基本 heat 模板示例:

heat_template_version: 2013-05-23

description: > A very basic Heat template.

parameters:
  key_name:
    type: string
    default: lars
    description: Name of an existing key pair to use for the instance
  flavor:
    type: string
    description: Instance type for the instance to be created
    default: m1.small
  image:
    type: string
    default: cirros
    description: ID or name of the image to use for the instance

resources:
  my_instance:
    type: OS::Nova::Server
    properties:
      name: My Cirros Instance
      image: { get_param: image }
      flavor: { get_param: flavor }
      key_name: { get_param: key_name }

output:
  instance_name:
    description: Get the instance's name
    value: { get_attr: [ my_instance, name ] }

此模板使用 资源类型:OS::Nova::Server 创建名为 my_instance 的实例,其具有云用户指定的特定类别、镜像和密钥。堆栈可以返回 instance_name 的值,它名为 My Cirros Instance

重要

heat 模板还需要 heat_template_version 参数,该参数定义要使用的语法版本以及可用的功能。如需更多信息,请参阅 官方 Heat 文档

5.2. 了解环境文件

环境文件是可用来自定义 heat 模板的特殊模板。除了核心 heat 模板外,您还可以在部署命令中包含环境文件。环境文件包含三个主要部分:

resource_registry
本节定义与其他 heat 模板关联的自定义资源名称。这提供了一种方法,可以创建在核心资源集合中不存在的自定义资源。
parameters
这些是适用于顶级模板参数的通用设置。例如,如果您有一个部署嵌套堆栈(如资源 registry 映射)的模板,这些参数仅适用于顶级模板,而不应用到嵌套资源的模板。
parameter_defaults
这些参数为所有模板中的参数修改默认值。例如,如果您有一个部署嵌套堆栈的 heat 模板,如资源 registry 映射,则参数默认为所有模板。
重要

在为 overcloud 创建自定义环境文件时,使用 parameter_defaults 而不是 parameters,以便您的参数应用到 overcloud 的所有堆栈模板。

基本环境文件示例:

resource_registry:
  OS::Nova::Server::MyServer: myserver.yaml

parameter_defaults:
  NetworkName: my_network

parameters:
  MyIP: 192.168.0.1

从特定 heat 模板(my_template.yaml)创建堆栈时,可能会包含此环境文件(my_env.yaml)。my_env.yaml 文件会创建一个名为 OS::Nova::Server::MyServer 的新资源类型。myserver.yaml 文件是一个 heat 模板文件,为这个资源类型提供实现,可覆盖任何内置文件。您可以在 my_template.yaml 文件中包含 OS::Nova::Server::MyServer 资源。

MyIP 仅将参数应用于使用此环境文件部署的主要 heat 模板。在本例中,MyIP 仅适用于 my_template.yaml 中的参数。

networkName 应用到主 heat 模板 my_template.yaml 以及与主模板中包含的资源关联的模板,如 OS::Nova::Server::MyServer 资源及其 myserver.yaml 模板。

注意

要使 RHOSP 使用 heat 模板文件作为自定义模板资源,文件扩展必须是 .yaml 或 .template。

5.3. 获取默认 director 模板

director 使用高级 heat 模板集合来创建 overcloud。此集合可从 openstack-tripleo-heat-templates 存储库中的 Github 上的 openstack 组获取。

流程

  • 要获取此模板集合的克隆,请输入以下命令:

    $ git clone https://github.com/openstack/tripleo-heat-templates.git
注意

特定于红帽的此模板集合版本可从 openstack-tripleo-heat-template 软件包中获得,该软件包会将集合安装到 /usr/share/openstack-tripleo-heat-templates 中。

这个模板集合中的主要文件和目录是:

overcloud.j2.yaml
这是 director 用来创建 overcloud 环境的主要模板文件。此文件使用 Jinja2 语法来迭代模板中的某些部分,以创建自定义角色。在 overcloud 部署过程中将呈现 Jinja2 格式到 YAML 中。
overcloud-resource-registry-puppet.j2.yaml
这是 director 用来创建 overcloud 环境的主要环境文件。它为存储在 overcloud 镜像上的 Puppet 模块提供了一组配置。在 director 将 overcloud 镜像写入每个节点后,heat 会使用此环境文件中注册的资源启动每个节点的 Puppet 配置。此文件使用 Jinja2 语法来迭代模板中的某些部分,以创建自定义角色。在 overcloud 部署过程中将呈现 Jinja2 格式到 YAML 中。
roles_data.yaml
此文件包含 overcloud 中角色的定义,以及将服务映射到各个角色。
network_data.yaml
此文件包含 overcloud 中网络的定义,以及它们的属性,如子网、分配池和 VIP 状态。默认 network_data.yaml 文件包含默认网络: External、In Internal Api、Storage、Storage Management、Tenant 和 Management。您可以创建自定义 network_data.yaml 文件,并使用 -n 选项将其添加到 openstack overcloud deploy 命令中。
plan-environment.yaml
此文件包含 overcloud 计划的元数据定义。这包括要使用的计划名称、要使用的主要模板,以及应用到 overcloud 的环境文件。
capabilities-map.yaml
此文件包含 overcloud 计划的环境文件映射。
部署
此目录包含 heat 模板。overcloud-resource-registry-puppet.j2.yaml 环境文件使用此目录中的文件来驱动每个节点上的 Puppet 配置应用。
environments
此目录包含额外的 heat 环境文件,可用于创建 overcloud。这些环境文件为生成的 Red Hat OpenStack Platform (RHOSP)环境启用额外的功能。例如,目录包含一个环境文件,用于启用 Cinder NetApp 后端存储(cinder-netapp-config.yaml)。
network
此目录包含一组 heat 模板,可用于创建隔离的网络和端口。
puppet
此目录包含控制 Puppet 配置的模板。overcloud-resource-registry-puppet.j2.yaml 环境文件使用此目录中的文件来驱动每个节点上的 Puppet 配置应用。
Puppet/服务
此目录包含所有服务配置的旧 heat 模板。部署 目录中的模板替换 puppet/services 目录中的大部分模板。
extraconfig
此目录包含可用于启用额外功能的模板。
firstboot
此目录包含 director 在最初创建节点时使用 的第一个_boot 脚本示例。
重要

本指南以前版本包含使用配置 hook 集成服务的参考材料。合作伙伴集成服务的建议方法是使用可组合服务框架。

第 6 章 可组合的服务

Red Hat OpenStack Platform (RHOSP)包含了在角色上定义自定义角色和 compose 服务组合的功能。有关更多信息,请参阅高级 Overcloud 自定义指南中的可组合服务和自定义角色https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/advanced_overcloud_customization/chap-roles作为集成的一部分,您可以定义自己的自定义服务,并将它们包含在所选角色上。

6.1. 检查可组合的服务架构

核心 heat 模板集合包含两组可组合服务模板:

  • deployment 包含关键 OpenStack 服务的模板。
  • puppet/services 包含用于配置可组合服务的传统模板。在某些情况下,可组合的服务使用该目录中的模板的兼容性。在大多数情况下,可组合的服务使用 部署 目录中的模板。

每个模板都包含一个标识其用途的描述。例如,Deployment /time/ntp-baremetal-puppet.yaml 服务模板包含以下描述:

description: >
  NTP service deployment using puppet, this YAML file
  creates the interface between the HOT template
  and the puppet manifest that actually installs
  and configure NTP.

这些服务模板是作为特定于 Red Hat OpenStack Platform 部署的资源注册的。这意味着,您可以使用 overcloud-resource-registry-puppet.j2.yaml 文件中定义的唯一 heat 资源命名空间调用各个资源。所有服务都将 OS::TripleO::Services 命名空间用作其资源类型。

有些资源直接使用基本可组合服务模板:

resource_registry:
  ...
  OS::TripleO::Services::Ntp: deployment/time/ntp-baremetal-puppet.yaml
  ...

但是,核心服务需要容器并使用容器化服务模板。例如,keystone 容器化服务使用以下资源:

resource_registry:
  ...
  OS::TripleO::Services::Keystone: deployment/keystone/keystone-container-puppet.yaml
  ...

这些容器化模板通常引用其他模板以包含依赖项。例如,deploy /keystone/keystone-container-puppet.yaml 模板会将基本模板的输出存储在 ContainersCommon 资源中:

resources:
  ContainersCommon:
    type: ../containers-common.yaml

然后,容器化模板可以包含 container -common.yaml 模板中的功能和数据。

overcloud.j2.yaml heat 模板包含 Jinja2 的代码部分,用于在 roles_data.yaml 文件中为每个自定义角色定义一个服务列表:

{{role.name}}Services:
  description: A list of service resources (configured in the heat
               resource_registry) which represent nested stacks
               for each service that should get installed on the {{role.name}} role.
  type: comma_delimited_list
  default: {{role.ServicesDefault|default([])}}

对于默认角色,这将创建以下服务列表参数: ControllerServicesComputeServicesBlockStorageServicesObjectStorageServices、CephStorageServices 和 CephStorageServices

您可以在 roles_data.yaml 文件中为每个自定义角色定义默认服务。例如,默认的 Controller 角色包含以下内容:

- name: Controller
  CountDefault: 1
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephMon
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::CephRgw
    - OS::TripleO::Services::CinderApi
    - OS::TripleO::Services::CinderBackup
    - OS::TripleO::Services::CinderScheduler
    - OS::TripleO::Services::CinderVolume
    - OS::TripleO::Services::Core
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Keystone
    - OS::TripleO::Services::GlanceApi
    - OS::TripleO::Services::GlanceRegistry
...

这些服务随后被定义为 ControllerServices 参数的默认列表。

注意

您还可以使用环境文件覆盖服务参数的默认列表。例如,您可以在环境文件中将 ControllerServices 定义为 parameter_default,以覆盖 roles_data.yaml 文件中的服务列表。

6.2. 创建用户定义的可组合服务

本示例将探讨如何创建用户定义的可组合服务并专注于实施当日消息(motd)服务。在本例中,overcloud 镜像包含一个自定义 motd Puppet 模块,通过配置 hook 加载或修改 overcloud 镜像。

流程

在创建自己的服务时,您必须在服务的 heat 模板中定义以下项目:

parameters
  • ServiceData - 服务特定数据的映射。使用空 hash ({}) 作为默认值,因为 heat 模板中的值覆盖此参数。
  • ServiceNetMap - 服务映射到网络.使用空 hash ({}) 作为默认值,因为 heat 模板中的值覆盖此参数。
  • EndpointMap - OpenStack 服务端点的列表,供协议使用。使用空 hash ({}) 作为默认值,因为 heat 模板中的值覆盖此参数
  • DefaultPasswords - 默认密码列表。使用空 hash ({}) 作为默认值,因为 heat 模板中的值覆盖此参数。
  • RoleName - 部署此服务的角色的名称。使用空字符串('') 作为默认值,因为 heat 模板中的值覆盖此参数。
  • RoleParameters - 特定于角色的参数。这些参数使用 < RoleName>Parameters 参数定义,将 <RoleName > 替换为角色的名称。使用空 hash ({}) 作为默认值,因为 heat 模板中的值覆盖此参数

定义服务所需的任何其他参数。

输出
以下输出参数定义主机上的服务配置。更多信息请参阅 第 6.4 节 “可组合的服务参数”

以下是 motd 服务的示例 heat 模板(service.yaml):

heat_template_version: 2016-04-08

description: >
  Message of the day service configured with Puppet

parameters:
  ServiceNetMap:
    default: {}
    type: json
  DefaultPasswords:
    default: {}
    type: json
  EndpointMap:
    default: {}
    type: json
  MotdMessage: 1
    default: |
      Welcome to my Red Hat OpenStack Platform environment!

    type: string
    description: The message to include in the motd

outputs:
  role_data:
    description: Motd role using composable services.
    value:
      service_name: motd
      config_settings: 2
        motd::content: {get_param: MotdMessage}
      step_config: | 3
        if hiera('step') >= 2 {
          include ::motd
        }
1
该模板包含一个 MotdMessage 参数,用于定义当日消息。参数包含默认消息,但您可以使用自定义环境文件中的相同参数来覆盖该消息。
2
outputs 部分定义 config_settings 中的一些服务 hieradata。motd::content hieradata 存储 MotdMessage 参数中的内容。motd Puppet 类最终读取此 hieradata,并将用户定义的消息传递给 /etc/motd 文件。
3
outputs 部分包含 step_config 中的 Puppet 清单片断。该片段检查配置是否已达到第 2 步,如果是如此,则运行 motd Puppet 类。

6.3. 包括用户定义的可组合服务

您只能在 overcloud Controller 节点上配置自定义 motd 服务。这需要一个自定义环境文件,以及您的部署中包含的自定义角色数据文件。根据您的要求替换此流程中的输入示例。

流程

  1. 将新服务添加到环境文件 env-motd.yaml 中,作为 OS::TripleO::Services 命名空间中的注册的 heat 资源。在本例中,我们的 motd 服务的资源名称为 OS::TripleO::Services::Motd

    resource_registry:
      OS::TripleO::Services::Motd: /home/stack/templates/motd.yaml
    
    parameter_defaults:
      MotdMessage: |
        You have successfully accessed my Red Hat OpenStack Platform environment!

    此自定义环境文件还包含新消息,用于覆盖 MotdMessage 的默认消息。

    部署现在包含 motd 服务。但是,需要此新服务的每个角色都必须在自定义 roles_data.yaml 文件中具有更新的 ServicesDefault 列表。

  2. 创建默认 roles_data.yaml 文件的副本:

    $ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml ~/custom_roles_data.yaml
  3. 要编辑此文件,请滚动到 Controller 角色,并将服务包括在 ServicesDefault 列表中:

    - name: Controller
      CountDefault: 1
      ServicesDefault:
        - OS::TripleO::Services::CACerts
        - OS::TripleO::Services::CephMon
        - OS::TripleO::Services::CephExternal
    ...
        - OS::TripleO::Services::FluentdClient
        - OS::TripleO::Services::VipHosts
        - OS::TripleO::Services::Motd           # Add the service to the end
  4. 创建 overcloud 时,将生成的环境文件和 custom_roles_data.yaml 文件包含与其他环境文件和部署选项一起:

    $ openstack overcloud deploy --templates -e /home/stack/templates/env-motd.yaml -r ~/custom_roles_data.yaml [OTHER OPTIONS]

6.4. 可组合的服务参数

以下参数用于所有可组合服务中的输出:

service_name

服务的名称。您可以使用这个配置来通过 service_config_settings 应用其他可组合服务的配置。

config_settings

服务的自定义 hieradata 设置。

kolla_config

在容器中创建 kolla 配置的映射。格式从配置文件的绝对路径作为键开头,然后使用以下子参数作为键的值:

命令
容器启动时要运行的命令。
config_files
在服务启动前,服务配置文件()和容器中的位置(dest)。另外,还包括在容器中合并或替换这些文件的选项(合并),是否要保留文件权限和其他属性(preserve_properties)。
权限
为容器上某些目录设置权限。需要 路径和 所有者 ( 属于用户:group 组合)。您还可以以递归方式应用权限(递归)。

以下是 keystone 服务的 kolla_config 参数示例:

kolla_config:
  /var/lib/kolla/config_files/keystone.json:
    command: /usr/sbin/httpd -DFOREGROUND
    config_files:
      - source: "/var/lib/kolla/config_files/src/*"
        dest: "/"
        merge: true
        preserve_properties: true
  /var/lib/kolla/config_files/keystone_cron.json:
    command: /usr/sbin/crond -n
    config_files:
      - source: "/var/lib/kolla/config_files/src/*"
        dest: "/"
        merge: true
        preserve_properties: true
    permissions:
      - path: /var/log/keystone
        owner: keystone:keystone
        recurse: true

docker_config

传递到 paunch 命令的数据以配置每一步上的容器。

  • step_0 - 按 hiera 设置生成的容器配置文件。
  • step_1 - Load Balancer configuration

    1. 裸机配置
    2. 容器配置
  • step_2 - Core Services (Database/Rabbit/NTP/etc.)

    1. 裸机配置
    2. 容器配置
  • step_3 - 早期 OpenStack 服务设置(Ringbuilder 等)

    1. 裸机配置
    2. 容器配置
  • step_4 - General OpenStack Services

    1. 裸机配置
    2. 容器配置
    3. Keystone 容器发布初始化(租户、服务、端点创建)
  • step_5 - 服务激活(Pacemaker)

    1. 裸机配置
    2. 容器配置

YAML 文件使用一组参数来定义容器在每个步骤中运行,以及与每个容器关联的 podman 设置。例如:

docker_config:
  step_3:
    keystone:
      start_order: 2
      image: *keystone_image
      net: host
      privileged: false
      restart: always
      healthcheck:
        test: /openstack/healthcheck
      volumes: *keystone_volumes
      environment:
        - KOLLA_CONFIG_STRATEGY=COPY_ALWAYS

这会创建一个 keystone 容器,并使用对应的参数来定义详细信息,包括要使用的镜像、网络类型和环境变量。

puppet_config

本节是嵌套的键值对集合,驱动使用 Puppet 创建配置文件。包括以下所需参数:

puppet_tags
用于通过 Puppet 生成配置文件的 Puppet 资源标签名称。仅使用命名的配置资源来生成文件。任何指定标签的服务都具有 file,concat,file_line,augeas,cron 附加到 设置的默认标签。示例: keystone_config
config_volume
为该服务生成配置文件的卷名称(目录)。使用此位置将挂载绑定到正在运行的 Kolla 容器中进行配置。
config_image
用于生成配置文件的容器镜像的名称。这通常是运行时服务使用的相同容器。有些服务共享一组通用配置文件,这些文件在通用基本容器中生成。
step_config
此设置控制用于创建使用 Puppet 的配置文件的清单。将以下 Puppet 标签与清单一起使用,为该容器生成配置目录。

container_puppet_tasks

提供用于直接驱动 container-puppet.py 工具的数据。该任务在集群内执行一次,不适用于初始化 keystone 端点和数据库用户所需要的几个 Puppet 代码片段。例如:

container_puppet_tasks:
  # Keystone endpoint creation occurs only on single node
  step_3:
    config_volume: 'keystone_init_tasks'
    puppet_tags: 'keystone_config,keystone_domain_config,keystone_endpoint,keystone_identity_provider,keystone_paste_ini,keystone_role,keystone_service,keystone_tenant,keystone_user,keystone_user_role,keystone_domain'
    step_config: 'include ::tripleo::profile::base::keystone'
    config_image: *keystone_config_image

global_config_settings

分发到所有角色的自定义 hieradata 设置。

service_config_settings

其他服务的自定义 hieradata 设置。例如,您的服务可能需要在 OpenStack Identity (keystone)中注册其端点。这提供了从一个服务到另一个服务的参数,并提供了一种跨服务配置的方法,即使服务在不同的角色中也是如此。

step_config

这是用于配置 服务的 Puppet 片段。此片断添加到在服务配置过程的每个步骤中创建并运行的合并清单:

  • 第 1 步 - 负载均衡器配置
  • 第 2 步- 核心高可用性和常规服务(Database、RabbitMQ、NTP)
  • 第 3 步- 早期 OpenStack 平台服务设置(存储,Ring 构建)
  • 第 4 步 - 通用 OpenStack 平台服务
  • 第 5 步 - 服务激活(Pacemaker)和 OpenStack Identity (keystone)角色和用户创建

在任何引用的 puppet 清单中,您可以使用 步骤 hieradata (使用 hiera ('step'))在部署过程中的特定步骤定义特定操作。

host_prep_tasks

这是一个 ansible 代码片段,可在节点主机上执行,为容器化服务准备它。例如,您可能需要在创建期间挂载容器中的特定目录。

external_deploy_tasks

在 undercloud 上执行 Ansible 任务,并在部署过程中运行每个 step

upgrade_tasks

这是一个 ansible 代码片段,可帮助升级服务。该代码片段添加到组合的 playbook 中。每个操作都使用标签来定义 步骤,其中包括以下几项:

  • common - 适用于所有步骤
  • step0 - Validation
  • Step1 - 停止所有 OpenStack 服务。
  • step2 - 停止所有 Pacemaker 控制的服务
  • 步骤3 - 软件包更新和新软件包安装
  • step4 - 启动数据库升级所需的 OpenStack 服务
  • 第5 步 - 升级数据库

upgrade_batch_tasks

执行类似的功能,以 upgrade_tasks 来执行,但仅按照列出的顺序执行一组 Ansible 任务。默认值为 1,但您可以使用 roles_data.yaml 文件中的 upgrade_batch_size 参数来更改此角色。

post_upgrade_tasks

完成升级过程后,执行 Ansible 任务。

external_upgrade_tasks

在 undercloud 上执行 Ansible 任务,并在升级过程中运行每个 step

update_tasks

Ansible 代码片段,帮助介绍服务的次版本更新。该代码片段添加到组合的 playbook 中。每个操作都使用标签来定义 步骤,其中包括以下几项:

  • common - 适用于所有步骤
  • step0 - Validation
  • Step1 - 停止所有 OpenStack 服务。
  • step2 - 停止所有 Pacemaker 控制的服务
  • 步骤3 - 软件包更新和新软件包安装
  • step4 - 启动数据库升级所需的 OpenStack 服务
  • 第5 步 - 升级数据库

post_update_tasks

完成更新过程后,执行 Ansible 任务。

external_update_tasks

在 undercloud 上执行 Ansible 任务,并在此版本更新过程中运行每个 step

第 7 章 构建经认证的容器镜像

您可以使用合作伙伴 构建服务为 认证构建应用程序容器。构建 服务从 Git 存储库构建容器,这些存储库可通过 SSH 密钥公开或私有访问。

使用自动化构建 服务作为 Red Hat OpenStack 和 NFV Zone 的一部分,自动为 Red Hat OpenStack Platform (RHOSP) 16.1 基础容器构建容器化合作伙伴平台插件。

前提条件

  • 在红帽连接技术合作伙伴注册.
  • 应用区域访问 Red Hat OpenStack 和 NFV 区域。
  • 创建产品.当您提供的信息会在 Red Hat 目录中发布认证时使用。
  • 使用 Dockerfile 和要包含在容器中的组件,为您的插件创建 git 存储库。

如果您在注册或访问 Red Hat Connect 站点时有任何问题,请联系红帽技术合作伙伴成功解密 :https://connect.redhat.com/support/technology-partner/

7.1. 添加容器项目

个项目代表一个合作伙伴镜像。如果有多个镜像,您必须创建多个项目。

流程

  1. 登录到 Red Hat Connect for Technology Partners 并单击 Zones
  2. 向下滚动并选择 Red Hat OpenStack 和 NFV 区域。单击框中的任意位置。
  3. Certify 访问贵公司的现有产品和项目。
  4. 单击 Add Project 以创建新项目。
  5. 设置 项目名称

    • 项目名称在系统外不可见。
    • 项目名称必须包含以下元素:[ product][version]-[extended-base-container-image]-[your-plugin]
    • 对于 Red Hat OpenStack Platform (RHOSP)目的,格式为 rhospXX-baseimage-myplugin
    • 示例: rhosp16-openstack-cinder-volume-myplugin
  6. 根据您的产品或插件,以及其版本,选择 Product, Product Version, 和 Release Category

    • 在创建项目之前,创建产品及其版本。
    • 将标签版本类别设置为技术预览。在使用 Red Hat 认证完成 API 测试前,正式发布(GA)不能选择。如果您有认证容器镜像,请参阅插件认证要求。
  7. 根据您要使用合作伙伴插件修改的基础镜像选择 Red Hat ProductRed Hat Product Version。在本发行版本中,选择 Red Hat OpenStack Platform16.1
  8. Submit 以创建新项目。

7.2. 容器认证清单遵循容器认证清单

认证的容器符合红帽打包、分发和维护的标准。红帽通过认证的容器具有高度信任和支持,独立于容器支持的平台,包括 Red Hat OpenStack Platform (RHOSP)。为保持此维护,合作伙伴必须保持其镜像最新状态。

流程

  1. Certification Checklist
  2. 完成清单的所有部分。如果需要有关清单上的项目的更多信息,请点击左侧的下拉箭头来查看项目信息和链接到其他资源。

CertificationChecklist

检查清单包括以下项目:

更新您的公司概况
确保您的公司概况表为最新。
更新您的产品配置集
本页面有关产品配置集的详细信息,包括产品类型、描述、存储库 URL、版本和联系分发列表。
接受 OpenStack 附录
容器条款的站点协议.
更新项目配置集
检查支持的镜像设置,如 auto publish、registry 命名空间、发行版本类别以及支持的平台。
注意

在支持的 Platform 部分,您必须选择一个选项,以便可以在此页面中保存其他必填字段。

将应用程序打包为容器
按照此页面的说明来配置构建服务。构建服务依赖于完成前面的步骤。
上传文档和营销材料
这会将您重定向到产品页面。滚动到底部并点击 Add new Collateral 上传您的产品信息。
注意

您必须至少提供三个材料。第一个资料必须是 文档 类型。

提供容器 registry 命名空间
这与项目页面配置集页面相同。
提供销售联系信息
这些信息与公司概况相同。
从红帽获取发布批准
红帽为此步骤提供批准。
配置自动化构建服务
执行容器镜像的构建和扫描的配置信息。

7.3. Dockerfile 要求

作为镜像构建流程的一部分,构建服务会扫描您构建的镜像,以确保它符合红帽标准。使用以下指南作为项目中包含的 dockerfile 的基础:

  • 基础镜像必须是红帽镜像。使用 Ubuntu、Debian 和 CentOS 的任何镜像都不会传递扫描程序。
  • 您必须配置所需的标签:

    • name
    • maintainer
    • vendor
    • version
    • release
    • summary
  • 您必须将软件许可证包括在镜像中作为文本文件。将软件许可证添加到项目根目录下的 许可证 目录。
  • 您必须配置不是 root 用户的用户。

以下 dockerfile 示例演示了扫描所需的信息:

FROM registry.redhat.io/rhosp-rhel8/openstack-cinder-volume
MAINTAINER VenderX Systems Engineering <maintainer@vendorX.com>

###Required Labels
LABEL name="rhosp-rhel8/openstack-cinder-volume-vendorx-plugin" \
      maintainer="maintainer@vendorX.com" \
      vendor="VendorX" \
      version="3.7" \
      release="1" \
      summary="Red Hat OpenStack Platform 16.1 cinder-volume VendorX PluginY" \
      description="Red Hat OpenStack Platform 16.1 cinder-volume VendorX PluginY"


USER root

###Adding package
###repo exmple
COPY vendorX.repo /etc/yum.repos.d/vendorX.repo

###adding package with curl
RUN curl -L -o /verdorX-plugin.rpm http://vendorX.com/vendorX-plugin.rpm

###adding local package
COPY verdorX-plugin.rpm /

# Enable a repo to install a package
RUN dnf clean all
RUN yum-config-manager --enable openstack-16.1-for-rhel-8-x86_64-rpms
RUN dnf install -y vendorX-plugin
RUN yum-config-manager --disable openstack-16.1-for-rhel-8-x86_64-rpms

# Add required license as text file in Liceses directory (GPL, MIT, APACHE, Partner End User Agreement, etc)
RUN mkdir /licenses
COPY licensing.txt /licenses

USER cinder

7.4. 设置项目详情

您必须设置项目的详细信息,包括容器镜像的命名空间和 registry。

流程

  1. 单击 Project Settings
  2. 确保您的项目名称采用正确的格式。另外,如果您想要自动发布通过认证的容器,将 Auto-Publish 设置为 ON。已认证容器会在 Red Hat Container Catalog 中发布。

    ProjectSettings01

  3. 要设置 Container Registry 命名空间,请按照在线说明进行操作。

    ProjectSettings02

    • 容器 registry 命名空间是公司的名称。
    • 最终的 registry URL 是 registry.connect.redhat.com/namespace/repository:tag
    • 示例: registry.connect.redhat.com/mycompany/rhosp16-openstack-cinder-volume-myplugin:1.0
  4. 要设置 Outbound Repository NameOutbound Repository Descriptions,请按照在线说明操作。出站存储库名称必须与项目名称相同。

    ProjectSettings03

    • [product][version]-[extended_base_container_image]-[your_plugin]
    • 对于 Red Hat OpenStack Platform (RHOSP)目的,格式为 rhospXX-baseimage-myplugin
    • 最终的 registry URL 是 registry.connect.redhat.com/namespace/repository:tag
    • 示例: registry.connect.redhat.com/mycompany/rhosp16-openstack-cinder-volume-myplugin:1.0
  5. 在相关字段中添加关于项目的附加信息:

    • 仓库描述
    • 支持文档
  6. Submit

7.5. 使用构建服务构建容器镜像

为您的合作伙伴插件构建容器镜像。

流程

  1. 单击 Build Service
  2. 单击 Configure Build Service 以配置您的构建详情。

    1. 确保 红帽容器构建 设置为 ON
    2. 添加 Git Source URL,并选择性地添加 源代码 SSH 密钥 (如果您的 git 存储库受到保护)。URL 可以是 HTML 或 SSH。保护的 git 存储库需要 SSH。
    3. 可选:添加 Dockerfile 名称或留空(如果 Dockerfile 名称为 Dockerfile )。
    4. 可选:如果 docker 构建上下文 root 不是 git 存储库的根目录,则添加上下文目录。否则,将此字段留空。
    5. 将 git 存储库中的 Branch 设置为基础容器镜像。
    6. 单击 Submit 以完成 Build Service 设置。
  3. 单击 Start Build
  4. 添加 Tag Name,再单击 Submit。构建完成最多可能需要六分钟时间。

    • 标签名称必须是您的插件的版本。
    • 最终的引用 URL 是 registry.connect.redhat.com/namespace/repository:tag
    • 示例: registry.connect.redhat.com/mycompany/rhosp16-openstack-cinder-volume-myplugin:1.0
  5. Refresh 以检查您的构建是否已完成。可选:点击匹配的 构建 ID 查看构建详情和日志。
  6. 构建服务均构建并扫描镜像。这通常需要 10-15 分钟完成。扫描完成后,单击 View 链接以展开扫描结果。

7.6. 修正失败的扫描结果

Scan Details 页面显示扫描的结果,包括任何失败的项目。如果您的镜像扫描报告 FAILED 状态,请使用以下步骤调查如何更正失败。

流程

  1. Container Information 页面中,点 View 链接来展开扫描结果。
  2. 点 failed 项。例如,在以下屏幕截图中,has_licenses 检查失败。

    ScanDetails

  3. 点击失败项打开 相关文档中 的策略指南,并查看有关如何更正此问题的更多信息。
注意

如果您在访问 策略指南 时收到 Access Denied 警告,请发送电子邮件至 connect@redhat.com

7.7. 发布容器镜像

容器镜像通过扫描后,您可以发布容器镜像。

流程

  1. Container Information 页面中,单击 Publish 链接,以发布容器镜像实时。
  2. Publish 链接会更改为 Unpublish。要取消发布容器,点 Unpublish 链接。

7.8. 部署容器镜像

有关如何部署容器镜像的说明,请参阅高级 Overcloud 自定义指南中的 部署供应商插件

第 8 章 将 OpenStack 组件及其与 director 和 overcloud 的关系集成

请使用以下有关特定集成点的概念,开始将硬件和软件与红帽 OpenStack 平台(RHOSP)集成。

8.1. 裸机置备(ironic)

使用 director 中的 OpenStack Bare Metal Provisioning (ironic)组件来控制节点的电源状态。director 使用一组后端驱动程序来与特定的裸机电源控制器连接。这些驱动程序是启用硬件和供应商特定扩展和功能的关键。最常见的驱动程序是 IPMI 驱动程序 pxe_ipmitool,它控制支持智能平台管理接口(IPMI)的任何服务器的电源状态。

与裸机置备集成从上游 OpenStack 社区开始。默认情况下,ironic 驱动程序接受的上游会自动包含在核心 RHOSP 产品和 director 中。但是,根据认证要求,可能无法获得支持。

硬件驱动程序必须持续进行持续集成测试以确保其持续的功能。有关第三方驱动程序测试和适用性的更多信息,请参阅 OpenStack 社区页面 Ironic 测试

上游存储库:

Puppet 模块:

Bugzilla 组件:

  • openstack-ironic
  • python-ironicclient
  • openstack-puppet-modules
  • openstack-tripleo-heat-templates

集成备注:

  • 上游项目包含 ironic/drivers 目录中的驱动程序。
  • director 执行 JSON 文件中定义的节点批量注册。
  • director 会自动配置为使用裸机置备,这意味着 Puppet 配置不需要很少修改。但是,如果您的驱动程序包括在 Bare Metal Provisioning 中,您必须将驱动程序添加到 /etc/ironic/ironic.yaml 文件中。编辑此文件并搜索 IronicEnabledHardwareTypes 参数:

    IronicEnabledHardwareTypes=ipmi,redfish,idrac,ilo

    这允许裸机置备使用驱动程序目录中的指定 驱动程序

8.2. networking (neutron)

OpenStack Networking (neutron)提供了在云环境中创建网络架构的功能。该项目为软件定义型网络(SDN)供应商提供了多个集成点。这些集成点通常属于插件或代理类别:

插件允许扩展和自定义预先存在的 neutron 功能。供应商可以编写插件以确保 neutron 和认证软件与硬件之间的互操作性。为 neutron Modular Layer 2 (ml2)插件开发驱动程序,它为集成您自己的驱动程序提供模块化后端。

代理提供特定的网络功能。主 neutron 服务器及其插件与 neutron 代理通信。现有示例包括 DHCP、第 3 层支持和桥接支持的代理。

对于两个插件和代理,您可以选择以下选项之一:

  • 作为 Red Hat OpenStack Platform (RHOSP)解决方案的一部分来包括它们作为发布(RHOSP)解决方案
  • 在 RHOSP 发行版本后将它们添加到 overcloud 镜像

分析现有插件和代理的功能,以确定如何集成您自己的认证硬件和软件。特别是,建议首先将驱动程序作为 ml2 插件的一部分开发。

上游存储库:

上游蓝图:

Puppet 模块:

Bugzilla 组件:

  • openstack-neutron
  • python-neutronclient
  • openstack-puppet-modules
  • openstack-tripleo-heat-templates

集成备注:

  • 上游 neutron 项目包含多个集成点:

    • 插件位于 neutron/plugins/
    • ml2 插件驱动程序位于 neutron/plugins/ml2/drivers/
    • 代理位于 neutron/agents/
  • 自 OpenStack Liberty 发行版以来,很多特定于供应商的 ml2 插件都已移到 https://opendev.org/openstack 中的自己的存储库中。例如,Cisco 特定的插件位于 https://opendev.org/openstack/networking-cisco 中。
  • puppet-neutron 存储库还包含不同的目录来配置这些集成点:

    • 插件配置位于 manifests/plugins/
    • ml2 插件驱动程序配置位于 manifests/plugins/ml2/中。
    • 代理配置位于 manifests/agents/
  • puppet-neutron 存储库包含用于配置功能的大量库。例如,neutron_plugin_ml2 库添加一个函数,以将属性添加到 ml2 插件配置文件中。

8.3. Block Storage (cinder)

OpenStack Block Storage (cinder)提供了一个与块存储设备交互的 API,Red Hat OpenStack Platform (RHOSP)用于创建卷。例如,块存储为实例提供虚拟存储设备。块存储提供一组核心驱动程序来支持不同的存储硬件和协议。例如,一些核心驱动程序包括对 NFS、iSCSI 和 Red Hat Ceph Storage 的支持。供应商可包括支持其他认证硬件的驱动程序。

还有一组经过认证的供应商相关驱动程序来支持第三方存储硬件。认证驱动程序通过上游 OpenStack 项目提供,并集成到红帽 OpenStack 解决方案中。有关已认证驱动程序的列表,请参阅 Red Hat OpenStack 生态系统目录

上游存储库:

上游蓝图:

Puppet 模块:

Bugzilla 组件:

  • openstack-cinder
  • python-cinderclient
  • openstack-puppet-modules
  • openstack-tripleo-heat-templates

集成备注:

  • 上游 cinder 存储库包含 cinder/volume/drivers/中的驱动程序。
  • puppet-cinder 存储库包含两个用于驱动程序配置的主要目录:

    • manifests/backend 目录包含一组配置驱动程序定义的类型。
    • manifests/volume 目录包含一组用于配置默认块存储设备的类。
  • puppet-cinder 存储库包含一个名为 cinder_config 的库,用于向 Cinder 配置文件添加属性。

8.4. 镜像存储(glance)

OpenStack Image 服务(glance)提供了一个与存储类型交互的 API,以便为镜像提供存储。镜像服务提供一组核心驱动程序来支持不同的存储硬件和协议。例如,核心驱动程序包括对文件、OpenStack Object Storage (swift)、OpenStack Block Storage (cinder)和 Red Hat Ceph Storage 的支持。供应商可包括支持其他认证硬件的驱动程序。

上游存储库:

上游蓝图:

Puppet 模块:

Bugzilla 组件:

  • openstack-glance
  • python-glanceclient
  • openstack-puppet-modules
  • openstack-tripleo-heat-templates

集成备注:

  • 不需要添加特定于供应商的驱动程序,因为镜像服务可以使用块存储服务(包含集成点)来管理镜像存储。
  • 上游 glance_store 存储库包含 glance_store/_drivers 中的驱动程序。
  • puppet-glance 存储库包含 manifests/backend 目录中的驱动程序配置。
  • puppet-glance 存储库包含一个名为 glance_api_config 的库,用于向 Glance 配置文件添加属性。

8.5. 共享文件系统服务(manila)

OpenStack 共享文件系统服务(manila)为共享和分布式文件系统服务提供 API。供应商可包括支持其他认证硬件的驱动程序。

上游存储库:

上游蓝图:

Puppet 模块:

Bugzilla 组件:

  • openstack-manila
  • python-manilaclient
  • openstack-puppet-modules
  • openstack-tripleo-heat-templates

集成备注:

  • 上游 manila 存储库包含 manila/share/drivers/ 中的驱动程序。
  • puppet-manila 存储库包含 manifests/backend 目录中的驱动程序配置。
  • puppet-manila 存储库包含一个名为 manila_config 的库,用于向 manila 配置文件添加属性。

8.6. OpenShift-on-OpenStack

Red Hat OpenStack Platform (RHOSP)旨在支持 OpenShift-on-OpenStack 部署。有关这些部署合作伙伴集成的更多信息,请参阅 Red Hat OpenShift 合作伙伴 页面。