搜索
支持控制台（Console）开发人员开始试用联系人

第 10 章 使用编排服务(heat)配置 overcloud.

download PDF

您可以使用编排服务(heat)在 heat 模板和环境文件中创建自定义 overcloud 配置。

10.1. 了解 heat 模板

本指南中的自定义配置使用 heat 模板和环境文件来定义 overcloud 的某些方面。本章介绍了 heat 模板，以便您可以了解 Red Hat OpenStack Platform director 中这些模板的结构和格式。

10.1.1. Heat 模板

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

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 处理模板时，它会为模板创建堆栈，并为资源模板创建一组子堆栈。这会创建您通过模板定义的主堆栈中解掉的堆栈层次结构。您可以使用以下命令查看堆栈层次结构： 

$ openstack stack list --nested

10.1.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。

10.1.3. 核心 overcloud heat 模板

director 包含 overcloud 的核心 heat 模板集合和环境文件集合。此集合存储在 /usr/share/openstack-tripleo-heat-templates 中。

此模板集合中的主文件和目录有：

overcloud.j2.yaml
这是 director 用于创建 overcloud 环境的主要模板文件。此文件使用 Jinja2 语法来迭代模板中的某些部分，以创建自定义角色。Jinja2 格式在 overcloud 部署期间呈现为 YAML。
overcloud-resource-registry-puppet.j2.yaml
这是 director 用于创建 overcloud 环境的主要环境文件。它为 overcloud 镜像中存储的 Puppet 模块提供一组配置。在将 overcloud 镜像写入每个节点后，heat 会使用此环境文件中注册的资源启动每个节点的 Puppet 配置。此文件使用 Jinja2 语法来迭代模板中的某些部分，以创建自定义角色。Jinja2 格式在 overcloud 部署期间呈现为 YAML。
roles_data.yaml
此文件包含 overcloud 中角色的定义，并将服务映射到每个角色。
network_data.yaml
此文件包含 overcloud 中网络的定义，以及它们的属性，如子网、分配池和 VIP 状态。默认 network_data.yaml 文件包含默认网络： External, 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/services
此目录包含所有服务配置的传统 heat 模板。部署 目录中的模板替换 puppet/services 目录中的大多数模板。
extraconfig
此目录包含可用于启用额外功能的模板。

10.1.4. 在 overcloud 创建中包含环境文件

在部署命令中包括环境文件，并使用 -e 选项。您可以根据需要纳入多个环境文件。但是，环境文件的顺序非常重要，因为后续环境文件中定义的参数和资源具有优先权。例如，您有两个环境文件，其中包含一个通用资源类型 OS::TripleO::NodeExtraConfigPost，以及一个通用参数 TimeZone ：

environment-file-1.yaml

resource_registry:
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/template-1.yaml

parameter_defaults:
  RabbitFDLimit: 65536
  TimeZone: 'Japan'

environment-file-2.yaml

resource_registry:
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/template-2.yaml

parameter_defaults:
  TimeZone: 'Hongkong'

在部署命令中包含这两个环境文件： 

$ openstack overcloud deploy --templates -e environment-file-1.yaml -e environment-file-2.yaml

openstack overcloud deploy 命令通过以下进程运行：

  1. 从核心 heat 模板集合中加载默认配置。
  2. 应用 environment-file-1.yaml 的配置，它会覆盖默认配置中的任何通用设置。
  3. 应用 environment-file-2.yaml 的配置，它会覆盖来自默认配置和 environment-file-1.yaml 的任何通用设置。

这会对 overcloud 的默认配置进行以下更改：

  • OS::TripleO::NodeExtraConfigPost 资源设置为 /home/stack/templates/template-2.yaml，如 environment-file-2.yaml 中定义的。
  • timezone 参数设置为 Hongkong，如 environment-file-2.yaml 中定义的。
  • RabbitFDLimit 参数设为 65536，如 environment-file-1.yaml 中定义的。environment-file-2.yaml 不会更改此值。

您可以使用此机制为 overcloud 定义自定义配置，而无需多个环境文件中的值冲突。

10.1.5. 使用自定义核心 heat 模板

