合作伙伴集成
在 Red Hat OpenStack Platform 环境中集成并认证第三方软件和硬件
摘要
第 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 认证合作伙伴解决方案。
OpenStack 插件认证指南
OpenStack 应用程序认证指南
第 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.1.1. 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.1.2. Heat 复制链接链接已复制到粘贴板!
Heat 是一种应用堆栈编排引擎。在将应用部署到云之前,您可以使用 heat 为应用程序定义元素。创建包括多个基础架构资源(如实例、网络、存储卷和弹性 IP)的堆栈模板,以及一组用于配置的参数。使用 heat 创建基于给定依赖项链的这些资源,监控资源的可用性,并在需要时扩展资源。您可以使用这些模板使应用堆栈可移植,并实现可重复的结果。
图 2.3. 在将应用部署到云之前,使用 heat 服务定义应用程序的元素
director 使用原生 OpenStack heat API 来置备和管理与 overcloud 部署关联的资源。这包括精确的详细信息,如定义每个节点角色要调配的节点数量、为每个节点配置的软件组件,以及 director 配置这些组件和节点类型的顺序。director 还使用 heat 来对部署后进行故障排除并进行更改。
以下示例是从 heat 模板的一个片段,定义 Controller 节点的参数:
Heat 会消耗 director 中包含的模板,以协助创建 overcloud,其中包括调用 ironic 以为节点提供电源。您可以使用标准 heat 工具查看中 overcloud 的资源和状态。例如,您可以使用 heat 工具将 overcloud 作为嵌套应用堆栈显示。使用 heat 模板的语法来声明和创建生产 OpenStack 云。由于每个合作伙伴集成用例都需要 heat 模板,因此您必须对合作伙伴集成有先理解和熟练程度。
2.1.3. 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,请输入以下命令:
grep mysql_root_password hieradata.yaml # View the data in the hieradata file openstack::controller::mysql_root_password: ‘redhat123'
[root@localhost ~]# grep mysql_root_password hieradata.yaml # View the data in the hieradata file openstack::controller::mysql_root_password: ‘redhat123'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要引用 Puppet 清单中的 hieradata,请输入以下命令:
grep mysql_root_password example.pp # Now referenced in the Puppet manifest mysql_root_password => hiera(‘openstack::controller::mysql_root_password')
[root@localhost ~]# grep mysql_root_password example.pp # Now referenced in the Puppet manifest mysql_root_password => hiera(‘openstack::controller::mysql_root_password')Copy to Clipboard Copied! Toggle word wrap Toggle overflow
需要软件包安装和服务启用的合作伙伴集成服务可以创建 Puppet 模块来满足其要求。有关获取当前 OpenStack Puppet 模块和示例的更多信息,请参阅 第 4.2 节 “获取 OpenStack Puppet 模块”。
2.1.4. tripleo 和 TripleO heat 模板 复制链接链接已复制到粘贴板!
director 基于上游 TripleO 项目。此项目将一组 OpenStack 服务与以下目标相结合:
- 使用镜像服务(glance)存储 overcloud 镜像。
- 使用编排服务(heat)编配 overcloud
- 使用裸机置备(ironic)和计算(nova)服务置备裸机
TripleO 还包括定义红帽支持的 overcloud 环境的 heat 模板集合。使用 heat,读取此模板集合并编配 overcloud 堆栈。
2.1.5. 可组合的服务 复制链接链接已复制到粘贴板!
Red Hat OpenStack Platform 的每个方面被分为可组合服务。这意味着您可以定义使用不同服务组合的不同角色。例如,您可以将网络代理从默认 Controller 节点移到独立的 Networker 节点。
有关可组合服务架构的更多信息,请参阅 第 6 章 可组合的服务。
2.1.6. 容器化服务和 Kolla 复制链接链接已复制到粘贴板!
每个主 Red Hat OpenStack Platform (RHOSP)服务都在容器中运行。这提供了一种将每个服务保持在与主机分离的隔离命名空间内的方法。这样做有以下影响:
- 在部署过程中,RHOSP 从红帽客户门户网站中提取并运行容器镜像。
-
podman命令运行管理功能,如启动和停止服务。 - 要升级容器,您必须拉取新的容器镜像,并使用更新的版本替换现有的容器。
Red Hat OpenStack Platform 使用了通过 Kolla 工具集来构建和管理的一组容器。
2.1.7. 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 系统。
流程
要获取这些镜像,请安装
rhosp-director-images和rhosp-director-images-ipa软件包:sudo yum install rhosp-director-images rhosp-director-images-ipa
$ sudo yum install rhosp-director-images rhosp-director-images-ipaCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将存档提取到 stack 用户主目录
/home/上的 images 目录中:stack/imagescd ~/images for i in /usr/share/rhosp-director-images/overcloud-full-latest-13.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-13.0.tar; do tar -xvf $i; done
$ cd ~/images $ for i in /usr/share/rhosp-director-images/overcloud-full-latest-13.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-13.0.tar; do tar -xvf $i; doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2. initrd:修改初始 ramdisk 复制链接链接已复制到粘贴板!
有些情况可能需要您修改初始 ramdisk。例如,您可能需要在内省或置备过程中引导节点时特定的驱动程序可用。在 overcloud 上下文中,这包括以下 ramdisk 之一:
-
内省 ramdisk -
ironic-python-agent.initramfs -
置备 ramdisk -
overcloud-full.initrd
此流程将额外的 RPM 软件包添加到 ironic-python-agent.initramfs ramdisk 中作为示例。
流程
以
root用户身份登录,再为 ramdisk 创建临时目录:mkdir ~/ipa-tmp cd ~/ipa-tmp
# mkdir ~/ipa-tmp # cd ~/ipa-tmpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
skipcpio和cpio命令,将 ramdisk 提取到临时目录:/usr/lib/dracut/skipcpio ~/images/ironic-python-agent.initramfs | zcat | cpio -ivd | pax -r
# /usr/lib/dracut/skipcpio ~/images/ironic-python-agent.initramfs | zcat | cpio -ivd | pax -rCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将 RPM 软件包安装到提取的内容:
rpm2cpio ~/RPMs/python-proliantutils-2.1.7-1.el7ost.noarch.rpm | pax -r
# rpm2cpio ~/RPMs/python-proliantutils-2.1.7-1.el7ost.noarch.rpm | pax -rCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重新创建新的 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
# 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.initramfsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 验证新软件包现在存在于 ramdisk 中:
lsinitrd /home/stack/images/ironic-python-agent.initramfs | grep proliant
# lsinitrd /home/stack/images/ironic-python-agent.initramfs | grep proliantCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3. QCOW:安装 virt-customize 到 director 复制链接链接已复制到粘贴板!
libguestfs-tools 软件包包含 virt-customize 工具。
流程
从
rhel-8-for-x86_64-appstream-eus-rpms存储库安装libguestfs-tools:sudo yum install libguestfs-tools
$ sudo yum install libguestfs-toolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
如果在 undercloud 上安装 libguestfs-tools 软件包,请禁用 iscsid.socket 以避免与 undercloud 上的 tripleo_iscsid 服务冲突:
sudo systemctl disable --now iscsid.socket
$ sudo systemctl disable --now iscsid.socket
3.4. QCOW:检查 overcloud 镜像 复制链接链接已复制到粘贴板!
在查看 overcloud-full.qcow2 镜像的内容前,您必须创建使用此镜像的虚拟机。
流程
要创建使用
overcloud-full.qcow2镜像的虚拟机实例,请使用guestmount命令:mkdir ~/overcloud-full guestmount -a overcloud-full.qcow2 -i --ro ~/overcloud-full
$ mkdir ~/overcloud-full $ guestmount -a overcloud-full.qcow2 -i --ro ~/overcloud-fullCopy to Clipboard Copied! Toggle word wrap Toggle overflow 您可以查看
~/overcloud-full中的 QCOW2 镜像内容。另外,您可以使用 virt-manager 使用以下引导选项创建虚拟机:
- 内核路径: /overcloud-full.vmlinuz
- initrd 路径: /overcloud-full.initrd
- 内核参数: root=/dev/sda
3.5. QCOW:设置 root 密码 复制链接链接已复制到粘贴板!
设置 root 密码,以通过控制台为您的节点提供管理员级别的访问。
流程
在镜像中设置 root 用户的密码:
virt-customize --selinux-relabel -a overcloud-full.qcow2 --root-password password:test [ 0.0] Examining the guest ... [ 18.0] Setting a random seed [ 18.0] Setting passwords [ 19.0] Finishing off
$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --root-password password:test [ 0.0] Examining the guest ... [ 18.0] Setting a random seed [ 18.0] Setting passwords [ 19.0] Finishing offCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.6. QCOW:注册镜像 复制链接链接已复制到粘贴板!
将 overcloud 镜像注册到 Red Hat Content Delivery Network。
流程
临时注册您的镜像,以启用与您的自定义相关的红帽软件仓库:
virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager register --username=[username] --password=[password]' [ 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
$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager register --username=[username] --password=[password]' [ 0.0] Examining the guest ... [ 10.0] Setting a random seed [ 10.0] Running: subscription-manager register --username=[username] --password=[password] [ 24.0] Finishing offCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将 [username] 和 [password] 替换为您的红帽客户帐户详情。这会在镜像中运行以下命令:
subscription-manager register --username=[username] --password=[password]
subscription-manager register --username=[username] --password=[password]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.7. QCOW:附加订阅并启用红帽软件仓库 复制链接链接已复制到粘贴板!
流程
从您的帐户订阅中查找池 ID 列表:
sudo subscription-manager list
$ sudo subscription-manager listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 选择订阅池 ID 并将其附加到镜像:
virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager attach --pool [subscription-pool]' [ 0.0] Examining the guest ... [ 12.0] Setting a random seed [ 12.0] Running: subscription-manager attach --pool [subscription-pool] [ 52.0] Finishing off
$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager attach --pool [subscription-pool]' [ 0.0] Examining the guest ... [ 12.0] Setting a random seed [ 12.0] Running: subscription-manager attach --pool [subscription-pool] [ 52.0] Finishing offCopy to Clipboard Copied! Toggle word wrap Toggle overflow 将 [subscription-pool] 替换为您选择的订阅池 ID:
subscription-manager attach --pool [subscription-pool]
subscription-manager attach --pool [subscription-pool]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 这会将池添加到镜像中,以便您可以启用存储库。
启用红帽软件仓库:
subscription-manager repos --enable=[repo-id]
$ subscription-manager repos --enable=[repo-id]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.8. QCOW:复制自定义存储库文件 复制链接链接已复制到粘贴板!
将第三方软件添加到镜像需要额外存储库。以下是一个存储库文件示例,其中包含使用 OpenDaylight 存储库内容的配置:
流程
列出
opendaylight.repo文件的内容:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将 上的存储库文件复制到镜像中:
virt-customize --selinux-relabel -a overcloud-full.qcow2 --upload opendaylight.repo:/etc/yum.repos.d/ [ 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
$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --upload opendaylight.repo:/etc/yum.repos.d/ [ 0.0] Examining the guest ... [ 12.0] Setting a random seed [ 12.0] Copying: opendaylight.repo to /etc/yum.repos.d/ [ 13.0] Finishing offCopy to Clipboard Copied! Toggle word wrap Toggle overflow upload 选项会将 存储库文件复制到 overcloud 镜像的
/etc/yum.repos.d/中。
重要: 红帽对非认证供应商的软件不提供支持。请咨询您的红帽支持代表,其中要安装的软件受支持。
3.9. QCOW:安装 RPM 复制链接链接已复制到粘贴板!
流程
使用
virt-customize命令将软件包安装到镜像中:virt-customize --selinux-relabel -a overcloud-full.qcow2 --install opendaylight [ 0.0] Examining the guest ... [ 11.0] Setting a random seed [ 11.0] Installing packages: opendaylight [ 91.0] Finishing off
$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --install opendaylight [ 0.0] Examining the guest ... [ 11.0] Setting a random seed [ 11.0] Installing packages: opendaylight [ 91.0] Finishing offCopy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
--install选项指定要安装的软件包。
3.10. QCOW:清理订阅池 复制链接链接已复制到粘贴板!
流程
安装必要的软件包以自定义镜像后,删除订阅池并取消注册镜像:
virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager remove --all' [ 0.0] Examining the guest ... [ 12.0] Setting a random seed [ 12.0] Running: subscription-manager remove --all [ 18.0] Finishing off
$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager remove --all' [ 0.0] Examining the guest ... [ 12.0] Setting a random seed [ 12.0] Running: subscription-manager remove --all [ 18.0] Finishing offCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.11. QCOW:取消注册镜像 复制链接链接已复制到粘贴板!
流程
取消注册镜像,以便 overcloud 部署过程可以将镜像部署到您的节点上,并单独注册每个镜像:
virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager unregister' [ 0.0] Examining the guest ... [ 11.0] Setting a random seed [ 11.0] Running: subscription-manager unregister [ 17.0] Finishing off
$ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'subscription-manager unregister' [ 0.0] Examining the guest ... [ 11.0] Setting a random seed [ 11.0] Running: subscription-manager unregister [ 17.0] Finishing offCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.12. QCOW:重置机器 ID 复制链接链接已复制到粘贴板!
流程
为镜像重置机器 ID,以便使用这个镜像的机器不使用重复的机器 ID:
virt-sysprep --operation machine-id -a overcloud-full.qcow2
$ virt-sysprep --operation machine-id -a overcloud-full.qcow2Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.13. 将镜像上传到 director 复制链接链接已复制到粘贴板!
修改镜像后,您需要将其上传到 director。
流程
查找
stackrc文件,以便您可以从命令行访问 director:source stackrc
$ source stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 上传用于部署 overcloud 的默认 director 镜像:
openstack overcloud image upload --image-path /home/stack/images/
$ openstack overcloud image upload --image-path /home/stack/images/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 这会将下列镜像上传到 director:
- bm-deploy-kernel
- bm-deploy-ramdisk
- overcloud-full
- overcloud-full-initrd
overcloud-full-vmlinuz
该脚本还会在 director 的 PXE 服务器上安装内省镜像。
在 CLI 中查看镜像列表:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 此列表不显示内省 PXE 镜像(agent.*)。director 将这些文件复制到
/httpboot。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 4 章 配置 OpenStack Puppet 模块的添加 复制链接链接已复制到粘贴板!
本章介绍了如何为 OpenStack Puppet 模块提供添加的内容。其中包括一些有关开发 Puppet 模块的基本指南。
4.1. Puppet 语法和模块结构 复制链接链接已复制到粘贴板!
以下部分提供了几个基本知识,可帮助您理解 Puppet 语法和 Puppet 模块的结构。
4.1.1. Puppet 模块分析 复制链接链接已复制到粘贴板!
在贡献 OpenStack 模块前,您必须了解创建 Puppet 模块的组件。
- manifests
清单是包含用于定义一组资源及其属性的代码的文件。资源是系统的任何可配置部分。资源示例包括软件包、服务、文件、用户和组、SELinux 配置、SSH 密钥身份验证、cron 作业等。清单使用一组键值对来定义每个所需的资源。
package { 'httpd': ensure => installed, }package { 'httpd': ensure => installed, }Copy to Clipboard Copied! Toggle word wrap Toggle overflow 例如,此声明将检查是否安装了
httpd软件包。如果没有,则清单将执行dnf并安装它。清单位于模块的 清单目录中。Puppet 模块也使用测试目录进行测试清单。这些清单用于测试官方清单中某些类。- 类
- 类统一清单中的多个资源。例如,如果您安装并配置 HTTP 服务器,您可以创建一个以下三个资源的类:一个用于安装 HTTP 服务器软件包,一个用于配置 HTTP 服务器,另一个用于启动或停止服务器。您还可以引用来自其他模块的类,以应用其配置。例如,如果要配置还需要 webserver 的应用,您可以引用前面提到的 HTTP 服务器类。
- 附录文件
模块可以包含静态文件,供 Puppet 复制到系统上的特定位置。通过使用清单中的 file 资源声明来定义位置和其他属性(如权限)。
静态文件位于模块的文件目录中。
- templates
有时,配置文件需要自定义内容。在这种情况下,用户会创建一个模板而不是静态文件。与静态文件一样,模板在清单中定义,并复制到系统上的位置。区别在于,模板允许 Ruby 表达式定义自定义内容和变量输入。例如,如果要使用自定义端口配置 httpd,那么配置文件的模板包括:
Listen <%= @httpd_port %>
Listen <%= @httpd_port %>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 此例中的
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.1.2. 安装服务 复制链接链接已复制到粘贴板!
有些软件需要软件包安装。这是 Puppet 模块可以执行的一个功能。这需要一个定义特定软件包配置的资源定义。
例如,要通过 mymodule 模块安装 httpd 软件包,请将以下内容添加到 mymodule 模块中的 Puppet 清单中:
class mymodule::httpd {
package { 'httpd':
ensure => installed,
}
}
class mymodule::httpd {
package { 'httpd':
ensure => installed,
}
}
此代码定义了名为 httpd 的 mymodule 的子类,然后为 httpd 软件包定义软件包资源声明。ensure => installed 属性告知 Puppet 检查是否安装了该软件包。如果没有安装,Puppet 将执行 yum 进行安装。
4.1.3. 启动和启用服务 复制链接链接已复制到粘贴板!
安装软件包后,您可能需要启动服务。使用另一个名为 service 的资源声明。使用以下内容编辑清单:
结果:
-
ensure => running属性检查该服务是否正在运行。如果没有,Puppet 会启用它。 -
enable => true属性将服务设置为在系统启动时运行。 -
require => Package["httpd"]属性定义一个资源声明和其他资源声明间的顺序关系。在本例中,它会确保httpd服务在安装httpd软件包后启动。这会在服务及其对应的软件包之间创建一个依赖项。
4.1.4. 配置服务 复制链接链接已复制到粘贴板!
HTTP 服务器在 /etc/httpd/conf/httpd.conf 中提供了一些默认配置,该配置在端口 80 上提供 Web 主机。但是,您可以添加额外配置,以在用户指定的端口上提供额外的 web 主机。
流程
您必须使用模板文件来存储 HTTP 配置文件,因为用户定义的端口需要变量输入。在模块模板目录中,添加名为
myserver.conf.erb的文件,其内容如下:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 此模板遵循 Apache Web 服务器配置的标准语法。唯一的区别是包含 Ruby 转义字符来注入模块的变量。例如,
httpd_port用于指定 Web 服务器端口。包含
fqdn是一个存储系统完全限定域名的变量。这称为 系统事实。系统事实从每个系统收集,然后生成系统的每一目录。Puppet 使用facter命令收集这些系统事实,您也可以运行facter来查看这些事实的列表。-
保存
myserver.conf.erb。 将资源添加到模块的 Puppet 清单:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
结果:
-
您可以为服务器配置文件
(/etc/httpd/conf.d/myserver.conf)添加 file 资源声明。此文件的内容是您创建的myserver.conf.erb模板。 -
您可在添加此文件前检查
httpd软件包。 -
为您的 web 服务器添加第二个文件资源声明,用于创建目录
/var/www/myserver。 -
您可以使用
notify => Service["服务间添加关系。这将检查您的配置文件是否有更改。如果文件已更改,Puppet 会重新启动该服务。httpd"] 属性在配置文件和 httpd
4.2. 获取 OpenStack Puppet 模块 复制链接链接已复制到粘贴板!
Red Hat OpenStack Platform 使用官方的 OpenStack Puppet 模块。要获取 OpenStack Puppet 模块,请参阅 Github 上的 openstack 组。
流程
- 在您的浏览器中,访问 https://github.com/openstack。
-
在过滤器部分中,搜索
Puppet。所有 Puppet 模块都使用前缀puppet-。 克隆您想要的 Puppet 模块。例如,官方 OpenStack Block Storage (cinder)模块:
git clone https://github.com/openstack/puppet-cinder.git
$ git clone https://github.com/openstack/puppet-cinder.gitCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3. Puppet 模块配置示例 复制链接链接已复制到粘贴板!
OpenStack 模块主要旨在配置核心服务。大多数模块还包含额外的清单来配置其他服务,有时也称为 后端、代理或 插件。例如,cinder 模块包含一个名为 backends 的目录,它包含用于不同存储设备的配置选项,包括 NFS、iSCSI、Red Hat Ceph Storage 等。
例如,manifests/backends/nfs.pp 文件包含以下配置:
结果:
-
定义语句创建一个名为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;"${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;Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将以下代码片段保存到
cinder.conf文件中:[mynfs] volume_backend_name=mynfs volume_driver=cinder.volume.drivers.nfs.NfsDriver nfs_shares_config=/etc/cinder/shares.conf
[mynfs] volume_backend_name=mynfs volume_driver=cinder.volume.drivers.nfs.NfsDriver nfs_shares_config=/etc/cinder/shares.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
create_resources函数将哈希转换为一组资源。在本例中,清单会将$extra_options哈希转换为后端的一组附加配置选项。这提供了一种灵活的方法来添加未包含在清单的内核参数中的更多配置选项。
这显示了包含配置硬件的 OpenStack 驱动程序的清单的重要性。清单为 director 提供了一个包含与您的硬件相关的配置选项的方法。这充当 director 以将 overcloud 配置为使用硬件的主要集成点。
4.4. 将 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,
$nfs_mount_options = undef,
但是,您可以创建自己的清单来调用 cinder::backend::nfs 定义的类型,并将此选项替换为 hiera 数据:
cinder::backend::nfs { $cinder_nfs_backend:
nfs_mount_options => hiera('cinder_nfs_mount_options'),
}
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
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
cinder::backend::nfs::nfs_mount_options: rsize=8192,wsize=8192
以上 hiera 数据会覆盖对 cinder::backend::nfs 的每个评估的这个参数。
第 5 章 编配 复制链接链接已复制到粘贴板!
Red Hat OpenStack Platform (RHOSP) director 使用 Heat 编配模板(HOT)作为其 overcloud 部署计划的模板格式。HOT 格式的模板通常以 YAML 格式表示。模板的目的是定义和创建堆栈,这是 heat 创建的资源集合,以及资源的配置。资源是 RHOSP 中的对象,可以包含计算资源、网络配置、安全组、扩展规则和自定义资源。
要使 RHOSP 使用 heat 模板文件作为自定义模板资源,文件扩展必须是 .yaml 或 .template。
本章提供了一些了解 HOT 语法的基础知识,以便您可以创建自己的模板文件。
5.1. 学习 heat 模板基础知识 复制链接链接已复制到粘贴板!
5.1.1. 了解 heat 模板 复制链接链接已复制到粘贴板!
Heat 模板有三个主要部分:
- 参数
-
这些设置传递到 heat,以自定义堆栈。您还可以使用 heat 参数自定义默认值。这些设置在模板的
parameter部分中定义。 - Resources
-
这些是作为堆栈一部分创建和配置的具体对象。Red Hat OpenStack Platform (RHOSP)包含跨越所有组件的一组核心资源。它们在模板的
resources部分中定义。 - 输出
-
在创建堆栈后,这些值从 heat 传递。您可以通过 heat API 或客户端工具访问这些值。它们在模板的
output部分中定义。
以下是基本 heat 模板的示例:
此模板使用 资源类型:OS::Nova::Server 创建名为 my_instance 的实例,其具有特定类别、镜像和密钥。堆栈可以返回 instance_name 的值,它名为 My Cirros Instance。
heat 模板还需要 heat_template_version 参数,该参数定义要使用的语法版本以及可用的功能。如需更多信息,请参阅 官方 Heat 文档。
5.1.2. 了解环境文件 复制链接链接已复制到粘贴板!
环境文件是特殊的模板,可为您的 heat 模板提供自定义。这包括三个关键部分:
- 资源 Registry
-
本节定义链接到其他 heat 模板的自定义资源名称。这提供了一种方法,可以创建在核心资源集合中不存在的自定义资源。它们在环境文件的
resource_registry部分中定义。 - 参数
-
这些是适用于顶级模板参数的通用设置。例如,如果您有一个部署嵌套堆栈(如资源 registry 映射)的模板,这些参数仅适用于顶级模板,而不是嵌套资源的模板。参数在环境文件的
parameters部分中定义。 - 参数默认值
-
这些参数为所有模板中的参数修改默认值。例如,如果您有一个部署嵌套堆栈的 heat 模板,如资源 registry 映射,则参数默认为所有模板。参数默认值在环境文件的
parameter_defaults部分中定义。
为 overcloud 创建自定义环境文件时,请使用 parameter_defaults 而不是 参数。这样的参数将应用到 overcloud 的所有堆栈模板。
基本环境文件示例:
从 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 模板。在本例中,它只适用于 my_template.yaml 中的参数。
NetworkName 适用于主 heat 模板 my_template.yaml 和与包含主模板的资源关联的模板,如 OS::Nova::Server::MyServer 资源及其 myserver.yaml 模板。
要使 RHOSP 使用 heat 模板文件作为自定义模板资源,文件扩展必须是 .yaml 或 .template。
5.2. 获取默认 director 模板 复制链接链接已复制到粘贴板!
director 使用高级 heat 模板集合来创建 overcloud。此集合可从 存储库中的 Github 上的 openstack 组获取。
openstack -tripleo-heat-templates
流程
要获取此模板集合的克隆,请输入以下命令:
git clone https://github.com/openstack/tripleo-heat-templates.git
$ git clone https://github.com/openstack/tripleo-heat-templates.gitCopy to Clipboard Copied! Toggle word wrap Toggle overflow
特定于红帽的此模板集合版本可从 openstack-tripleo-heat-template 软件包中获得,该软件包会将集合安装到 /usr/share/openstack-tripleo-heat-templates 中。
这个模板集合中的主要文件和目录是:
overcloud.j2.yaml- 这是创建 overcloud 环境的主要模板文件。此文件使用 Jinja2 语法来迭代模板中的某些部分,以创建自定义角色。在 overcloud 部署过程中将呈现 Jinja2 格式到 YAML 中。
overcloud-resource-registry-puppet.j2.yaml- 这是创建 overcloud 环境的主要环境文件。它为存储在 overcloud 镜像上的 Puppet 模块提供了一组配置。在 director 将 overcloud 镜像写入每个节点后,heat 会使用此环境文件中注册的资源启动每个节点的 Puppet 配置。此文件使用 Jinja2 语法来迭代模板中的某些部分,以创建自定义角色。在 overcloud 部署过程中将呈现 Jinja2 格式到 YAML 中。
roles_data.yaml- 这是一个文件,它在 overcloud 中定义角色并将服务映射到各个角色。
network_data.yaml-
这是在 overcloud 中定义网络的文件,以及子网、分配池和 VIP 状态等属性。默认
network_data文件包含默认网络: External、In Internal Api、Storage、Storage Management、Tenant 和 Management。您可以创建自定义network_data文件,并使用-n选项将其添加到openstack overcloud deploy命令中。 plan-environment.yaml- 这是定义 overcloud 计划元数据的文件。这包括要使用的计划名称、要使用的主要模板,以及应用到 overcloud 的环境文件。
capabilities-map.yaml-
这是 overcloud 计划的环境文件映射。使用此文件描述并在 director Web UI 上启用环境文件。在 overcloud 计划中的
环境目录中检测到的自定义环境文件,但在capabilities-map.yaml中没有定义,在 web UI 中指定 Deployment Configuration > Overall Settings 的 Other 子选项卡中列出。 environments-
包含可用于创建 overcloud 的额外 heat 环境文件。这些环境文件为生成的 Red Hat OpenStack Platform (RHOSP)环境启用额外的功能。例如,目录包含一个环境文件,用于启用 Cinder NetApp 后端存储(
cinder-netapp-config.yaml)。在此目录中检测到的任何环境文件(在capabilities-map.yaml文件中未定义)都会在 2 的其它 子选项卡中列出。在 director 的 Web UI 中指定 Deployment Configuration > Overall Settings 中。 network- 这是一组有助于创建隔离的网络和端口的 heat 模板。
puppet-
这些是主要由 Puppet 配置驱动的模板。
overcloud-resource-registry-puppet.j2.yaml环境文件使用此目录中的文件来驱动每个节点上的 Puppet 配置应用。 Puppet/服务- 这是包含可组合服务架构中所有服务的 heat 模板的目录。
extraconfig- 这些是启用额外功能的模板。
firstboot-
提供 director 在最初创建节点时使用
的第一个_boot脚本示例。
这提供了 director 用来编排 Overcloud 创建的模板的一般概述。下面几节介绍了如何创建自己的自定义模板和环境文件,供您添加到 Overcloud 部署中。
5.3. 首次启动:自定义第一个引导配置 复制链接链接已复制到粘贴板!
director 提供了一种机制,可在创建 Overcloud 的初始节点上执行配置。director 通过 cloud-init 达到此目的,您可以使用 OS::TripleO::NodeUserData 资源类型进行调用。
在本例中,您将使用所有节点上的自定义 IP 地址更新名称服务器。您必须首先创建一个基本的 heat 模板(/home/stack/templates/nameserver.yaml),该脚本将运行一个脚本,将每个节点的 resolv.conf 附加到特定名称服务器。您可以使用 OS::TripleO::MultipartMime 资源类型来发送配置脚本。
接下来,创建一个环境文件(/home/stack/templates/firstboot.yaml),将您的 heat 模板注册为 OS::TripleO::NodeUserData 资源类型。
resource_registry: OS::TripleO::NodeUserData: /home/stack/templates/nameserver.yaml
resource_registry:
OS::TripleO::NodeUserData: /home/stack/templates/nameserver.yaml
要添加第一次引导配置,请在首先创建 Overcloud 时将环境文件添加到堆栈中,以及其他环境文件。例如:
openstack overcloud deploy --templates \
...
-e /home/stack/templates/firstboot.yaml \
...
$ openstack overcloud deploy --templates \
...
-e /home/stack/templates/firstboot.yaml \
...
-e 将环境文件应用到 Overcloud 堆栈。
这会在所有节点首次创建并首次引导时将配置添加到所有节点。这些模板的后续包含不会运行这些脚本,如更新 Overcloud 堆栈。
您只能将 OS::TripleO::NodeUserData 注册到一个 heat 模板。后续使用会覆盖要使用的 heat 模板。
这可实现:
-
OS::TripleO::NodeUserData是集合中其他模板中使用的基于 director 的 Heat 资源,并将第一个引导配置应用到所有节点。此资源传递在cloud-init中使用的数据。默认的NodeUserData是指生成空白值的 Heat 模板(first/userdata_default.yaml)。在我们的示例中,我们的firstboot.yaml环境文件会将此默认值替换为我们自己的nameserver.yaml文件的引用。 -
nameserver_config定义了要在第一次引导时运行的 Bash 脚本。OS::Heat::SoftwareConfig资源定义为要应用的配置的一部分。 -
userdata使用OS::Heat::MultipartMime资源,将配置从nameserver_config转换为多部分 MIME 消息。 -
输出提供一个输出参数OS::stack_id,它取来自userdata的 MIME 消息并将其提供给 Heat 模板/资源调用它。
因此,每个节点在第一次引导时运行以下 Bash 脚本:
#!/bin/bash echo "nameserver 192.168.1.1" >> /etc/resolve.conf
#!/bin/bash
echo "nameserver 192.168.1.1" >> /etc/resolve.conf
本例演示了 Heat 模板如何将一个资源传递和 modfy 配置传递到另一个资源。它还演示了如何使用环境文件注册新的 Heat 资源或修改现有的资源。
5.4. pre-Configuration:自定义特定 Overcloud 角色 复制链接链接已复制到粘贴板!
本文档的早期版本使用 OS::TripleO::Tasks::*PreConfig 资源来为每个角色提供预配置 hook。director 的 Heat 模板集合需要专用于使用这些 hook,这意味着您不应该将它们用于自定义用途。反之,请使用下面概述的 OS::TripleO::*ExtraConfigPre hook。
Overcloud 使用 Puppet 作为 OpenStack 组件的核心配置。director 提供了一组 hook,用于在第一次引导完成并开始核心配置前为特定节点角色提供自定义配置。这些 hook 包括:
- OS::TripleO::ControllerExtraConfigPre
- 在核心 Puppet 配置前,应用到 Controller 节点的额外配置。
- OS::TripleO::ComputeExtraConfigPre
- 在 Puppet 核心配置之前,应用到 Compute 节点的额外配置。
- OS::TripleO::CephStorageExtraConfigPre
- 在核心 Puppet 配置之前,应用到 Ceph Storage 节点的额外配置。
- OS::TripleO::ObjectStorageExtraConfigPre
- 在 Puppet 核心配置之前,应用到 Object Storage 节点的额外配置。
- OS::TripleO::BlockStorageExtraConfigPre
- 在 Puppet 核心配置之前,应用到块存储节点的附加配置。
- OS::TripleO::[ROLE]ExtraConfigPre
-
在 Puppet 核心配置之前,应用到自定义节点的额外配置。用可组合角色名称替换
[ROLE]。
在本例中,您首先创建一个基本的 heat 模板(/home/stack/templates/nameserver.yaml),它将运行一个脚本来写入具有变量名称服务器的节点的 resolv.conf。
在本例中,Resources 部分包含以下内容:
- CustomExtraConfigPre
-
这定义了软件配置。在本例中,我们定义了 Bash
脚本,Heat 将_NAMESERVER_IP_替换为nameserver_ip参数中存储的值。 - CustomExtraDeploymentPre
这会执行软件配置,这是来自
CustomExtraConfigPre资源的软件配置。注意以下几点:-
配置参数引用
CustomExtraConfigPre资源,因此 Heat 知道要应用的配置。 -
server参数检索 Overcloud 节点的映射。此参数由父模板提供,是此 hook 模板中的强制要求。 -
actions参数定义何时应用配置。在这种情况下,我们仅在创建或更新 Overcloud 时应用配置。可能的操作包括CREATE、UPDATE、DELETE、SUSPEND和RESUME。 -
input_values包含一个名为deploy_identifier的参数,它存储来自父模板中的DeployIdentifier。此参数为每个部署更新的资源提供时间戳。这可确保在后续的 overcloud 更新中资源恢复。
-
配置参数引用
接下来,创建一个环境文件(/home/stack/templates/pre_config.yaml),将 heat 模板注册到基于角色的资源类型。例如,要仅应用到 Controller 节点,请使用 ControllerExtraConfigPre hook:
resource_registry: OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/nameserver.yaml parameter_defaults: nameserver_ip: 192.168.1.1
resource_registry:
OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/nameserver.yaml
parameter_defaults:
nameserver_ip: 192.168.1.1
要应用配置,请在创建或更新 Overcloud 时将环境文件添加到堆栈中,以及其他环境文件。例如:
openstack overcloud deploy --templates \
...
-e /home/stack/templates/pre_config.yaml \
...
$ openstack overcloud deploy --templates \
...
-e /home/stack/templates/pre_config.yaml \
...
这会在核心配置开始初始 Overcloud 创建或后续更新时,将配置应用到所有 Controller 节点。
您只能为每个 hook 只注册每个资源的一个 Heat 模板。后续使用会覆盖要使用的 Heat 模板。
这可实现:
-
OS::TripleO::ControllerExtraConfigPre是 Heat 模板集合中配置模板中使用的基于 director 的 Heat 资源。此资源将配置传递给每个 Controller 节点。默认ControllerExtraConfigPre是指生成空白值的 Heat 模板(puppet/extraconfig/pre_deploy/default.yaml)。在我们的情形中,我们的pre_config.yaml环境文件将这个默认文件替换为我们自己的nameserver.yaml文件的引用。 -
环境文件还会将
nameserver_ip传递为我们环境的parameter_default值。这是存储名称服务器的 IP 地址的参数。然后,name.yamlHeat 模板接受此参数,如parameters部分中定义。 -
该模板通过
OS::Heat::SoftwareConfig将CustomExtraConfigPre定义为配置资源。注意group: script属性。组定义了要使用的软件配置工具,该工具通过一组用于 Heat 的 hook 使用。在本例中,脚本hook 运行您在SoftwareConfig资源中定义的可执行脚本,作为配置属性。 脚本本身将
/etc/resolve.conf附加至名称服务器 IP 地址。请注意str_replace属性,它允许您使用params部分中的参数替换template部分中的变量。在本例中,我们将 NAMESERVER_IP 设置为名称服务器 IP 地址,这将替换 脚本中的相同变量。这会生成以下脚本:#!/bin/sh echo "nameserver 192.168.1.1" >> /etc/resolve.conf
#!/bin/sh echo "nameserver 192.168.1.1" >> /etc/resolve.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow
本例演示了如何创建 Heat 模板,该模板在核心配置前使用 OS::Heat::SoftwareConfig 和 OS::Heat::SoftwareDeployments 进行部署。它还介绍了如何在环境文件中定义参数,并将其传递到配置中的模板。
5.5. pre-Configuration:自定义所有 Overcloud 角色 复制链接链接已复制到粘贴板!
Overcloud 使用 Puppet 作为 OpenStack 组件的核心配置。director 提供了一个 hook,用于在第一次引导完成后以及启动核心配置前配置所有节点类型:
- OS::TripleO::NodeExtraConfig
- 在核心 Puppet 配置之前,将额外的配置应用到所有节点角色。
在本例中,您首先创建一个基本的 heat 模板(/home/stack/templates/nameserver.yaml),它将运行一个脚本,将每个节点的 resolv.conf 附加到变量名称服务器。
在本例中,Resources 部分包含以下内容:
- CustomExtraConfigPre
-
这定义了软件配置。在本例中,我们定义了 Bash
脚本,Heat 将_NAMESERVER_IP_替换为nameserver_ip参数中存储的值。 - CustomExtraDeploymentPre
这会执行软件配置,这是来自
CustomExtraConfigPre资源的软件配置。注意以下几点:-
配置参数引用
CustomExtraConfigPre资源,因此 Heat 知道要应用的配置。 -
server参数检索 Overcloud 节点的映射。此参数由父模板提供,是此 hook 模板中的强制要求。 -
actions参数定义何时应用配置。在这种情况下,我们仅在创建或更新 Overcloud 时应用配置。可能的操作包括CREATE、UPDATE、DELETE、SUSPEND和RESUME。 -
input_values参数包含名为deploy_identifier的子参数,用于存储父模板中的DeployIdentifier。此参数为每个部署更新的资源提供时间戳。这可确保在后续的 overcloud 更新中资源恢复。
-
配置参数引用
接下来,创建一个环境文件(/home/stack/templates/pre_config.yaml),将您的 heat 模板注册为 OS::TripleO::NodeExtraConfig 资源类型。
resource_registry: OS::TripleO::NodeExtraConfig: /home/stack/templates/nameserver.yaml parameter_defaults: nameserver_ip: 192.168.1.1
resource_registry:
OS::TripleO::NodeExtraConfig: /home/stack/templates/nameserver.yaml
parameter_defaults:
nameserver_ip: 192.168.1.1
要应用配置,请在创建或更新 Overcloud 时将环境文件添加到堆栈中,以及其他环境文件。例如:
openstack overcloud deploy --templates \
...
-e /home/stack/templates/pre_config.yaml \
...
$ openstack overcloud deploy --templates \
...
-e /home/stack/templates/pre_config.yaml \
...
这会在内核配置开始初始 Overcloud 创建或后续更新时,将配置应用到所有节点。
您只能将 OS::TripleO::NodeExtraConfig 注册到一个 Heat 模板。后续使用会覆盖要使用的 Heat 模板。
这可实现:
-
OS::TripleO::NodeExtraConfig是 Heat 模板集合中配置模板中使用的基于 director 的 Heat 资源。此资源将配置传递给每个节点。默认的NodeExtraConfig是指生成空白值的 Heat 模板(puppet/extraconfig/pre_deploy/default.yaml)。在我们的情形中,我们的pre_config.yaml环境文件将这个默认文件替换为我们自己的nameserver.yaml文件的引用。 -
环境文件还会将
nameserver_ip传递为我们环境的parameter_default值。这是存储名称服务器的 IP 地址的参数。然后,name.yamlHeat 模板接受此参数,如parameters部分中定义。 -
该模板通过
OS::Heat::SoftwareConfig将CustomExtraConfigPre定义为配置资源。注意group: script属性。组定义了要使用的软件配置工具,该工具通过一组用于 Heat 的 hook 使用。在本例中,脚本hook 运行您在SoftwareConfig资源中定义的可执行脚本,作为配置属性。 脚本本身将
/etc/resolve.conf附加至名称服务器 IP 地址。请注意str_replace属性,它允许您使用params部分中的参数替换template部分中的变量。在本例中,我们将 NAMESERVER_IP 设置为名称服务器 IP 地址,这将替换 脚本中的相同变量。这会生成以下脚本:#!/bin/sh echo "nameserver 192.168.1.1" >> /etc/resolve.conf
#!/bin/sh echo "nameserver 192.168.1.1" >> /etc/resolve.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow
本例演示了如何创建 Heat 模板,该模板在核心配置前使用 OS::Heat::SoftwareConfig 和 OS::Heat::SoftwareDeployments 进行部署。它还介绍了如何在环境文件中定义参数,并将其传递到配置中的模板。
5.6. post-Configuration:自定义所有 Overcloud 角色 复制链接链接已复制到粘贴板!
本文档的早期版本使用 OS::TripleO::Tasks::*PostConfig 资源来为每个角色提供安装后 hook。director 的 Heat 模板集合需要专用于使用这些 hook,这意味着您不应该将它们用于自定义用途。反之,使用下面概述的 OS::TripleO::NodeExtraConfigPost hook。
当您完成 Overcloud 的创建但希望在初始创建或后续更新时,可以为所有角色添加额外的配置,会出现这种情况。在这种情况下,您可以使用以下后配置 hook:
- OS::TripleO::NodeExtraConfigPost
- 在核心 Puppet 配置后,应用到所有节点角色的额外配置。
在本例中,您首先创建一个基本的 heat 模板(/home/stack/templates/nameserver.yaml),它将运行一个脚本,将每个节点的 resolv.conf 附加到变量名称服务器。
在本例中,Resources 部分包含以下内容:
- CustomExtraConfig
-
这定义了软件配置。在本例中,我们定义了 Bash
脚本,Heat 将_NAMESERVER_IP_替换为nameserver_ip参数中存储的值。 - CustomExtraDeployments
这会执行软件配置,这是来自
CustomExtraConfig资源的软件配置。注意以下几点:-
配置参数引用
CustomExtraConfig资源,以便 Heat 了解要应用的配置。 -
servers参数检索 Overcloud 节点的映射。此参数由父模板提供,是此 hook 模板中的强制要求。 -
actions参数定义何时应用配置。在这种情况下,我们仅在创建 Overcloud 时应用配置。可能的操作包括CREATE、UPDATE、DELETE、SUSPEND和RESUME。 -
input_values包含一个名为deploy_identifier的参数,它存储来自父模板中的DeployIdentifier。此参数为每个部署更新的资源提供时间戳。这可确保在后续的 overcloud 更新中资源恢复。
-
配置参数引用
接下来,创建一个环境文件(/home/stack/templates/post_config.yaml),将您的 heat 模板注册为 OS::TripleO::NodeExtraConfigPost: 资源类型。
resource_registry: OS::TripleO::NodeExtraConfigPost: /home/stack/templates/nameserver.yaml parameter_defaults: nameserver_ip: 192.168.1.1
resource_registry:
OS::TripleO::NodeExtraConfigPost: /home/stack/templates/nameserver.yaml
parameter_defaults:
nameserver_ip: 192.168.1.1
要应用配置,请在创建或更新 Overcloud 时将环境文件添加到堆栈中,以及其他环境文件。例如:
openstack overcloud deploy --templates \
...
-e /home/stack/templates/post_config.yaml \
...
$ openstack overcloud deploy --templates \
...
-e /home/stack/templates/post_config.yaml \
...
这会在初始 Overcloud 创建或后续更新上完成核心配置后,将配置应用到所有节点。
您只能将 OS::TripleO::NodeExtraConfigPost 注册到一个 Heat 模板。后续使用会覆盖要使用的 Heat 模板。
这可实现:
-
OS::TripleO::NodeExtraConfigPost是集合中后配置模板中使用的基于 director 的 Heat 资源。此资源通过*-post.yaml模板将配置传递给每个节点类型。默认的NodeExtraConfigPost是指生成空白值的 Heat 模板(extraconfig/post_deploy/default.yaml)。在我们的示例中,我们的post_config.yaml环境文件将这个默认文件替换为我们自己的nameserver.yaml文件的引用。 -
环境文件还会将
nameserver_ip传递为我们环境的parameter_default值。这是存储名称服务器的 IP 地址的参数。然后,name.yamlHeat 模板接受此参数,如parameters部分中定义。 -
该模板通过
OS::Heat::SoftwareConfig将CustomExtraConfig定义为配置资源。注意group: script属性。组定义了要使用的软件配置工具,该工具通过一组用于 Heat 的 hook 使用。在本例中,脚本hook 运行您在SoftwareConfig资源中定义的可执行脚本,作为配置属性。 脚本本身将
/etc/resolve.conf附加至名称服务器 IP 地址。请注意str_replace属性,它允许您使用params部分中的参数替换template部分中的变量。在本例中,我们将 NAMESERVER_IP 设置为名称服务器 IP 地址,这将替换 脚本中的相同变量。这会生成以下脚本:#!/bin/sh echo "nameserver 192.168.1.1" >> /etc/resolve.conf
#!/bin/sh echo "nameserver 192.168.1.1" >> /etc/resolve.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow
本例演示了如何创建 Heat 模板,该模板定义配置并使用 OS::Heat::SoftwareConfig 和 OS::Heat::SoftwareDeployments 进行部署。它还介绍了如何在环境文件中定义参数,并将其传递到配置中的模板。
5.7. Puppet:将自定义配置应用到 Overcloud 复制链接链接已复制到粘贴板!
之前,我们讨论了为 OpenStack Puppet 模块添加新后端的配置。本节介绍 director 如何执行新配置的应用程序。
Heat 模板提供了一个 hook,允许您将 Puppet 配置应用到 OS::Heat::SoftwareConfig 资源。这个过程和我们包含和执行 Bash 脚本的方式类似。但是,我们改为使用 group: puppet hook,而不是 group: script hook。
例如,您可能有一个 Puppet 清单(example-puppet-manifest.pp),它使用官方 Cinder Puppet 模块启用 NFS Cinder 后端:
cinder::backend::nfs { 'mynfsserver':
nfs_servers => ['192.168.1.200:/storage'],
}
cinder::backend::nfs { 'mynfsserver':
nfs_servers => ['192.168.1.200:/storage'],
}
此 Puppet 配置利用 cinder::backend::nfs 定义的类型来创建新的资源。要通过 Heat 应用此资源,请创建一个运行 Puppet 清单的基本 Heat 模板(puppet-config.yaml):
接下来,创建一个环境文件(puppet_config.yaml),将 Heat 模板注册为 OS::TripleO::NodeExtraConfigPost 资源类型。
resource_registry: OS::TripleO::NodeExtraConfigPost: puppet_config.yaml
resource_registry:
OS::TripleO::NodeExtraConfigPost: puppet_config.yaml
本例类似于使用上一节中的 脚本 hook 示例中的 SoftwareConfig 和 SoftwareDeployments。但是,在这个示例中有一些区别:
-
我们设置
group: puppet,以便我们执行puppethook。 -
config属性使用get_file属性来引用包含我们额外配置的 Puppet 清单。 options属性包含一些特定于 Puppet 配置的选项:-
enable_hiera选项使 Puppet 配置能够使用 Hiera 数据。 -
enable_facter选项可让 Puppet 配置使用facter命令中的系统事实。
-
本例演示了如何将 Puppet 清单作为 Overcloud 软件配置的一部分包含在内。这提供了一种在 Overcloud 镜像中应用现有 Puppet 模块的某些配置类的方法,帮助您自定义 Overcloud 以使用某些软件和硬件。
5.8. Puppet:为角色自定义 Hieradata 复制链接链接已复制到粘贴板!
Heat 模板集合包含一组参数,用于将额外配置传递给某些节点类型。这些参数将配置保存为节点的 Puppet 配置的 hieradata。这些参数:
- ControllerExtraConfig
- 添加至所有 Controller 节点的配置。
- ComputeExtraConfig
- 添加至所有 Compute 节点的配置。
- BlockStorageExtraConfig
- 添加至所有块存储节点的配置。
- ObjectStorageExtraConfig
- 添加至所有 Object Storage 节点的配置
- CephStorageExtraConfig
- 配置以添加到所有 Ceph Storage 节点
- [ROLE]ExtraConfig
-
要添加到可组合角色的配置。用可组合角色名称替换
[ROLE]。 - ExtraConfig
- 要添加到所有节点的配置。
要在部署后配置过程中添加额外的配置,请在 parameter_defaults 部分中创建一个包含这些参数的环境文件。例如,要将 Compute 主机保留的内存增加到 1024 MB,并将 VNC 键映射设置为日语:
parameter_defaults:
ComputeExtraConfig:
nova::compute::reserved_host_memory: 1024
nova::compute::vnc_keymap: ja
parameter_defaults:
ComputeExtraConfig:
nova::compute::reserved_host_memory: 1024
nova::compute::vnc_keymap: ja
在运行 openstack overcloud deploy 时包括此环境文件。
您只能定义一个参数一次。后续使用会覆盖之前的值。
5.9. 在 Overcloud 部署中添加环境文件 复制链接链接已复制到粘贴板!
在开发与自定义配置相关的一组环境文件后,在您的 Overcloud 部署中包括这些文件。这意味着,使用 -e 选项运行 openstack overcloud deploy 命令,后跟 环境文件。您可以根据自定义,多次指定 -e 选项。例如:
openstack overcloud deploy --templates -e network-configuration.yaml -e storage-configuration.yaml -e first-boot.yaml
$ openstack overcloud deploy --templates -e network-configuration.yaml -e storage-configuration.yaml -e first-boot.yaml
环境文件以连续顺序进行堆栈。这意味着每个后续文件均位于主要 Heat 模板集合和所有之前的环境文件上。这提供了一种覆盖资源定义的方法。例如,如果 Overcloud 部署中的所有环境文件都定义了 NodeExtraConfigPost 资源,则 Heat 将使用最后一个环境文件中定义的 NodeExtraConfigPost。因此,环境文件的顺序非常重要。确保订购环境文件,以便正确处理和堆栈。
使用 -e 选项添加到 Overcloud 的所有环境文件都会成为 Overcloud 堆栈定义的一部分。director 需要这些环境文件用于任何部署后或重新部署功能。未能包含这些文件可能会导致 Overcloud 损坏。
第 6 章 可组合的服务 复制链接链接已复制到粘贴板!
Red Hat OpenStack Platform (RHOSP)包含了在角色上定义自定义角色和 compose 服务组合的功能。有关更多信息,请参阅高级 Overcloud 自定义指南中的 {defaultURL}/advanced_overcloud_customization/chap-roles[Composable Services 和 Custom Roles]。作为集成的一部分,您可以定义自己的自定义服务,并将它们包含在所选角色上。
6.1. 检查可组合的服务架构 复制链接链接已复制到粘贴板!
核心 heat 模板集合包含两组可组合服务模板:
-
Puppet/服务包含用于配置可组合服务的基础模板。 -
Docker/服务包含关键 OpenStack 平台服务的容器化模板。这些模板作为对某些基础模板的增强并引用回基础模板。
每个模板都包含一个标识其用途的描述。例如,ntp.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.
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.
这些服务模板注册为特定于 RHOSP 部署的资源。这意味着,您可以使用 overcloud-resource-registry-puppet.j2.yaml 文件中定义的唯一 heat 资源命名空间调用每个资源。所有服务都将 OS::TripleO::Services 命名空间用作其资源类型。
有些资源直接使用基本可组合服务模板:
resource_registry: ... OS::TripleO::Services::Ntp: puppet/services/time/ntp.yaml ...
resource_registry:
...
OS::TripleO::Services::Ntp: puppet/services/time/ntp.yaml
...
但是核心服务需要容器,如使用容器化服务模板。例如,keystone 容器化服务使用以下方法:
resource_registry: ... OS::TripleO::Services::Keystone: docker/services/keystone.yaml ...
resource_registry:
...
OS::TripleO::Services::Keystone: docker/services/keystone.yaml
...
这些容器化模板通常引用到基础模板,以包括 Puppet 配置。例如,docker/services/keystone.yaml 模板将基本模板的输出存储在 KeystoneBase 参数中:
KeystoneBase: type: ../../puppet/services/keystone.yaml
KeystoneBase:
type: ../../puppet/services/keystone.yaml
然后,容器化模板可以包含基础模板中的功能和数据。
overcloud.j2.yaml heat 模板包含 Jinja2 的代码部分,用于在 roles_data.yaml 文件中为每个自定义角色定义一个服务列表:
对于默认角色,这将创建以下服务列表参数: ControllerServices、ComputeServices、BlockStorageServices、ObjectStorageServices、CephStorageServices 和 CephStorageServices。
您可以在 roles_data.yaml 文件中为每个自定义角色定义默认服务。例如,默认的 Controller 角色包含以下内容:
这些服务随后被定义为 ControllerServices 参数的默认列表。
您还可以使用环境文件覆盖服务参数的默认列表。例如,您可以在环境文件中将 ControllerServices 定义为 parameter_default,以覆盖 roles_data.yaml 文件中的服务列表。
6.2. 创建用户定义的可组合服务 复制链接链接已复制到粘贴板!
本示例将探讨如何创建用户定义的可组合服务并专注于实施当日消息(motd)服务。在本例中,overcloud 镜像包含一个自定义 motd Puppet 模块,通过配置 hook 加载或修改 overcloud 镜像。更多信息请参阅 第 3 章 使用 overcloud 镜像。
在创建自己的服务时,您必须在服务的 heat 模板中定义以下项目:
- parameters
以下是您必须在服务模板中包含的 compulsory 参数:
-
ServiceNetMap- 服务映射到网络.使用空 hash ({})作为默认值,因为此参数使用父 Heat 模板中的值覆盖。 -
DefaultPasswords- 默认密码列表。使用空 hash ({})作为默认值,因为此参数使用父 Heat 模板中的值覆盖。 -
EndpointMap- OpenStack 服务端点的列表,供协议使用。使用空 hash ({})作为默认值,因为此参数使用父 Heat 模板中的值覆盖。
定义服务所需的任何其他参数。
-
- 输出
- 以下输出参数定义主机上的服务配置。更多信息请参阅 附录 A, 可组合的服务参数。
以下是 motd 服务的示例 heat 模板(service.yaml):
- 1
- 该模板包含一个
MotdMessage参数,用于定义当日消息。参数包含默认消息,但您可以使用自定义环境文件中的相同参数来覆盖该消息。 - 2
outputs部分定义config_settings中的一些服务 hieradata。motd::contenthieradata 存储MotdMessage参数中的内容。motdPuppet 类最终读取此 hieradata,并将用户定义的消息传递给/etc/motd文件。- 3
outputs部分包含step_config中的 Puppet 清单片断。该片段检查配置是否已达到第 2 步,如果是如此,则运行motdPuppet 类。
6.3. 包括用户定义的可组合服务 复制链接链接已复制到粘贴板!
您只能在 overcloud Controller 节点上配置自定义 motd 服务。这需要一个自定义环境文件,以及您的部署中包含的自定义角色数据文件。根据您的要求替换此流程中的输入示例。
流程
将新服务添加到环境文件
env-motd.yaml中,作为OS::TripleO::Services命名空间中的注册的 heat 资源。在本例中,我们的motd服务的资源名称为OS::TripleO::Services::Motd:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 此自定义环境文件还包含新消息,用于覆盖
MotdMessage的默认消息。部署现在包含
motd服务。但是,需要此新服务的每个角色都必须在自定义roles_data.yaml文件中具有更新的ServicesDefault列表。创建默认
roles_data.yaml文件的副本:cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml ~/custom_roles_data.yaml
$ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml ~/custom_roles_data.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 要编辑此文件,请滚动到
Controller角色,并将服务包括在ServicesDefault列表中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建 overcloud 时,将生成的环境文件和
custom_roles_data.yaml文件包含与其他环境文件和部署选项一起:openstack overcloud deploy --templates -e /home/stack/templates/env-motd.yaml -r ~/custom_roles_data.yaml [OTHER OPTIONS]
$ openstack overcloud deploy --templates -e /home/stack/templates/env-motd.yaml -r ~/custom_roles_data.yaml [OTHER OPTIONS]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
这包括我们的部署中的自定义 motd 服务,仅在 Controller 节点上配置该服务。
第 7 章 构建经认证的容器镜像 复制链接链接已复制到粘贴板!
您可以使用合作伙伴 构建服务为 认证构建应用程序容器。构建 服务从 Git 存储库构建容器,这些存储库可通过 SSH 密钥公开或私有访问。
本节介绍了使用自动化构建服务作为 Red Hat OpenStack 和 NFV Zone 的一部分的步骤,以自动为 Red Hat OpenStack Platform 13 基本容器构建容器化合作伙伴平台插件。
前提条件
- 在红帽连接技术合作伙伴注册.
- 应用区域访问 Red Hat OpenStack 和 NFV 区域。
- 创建产品.当您提供的信息将在我们的目录中发布认证时使用。
- 使用 Dockerfile 和要包含在容器中的组件,为您的插件创建 git 存储库。
如果您在注册或访问 Red Hat Connect 站点时遇到问题,请联系红帽 技术合作伙伴成功停用。
7.1. 添加容器项目 复制链接链接已复制到粘贴板!
个项目代表一个合作伙伴镜像。如果有多个镜像,您必须创建多个项目。
流程
- 登录 Red Hat Connect for Technology Partners,再单击 Zones。
- 向下滚动并选择 Red Hat OpenStack 和 NFV 区域。单击框中的任意位置。
- 点 Certify 访问贵公司的现有产品和项目。
- 单击 Add Project 以创建新项目。
设置 项目名称。
- 项目名称无法在系统外可见。
-
项目名称应包括
[product][version]-[extended-base-container-image]-[your-plugin] -
对于 OpenStack,格式为
rhospXX-baseimage-myplugin。 -
示例:
rhosp13-openstack-cinder-volume-myplugin
根据您的产品或插件,选择 产品 、产品版本 和 发布类别,以及它们的版本。
- 在创建项目之前,创建产品及其版本。
- 将标签 release 类别设置为 技术预览。在使用 Red Hat 认证完成 API 测试前,正式发布(GA)不能选择。如果您有认证容器镜像,请参阅插件认证要求。
- 根据您使用合作伙伴插件修改的基础镜像选择 Red Hat Product 和 Red Hat Product Version。在本发行版本中,请选择 Red Hat OpenStack Platform 和 13。
- 单击 Submit 以创建新项目。
结果:
红帽评估并确认您的项目认证。
发送电子邮件到 connect@redhat.com,指示插件 是否处于树内 还是与上游代码相关的 树外。
- 在树形 中,插件包含在 OpenStack 上游代码库中,插件镜像由红帽构建,并使用 Red Hat OpenStack Platform {osp_curr_ver} 分发。
- Tree 意味着插件镜像没有包含在 OpenStack 上游代码库中, 不分布到 RHOSP {osp_curr_ver} 中。
7.2. 容器认证清单遵循容器认证清单 复制链接链接已复制到粘贴板!
认证的容器符合红帽打包、分发和维护的标准。红帽通过认证的容器具有高度信任和支持,独立于容器支持的平台,包括 Red Hat OpenStack Platform (RHOSP)。为保持此维护,合作伙伴必须保持其镜像最新状态。
流程
- 点 Certification Checklist。
- 完成清单的所有部分。如果需要有关清单上的项目的更多信息,请点击左侧的下拉箭头来查看项目信息和链接到其他资源。
检查清单包括以下项目:
- 更新您的公司概况
- 确保您的公司概况表为最新。
- 更新您的产品配置集
- 本页面有关产品配置集的详细信息,包括产品类型、描述、存储库 URL、版本和联系分发列表。
- 接受 OpenStack 附录
- 容器条款的站点协议.
- 更新项目配置集
- 检查支持的镜像设置,如 auto publish、registry 命名空间、发行版本类别以及支持的平台。
在支持的 Platform 部分,您必须选择一个选项,以便可以在此页面中保存其他必填字段。
- 将应用程序打包为容器
- 按照此页面的说明来配置构建服务。构建服务依赖于完成前面的步骤。
- 上传文档和营销材料
- 这会将您重定向到产品页面。滚动到底部,再单击 Add new Collateral 来上传您的产品信息。
您必须至少提供三个材料。第一个资料必须是 文档 类型。
- 提供容器 registry 命名空间
- 这与项目页面配置集页面相同。
- 提供销售联系信息
- 这些信息与公司概况相同。
- 从红帽获取发布批准
- 红帽为此步骤提供批准。
- 配置自动化构建服务
- 执行容器镜像的构建和扫描的配置信息。
清单中的最后一个项是 Configure Automated Build Service。在配置此服务前,您必须确保您的项目包含符合 Red Hat 认证标准的 dockerfile。
7.3. Dockerfile 要求 复制链接链接已复制到粘贴板!
作为镜像构建流程的一部分,构建服务会扫描您构建的镜像,以确保它符合红帽标准。使用以下指南作为项目中包含的 dockerfile 的基础:
- 基础镜像 必须是一个红帽镜像。任何使用 Ubuntu、Debian 和 CentOS 作为基础的镜像都不会通过扫描程序。
您必须配置所需的标签:
-
name -
maintainer -
vendor -
version -
release -
summary
-
-
您必须在镜像中包含软件许可证作为文本文件。将软件许可证 添加到项目根目录下的
许可证目录中。 -
您必须配置不是
root用户的用户。
以下 dockerfile 示例演示了扫描所需的信息:
7.4. 设置项目详情 复制链接链接已复制到粘贴板!
您必须设置项目的详细信息,包括容器镜像的命名空间和 registry。
流程
- 单击 Project Settings。
确保您的项目名称采用正确的格式。另外,如果您想要自动发布通过认证的容器,将 Auto-Publish 设置为 ON。已认证容器会在 Red Hat Container Catalog 中发布。
要设置
Container Registry 命名空间,请按照在线说明进行操作。
- 容器 registry 命名空间是公司的名称。
-
最终的 registry URL 是
registry.connect.redhat.com/namespace/repository:tag。 -
示例:
registry.connect.redhat.com/mycompany/rhosp16-openstack-cinder-volume-myplugin:1.0
要设置 Outbound Repository Name 和 Outbound Repository Descriptions,请按照在线说明操作。出站存储库名称必须与项目名称相同。
-
[product][version]-[extended_base_container_image]-[your_plugin] -
对于 OpenStack,格式为
rhospXX-baseimage-myplugin -
最终 registry URL 为
registry.connect.redhat.com/namespace/repository:tag -
示例:
registry.connect.redhat.com/mycompany/rhosp13-openstack-cinder-volume-myplugin:1.0
-
在相关字段中添加关于项目的附加信息:
- 仓库描述
- 支持文档
- 点 Submit。
7.5. 使用构建服务构建容器镜像 复制链接链接已复制到粘贴板!
为您的合作伙伴插件构建容器镜像。
流程
- 单击 Build Service。
单击 Configure Build Service 以配置您的构建详情。
- 确保 红帽容器构建 设置为 ON。
- 添加 Git Source URL,并选择性地添加 源代码 SSH 密钥 (如果您的 git 存储库受到保护)。URL 可以是 HTML 或 SSH。保护的 git 存储库需要 SSH。
-
可选:添加 Dockerfile 名称或留空(如果 Dockerfile 名称为
Dockerfile)。 - 可选:如果 docker 构建上下文 root 不是 git 存储库的根目录,则添加上下文目录。否则,将此字段留空。
- 将 git 存储库中的 Branch 设置为基础容器镜像。
- 单击 Submit 以完成 Build Service 设置。
- 单击 Start Build。
添加 Tag Name,再单击 Submit。构建完成最多可能需要 6 分钟时间。
- 标签名称应为插件的版本
-
最终的参考 URL 为
registry.connect.redhat.com/namespace/repository:tag -
示例:
registry.connect.redhat.com/mycompany/rhosp13-openstack-cinder-volume-myplugin:1.0
- 点 Refresh 以检查您的构建是否已完成。可选:点击匹配的 构建 ID 查看构建详情和日志。
-
构建服务均构建并扫描镜像。这通常需要 10-15 分钟完成。扫描完成后,单击
View链接以展开扫描结果。
7.6. 修正失败的扫描结果 复制链接链接已复制到粘贴板!
Scan Details 页面显示扫描的结果,包括任何失败的项目。如果您的镜像扫描报告 FAILED 状态,请使用以下步骤调查如何更正失败。
流程
- 在 Container Information 页面中,点 View 链接来展开扫描结果。
点 failed 项。例如,在以下屏幕截图中,
has_licenses检查失败。
- 点击失败项打开 相关文档中 的策略指南,并查看有关如何更正此问题的更多信息。
如果您在访问策略 指南 时收到一个 Access Denied 警告,请发送电子邮件 connect@redhat.com
7.7. 发布容器镜像 复制链接链接已复制到粘贴板!
容器镜像通过扫描后,您可以发布容器镜像。
流程
- 在 Container Information 页面中,单击 Publish 链接,以发布容器镜像实时。
- Publish 链接会更改为 Unpublish。要取消发布容器,点 Unpublish 链接。
发布该链接后,请查看认证文档,以了解有关认证插件的更多信息。有关认证文档的链接,请参阅 第 1.1 节 “合作伙伴集成先决条件”。
7.8. 部署供应商插件 复制链接链接已复制到粘贴板!
要将第三方硬件用作块存储后端,您必须部署供应商插件。以下示例演示了如何部署供应商插件以使用 Dell EMC 硬件作为块存储后端。
登录到
registry.connect.redhat.com目录:docker login registry.connect.redhat.com
$ docker login registry.connect.redhat.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 下载插件:
docker pull registry.connect.redhat.com/dellemc/openstack-cinder-volume-dellemc-rhosp13
$ docker pull registry.connect.redhat.com/dellemc/openstack-cinder-volume-dellemc-rhosp13Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用与 OpenStack 部署相关的 undercloud IP 地址,标记并将镜像推送到本地 undercloud registry:
docker tag registry.connect.redhat.com/dellemc/openstack-cinder-volume-dellemc-rhosp13 192.168.24.1:8787/dellemc/openstack-cinder-volume-dellemc-rhosp13 docker push 192.168.24.1:8787/dellemc/openstack-cinder-volume-dellemc-rhosp13
$ docker tag registry.connect.redhat.com/dellemc/openstack-cinder-volume-dellemc-rhosp13 192.168.24.1:8787/dellemc/openstack-cinder-volume-dellemc-rhosp13 $ docker push 192.168.24.1:8787/dellemc/openstack-cinder-volume-dellemc-rhosp13Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用包含以下参数的额外环境文件部署 overcloud:
parameter_defaults: DockerCinderVolumeImage: 192.168.24.1:8787/dellemc/openstack-cinder-volume-dellemc-rhosp13
parameter_defaults: DockerCinderVolumeImage: 192.168.24.1:8787/dellemc/openstack-cinder-volume-dellemc-rhosp13Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 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 测试。
上游存储库:
上游蓝图:
- Launchpad: http://launchpad.net/ironic
Puppet 模块:
Bugzilla 组件:
- openstack-ironic
- python-ironicclient
- python-ironic-oscplugin
- openstack-ironic-discoverd
- openstack-puppet-modules
- openstack-tripleo-heat-templates
集成备注:
-
上游项目包含
ironic/drivers目录中的驱动程序。 -
director 执行 JSON 文件中定义的节点批量注册。
os-cloud-config工具 https://github.com/openstack/os-cloud-config/ 可解析此文件来确定节点注册详情并执行注册。这意味着os-cloud-config工具(特别是nodes.py文件)需要支持您的驱动程序。 director 会自动配置为使用裸机置备,这意味着 Puppet 配置不需要很少修改。但是,如果您的驱动程序包括在 Bare Metal Provisioning 中,您必须将驱动程序添加到
/etc/ironic/ironic.conf文件中。编辑此文件并搜索enabled_drivers参数:enabled_drivers=pxe_ipmitool,pxe_ssh,pxe_drac
enabled_drivers=pxe_ipmitool,pxe_ssh,pxe_dracCopy to Clipboard Copied! Toggle word wrap Toggle overflow 这允许裸机置备使用驱动程序目录中的指定
驱动程序。
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 插件的一部分开发。
上游存储库:
上游蓝图:
- Launchpad: http://launchpad.net/neutron
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 插件都已移到自己的存储库中,即以
networking-开始。例如,Cisco 特定的插件位于 https://github.com/openstack/networking-cisco中 puppet-neutron存储库还包含不同的目录来配置这些集成点:-
插件配置位于
manifests/plugins/中 -
ml2 插件驱动程序配置位于
manifests/plugins/ml2/中。 -
代理配置位于
manifests/agents/中
-
插件配置位于
-
puppet-neutron存储库包含用于配置功能的大量库。例如,neutron_plugin_ml2库添加一个函数,以将属性添加到 ml2 插件配置文件中。
8.3. 块存储(Cinder) 复制链接链接已复制到粘贴板!
OpenStack Block Storage (cinder)提供了一个与块存储设备交互的 API,Red Hat OpenStack Platform (RHOSP)用于创建卷。例如,块存储为实例提供虚拟存储设备。块存储提供一组核心驱动程序来支持不同的存储硬件和协议。例如,一些核心驱动程序包括对 NFS、iSCSI 和 Red Hat Ceph Storage 的支持。供应商可包括支持其他认证硬件的驱动程序。
供应商在开发的驱动程序和配置方面有两个主要选项:
- 作为 RHOSP 解决方案的一部分,包括它们以用于分发
- 在 RHOSP 发行版本后将它们添加到 overcloud 镜像
分析现有驱动程序的功能,以确定如何集成您自己的认证硬件和软件。
上游存储库:
上游蓝图:
- Launchpad: http://launchpad.net/cinder
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 的支持。供应商可包括支持其他认证硬件的驱动程序。
上游存储库:
OpenStack:
GitHub:
上游蓝图:
- Launchpad: http://launchpad.net/glance
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.6. OpenShift-on-OpenStack 复制链接链接已复制到粘贴板!
Red Hat OpenStack Platform (RHOSP)旨在支持 OpenShift-on-OpenStack 部署。有关这些部署合作伙伴集成的更多信息,请参阅 Red Hat OpenShift 合作伙伴 页面。
附录 A. 可组合的服务参数 复制链接链接已复制到粘贴板!
以下参数用于所有可组合服务中的输出:
以下参数用于特定于容器化可组合服务的输出:
A.1. 所有可组合服务 复制链接链接已复制到粘贴板!
以下参数适用于所有可组合服务。
service_name
服务的名称。您可以使用它来通过 service_config_settings 从其他可组合服务应用配置。
config_settings
服务的自定义 hieradata 设置。
service_config_settings
其他服务的自定义 hieradata 设置。例如,您的服务可能需要在 OpenStack 身份服务中注册的端点(keystone)。这为另一个服务提供参数,并提供一个跨服务配置的方法,即使服务在不同的角色中也是如此。
global_config_settings
分发到所有角色的自定义 hieradata 设置。
step_config
用于配置 服务的 Puppet 代码片段。此片断添加到在服务配置过程的每个步骤中创建并运行的合并清单。这些步骤包括:
- 第 1 步 - 负载均衡器配置
- 第 2 步- 核心高可用性和常规服务(Database、RabbitMQ、NTP)
- 第 3 步- 早期 OpenStack 平台服务设置(存储,Ring 构建)
- 第 4 步 - 通用 OpenStack 平台服务
- 第 5 步 - 服务激活(Pacemaker)和 OpenStack Identity (keystone)角色和用户创建
在任何引用的 puppet 清单中,您可以使用 步骤 hieradata (使用 hiera ('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 参数来更改此角色。
A.2. 容器化可组合服务 复制链接链接已复制到粘贴板!
以下参数适用于所有容器化可组合服务。
puppet_config
本节是嵌套的键值对,利用 puppet 驱动创建配置文件。所需的参数包括:
- puppet_tags
-
用于通过 Puppet 生成配置文件的 Puppet 资源标签名称。仅使用命名的配置资源来生成文件。任何指定标签的服务都会包含文件, concat,file_line,augeas,cron 附加到该设置的默认标签。示例:
keystone_config - config_volume
- 为该服务生成配置文件的卷名称(目录)。使用此位置将挂载绑定到正在运行的 Kolla 容器中进行配置。
- config_image
- 用于生成配置文件的 docker 镜像的名称。这通常是运行时服务使用的相同容器。有些服务共享一组通用配置文件,这些文件在通用基本容器中生成。
- step_config
- 此设置控制用于通过 Puppet 创建 docker 配置文件的清单。以下 Puppet 标签和此清单一起使用,以便为该容器生成配置目录。
kolla_config
在容器中创建 Kolla 配置的映射。格式从配置文件的绝对路径开始,并将它用于以下子参数:
- 命令
- 容器启动时要运行的命令。
- config_files
-
服务配置文件(
源)和容器(st )的位置,然后再启动服务之前。另外,还包括在容器中合并或替换这些文件的选项(合并),是否要保留文件权限和其他属性(preserve_properties)。 - 权限
-
为容器上某些目录设置权限。需要
路径、所有者和组。您还可以以递归方式应用权限(递归)。
以下是 keystone 服务的 kolla_config 参数示例:
docker_config
传递给 docker-cmd hook 的数据,以便在每个步骤中配置容器。
-
step_0- 按 hiera 设置生成的容器配置文件。 step_1- Load Balancer configuration- 裸机配置
- 容器配置
step_2- Core Services (Database/Rabbit/NTP/etc.)- 裸机配置
- 容器配置
step_3- 早期 OpenStack 服务设置(Ringbuilder 等)- 裸机配置
- 容器配置
step_4- General OpenStack Services- 裸机配置
- 容器配置
- Keystone 容器发布初始化(租户、服务、端点创建)
step_5- 服务激活(Pacemaker)- 裸机配置
- 容器配置
YAML 使用一组参数来定义容器容器在每个步骤中运行,以及与每个容器关联的 Docker 设置。例如:
这会创建一个 keystone 容器,并使用对应的参数来定义详细信息,包括要使用的镜像、网络类型和环境变量。
docker_puppet_tasks
提供直接驱动 docker-puppet.py 工具的数据。该任务仅在集群内(不能在各个节点上)内执行一次,对于初始化 keystone 端点和数据库用户等内容所需的多个 Puppet 代码片段来说也很有用。例如:
host_prep_tasks
这是一个 ansible 代码片段,可在节点主机上执行,为容器化服务准备它。例如,您可能需要在创建期间挂载容器中的特定目录。
fast_forward_upgrade_tasks
Ansible 代码片段,帮助进行快进的升级过程。此片段添加到组合的 playbook 中。每个操作都使用标签来定义 步骤和 发行版本
这些步骤 通常遵循以下阶段:
-
step=0- Check running services -
step=1- 停止服务 -
step=2- 停止集群 -
step=3- Update repositories -
step=4- Database backups -
step=5- Pre-package update commands -
step=6- Package updates -
第=7 步- Post-package 更新命令 -
step=8- Database updates -
step=9- Verification
标签 与一个发行版本对应:
-
tag=ocata- OpenStack Platform 11 -
tag=pike- OpenStack Platform 12 -
tag=queens- OpenStack Platform 13