Kolla Ansible 配置¶

Kayobe 严重依赖 Kolla Ansible 来部署 OpenStack 控制平面。Kolla Ansible 安装在 Ansible 控制主机上（即执行 Kayobe 命令的主机），并且 Kolla Ansible 命令从那里执行。

Kolla Ansible 配置存储在 ${KAYOBE_CONFIG_PATH}/kolla.yml 中。

Ansible 配置¶

Ansible 配置在 Ansible 文档中有详细描述。除了标准位置之外，Kayobe 还支持使用位于 Kayobe 配置中的 Ansible 配置文件，即 ${KAYOBE_CONFIG_PATH}/kolla/ansible.cfg 或 ${KAYOBE_CONFIG_PATH}/ansible.cfg。请注意，如果指定了 ANSIBLE_CONFIG 环境变量，则它优先于此文件。

Kolla Ansible 安装¶

在部署容器之前，Kolla Ansible 及其依赖项将安装在 Ansible 控制主机上。以下变量会影响 Kolla Ansible 的安装

kolla_ansible_ctl_install_type: Kolla Ansible 控制安装的类型。可以是 binary（PyPI）或 source（git）。默认值为 source。
kolla_ansible_source_url: 如果类型为 source，则 Kolla Ansible 源代码仓库的 URL。默认值为 https://opendev.org/openstack/kolla-ansible。
kolla_ansible_source_version: 如果类型为 source，则 Kolla Ansible 源代码仓库的版本（分支、标签等）。默认值与 Kayobe 上游分支相同。
kolla_ansible_venv_extra_requirements: 要在 Kolla Ansible 虚拟环境中安装的额外依赖项。默认值为空列表。
kolla_upper_constraints_file: Kolla 安装的上层约束文件。默认值为 {{ pip_upper_constraints_file }}，其默认值为 https://releases.openstack.org/constraints/upper/{{ openstack_branch }}。

示例：自定义 git 仓库¶

要从自定义 git 仓库安装 Kolla Ansible

$KAYOBE_CONFIG_PATH/kolla.yml¶

kolla_ansible_source_url: https://git.example.com/kolla-ansible
kolla_ansible_source_version: downstream

虚拟环境额外需求¶

可以安装额外的 Python 包到 Kolla Ansible 虚拟环境中，例如当 Ansible 插件需要时。

例如，要使用 hashi_vault Ansible lookup 插件，可以使用以下方法安装其 hvac 依赖项

$KAYOBE_CONFIG_PATH/kolla.yml¶

---
# Extra requirements to install inside the Kolla Ansible virtualenv.
kolla_ansible_venv_extra_requirements:
  - "hvac"

本地环境¶

以下变量会影响 Ansible 控制主机上的本地环境。它们引用环境变量，应使用这些环境变量进行配置，而不是直接修改 Ansible 变量。 kayobe-config git 仓库中的 kayobe-env 文件基于推荐的环境目录结构为这些变量设置了一些合理的默认值。

kolla_ansible_source_path: Kolla Ansible 源代码检出目录的路径。默认值为 $KOLLA_SOURCE_PATH 或 $PWD/src/kolla-ansible。
kolla_ansible_venv: 在 Ansible 控制主机上安装 Kolla Ansible 的虚拟环境的路径。默认值为 $KOLLA_VENV_PATH 或 $PWD/venvs/kolla-ansible。
kolla_config_path: Kolla Ansible 配置文件目录的路径。默认值为 $KOLLA_CONFIG_PATH 或 /etc/kolla。

全局配置¶

以下变量是全局变量，会影响所有容器。它们用于生成 Kolla Ansible 配置文件 globals.yml，并影响 Kolla 镜像构建配置。

Kolla 镜像¶

以下变量会影响使用的 Kolla 镜像以及访问方式。

