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

覆盖默认配置¶

变量优先级¶

角色默认值¶

每个角色都有一个文件，defaults/main.yml，其中包含可被部署者覆盖的常用变量，就像一个普通的 Ansible 角色一样。这些默认值尽可能地接近 OpenStack 标准。

它们可以在多个级别被覆盖。

组变量和主机变量¶

OpenStack-Ansible 在其 group_vars 文件夹中为部署者提供安全的默认值。它们负责不同角色之间的连接，例如存储有关如何从 nova 角色访问 RabbitMQ 的信息。

您可以通过在 /etc/openstack_deploy/group_vars（和 /etc/openstack_deploy/host_vars 分别）中创建自己的文件夹来覆盖现有的组变量（和主机变量）。

如果您想更改覆盖文件夹的位置，可以调整您的 user.rc 文件（有关详细信息，请参阅定义部署环境变量），或在您的 shell 会话期间导出 GROUP_VARS_PATH 和 HOST_VARS_PATH。

角色变量¶

每个角色都在 vars/ 中使用额外的变量，这些变量优先于组变量。

这些变量通常是角色的内部变量，并非设计为被覆盖。但是，部署者可以选择使用 extra-vars 通过将覆盖项放置在用户变量文件中来覆盖它们。

用户变量¶

如果您想全局覆盖变量，可以在 /etc/openstack_deploy/user_*.yml 文件中定义您想要覆盖的变量。它将应用于所有主机。

user_*.yml 文件详解¶

在 /etc/openstack_deploy 中以 user_ 开头的文件将在任何 openstack-ansible 命令中自动被引用。或者，可以使用 ansible-playbook 命令的 -e 参数来引用这些文件。

user_variables.yml 和 user_secrets.yml 由 OpenStack-Ansible 直接使用。将自定义变量（由您自己的角色和 playbook 使用）添加到这些文件中不建议这样做。这样做会使您的升级路径更加复杂，因为比较您现有的文件与这些文件的后续版本会更加困难。相反，推荐的做法是将您自己的变量放在遵循 user_*.yml 模式命名的文件中，以便它们与 OpenStack-Ansible 专用的变量一起被引用。

user_*.yml 文件包含 YAML 变量，这些变量在执行 openstack-ansible 以运行 playbook 时作为 extra-vars 应用。它们将按字母数字顺序被 openstack-ansible 引用。如果在 user_*.yml 文件中出现重复的变量，则最后读取的文件中的变量将优先。

使用 config_template 在配置文件中设置覆盖项¶

所有使用 YAML、JSON 或 INI 进行配置的服务都可以通过名为 config_template 的 Ansible 操作插件接收覆盖项。配置模板引擎允许部署者使用简单的字典来修改或在运行时添加到配置文件中的项目，这些项目可能没有预设的模板选项。所有 OpenStack-Ansible 角色在适用时都允许使用此功能。可以在 defaults/main.yml 文件中查看可用于接收覆盖项的文件，作为标准的空字典（哈希）。

此模块未被接受到 Ansible Core 中（请参阅 PR1 和 PR2），并且永远不会被接受。

config_template 文档¶

这些是在虚拟模块文档部分中找到的可用选项。

module: config_template
version_added: 1.9.2
short_description: >
  Renders template files providing a create/update override interface
description:
  - The module contains the template functionality with the ability to
    override items in config, in transit, through the use of a simple
    dictionary without having to write out various temp files on target
    machines. The module renders all of the potential jinja a user could
    provide in both the template file and in the override dictionary which
    is ideal for deployers who may have lots of different configs using a
    similar code base.
  - The module is an extension of the **copy** module and all of attributes
    that can be set there are available to be set here.
options:
  src:
    description:
      - Path of a Jinja2 formatted template on the local server. This can
        be a relative or absolute path.
    required: true
    default: null
  dest:
    description:
      - Location to render the template to on the remote machine.
    required: true
    default: null
  config_overrides:
    description:
      - A dictionary used to update or override items within a configuration
        template. The dictionary data structure may be nested. If the target
        config file is an ini file the nested keys in the ``config_overrides``
        will be used as section headers.
  config_type:
    description:
      - A string value describing the target config type.
    choices:
      - ini
      - json
      - yaml