在创建 overcloud 时，director 使用位于 /usr/share/openstack-tripleo-heat-templates 中的核心 heat 模板。如果要自定义此核心模板集合，请使用以下 Git 工作流来管理您的自定义模板集合：

流程

  • 创建包含 heat 模板集合的初始 Git 存储库：

    1. 将模板集合复制到 /home/stack/templates 目录中： 

      $ cd ~/templates
$ cp -r /usr/share/openstack-tripleo-heat-templates .

    2. 进入自定义模板目录并初始化 Git 存储库： 

      $ cd ~/templates/openstack-tripleo-heat-templates
$ git init .

    3. 配置 Git 用户名和电子邮件地址： 

      $ git config --global user.name "<USER_NAME>"
$ git config --global user.email "<EMAIL_ADDRESS>"
  • 将 <USER_NAME > 替换为您要使用的用户名。

  • 将 <EMAIL_ADDRESS > 替换为您的电子邮件地址。

    1. 为初始提交暂存所有模板： 

      $ git add *

    2. 创建初始提交： 

      $ git commit -m "Initial creation of custom core heat templates"

      这将创建一个包含最新核心模板集合的初始 master 分支。使用此分支作为自定义分支的基础，并将新模板版本合并到此分支中。

  • 使用自定义分支将您的更改保存到核心模板集合。使用以下步骤创建 my-customizations 分支并添加自定义：

    1. 创建 my-customizations 分支并切换到它： 

      $ git checkout -b my-customizations
    2. 编辑自定义分支中的文件。

    3. 暂存 git 中的更改： 

      $ git add [edited files]

    4. 将更改提交到自定义分支： 

      $ git commit -m "[Commit message for custom changes]"

      这会将您的更改作为提交添加到 my-customizations 分支。当 master 分支更新时，您可以将 my-customizations 从 master 进行更新，这会导致 git 将这些提交添加到更新的模板集合中。这有助于跟踪您的自定义信息，并在将来的模板更新中重新显示它们。

  • 更新 undercloud 时，openstack-tripleo-heat-templates 软件包也可能收到更新。当发生这种情况时，还必须更新自定义模板集合：

    1. 将 openstack-tripleo-heat-templates 软件包版本保存为环境变量： 

      $ export PACKAGE=$(rpm -qv openstack-tripleo-heat-templates)

    2. 进入模板集合目录并为更新的模板创建新分支： 

      $ cd ~/templates/openstack-tripleo-heat-templates
$ git checkout -b $PACKAGE

    3. 删除分支中的所有文件，并将其替换为新版本： 

      $ git rm -rf *