kolla_base_distro: Kolla 基本容器镜像发行版。默认值为 {{ os_distribution }}。
kolla_base_distro_version: Kolla 基本容器镜像发行版版本。默认值取决于 kolla_base_distro。
kolla_docker_registry: 用于 Kolla 镜像的 docker 仓库的 URL。默认值未设置，在这种情况下将使用 Quay.io。
kolla_docker_namespace: Kolla 镜像使用的 Docker 命名空间。默认值为 kolla。
kolla_docker_registry_username: 用于访问 docker 仓库的用户名。默认值未设置，在这种情况下将使用不带身份验证的仓库。
kolla_docker_registry_password: 用于访问 docker 仓库的密码。默认值未设置，在这种情况下将使用不带身份验证的仓库。
kolla_openstack_release: Kolla OpenStack 发布版本。这应该是一个 Docker 镜像标签。默认值为 {{ openstack_release }}，它在稳定分支和已标记的发布版上获取 OpenStack 发布名称（例如 rocky），或在 Kayobe master 分支上获取 master。

例如，要部署 Kolla rocky 镜像，命名空间为 example，私有 Docker 仓库位于 registry.example.com:4000，以及 zed 发布版。

$KAYOBE_CONFIG_PATH/kolla.yml¶

kolla_base_distro: rocky
kolla_docker_namespace: example
kolla_docker_registry: registry.example.com:4000
kolla_openstack_release: zed

部署的 ironic-api 镜像将如下所示

registry.example.com:4000/example/ironic-api:zed-rocky-9

Ansible¶

以下变量会影响 Ansible 访问远程主机的方式。

kolla_ansible_user: 用于 Kolla SSH 访问的用户帐户。默认值为 kolla。
kolla_ansible_group: Kolla SSH 用户的首要组。默认值为 kolla。
kolla_ansible_become: 是否对通过 Kolla Ansible 执行的所有操作使用权限提升。默认值为 false，自 8.0.0 Ussuri 发布版以来。
kolla_ansible_target_venv: 远程主机上用于 Ansible 模块执行的虚拟环境的路径。默认值为 {{ virtualenv_path }}/kolla-ansible。可以设置为 None 以使用系统 Python 解释器。

上下文：远程执行环境¶

默认情况下，Ansible 执行模块远程使用系统 python 解释器，即使 Ansible 控制进程是从虚拟环境中执行的（除非使用 local 连接插件）。如果必须与系统 python 包隔离安装 python 依赖项，则这不是理想的选择。可以通过将主机变量 ansible_python_interpreter 设置为现有虚拟环境中 python 解释器的路径来配置 Ansible 以使用虚拟环境。

变量 kolla_ansible_target_venv 配置远程主机上虚拟环境的使用。默认配置在大多数情况下都应该有效。

用户帐户创建¶

自 Ussuri 发布版以来，Kayobe 创建用于 Kolla Ansible 的用户帐户，而不是在 Kolla Ansible 的 bootstrap-servers 命令期间完成此操作。此工作流程与 Ansible fact 缓存更加兼容，但这意味着不能使用 Kolla Ansible 的 create_kolla_user 变量来禁用用户帐户的创建。而是将 kolla_ansible_create_user 设置为 false。

kolla_ansible_create_user: 是否创建用户帐户、配置无密码 sudo 并授权 SSH 密钥用于 Kolla Ansible。默认值为 true。

OpenStack 日志记录¶

以下变量会影响 OpenStack 调试日志记录。

kolla_openstack_logging_debug: 是否为 OpenStack 服务启用调试日志记录。默认值为 false。

示例：启用调试日志记录¶

在某些情况下，可能需要为所有 OpenStack 服务启用调试日志记录。通常不建议在生产环境中这样做。

$KAYOBE_CONFIG_PATH/kolla.yml¶

---
kolla_openstack_logging_debug: true

API 地址¶

注意

应使用以下变量，而不是已弃用的 vip_address 和 fqdn 网络属性。

以下变量会影响外部和内部 API 使用的地址。