使用 config_template 模块的示例任务¶

在此任务中，test.ini.j2 文件是一个将被渲染并写入到 /tmp/test.ini 的模板。**config_overrides** 条目是一个字典（哈希），允许部署者设置任意数据作为在运行时写入配置文件的覆盖项。**config_type** 条目指定模块将与之交互的配置文件的类型；可用选项是“yaml”、“json”和“ini”。

- name: Run config template ini
  config_template:
    src: test.ini.j2
    dest: /tmp/test.ini
    config_overrides: "{{ test_overrides }}"
    config_type: ini

这是一个示例覆盖字典（哈希）

test_overrides:
  DEFAULT:
    new_item: 12345

这是模板文件

[DEFAULT]
value1 = abc
value2 = 123

磁盘上的渲染文件，即 /tmp/test.ini 如下所示

[DEFAULT]
value1 = abc
value2 = 123
new_item = 12345

发现可用的覆盖项¶

所有这些选项都可以以适合您部署的方式指定。就易用性和灵活性而言，建议您将覆盖项定义在用户变量文件中，例如 /etc/openstack_deploy/user_variables.yml。

可以通过执行以下命令找到可用的覆盖项列表

ls /etc/ansible/roles/*/defaults/main.yml -1 \
    | xargs -I {} grep '_.*_overrides:' {} \
    | grep -Ev "^#|^\s" \
    | sort -u

注意

可能的其他覆盖项可以在每个角色的 main.yml 文件的“可调整部分”中找到，例如 /etc/ansible/roles/role_name/defaults/main.yml。

覆盖 OpenStack 配置默认值¶

OpenStack 在 .conf 文件（以标准的 INI 文件格式）、策略文件（以标准的 JSON 文件格式）和 YAML 文件中提供许多配置选项，因此可以使用上述 config_template 模块。

OpenStack-Ansible 允许您通过在 /etc/openstack_deploy/user_variables.yml 中使用一组简单的配置条目来引用 OpenStack 配置参考中的任何选项。

覆盖 .conf 文件¶

最常见的是，覆盖项是为 <service>.conf 文件（例如，nova.conf）实现的。这些文件使用标准的 INI 文件格式。

例如，您可能想将以下参数添加到 nova.conf 文件

[DEFAULT]
remove_unused_original_minimum_age_seconds = 43200

[libvirt]
cpu_mode = host-model
disk_cachemodes = file=directsync,block=none

[database]
idle_timeout = 300
max_pool_size = 10

为此，您在 /etc/openstack_deploy/user_variables.yml 文件中使用以下配置条目

nova_nova_conf_overrides:
  DEFAULT:
    remove_unused_original_minimum_age_seconds: 43200
  libvirt:
    cpu_mode: host-model
    disk_cachemodes: file=directsync,block=none
  database:
    idle_timeout: 300
    max_pool_size: 10

注意

用于覆盖项的变量名的通用格式是 <service>_<filename>_<file extension>_overrides。例如，用于将参数添加到 nova.conf 文件的变量名是 nova_nova_conf_overrides。

您还可以以相同的方式将覆盖项应用于 uwsgi 服务。例如

nova_api_os_compute_uwsgi_ini_overrides:
  uwsgi:
    limit: 1024

注意

一些角色，如 uwsgi，被用于许多角色，并且具有“特殊”覆盖项（如 uwsgi_ini_overrides），这些覆盖项可以定义以影响所有使用 uwsgi 的服务。这些变量是“特殊”的，因为它们将优先于角色定义的 *_uwsgi_ini_overrides。

您还可以使用以下配置在 /etc/openstack_deploy/openstack_user_config.yml 文件中按主机应用覆盖项

compute_hosts:
  900089-compute001:
    ip: 192.0.2.10
    host_vars:
      nova_nova_conf_overrides:
        DEFAULT:
          remove_unused_original_minimum_age_seconds: 43200
        libvirt:
          cpu_mode: host-model
          disk_cachemodes: file=directsync,block=none
        database:
          idle_timeout: 300
          max_pool_size: 10

对于 OpenStack 项目中部署的 OpenStack-Ansible 中的所有具有 INI 格式的文件，请使用此方法。

覆盖 .json 文件¶

为了实现与标准 OpenStack 环境不同的访问控制，您可以调整服务应用的默认策略。策略文件采用 JSON 格式。

例如，您可能想将以下策略添加到 Identity 服务（keystone）的 policy.json 文件中

{
    "identity:foo": "rule:admin_required",
    "identity:bar": "rule:admin_required"
}

为此，您在 /etc/openstack_deploy/user_variables.yml 文件中使用以下配置条目

keystone_policy_overrides:
  identity:foo: "rule:admin_required"
  identity:bar: "rule:admin_required"

注意

用于覆盖项的变量名的通用格式是 <service>_policy_overrides。例如，用于将策略添加到 Identity 服务（keystone）policy.json 文件的变量名是 keystone_policy_overrides。

对于 OpenStack 项目中部署的 OpenStack-Ansible 中的所有具有 JSON 格式的文件，请使用此方法。

为了帮助您找到用于覆盖项的适当变量名，变量名的通用格式是 <service>_policy_overrides。

覆盖 .yml 文件¶

您可以通过提供替换的 YAML 内容来覆盖 .yml 文件值。

注意

所有默认 YAML 文件内容都将被覆盖项完全覆盖，因此必须提供整个 YAML 源代码（包括现有内容和您的更改）。

例如，您可能想为 Telemetry 服务（ceilometer）的 pipeline.yml 文件中定义所有硬件项目的计量排除项

sources:
    - name: meter_source
    interval: 600
    meters:
        - "!hardware.*"
    sinks:
        - meter_sink
    - name: foo_source
    value: foo

为此，您在 /etc/openstack_deploy/user_variables.yml 文件中使用以下配置条目

ceilometer_pipeline_yaml_overrides:
  sources:
      - name: meter_source
      interval: 600
      meters:
          - "!hardware.*"
      sinks:
          - meter_sink
      - name: source_foo
      value: foo

注意

用于覆盖项的变量名的通用格式是 <service>_<filename>_<file extension>_overrides。例如，用于在 Telemetry 服务（ceilometer）的 pipeline.yml 文件中定义计量排除项的变量名是 ceilometer_pipeline_yaml_overrides。

覆盖 OpenStack 上限约束¶

每个 OpenStack 版本都使用一个 upper-constraints.txt 文件来定义每个 Python 包允许的最大版本。在某些情况下，可能需要覆盖此文件，例如当您的本地部署需要利用错误修复时。在修改此文件时应小心，因为 OpenStack 服务可能尚未针对更新的软件包版本进行测试。

要覆盖部署的上限约束，请克隆 OpenStack requirements git 仓库，您可以将其存储为指向您选择的 URL 的 fork，或存储在您用于部署 OpenStack Ansible 的主机的本地文件系统中。克隆后，切换到与您部署的 OpenStack 版本名称匹配的分支，并根据需要修改上限约束。

接下来，编辑您的 /etc/openstack_deploy/user_variables.yml 文件，以使用 requirements_git_repo 和 requirements_git_install_branch 变量指示 requirements git 仓库的路径和包含您更改的 commit 的 git 哈希。当使用本地文件系统时，requirements_git_repo 应该以 file:// 开头。

最后，运行 repo-install.yml playbook 将这些修改后的约束上传到您的 repo 主机。

覆盖默认配置

覆盖默认配置¶

变量优先级¶

角色默认值¶

组变量和主机变量¶

角色变量¶

用户变量¶

user_*.yml 文件详解¶

使用 config_template 在配置文件中设置覆盖项¶

config_template 文档¶

使用 config_template 模块的示例任务¶

发现可用的覆盖项¶

覆盖 OpenStack 配置默认值¶

覆盖 .conf 文件¶

覆盖 .json 文件¶

覆盖 .yml 文件¶

覆盖 OpenStack 上限约束¶

openstack-ansible 32.0.0.0rc2.dev9

页面内容