[ 英语 | 印度尼西亚语 | 俄语 ]

配置清单¶

在本章中，您可以找到有关如何根据您的需求配置 OpenStack-Ansible 动态清单的信息。

介绍¶

OpenStack-Ansible 通过 /etc/openstack_deploy/openstack_user_config.yml 设置文件定义了常见的 OpenStack 服务及其配置。

为了管理文件大小，应使用 /etc/openstack_deploy/conf.d 中的 YAML 文件来定义其他服务。

/etc/openstack_deploy/env.d 目录会将所有 YAML 文件导入到部署环境中，允许部署者定义其他组映射。该目录用于扩展环境骨架，或修改在 inventory/env.d 目录中定义的默认设置。

要了解动态清单的工作方式，请参阅了解清单。

警告

切勿编辑或删除文件 /etc/openstack_deploy/openstack_inventory.json。这可能导致清单出现问题：现有的主机和容器将变为未管理状态，并会生成新的主机和容器，从而破坏您现有的部署。

配置约束¶

组别成员关系¶

在添加组时，请记住以下几点

一个组可以包含主机
一个组可以包含子组

但是，组不能同时包含子组和主机。

lxc_hosts 组¶

当动态清单脚本创建容器名称时，容器所在的宿主机会被添加到 lxc_hosts 清单组中。

在配置中使用此名称作为组名会导致运行时错误。

直接部署到主机¶

要在主机上直接部署组件，而不是在容器内部署，请在适当文件的 container_skel 部分中将容器组的 is_metal 属性设置为 true。

对于直接部署到主机的服务，container_vars 的使用以及容器组到主机组的映射是相同的。

您还可以使用 no_containers 选项来指定将所有服务在其内部部署到金属上的主机。

注意

默认情况下，cinder-volume 组件直接部署到主机上。请参阅 env.d/cinder.yml 文件以获取此示例。

示例：在金属上运行所有控制器¶

例如，如果您想在金属上运行所有控制器，则需要在您的 openstack_user_config.yml 中包含以下内容。

infra_hosts:
  infra1:
    ip: 172.39.123.11
    no_containers: true
  infra2:
    ip: 172.39.123.12
    no_containers: true
  infra3:
    ip: 172.39.123.13
    no_containers: true

示例：在专用主机上运行 Galera¶

例如，要在专用主机上直接运行 Galera，您将执行以下步骤

修改 env.d/galera.yml 文件的 container_skel 部分。例如

container_skel:
  galera_container:
    belongs_to:
      - db_containers
    contains:
      - galera
    properties:
      is_metal: true

注意

要在这些专用主机上在容器内部署，请省略 is_metal: true 属性。

通过在新的或现有文件中（例如 env.d/galera.yml）为主机组提供 physical_skel 部分，将 db_containers 容器组（来自上一步）分配给主机组。例如
```
physical_skel:
  db_containers:
    belongs_to:
      - all_containers
  db_hosts:
    belongs_to:
      - hosts
```
在 conf.d/ 文件（例如 galera.yml）中定义主机组 (db_hosts)。例如
```
db_hosts:
  db-host1:
    ip: 172.39.123.11
  db-host2:
    ip: 172.39.123.12
  db-host3:
    ip: 172.39.123.13
```
注意

在此示例中的每个自定义组名 (db_containers 和 db_hosts) 都是任意的。选择您自己的组名，但请确保所有相关文件中的引用保持一致。

添加虚拟嵌套组¶

如果您想为主机和这些主机内的容器的任意分组创建自定义组，但跳过任何新容器的生成，您应该使用 container_skel 下的 is_nest 属性，并跳过定义 belongs_to 结构。is_nest 属性会将主机-容器作为该组的子项添加。

示例：定义可用区¶

如何使用 is_nest 属性的一个很好的示例是描述可用区。当操作多个可用区时，为每个可用区的所有主机定义特定于可用区的变量（例如可用区名称）非常有用。而利用 group_vars 是确保属于同一可用区的所有主机具有相同的配置的最佳方法。

假设您有 3 个控制器，每个控制器都放置在不同的可用区。每个可用区还有一个计算节点。我们希望放置在特定可用区中的每个主机或容器都属于其自己的组（例如 azN_all）

为了实现这一点，我们需要

在 conf.d 或 openstack_user_config.yml 中定义主机组，以根据其可用区分配主机

az1-infra_hosts: &infra_az1
  az1-infra1:
    ip: 172.39.123.11

az2-infra_hosts: &infra_az2
  az2-infra2:
    ip: 172.39.123.12

az3-infra_hosts: &infra_az3
  az3-infra3:
    ip: 172.39.123.13