kolla_internal_vip_address: OpenStack 内部 API 的虚拟 IP 地址。默认值为内部网络的 vip_address 属性。
kolla_internal_fqdn: OpenStack 内部 API 的完全限定域名 (FQDN)。默认值为内部网络的 fqdn 属性（如果已设置），否则为 kolla_internal_vip_address。
kolla_external_vip_address: OpenStack 外部 API 的虚拟 IP 地址。默认值为外部网络的 vip_address 属性。
kolla_external_fqdn: OpenStack 外部 API 的完全限定域名 (FQDN)。默认值为外部网络的 fqdn 属性（如果已设置），否则为 kolla_external_vip_address。

API 的 TLS 加密¶

以下变量会影响公共 API 的 TLS 加密。

kolla_enable_tls_external: 是否为公共 API 端点启用 TLS。默认值为 no。
kolla_external_tls_cert: 如果 kolla_enable_tls_external 为 true，则用于公共 API 端点的 TLS 证书包。请注意，这应格式化为字面量样式块标量。

以下变量会影响内部 API 的 TLS 加密。目前，这需要构建所有 Kolla 镜像，使其信任 API 的根 CA。

kolla_enable_tls_internal: 是否为内部 API 端点启用 TLS。默认值为 no。
kolla_internal_tls_cert: 如果 kolla_enable_tls_internal 为 true，则用于内部 API 端点的 TLS 证书包。请注意，这应格式化为字面量样式块标量。

以下变量会影响生成的 admin-openrc.sh 和 public-openrc.sh 环境变量文件。

kolla_public_openrc_cacert: 当 TLS 启用时，用于 public-openrc.sh 文件中 OS_CACERT 环境变量的 CA 证书文件的路径，而不是 kolla_admin_openrc_cacert。
kolla_admin_openrc_cacert: 当 TLS 启用时，用于 admin-openrc.sh 和 public-openrc.sh 文件中 OS_CACERT 环境变量的 CA 证书文件的路径，而不是 Kolla Ansible 的默认值。

示例：启用公共 API 的 TLS¶

强烈建议使用 TLS 加密来保护公共 API。这是一个示例

$KAYOBE_CONFIG_PATH/kolla.yml¶

---
kolla_enable_tls_external: yes
kolla_external_tls_cert: |
  -----BEGIN CERTIFICATE-----
  ...
  -----END CERTIFICATE-----
kolla_admin_openrc_cacert: /path/to/ca/certificate/bundle

示例：启用内部 API 的 TLS¶

强烈建议使用 TLS 加密来保护内部 API。这是一个示例

$KAYOBE_CONFIG_PATH/kolla.yml¶

---
kolla_enable_tls_internal: yes
kolla_internal_tls_cert: |
  -----BEGIN CERTIFICATE-----
  ...
  -----END CERTIFICATE-----
kolla_admin_openrc_cacert: /path/to/ca/certificate/bundle

其他证书¶

通常，Kolla Ansible 期望证书位于通过 kolla_certificates_dir 配置的目录中，默认情况下，该目录名为 certificates，与 globals.yml 位于同一目录。Kayobe 遵循此模式，并将添加到 ${KAYOBE_CONFIG_PATH}/kolla/certificates/ 的文件和目录传递给 Kolla Ansible。这在启用后端 API TLS 加密或提供要添加到容器信任存储中的自定义 CA 证书时非常有用。也可以使用此路径提供外部或内部 API 的证书捆绑包，作为 kolla_external_tls_cert 和 kolla_internal_tls_cert 的替代方案。

请注意，如果 Ansible Vault 对这些文件进行了加密并且 Ansible 可以访问 Vault 密码，Ansible 将自动解密这些文件。

示例：将受信任的自定义 CA 证书添加到容器¶

在具有私有 CA 的环境中，可能需要将根 CA 证书添加到容器的信任存储中。

$KAYOBE_CONFIG_PATH¶

kolla/
  certificates/
    ca/
      private-ca.crt

这些文件应采用 PEM 格式，并具有 .crt 扩展名。

示例：添加后端 TLS 证书¶

Kolla Ansible 后端 TLS 可用于提供 API 流量的端到端加密。

$KAYOBE_CONFIG_PATH¶

kolla/
  certificates/
    backend-cert.pem
    backend-key.pem

有关如何提供服务和/或主机特定证书和密钥的信息，请参阅 Kolla Ansible 文档。

