[ English | Deutsch | русский | English (United Kingdom) ]

Переопределение конфигурации по умолчанию

Переменный приоритет

Значения по умолчанию для роли

У каждой роли есть файл defaults/main.yml, который содержит обычные переменные, которые может переопределять оператор, как и обычная роль Ansible. Эти значения по умолчанию максимально приближены к стандартам OpenStack.

Их можно переопределить на нескольких уровнях.

Групповые переменные и переменные хоста

OpenStack-Ansible предоставляет безопасные значения по умолчанию для развертывателей в своей папке group_vars. Они заботятся о связях между различными ролями, например, хранят информацию о том, как получить доступ к RabbitMQ из роли nova.

Вы можете переопределить существующие групповые переменные (и переменные хоста), создав собственную папку в /etc/openstack_deploy/group_vars (и /etc/openstack_deploy/host_vars соответственно).

Если вы хотите изменить расположение папки переопределения, вы можете адаптировать файл openstack-ansible.rc или экспортировать GROUP_VARS_PATH и HOST_VARS_PATH во время shell сессии.

Переменные роли

Каждая роль использует дополнительные переменные в vars/, которые имеют приоритет над групповыми переменными.

Эти переменные обычно являются внутренними для роли и не предназначены для переопределения. Однако разработчики могут переопределить их с помощью extra-vars, поместив переопределения в файл пользовательских переменных.

Пользовательские переменные

Если вы хотите глобально переопределить переменную, вы можете назначить переменную, которую хотите переопределить, в файле /etc/openstack_deploy/user_*.yml. Это будет применено ко всем хостам.

Подробнее про файлы user_*.yml

Файлы в /etc/openstack_deploy, начинающиеся с user_, будут автоматически получены в любой команде openstack-ansible. В качестве альтернативы файлы могут быть получены с помощью параметра -e команды ansible-playbook.

user_variables.yml и user_secrets.yml используются непосредственно OpenStack-Ansible. Не рекомендуется добавлять в эти файлы пользовательские переменные, используемые вашими собственными ролями и сценариями. Это усложнит ваш путь обновления, сделав сравнение ваших существующих файлов с более поздними версиями этих файлов более трудным. Вместо этого рекомендуемая практика заключается в том, чтобы помещать ваши собственные переменные в файлы, названные по шаблону user_*.yml, чтобы они были получены вместе с теми, которые используются исключительно OpenStack-Ansible.

Файлы user_*.yml содержат переменные YAML, которые применяются как extra-vars при выполнении openstack-ansible для запуска плейбуков. Они будут получены в алфавитно-цифровом порядке openstack-ansible. Если в файлах user_*.yml встречаются дублирующиеся переменные, то приоритет будет иметь переменная в последнем прочитанном файле.

Установка переопределений в файлах конфигурации с помощью config_template

Все службы, использующие YAML, JSON или INI для конфигурации, могут получать переопределения с помощью плагина действия Ansible с именем config_template. Механизм шаблонов конфигурации позволяет операторы использовать простой словарь для изменения или добавления элементов в файлы конфигурации во время выполнения, которые могут не иметь предустановленного шаблона. Все роли 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:' {} \
    | egrep -v "^#|^\s" \
    | sort -u

Примечание

Возможные дополнительные переопределения можно найти в «Настраиваемом разделе» файла main.yml каждой роли, например /etc/ansible/roles/role_name/defaults/main.yml.

Переопределение настроек OpenStack по умолчанию

OpenStack имеет множество параметров конфигурации, доступных в файлах .conf (в стандартном формате INI), файлах политик (в стандартном формате JSON) и файлах YAML, и поэтому может использовать модуль config_template, описанный выше.

OpenStack-Ansible позволяет ссылаться на любые параметры в Справочнике по конфигурации OpenStack с помощью простого набора записей конфигурации в /etc/openstack_deploy/user_variables.yml.

Переопределение файлов .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

Используйте этот метод для любых файлов формата INI в проектах OpenStack, развернутых в OpenStack-Ansible.

Переопределение файлов .json

Для реализации контроля доступа, отличающегося от стандартного в среде OpenStack, можно настроить политики по умолчанию, применяемые службами. Файлы политик находятся в формате JSON.

Например, вы можете добавить следующую политику в файл policy.json для службы идентификации (keystone):

{
    "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. Например, имя переменной, используемое в этом примере для добавления политики в файл policy.json службы идентификации (keystone) - keystone_policy_overrides.

Используйте этот метод для любых файлов формата JSON в проектах OpenStack, развернутых в OpenStack-Ansible.

Чтобы помочь вам найти подходящее имя переменной для переопределений, общий формат имени переменной <service>_policy_overrides.

Переопределение файлов .yml

Вы можете переопределить значения файла .yml, указав заменяющее содержимое YAML.

Примечание

Все содержимое файла YAML по умолчанию полностью перезаписывается переопределениями, поэтому необходимо предоставить весь исходный файл YAML (как существующее содержимое, так и ваши изменения).

Например, вы можете захотеть определить исключение счетчика для всех элементов оборудования в содержимом по умолчанию файла pipeline.yml для службы телеметрии (ceilometer):

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. Например, имя переменной, используемое в этом примере для определения исключения счетчика в файле pipeline.yml для службы телеметрии (ceilometer) - ceilometer_pipeline_yaml_overrides.

Переопределение ограничений версий пакетов OpenStack

Каждый релиз OpenStack использует файл upper-constraints.txt для определения максимально допустимой версии каждого пакета Python. В некоторых случаях может потребоваться переопределить этот файл, например, когда локальное развертывание должно воспользоваться исправлением ошибки. При изменении этого файла следует соблюдать осторожность, поскольку службы OpenStack могли не быть протестированы с более поздними версиями пакетов.

Чтобы переопределить ограничения версий пакетов для развертывания, клонируйте репозиторий git требований OpenStack, либо сохранив его как форк по URL-адресу по вашему выбору, либо в локальной файловой системе хоста, который вы используете для развертывания OpenStack Ansible. После клонирования переключитесь на ветку, которая соответствует имени вашей развернутой версии OpenStack, и измените ограничения по мере необходимости.

Далее отредактируйте файл /etc/openstack_deploy/user_variables.yml, чтобы указать путь к репозиторию git требований и хэш git коммита, содержащего ваши изменения, используя переменные requirements_git_repo и requirements_git_install_branch. При использовании локальной файловой системы requirements_git_repo должен начинаться с file://.

Наконец, запустите сценарий repo-install.yml, чтобы загрузить эти измененные ограничения на хост(ы) вашего репозитория.