shared-infra_hosts: &controllers
  <<: *infra_az1
  <<: *infra_az2
  <<: *infra_az3

az1-compute_hosts: &computes_az1
  az1-compute01:
    ip: 172.39.123.100

az2-compute_hosts: &computes_az2
  az2-compute01:
    ip: 172.39.123.150

az3-compute_hosts: &computes_az3
  az3-compute01:
    ip: 172.39.123.200

compute_hosts:
  <<: *computes_az1
  <<: *computes_az2
  <<: *computes_az3

az1_hosts:
  <<: *computes_az1
  <<: *infra_az1

az2_hosts:
  <<: *computes_az2
  <<: *infra_az2

az3_hosts:
  <<: *computes_az3
  <<: *infra_az3

创建一个 env.d/az.yml 文件，该文件将利用 is_nest 属性，并允许所有基础设施容器都成为可用区组的一部分

component_skel:
  az1_containers:
    belongs_to:
      - az1_all
  az1_hosts:
    belongs_to:
      - az1_all

  az2_containers:
    belongs_to:
      - az2_all
  az2_hosts:
    belongs_to:
      - az2_all

  az3_containers:
    belongs_to:
      - az3_all
  az3_hosts:
    belongs_to:
      - az3_all

container_skel:
  az1_containers:
    properties:
      is_nest: true
  az2_containers:
    properties:
      is_nest: true
  az3_containers:
    properties:
      is_nest: true

现在，您可以使用 group_vars 文件将变量应用于可用区中的所有容器和裸机主机。例如 /etc/openstack_deploy/group_vars/az1_all.yml
```
---
az_name: az1
cinder_storage_availability_zone: "{{ az_name }}"
```

每个主机没有组件类型（或多个组件类型）的部署¶

当 OpenStack-Ansible 生成其动态清单时，亲和性设置决定了单个物理主机上部署了多少个相同类型的容器。

以 shared-infra_hosts 为例，考虑此 openstack_user_config.yml 配置

shared-infra_hosts:
  infra1:
    ip: 172.29.236.101
  infra2:
    ip: 172.29.236.102
  infra3:
    ip: 172.29.236.103

将三个主机分配给 shared-infra_hosts 组，OpenStack-Ansible 确保每个主机运行一个数据库容器、一个 Memcached 容器和一个 RabbitMQ 容器。默认情况下，每个主机的亲和性为 1，这意味着每个主机运行每个容器类型的一个实例。

如果您正在部署独立的 Object Storage (swift) 环境，您可以跳过 RabbitMQ 的部署。如果您使用此配置，您的 openstack_user_config.yml 文件将如下所示

shared-infra_hosts:
  infra1:
    affinity:
      rabbit_mq_container: 0
    ip: 172.29.236.101
  infra2:
    affinity:
      rabbit_mq_container: 0
    ip: 172.29.236.102
  infra3:
    affinity:
      rabbit_mq_container: 0
    ip: 172.29.236.103

此配置在每个主机上部署一个 Memcached 容器和一个数据库容器，但不部署任何 RabbitMQ 容器。

从部署中省略服务或组件¶

要从部署中省略组件，可以使用以下几种选项

通过删除位于 env.d/ 目录中的相关文件，删除容器组和主机组之间的 physical_skel 链接。
不要运行安装该组件的 playbook。除非您使用 is_metal 属性直接在主机上运行该组件，否则将为此组件创建一个容器。
将添加虚拟嵌套组调整为主机组的 0。与此处列出的第二个选项类似，除非您使用 is_metal 属性直接在主机上运行该组件，否则将为此组件创建一个容器。

SSH 网络与 OpenStack 管理网络不同¶

在某些环境中，用于从部署主机访问节点的 SSH 网络与管理网络不同。在这种情况下，重要的是服务正在侦听正确的网络，同时确保 Ansible 使用 SSH 网络来访问受管主机。在这些情况下，您可以在 openstack_user_config.yml 文件中定义主机时定义 management_ip 键。

management_ip 将用作节点的 management_address，而 ip 将用作通过 SSH 访问节点的 ansible_host。

示例

shared-infra_hosts:
  infra1:
    ip: 192.168.0.101
    management_ip: 172.29.236.101

配置库存

配置清单¶

介绍¶

配置约束¶

组别成员关系¶

lxc_hosts 组¶

直接部署到主机¶

示例：在金属上运行所有控制器¶

示例：在专用主机上运行 Galera¶

添加虚拟嵌套组¶

示例：定义可用区¶

每个主机没有组件类型（或多个组件类型）的部署¶

从部署中省略服务或组件¶

SSH 网络与 OpenStack 管理网络不同¶

openstack-ansible 32.0.0.0rc2.dev9

页面内容