自定义全局变量¶

Kolla Ansible 使用单个文件来存储全局变量，即 globals.yml。Kayobe 为所有必需变量和此文件中许多最常用的变量提供配置变量。其中一些变量位于 $KAYOBE_CONFIG_PATH/kolla.yml 中，其他变量则由网络配置等其他来源确定，例如 $KAYOBE_CONFIG_PATH/networks.yml。

可以通过创建 $KAYOBE_CONFIG_PATH/kolla/globals.yml 来提供额外的全局配置。此文件中的变量将使用 Jinja2 进行模板化，并与 Kayobe globals.yml 配置合并。

示例：为每个镜像使用特定的标签¶

为了对镜像进行更细粒度的控制，Kolla Ansible 允许为每个镜像定义一个标签。例如，对于 nova-api

$KAYOBE_CONFIG_PATH/kolla/globals.yml¶

---
# Use a custom tag for the nova-api container image.
nova_api_tag: v1.2.3

示例：为每个服务启用调试日志¶

全局启用调试日志可能会产生大量的额外日志。通常我们只对特定的服务感兴趣。例如，要为 Nova 服务启用调试日志

$KAYOBE_CONFIG_PATH/kolla/globals.yml¶

---
nova_logging_debug: true

主机变量¶

Kayobe 为 Kolla Ansible 库存中的每个主机生成一个 host_vars 文件。这些文件包含网络接口和其他主机特定信息。一些 Kayobe Ansible 变量会传递给 Kolla Ansible，如以下变量定义。默认变量集通常应保持不变。可以通过 *_extra 变量传递额外的变量，如下所述。如果传递的变量未为某个主机定义，则会被忽略。

kolla_seed_inventory_pass_through_host_vars

如果设置，则将 Kayobe 主机中的主机变量名称列表传递给 Kolla Ansible seed 主机。请参阅 kolla_seed_inventory_pass_through_host_vars_map。默认值为

kolla_seed_inventory_pass_through_host_vars:
  - "ansible_host"
  - "ansible_port"
  - "ansible_ssh_private_key_file"
  - "kolla_api_interface"
  - "kolla_bifrost_network_interface"

可以通过 kolla_seed_inventory_pass_through_host_vars_extra 扩展此列表。

kolla_seed_inventory_pass_through_host_vars_map

将 kolla_seed_inventory_pass_through_host_vars 中的变量名称映射到 Kolla Ansible 中使用的变量的字典。如果变量名称未在此映射中，则使用 kayobe 名称。默认值为

kolla_seed_inventory_pass_through_host_vars_map:
  kolla_api_interface: "api_interface"
  kolla_bifrost_network_interface: "bifrost_network_interface"

可以通过 kolla_seed_inventory_pass_through_host_vars_map_extra 扩展此字典。

kolla_overcloud_inventory_pass_through_host_vars

如果设置，则将 Kayobe 主机中的主机变量名称列表传递给 Kolla Ansible 主机。请参阅 kolla_overcloud_inventory_pass_through_host_vars_map。默认值为

kolla_overcloud_inventory_pass_through_host_vars:
  - "ansible_host"
  - "ansible_port"
  - "ansible_ssh_private_key_file"
  - "kolla_network_interface"
  - "kolla_api_interface"
  - "kolla_storage_interface"
  - "kolla_cluster_interface"
  - "kolla_swift_storage_interface"
  - "kolla_swift_replication_interface"
  - "kolla_provision_interface"
  - "kolla_inspector_dnsmasq_interface"
  - "kolla_dns_interface"
  - "kolla_tunnel_interface"
  - "kolla_external_vip_interface"
  - "kolla_neutron_external_interfaces"
  - "kolla_neutron_bridge_names"
  - "kolla_neutron_physical_networks"

可以通过 kolla_overcloud_inventory_pass_through_host_vars_extra 扩展此列表。

kolla_overcloud_inventory_pass_through_host_vars_map

将 kolla_overcloud_inventory_pass_through_host_vars 中的变量名称映射到 Kolla Ansible 中使用的变量的字典。如果变量名称未在此映射中，则使用 Kayobe 名称。默认值为