$ cp -r /usr/share/openstack-tripleo-heat-templates/* .

    4. 为初始提交添加所有模板： 

      $ git add *

    5. 为软件包更新创建提交： 

      $ git commit -m "Updates for $PACKAGE"

    6. 将分支合并到 master 中。如果使用 Git 管理系统（如 GitLab），请使用管理工作流。如果您在本地使用 git，切换到 master 分支并运行 git merge 命令： 

      $ git checkout master
$ git merge $PACKAGE

master 分支现在包含核心模板集合的最新版本。现在，您可以从这个更新的集合中重新构建 my-customization 分支。

  • 更新 my-customization 分支：

    1. 进入 my-customizations 分支： 

      $ git checkout my-customizations

    2. 将分支更新为 master ： 

      $ git rebase master

      这将更新 my-customizations 分支，并重播为此分支发出的自定义提交。

  • 解决在 rebase 过程中发生的任何冲突：

    1. 检查哪些文件包含冲突： 

      $ git status
    2. 解决确定的模板文件冲突。

    3. 添加解析的文件： 

      $ git add [resolved files]

    4. 继续 rebase： 

      $ git rebase --continue

  • 部署自定义模板集合：

    1. 确保您已切换到 my-customization 分支： 

      git checkout my-customizations

    2. 使用 --templates 选项运行 openstack overcloud deploy 命令来指定您的本地目录： 

      $ openstack overcloud deploy --templates /home/stack/templates/openstack-tripleo-heat-templates [OTHER OPTIONS]
注意

如果您指定了不带目录的 --templates 选项，director 将使用默认模板目录(/usr/share/openstack-tripleo-heat-templates)。

重要

红帽建议在 第 10.3 节 “配置 hook” 中使用方法，而不是修改 heat 模板集合。

10.1.6. Jinja2 渲染

/usr/share/openstack-tripleo-heat-templates 中的核心 heat 模板包含多个具有 j2.yaml 文件扩展名的文件。这些文件包含 Jinja2 模板语法，director 会将这些文件呈现成其具有 .yaml 扩展名的静态 heat 模板。例如，主 overcloud.j2.yaml 文件呈现到 overcloud.yaml 中。director 使用生成的 overcloud.yaml 文件。

启用 Jinja2 的 heat 模板使用 Jinja2 语法来创建用于迭代值的参数和资源。例如，overcloud.j2.yaml 文件包含以下代码片段： 

parameters:
...
{% for role in roles %}
  ...
  {{role.name}}Count:
    description: Number of {{role.name}} nodes to deploy
    type: number
    default: {{role.CountDefault|default(0)}}
  ...
{% endfor %}

当 director 呈现 Jinja2 语法时，director 会迭代 roles_data.yaml 文件中定义的角色，并使用角色的名称填充 {{role.name}}Count 参数。默认 roles_data.yaml 文件包含五个角色，并从我们的示例中生成以下参数：

  • ControllerCount
  • ComputeCount
  • BlockStorageCount
  • ObjectStorageCount
  • CephStorageCount

参数渲染版本示例类似如下： 

parameters:
  ...
  ControllerCount:
    description: Number of Controller nodes to deploy
    type: number
    default: 1
  ...

director 仅从核心 heat 模板的 目录内呈现启用了 Jinja2 的模板和环境文件。以下用例演示了呈现 Jinja2 模板的正确方法。

使用案例 1：默认核心模板

模板目录： /usr/share/openstack-tripleo-heat-templates/

环境文件： /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.j2.yaml

director 使用默认核心模板位置(--templates)，并将 enable-internal-tls.j2.yaml 文件呈现到 enable-internal-tls.yaml 中。运行 openstack overcloud deploy 命令时，请使用 -e 选项包括渲染的 enable-internal-tls.yaml 文件的名称。 

$ openstack overcloud deploy --templates \
    -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml
    ...

使用案例 2：自定义核心模板

模板目录： /home/stack/tripleo-heat-installer-templates

环境文件： /home/stack/tripleo-heat-installer-templates/environments/ssl/enable-internal-tls.j2.yaml

director 使用自定义核心模板位置(--templates /home/stack/tripleo-heat-templates)，director 会将自定义核心模板中的 enable-internal-tls.j2.yaml 文件呈现到 enable-internal-tls.yaml 中。运行 openstack overcloud deploy 命令时，请使用 -e 选项包括渲染的 enable-internal-tls.yaml 文件的名称。 

$ openstack overcloud deploy --templates /home/stack/tripleo-heat-templates \
    -e /home/stack/tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml
    ...

使用案例 3：不正确使用

模板目录： /usr/share/openstack-tripleo-heat-templates/

环境文件： /home/stack/tripleo-heat-installer-templates/environments/ssl/enable-internal-tls.j2.yaml

director 使用自定义核心模板位置(--templates /home/stack/tripleo-heat-installer-templates)。但是，所选的 enable-internal-tls.j2.yaml 不在自定义核心模板中，因此它不会呈现到 enable-internal-tls.yaml 中。这会导致部署失败。

将 Jinja2 语法处理到静态路由中

使用 process-templates.py 脚本将 openstack-tripleo-heat-templates 的 Jinja2 语法呈现到一组静态路由中。要使用 process-templates.py 脚本呈现 openstack-tripleo-heat-templates 集合的副本，请切换到 openstack-tripleo-heat-templates 目录： 

$ cd /usr/share/openstack-tripleo-heat-templates

运行位于 工具 目录中的 process-templates.py 脚本，以及 -o 选项来定义自定义目录来保存静态副本： 

$ ./tools/process-templates.py -o ~/openstack-tripleo-heat-templates-rendered

这会将所有 Jinja2 模板转换为呈现的 YAML 版本，并将结果保存到 ~/openstack-tripleo-heat-templates-rendered。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.