kolla_overcloud_inventory_pass_through_host_vars_map:
  kolla_network_interface: "network_interface"
  kolla_api_interface: "api_interface"
  kolla_storage_interface: "storage_interface"
  kolla_cluster_interface: "cluster_interface"
  kolla_swift_storage_interface: "swift_storage_interface"
  kolla_swift_replication_interface: "swift_replication_interface"
  kolla_provision_interface: "provision_interface"
  kolla_inspector_dnsmasq_interface: "ironic_dnsmasq_interface"
  kolla_dns_interface: "dns_interface"
  kolla_tunnel_interface: "tunnel_interface"
  kolla_neutron_external_interfaces: "neutron_external_interface"
  kolla_neutron_bridge_names: "neutron_bridge_name"
  kolla_neutron_physical_networks: "neutron_physical_networks"

可以通过 kolla_overcloud_inventory_pass_through_host_vars_map_extra 扩展此字典。

示例：传递一个额外的主机变量¶

在此示例中，我们将名为 my_kayobe_var 的变量从 Kayobe 传递到 Kolla Ansible。

$KAYOBE_CONFIG_PATH/kolla.yml¶

kolla_overcloud_inventory_pass_through_host_vars_extra:
  - my_kayobe_var

此变量可能在 Kayobe 库存中定义，例如：

$KAYOBE_CONFIG_PATH/inventory/host_vars/controller01¶

my_kayobe_var: foo

然后，可以在 $KAYOBE_CONFIG_PATH/kolla/globals.yml、Kolla Ansible 组变量或 Kolla Ansible 自定义服务配置中引用该变量。

如果变量需要在 Kolla Ansible 中使用不同的名称，请使用 kolla_overcloud_inventory_pass_through_host_vars_map_extra

$KAYOBE_CONFIG_PATH/kolla.yml¶

kolla_overcloud_inventory_pass_through_host_vars_map_extra:
  my_kayobe_var: my_kolla_ansible_var

自定义 Kolla 库存¶

在运行 Kolla Ansible playbook 时，kayobe 将检查以下位置中是否有任何自定义库存

${KAYOBE_CONFIG_PATH}/kolla/inventory/
${KAYOBE_CONFIG_PATH}/environments/<environment>/kolla/inventory/
- 仅与多环境功能一起使用

这些文件在 kayobe 生成 Kolla Ansible 配置时会被复制。副本作为附加库存传递给 Ansible，以运行任何 Kolla Ansible playbook。不执行任何模板化或额外的预处理。因此，此目录必须是有效的 Ansible 库存，除了忽略 *.j2 文件以与自定义 Kolla Ansible 库存模板保持兼容。

可以使用组变量为组中的所有主机设置配置。它们可以通过将文件放置在 Kolla Ansible 的 ${KAYOBE_CONFIG_PATH}/kolla/inventory/group_vars/* 中来设置。由于此目录直接复制到 Kolla Ansible 库存中，因此应使用 Kolla Ansible 组名称。应注意，extra-vars 和 host_vars 优先于 group_vars。有关变量优先级，请参阅 Ansible 文档。

示例：配置 Nova cell¶

在 Kolla Ansible 中，Nova cell 通过组变量进行配置。例如，要配置 cell0001，可以创建以下文件

$KAYOBE_CONFIG_PATH/kolla/inventory/group_vars/cell0001/all¶

---
nova_cell_name: cell0001
nova_cell_novncproxy_group: cell0001-vnc
nova_cell_conductor_group: cell0001-control
nova_cell_compute_group: cell0001-compute

密码¶

Kolla Ansible 会自动将密码生成到文件中，即 passwords.yml。Kayobe 处理此过程，以及使用在 KAYOBE_VAULT_PASSWORD 环境变量中指定的 Ansible Vault 密码对文件进行加密（如果存在）。该文件生成到 $KAYOBE_CONFIG_PATH/kolla/passwords.yml，应与其他 Kayobe 配置文件一起存储。不应手动修改此文件。

配置自定义密码¶

使用以下变量配置自定义密码

kolla_ansible_default_custom_passwords：Kolla Ansible 所需的默认自定义密码字典。包含由 Kolla 用户在 Kolla 主机上授权的 SSH 密钥、由 Bifrost 部署的主机中授权的 SSH 密钥、Docker Registry 密码和 compute libVirt 自定义密码。
kolla_ansible_extra_custom_passwords：包含要添加到 Kolla 密码文件或覆盖 Kolla 密码文件的额外自定义密码的字典。默认情况下为空字典。
kolla_ansible_custom_passwords：包含要添加到 Kolla 密码文件或覆盖 Kolla 密码文件的自定义密码的字典。默认情况下是 kolla_ansible_default_custom_passwords 和 kolla_ansible_extra_custom_passwords 的组合。

在此示例中，我们添加了自己的 my_custom_password 并覆盖 keystone_admin_password

$KAYOBE_CONFIG_PATH/kolla.yml¶

---
# Dictionary containing extra custom passwords to add or override in the
# Kolla passwords file.
kolla_ansible_extra_custom_passwords:
  my_custom_password: 'correcthorsebatterystaple'
  keystone_admin_password: 'superduperstrongpassword'

控制平面服务¶

Kolla Ansible 提供了一种灵活的机制来配置其部署的服务。Kayobe 会将一些常用配置选项添加到 Kolla Ansible 提供的默认配置中，但同时也允许使用 Kolla Ansible 支持的自由形式配置。Kolla Ansible 文档应该用作参考。

启用服务¶

Kolla Ansible 部署的服务通过标志启用。

kolla_enable_<service 或 feature>: 可以使用各种标志来启用功能。这些标志映射到 Kolla Ansible 中名为 enable_<service 或 feature> 的变量。默认启用的服务和功能的集合与 Kolla ansible 相同，除了 Kayobe 中默认启用 Ironic。

示例：启用服务¶

一个常见任务是启用新的 OpenStack 服务。这可以通过 kolla_enable_* 标志来完成，例如

$KAYOBE_CONFIG_PATH/kolla.yml¶

---
kolla_enable_swift: true

请注意，在某些情况下，可能需要额外的配置才能成功部署服务 - 请检查 Kolla Ansible 配置参考。

服务配置¶

Kolla-ansible 的灵活配置在 Kolla Ansible 服务配置文档中进行了描述。我们不会在这里重复，但基本上它涉及在 kayobe 用户将创建文件的目录中创建文件，即 $KOLLA_CONFIG_PATH/config。在 kayobe 中，这些文件是自动生成的并由 kayobe 管理。相反，用户应在 $KAYOBE_CONFIG_PATH/kolla/config 中使用相同的目录结构创建文件。这些文件将使用 Jinja2 进行模板化，与 kayobe 自己的配置合并，并写入 $KOLLA_CONFIG_PATH/config。

如果存在以下文件，将对其进行模板化并提供给 Kolla Ansible。所有路径都相对于 $KAYOBE_CONFIG_PATH/kolla/config。请注意，通常 Kolla Ansible 不使用相同的通配符模式，并且对将处理的文件集有更严格的限制。在某些情况下，可能需要检查 Kolla Ansible 配置任务以确定支持哪些文件。

Kolla-ansible 配置文件¶
文件	目的
`aodh.conf`	Aodh 配置。
`aodh/*`	扩展的 Aodh 配置。
`backup.my.cnf`	Mariabackup 配置。
`barbican.conf`	Barbican 配置。
`barbican/*`	扩展的 Barbican 配置。
`blazar.conf`	Blazar 配置。
`blazar/*`	扩展的 Blazar 配置。
`ceilometer.conf`	Ceilometer 配置。
`ceilometer/*`	扩展的 Ceilometer 配置。
`cinder.conf`	Cinder 配置。
`cinder/*`	扩展的 Cinder 配置。
`cloudkitty.conf`	CloudKitty 配置。
`cloudkitty/*`	扩展的 CloudKitty 配置。
`designate.conf`	Designate 配置。
`designate/*`	扩展的 Designate 配置。
`fluentd/filter`	Fluentd 过滤器配置。
`fluentd/input`	Fluentd 输入配置。
`fluentd/output`	Fluentd 输出配置。
`galera.cnf`	MariaDB 配置。
`glance.conf`	Glance 配置。
`glance/*`	扩展的 Glance 配置。
`global.conf`	所有 OpenStack 服务的全局配置。
`gnocchi.conf`	Gnocchi 配置。
`gnocchi/*`	扩展的 Gnocchi 配置。
`grafana.ini`	Grafana 配置。
`grafana/*`	扩展的 Grafana 配置。
`haproxy/*`	主要的 HAProxy 配置。
`haproxy-config/*`	模块化的 HAProxy 配置。
`heat.conf`	Heat 配置。
`heat/*`	扩展的 Heat 配置。
`horizon/*`	扩展的 horizon 配置。
`influx*`	InfluxDB 配置。
`ironic.conf`	Ironic 配置。
`ironic/*`	扩展的 ironic 配置。
`keepalived/*`	扩展的 keepalived 配置。
`keystone.conf`	Keystone 配置。
`keystone/*`	扩展的 keystone 配置。
`magnum.conf`	Magnum 配置。
`magnum/*`	扩展的 magnum 配置。
`manila.conf`	Manila 配置。
`manila/*`	扩展的 manila 配置。
`mariadb/*`	扩展的 MariaDB 配置。
`masakari.conf`	Masakari 配置。
`masakari/*`	扩展的 masakari 配置。
`multipath.conf`	Multipathd 配置。
`neutron.conf`	Neutron 配置。
`neutron/ml2_conf.ini`	Neutron ML2 配置。
`neutron/*`	扩展的 neutron 配置。
`nova.conf`	Nova 配置。
`nova/*`	扩展的 nova 配置。
`octavia.conf`	Octavia 配置。
`octavia/*`	扩展的 Octavia 配置。
`opensearch/*`	OpenSearch 配置。
`placement.conf`	Placement 配置。
`placement/*`	扩展的 Placement 配置。
`prometheus/*`	Prometheus 配置。
`swift/*`	扩展的 swift 配置。
`telegraf/*`	扩展的 Telegraf 配置。

配置 OpenStack 组件¶

为了向所有 glance 服务应用自定义配置，请创建 $KAYOBE_CONFIG_PATH/kolla/config/glance.conf。例如

$KAYOBE_CONFIG_PATH/kolla/config/glance.conf¶

[DEFAULT]
api_limit_max = 500

配置 OpenStack 服务¶

为了向 glance API 服务提供自定义配置，请创建 $KAYOBE_CONFIG_PATH/kolla/config/glance/glance-api.conf。例如

$KAYOBE_CONFIG_PATH/kolla/config/glance/glance-api.conf¶

[DEFAULT]
api_limit_max = 500

Kolla Ansible 配置

Kolla Ansible 配置¶

Ansible 配置¶

Kolla Ansible 安装¶

示例：自定义 git 仓库¶

虚拟环境额外需求¶

本地环境¶

全局配置¶

Kolla 镜像¶

Ansible¶

上下文：远程执行环境¶

用户帐户创建¶

OpenStack 日志记录¶

示例：启用调试日志记录¶

API 地址¶

API 的 TLS 加密¶

示例：启用公共 API 的 TLS¶

示例：启用内部 API 的 TLS¶

其他证书¶

示例：将受信任的自定义 CA 证书添加到容器¶

示例：添加后端 TLS 证书¶

自定义全局变量¶

示例：为每个镜像使用特定的标签¶

示例：为每个服务启用调试日志¶

主机变量¶

示例：传递一个额外的主机变量¶

自定义 Kolla 库存¶

示例：配置 Nova cell¶

密码¶

配置自定义密码¶

控制平面服务¶

启用服务¶

示例：启用服务¶

服务配置¶

配置 OpenStack 组件¶

配置 OpenStack 服务¶

kayobe 19.0.1.dev2

页面内容