Файл конфигурации

Получение последней конфигурации
Конфигурация окружения
Описание значений по разделам

Некоторые настройки Ansible можно настроить через файл конфигурации. Стандартной конфигурации должно быть достаточно для большинства пользователей, но могут быть причины, по которым вам захочется их изменить.

Изменения можно внести и использовать в файле конфигурации, который будет обрабатываться в следующем порядке:

* ANSIBLE_CONFIG (an environment variable)
* ansible.cfg (in the current directory)
* .ansible.cfg (in the home directory)
* /etc/ansible/ansible.cfg

До версии 1.5 порядок был:

* ansible.cfg (in the current directory)
* ANSIBLE_CONFIG (an environment variable)
* .ansible.cfg (in the home directory)
* /etc/ansible/ansible.cfg

Ansible обработает указанный выше список и воспользуется первым найденным файлом. Настройки в файлах не объединяются.

Примечание

Комментарии Файл конфигурации — это один из вариантов формата INI. Как знак хэша (“#”), так и точка с запятой (";") допускаются в качестве маркеров комментариев, когда комментарий находится в начале строки. Однако, если комментарий находится в строке вместе с обычными значениями, только точка с запятой может вводить комментарий. Например:

# some basic default values...
inventory = /etc/ansible/hosts  ; This points to the file that lists your hosts

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

Если Ansible устанавливается через менеджер пакетов, последняя ansible.cfg должна быть в каталоге /etc/ansible, возможно, в виде файла «.rpmnew» (или другого) в случае обновлений.

Однако, если вы установили его с помощью pip или из исходного кода, вам может потребоваться создать этот файл для переопределения значений по умолчанию в Ansible.

Вы можете обратиться к файлу ansible.cfg в системе управления версиями для получения всех возможных последних значений.

Конфигурация окружения

Ansible также позволяет настраивать параметры с помощью переменных окружения. Если эти переменные окружения установлены, они переопределяют любые настройки, загруженные из файла конфигурации. Эти переменные определены в constants.py.

Описание значений по разделам

Файл конфигурации разделен на разделы. Большинство опций находятся в разделе «general», но некоторые разделы файла предназначены для определенных типов подключений.

Общие значения по умолчанию

В разделе [defaults] файла ansible.cfg можно настраивать следующие параметры:

action_plugins

Действия — это фрагменты кода в Ansible, которые позволяют выполнять такие операции, как выполнение модулей, шаблонизацию и так далее.

Это функция, ориентированная на разработчиков, которая позволяет загружать расширения низкого уровня Ansible из разных мест:

action_plugins = ~/.ansible/plugins/action_plugins/:/usr/share/ansible_plugins/action_plugins

Большинству пользователей эта функция не потребуется. Подробнее см. Разработка плагинов.

allow_unsafe_lookups

Новая функция с версии 2.2.3,: 2.3.1

При включении этого параметра плагины поиска (используемые в переменных как {{lookup(‘foo’)}} или в цикле как with_foo) могут возвращать данные, которые не помечены как «небезопасные». По умолчанию такие данные помечаются как небезопасные, чтобы предотвратить оценку движком шаблонов любого языка шаблонизации jinja2, так как это может представлять собой угрозу безопасности.

Этот параметр предоставляется для обеспечения обратной совместимости, однако пользователям следует сначала рассмотреть возможность добавления allow_unsafe=True в любые запросы, которые, как ожидается, будут содержать данные, которые могут быть обработаны движком шаблонизации позже. Например:

{{lookup('pipe', '/path/to/some/command', allow_unsafe=True)}}

allow_world_readable_tmpfiles

Новая функция с версии 2.1.

Это делает временные файлы, созданные на машине, доступными для чтения всем пользователям и выводит предупреждение вместо завершения задачи с ошибкой.

Это полезно при переходе к пользователю без привилегий:

allow_world_readable_tmpfiles=True

ansible_managed

Строку ansible_managed можно вставить в файлы, созданные системой шаблонизации конфигурации Ansible:

{{ ansible_managed }}

Значение по умолчанию указывает, что файл управляется Ansible:

ansible_managed = Ansible managed

Эта строка полезна для указания того, что файл не следует изменять напрямую, поскольку Ansible может перезаписывать содержимое файла.

Существует несколько специальных значений заполнителей, которые могут быть помещены в строку ansible_managed . Эти значения не находятся в строке по умолчанию ansible_managed, потому что они могут заставить Ansible вести себя так, как будто изменился весь шаблон, когда изменилась только строка ansible_managed.

Эти значения заполнителей, а также ситуации, которые могут привести к тому, что Ansible сообщит о изменении шаблона при их использовании, перечислены ниже:

Стандартные директивы, которые можно использовать с :func:~time.strftime:. Время относится к времени изменения файла шаблона. Многие системы контроля версий маркируют файлы по времени их извлечения, а не по последнему времени изменения файла. Это означает, что Ansible будет считать, что файл был изменен всякий раз, когда происходит свежая выгрузка.

{file}: расширяется до имени полного пути к файлу шаблона. Если Ansible выполняется с несколькими выгрузками одного и того же репозитория конфигурации (например, в домашнем каталоге каждого системного администратора), то путь будет различаться в каждой выгрузке, заставляя Ansible вести себя так, как будто файл был изменён.
{host}: расширяется до имени хоста, на котором выполняется ansible. Если ansible вызывается на нескольких машинах (например, каждый системный администратор может выгрузить репозиторий конфигурации на свой рабочий стол и запустить ansible там), то хост будет отличаться на каждой из этих машин. Это заставит Ansible вести себя так, как будто файл был изменен.
{uid}: расширяется до владельца файла шаблона. Если Ansible выполняется на выгрузках репозитория конфигурации, созданных разными пользователями (например, если несколько системных администраторов делают выгрузки репозитория со своими учетными записями), это заставит Ansible вести себя так, как будто файл был изменён.

ask_pass

Это управляет тем, будет ли Ansible-playbook по умолчанию запрашивать пароль. Поведение по умолчанию — нет:

ask_pass = True

Если для аутентификации используются SSH-ключи, вероятно, нет необходимости изменять это значение.

ask_sudo_pass

Аналогично ask_pass, это управляет тем, будет ли Ansible-playbook по умолчанию запрашивать пароль sudo при использовании sudo. Поведение по умолчанию также — нет:

ask_sudo_pass = True

Пользователям на платформах, где включены пароли sudo, следует рассмотреть возможность изменения этого параметра.

ask_vault_pass

Это управляет тем, будет ли Ansible-playbook по умолчанию запрашивать пароль хранилища. Поведение по умолчанию — нет:

ask_vault_pass = True

bin_ansible_callbacks

Новая функция с версии 1.8.

Управляет тем, загружаются ли плагины обратного вызова при запуске /usr/bin/ansible. Это может использоваться для регистрации активности из командной строки, отправки уведомлений и т. д. Плагины обратного вызова всегда загружаются для /usr/bin/ansible-playbook, если они присутствуют, и их нельзя отключить:

bin_ansible_callbacks = False

До версии 1.8 плагины обратного вызова никогда не загружались для /usr/bin/ansible.

callback_plugins

Обратные вызовы — это фрагменты кода в Ansible, которые вызываются по определённым событиям, позволяя инициировать уведомления.

callback_plugins = ~/.ansible/plugins/callback:/usr/share/ansible/plugins/callback

Большинству пользователей эта функция не потребуется. Подробнее см. Разработка плагинов.

callback_whitelist

Новая функция с версии 2.0.

Сейчас Ansible поставляется со всеми включенными плагинами обратного вызова, готовыми к использованию, но они отключены по умолчанию. Этот параметр позволяет включить список дополнительных обратных вызовов. Это не может изменить или переопределить стандартный callback stdout, используйте stdout_callback для этого:

callback_whitelist = timer,mail

command_warnings

Новая функция с версии 1.8.

По умолчанию с Ansible 1.8 Ansible выводит предупреждение, когда используется модуль shell или command, и команда, похоже, аналогична существующему модулю Ansible. Например, это может включать напоминания об использовании модуля «git» вместо команд shell для выполнения «git». Использование модулей при возможности по сравнению с произвольными командами shell приводит к более надёжным и согласованным выполнением playbook, а также более легко поддерживаемым playbook:

command_warnings = False

Эти предупреждения можно отключить, изменив следующее значение или добавив warn=yes или warn=no в конец строки параметра командной строки, например так:

- name: usage of git that could be replaced with the git module
  shell: git update foo warn=yes

connection_plugins

Плагины подключений позволяют расширять канал, используемый ansible для передачи команд и файлов.

connection_plugins = ~/.ansible/plugins/connection_plugins/:/usr/share/ansible_plugins/connection_plugins

Большинству пользователей эта функция не потребуется. Подробнее см. Разработка плагинов.

deprecation_warnings

Новая функция с версии 1.3.

Позволяет отключить предупреждения о устаревании в выводе ansible-playbook:

deprecation_warnings = True

Предупреждения об устаревании указывают на использование устаревших функций, которые будут удалены в будущих релизах Ansible.

display_args_to_stdout

Новая функция с версии 2.1.0.

По умолчанию ansible-playbook выводит заголовок для каждой выполняемой задачи в stdout. Эти заголовки содержат поле name: из задачи, если вы его указали. Если нет, то ansible-playbook использует действие задачи, чтобы помочь определить, какая задача выполняется в настоящее время. Иногда вы выполняете много одинаковых действий, и вам нужна дополнительная информация о задаче, чтобы отличить её от других с тем же действием. Если вы установите эту переменную в True в конфигурации, то ansible-playbook также включит аргументы задачи в заголовок.

Это значение по умолчанию False, потому что есть вероятность, что у вас есть конфиденциальные значения в ваших параметрах, и вы не хотите, чтобы они отображались в stdout:

display_args_to_stdout = False

Если вы установите это значение в True, вы должны убедиться, что stdout вашей среды защищён (никто не может произвести shoulder surfing по вашему экрану, и вы не сохраняете stdout в небезопасный файл) или убедиться, что все ваши playbook явно добавили параметр no_log: True к задачам, которые имеют конфиденциальные значения. Смотрите Как хранить конфиденциальные данные в playbook? для получения дополнительной информации.

display_skipped_hosts

Если установлено значение False, ansible не будет отображать какой-либо статус для задачи, которая пропущена. По умолчанию отображаются пропущенные задачи:

display_skipped_hosts = True

Обратите внимание, что Ansible всегда будет отображать заголовок задачи для любой задачи, независимо от того, пропущена ли она или нет.

error_on_undefined_vars

Включено по умолчанию с Ansible 1.3, это заставляет Ansible завершать шаги, которые ссылаются на имена переменных, которые, вероятно, содержат опечатки:

error_on_undefined_vars = True

Если установлено значение False, любые выражения «{{ template_expression }}», содержащие неопределённые переменные, будут отображаться в шаблоне или строке действия ansible точно так, как написано.

executable

Это указывает команду для запуска оболочки в среде sudo. Пользователям может потребоваться изменить это на /bin/bash в редких случаях, когда sudo ограничен, но в большинстве случаев его можно оставить как есть:

executable = /bin/bash

Начиная с версии 2.1, это можно переопределить переменной инвентаризации ansible_shell_executable.

filter_plugins

Фильтры — это специфические функции, которые можно использовать для расширения системы шаблонов.

filter_plugins = ~/.ansible/plugins/filter_plugins/:/usr/share/ansible_plugins/filter_plugins

Большинству пользователей эта функция не потребуется. Подробнее см. Разработка плагинов.

force_color

Этот параметр принудительно включает режим цвета даже при запуске без TTY:

force_color = 1

force_handlers

Новая функция с версии 1.9.1.

Этот параметр заставляет выполняться уведомлённые обработчики на хосте даже если на этом хосте произошла ошибка:

force_handlers = True

По умолчанию значение False, что означает, что обработчики не будут выполняться, если на хосте произошел сбой. Это также можно настроить для каждого выполнения или в командной строке. Подробности см. в Обработчики и ошибки.

forks

Это число по умолчанию параллельных процессов, которые будут запущены при взаимодействии с удалёнными хостами. Начиная с Ansible 1.3, число процессов fork автоматически ограничено числом возможных хостов во время выполнения, поэтому это фактически ограничение на сетевую и процессорную нагрузку, которую вы считаете приемлемой. Многие пользователи устанавливают это значение в 50, некоторые — в 500 или более. Если у вас большое количество хостов, более высокие значения позволят быстрее завершить действия на всех этих хостах. По умолчанию значение очень консервативное:

forks = 5

fact_caching

Этот параметр позволяет настроить кэширование фактов. Когда кэширование фактов включено и для хоста имеются действительные данные, Ansible будет использовать эти данные вместо запуска неявной setup задачи на удалённом хосте.

Значение этого параметра должно быть именем плагина кэширования. Текущие версии Ansible включают redis и jsonfile.

fact_caching = jsonfile

fact_caching_connection

Этот параметр сообщает Ansible, где кэшировать факты. Значение зависит от плагина. Для плагина jsonfile это должен быть путь к локальному каталогу. Для плагина redis значением является host:port:database тройка:

fact_caching_connection = localhost:6379:0

fact_caching_timeout

Этот параметр сообщает Ansible, когда истекает срок действия значений в кэше. Установка этого значения в 0 фактически отключает истечение срока действия, а положительное значение — это TTL в секундах:

fact_caching_timeout = 86400

fact_path

Этот параметр позволяет глобально настроить пользовательский путь для Локальных фактов (Facts.d) для неявной setup задачи при использовании неявственной сборки фактов.

fact_path = /home/centos/ansible_facts.d

По умолчанию используется значение по умолчанию из модуля setup: /etc/ansible/facts.d Это ВЛИЯЕТ только на сбор фактов, инициированную выполнением, когда gather_facts: True.

gathering

Нововведение в версии 1.6, параметр `gathering` управляет политикой сбора фактов (переменные, обнаруженные на удалённых системах) по умолчанию.

Значение `implicit` является значением по умолчанию, что означает, что кэш фактов будет проигнорирован, и факты будут собираться для каждого выполнения, если `gather_facts: False` не задано. Значение `explicit` — обратное: факты не будут собираться, если не запрошены явно в выполнении. Значение `smart` означает, что каждый новый хост, на котором не обнаружены факты, будет сканироваться, но если один и тот же хост упоминается в нескольких выполнениях, он не будет повторно запрошен в ходе выполнения playbook. Этот параметр может быть полезен тем, кто хочет сэкономить время на сборе фактов. Как `smart`, так и `explicit` будут использовать кэш фактов:

gathering = smart

Нововведение в версии 2.1.

Вы можете указать подмножество собранных фактов с помощью директивы gather_facts выполнения, используя следующий параметр:

gather_subset = all

all:	собрать все подмножества (значение по умолчанию)
network:	собрать сетевые факты
hardware:	собрать аппаратные факты (самые долгие факты для извлечения)
virtual:	собрать факты о виртуальных машинах, размещенных на машине
ohai:	собрать факты из ohai
facter:	собрать факты из facter

Вы можете объединить их, используя список, разделенный запятыми (например: network,virtual,facter)

Вы также можете отключить определённые подмножества, добавив префикс !, как в этом примере:

# Don't gather hardware facts, facts from chef's ohai or puppet's facter
gather_subset = !hardware,!ohai,!facter

Набор основных фактов всегда собирается независимо от дополнительных выбранных подмножеств. Если вы хотите собрать минимальное количество фактов, используйте !all:

gather_subset = !all

hash_behaviour

Ansible по умолчанию переопределяет переменные в определённых порядках приоритета, как описано в Переменные. Когда переменная с более высоким приоритетом побеждает, она заменяет предыдущее значение.

Некоторые пользователи предпочитают, чтобы переменные, представляющие собой хеши (в терминах Python — «словари»), объединялись. Этот параметр называется «merge». Это не поведение по умолчанию, и это не влияет на переменные, значения которых являются скалярами (целые числа, строки) или массивами. Мы в целом рекомендуем не использовать этот параметр, если вы не видите в этом абсолютной необходимости, и playbooks в официальных репозиториях не используют этот параметр:

hash_behaviour = replace

Допустимые значения — «replace» (по умолчанию) или «merge».

Нововведение в версии 2.0.

Если вы хотите объединить хеши без изменения глобальных настроек, используйте фильтр combine , описанный в Фильтры.

hostfile

Этот параметр устарел с версии 1.9. Обратитесь к файлу инвентаризации для нового параметра.

host_key_checking

Как описано в Начало работы, проверка ключа хоста включена по умолчанию в Ansible 1.3 и более поздних версиях. Если вы понимаете последствия и хотите отключить её, вы можете сделать это здесь, установив значение в False:

host_key_checking = True

internal_poll_interval

Нововведение в версии 2.2.

Устанавливает интервал (в секундах) внутреннего опроса Ansible друг другу. Более низкие значения улучшают производительность с большими playbook, но за счёт дополнительной загрузки процессора. Более высокие значения лучше подходят для использования Ansible в сценариях автоматизации, когда реактивность пользовательского интерфейса не требуется, но использование процессора может быть проблемой. Значение по умолчанию соответствует жёстко закодированному значению в Ansible ≤ 2.1:

internal_poll_interval=0.001

inventory

Это расположение файла инвентаризации по умолчанию, скрипта или каталога, которые Ansible будет использовать, чтобы определить доступные хосты для взаимодействия:

inventory = /etc/ansible/hosts

Ранее он назывался hostfile в Ansible до версии 1.9

inventory_ignore_extensions

Список расширений файлов, разделенных запятыми, для игнорирования, когда инвентаризация Ansible — это каталог с несколькими источниками (статическими и динамическими):

inventory_ignore_extensions = ~, .orig, .bak, .ini, .cfg, .retry, .pyc, .pyo

Этот параметр можно переопределить, установив переменную окружения ANSIBLE_INVENTORY_IGNORE.

jinja2_extensions

Это функция, предназначенная для разработчиков, которая позволяет включить дополнительные расширения Jinja2:

jinja2_extensions = jinja2.ext.do,jinja2.ext.i18n

Если вы не знаете, что это делает, вам, вероятно, не нужно изменять эту настройку :)

library

Это место по умолчанию, где Ansible ищет модули:

library = /usr/share/ansible

Ansible может искать в нескольких местах, если вы передадите путь, разделённый двоеточием, и также будет искать модули в каталоге ./library рядом с playbook.

Это можно использовать для управления модулями, полученными из нескольких различных источников. Например, сайт, желающий скачивать модули из нескольких репозиториев git, может сделать это так:

$ mkdir -p /srv/modules
$ cd /srv/modules
$ git checkout https://vendor_modules .
$ git checkout ssh://custom_modules .
$ export ANSIBLE_LIBRARY=/srv/modules/custom_modules:/srv/modules/vendor_modules
$ ansible [...]

В случае модулей с одинаковыми именами пути к библиотекам просматриваются в порядке, и используется первый найденный модуль с этим именем.

local_tmp

Нововведение в версии 2.1.

Когда Ansible готовится отправить модуль на удалённую машину, ему обычно нужно добавить несколько вещей в модуль: некоторый шаблонный код, параметры модуля и несколько констант из файла конфигурации. Эта комбинация хранится во временном файле до тех пор, пока Ansible не завершит работу и не очистит за собой. По умолчанию расположение — это подкаталог домашнего каталога пользователя. Если вы хотите изменить это, вы можете изменить этот параметр:

local_tmp = ~/.ansible/tmp

Ansible затем выберет случайное имя каталога внутри этого расположения.

log_path

Если присутствует и настроен в ansible.cfg, Ansible будет записывать информацию о выполнении в указанном расположении. Убедитесь, что пользователь, запускающий Ansible, имеет права доступа к файлу журнала:

log_path=/var/log/ansible.log

Это поведение не включено по умолчанию. Обратите внимание, что Ansible без этой настройки будет записывать аргументы модулей в системный журнал управляемых машин. Аргументы паролей исключаются.

Для корпоративных пользователей, которые ищут более подробную историю логов, может быть интересна Ansible Tower.

lookup_plugins

Это функция, предназначенная для разработчиков, которая позволяет загружать низкоуровневые расширения Ansible из разных расположений:

lookup_plugins = ~/.ansible/plugins/lookup_plugins/:/usr/share/ansible_plugins/lookup_plugins

Большинству пользователей не нужно использовать эту функцию. Подробнее см. в Разработка плагинов

merge_multiple_cli_tags

Нововведение в версии 2.3.

Это позволяет изменить то, как обрабатываются несколько аргументов --tags и --skip-tags в командной строке. Указание --tags более одного раза объединяет все --tags варианты вместе. Если вы хотите поведение, как до версии 2.4.x, где используется только последнее значение --tags, то установите это значение в False. То же самое относится и к --skip-tags.

Примечание

Значение по умолчанию для этого параметра в версии 2.3 — False. В версии 2.4 — True. После версии 2.8 этот параметр будет удален. Несколько --tags и несколько --skip-tags всегда будут объединены.

module_lang

Это для установки языка по умолчанию для связи между модулем и системой. По умолчанию значение равно LANG на контроллере или, если не задано, en_US.UTF-8 (раньше это было C в предыдущих версиях):

module_lang = en_US.UTF-8

Примечание

Это используется только в том случае, если module_set_locale установлено в значение True.

module_name

Это значение по умолчанию для имени модуля (-m) для /usr/bin/ansible. По умолчанию используется модуль ‘command’. Помните, что модуль command не поддерживает переменные оболочки, конвейеры или кавычки, поэтому вы можете изменить его на ‘shell’:

module_name = command

module_set_locale

Это логическое значение, определяющее, будут ли в Ansible добавлены переменные окружения, специфичные для локали (как указано в параметре конфигурации module_lang). Если включено, при выполнении модуля на удаленной системе будут установлены переменные LANG, LC_MESSAGES и LC_ALL. По умолчанию эта опция отключена.

Примечание

Параметр module_set_locale был добавлен в Ansible-2.1 и по умолчанию был установлен в значение True. Значение по умолчанию было изменено на False в Ansible-2.2

module_utils

Это по умолчанию место, где Ansible ищет module_utils:

module_utils = /usr/share/ansible/my_module_utils

module_utils — это модули Python, которые Ansible может комбинировать с модулями Ansible при отправке их на удаленный компьютер. Наличие пользовательских module_utils полезно для извлечения общего кода при разработке набора модулей, специфичных для сайта.

Ansible может искать в нескольких местах, если вы предоставите путь, разделённый двоеточиями, и также будет искать модули в каталоге ./module_utils рядом с playbook.

nocolor

По умолчанию ansible пытается выводить цветной вывод, чтобы лучше отображать информацию об ошибках и состоянии. Если вам не нравится это поведение, вы можете отключить его, установив для ‘nocolor’ значение 1:

nocolor = 0

nocows

По умолчанию Ansible использует cowsay, если он установлен, чтобы сделать выполнение /usr/bin/ansible-playbook более интересным. Зачем? Мы считаем, что управление системами должно быть приятным опытом. Если вам не нравятся коровы, вы можете отключить их, установив ‘nocows’ в значение 1:

nocows = 0

pattern

Это группа хостов по умолчанию, с которыми взаимодействует playbook, если не указан раздел «hosts:». По умолчанию взаимодействие происходит со всеми хостами. Вы можете изменить это, чтобы защититься от неожиданностей:

hosts = *

Обратите внимание, что /usr/bin/ansible всегда требует шаблона хоста и не использует это значение, только /usr/bin/ansible-playbook.

poll_interval

Для асинхронных задач в Ansible (описано в Асинхронные действия и опросы) этот параметр определяет, как часто проверять состояние этих задач, если явное значение интервала опроса не задано. Значение по умолчанию составляет разумные 15 секунд, что является компромиссом между частым контролем и быстрым откликом, когда что-то может завершиться:

poll_interval = 15

private_key_file

Если вы используете файл pem для аутентификации с машинами вместо SSH-агента или паролей, вы можете установить здесь значение по умолчанию, чтобы избежать повторного указания --private-key при каждом вызове:

private_key_file=/path/to/file.pem

remote_port

Это устанавливает порт SSH по умолчанию на всех ваших системах для систем, которые не указали альтернативное значение в инвентаризации. Значение по умолчанию — стандартный порт 22:

remote_port = 22

remote_tmp

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

remote_tmp = ~/.ansible/tmp

По умолчанию используется подкаталог домашнего каталога пользователя. Ansible затем выберет случайное имя каталога внутри этого расположения.

remote_user

Это имя пользователя по умолчанию, с которым ansible будет подключаться для /usr/bin/ansible-playbook. Обратите внимание, что /usr/bin/ansible всегда по умолчанию подключается к текущему пользователю, если это не определено:

remote_user = root

retry_files_enabled

Это управляет тем, будет ли создан файл .retry для playbook Ansible при ошибке. Значение по умолчанию — True:

retry_files_enabled = False

retry_files_save_path

Путь сохранения файлов retry — это место, где Ansible сохранит файлы .retry, когда playbook завершится неудачно, и retry_files_enabled установлено в значение True (значение по умолчанию). По умолчанию расположение находится рядом с playbook (~/ в версиях, более ранних чем 2.0), и может быть изменено на любой доступный для записи путь:

retry_files_save_path = ~/.ansible/retry-files

Каталог будет создан, если он ещё не существует.

roles_path

Новое в версии 1.4.

Путь к ролям указывает дополнительные каталоги, помимо подкаталога «roles/» проекта playbook, в которых необходимо искать роли Ansible. Например, если есть репозиторий исходного кода общих ролей и другой репозиторий playbooks, вы можете установить соглашение о расположении ролей в /opt/mysite/roles, как показано ниже:

roles_path = /opt/mysite/roles

Дополнительные пути могут быть заданы, разделённые двоеточиями, точно так же, как и другие пути:

roles_path = /opt/mysite/roles:/opt/othersite/roles

Роли сначала будут искаться в каталоге playbook. Если роль не найдена, будет указан список всех возможных путей поиска.

squash_actions

Новое в версии 2.0.

Ansible может оптимизировать действия, вызывающие модули, поддерживающие параметры списков, при использовании циклов with_. Вместо вызова модуля для каждого элемента модуль вызывается один раз со списком целиком.

Значение по умолчанию для этого параметра определено только для некоторых менеджеров пакетов, но может быть использовано для любого модуля:

squash_actions = apk,apt,dnf,homebrew,package,pacman,pkgng,yum,zypper

В настоящее время это поддерживается только для модулей, имеющих параметр name, и только когда элемент является единственным аргументом, передаваемым в этот параметр.

stdout_callback

Новое в версии 2.0.

Этот параметр позволяет переопределить обратный вызов stdout для ansible-playbook:

stdout_callback = skippy

strategy_plugins

Плагины стратегии позволяют пользователям изменять способ, которым Ansible выполняет задачи на целевых хостах.

Это функция, ориентированная на разработчиков, позволяющая загружать расширения низкого уровня для Ansible из разных мест:

strategy_plugins = ~/.ansible/plugins/strategy_plugins/:/usr/share/ansible_plugins/strategy_plugins

Большинству пользователей эта функция не понадобится. Подробнее см. Разработка плагинов

strategy

Стратегии позволяют изменить стратегию по умолчанию, используемую Ansible:

strategy = free

sudo_exe

При использовании альтернативной реализации sudo на удалённых машинах, путь к sudo может быть изменён здесь, при условии, что реализация sudo соответствует флагам командной строки стандартному sudo:

sudo_exe = sudo

sudo_flags

Дополнительные флаги, передаваемые в sudo при использовании поддержки sudo. По умолчанию это ‘-H -S -n’, что устанавливает переменную окружения HOME, запрашивает пароли через STDIN и избегает запросов ввода у пользователя. Обратите внимание, что ‘-n’ будет конфликтовать с использованием аутентификации sudo без пароля, такой как pam_ssh_agent_auth. В некоторых ситуациях вы можете добавить или удалить флаги, но в общем большинство пользователей не нуждаются в изменении этого параметра:

sudo_flags=-H -S -n

sudo_user

Это пользователь по умолчанию, которому нужно выполнить sudo, если --sudo-user не указан или ‘sudo_user’ не указан в playbook Ansible. Значение по умолчанию — наиболее логичное: ‘root’:

sudo_user = root

system_warnings

Новое в версии 1.6.

Позволяет отключить предупреждения, связанные с потенциальными проблемами на системе, на которой выполняется сам ansible (не на управляемых хостах):

system_warnings = True

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

timeout

Это значение по умолчанию для таймаута SSH при попытке подключения:

timeout = 10

transport

Это транспорт по умолчанию, который следует использовать, если «-c <имя_транспорта>» не указан для /usr/bin/ansible или /usr/bin/ansible-playbook. Значение по умолчанию — ‘smart’, которое будет использовать ‘ssh’ (на основе OpenSSH), если операционная система достаточно новая, чтобы поддерживать технологию ControlPersist, а в противном случае будет использовать ‘paramiko’. Другие варианты транспорта включают ‘local’, ‘chroot’, ‘jail’ и т. д.

Пользователям обычно следует оставить это значение как ‘smart’ и позволить своим playbooks выбирать альтернативное значение при необходимости с параметром «connection:» play:

transport = paramiko

vars_plugins

vars_plugins = ~/.ansible/plugins/vars_plugins/:/usr/share/ansible_plugins/vars_plugins

Большинству пользователей эта функция не понадобится. Подробнее см. Разработка плагинов

vault_password_file

Новое в версии 1.7.

Настраивает путь к файлу пароля Vault в качестве альтернативы указанию --vault-password-file в командной строке:

vault_password_file = /path/to/vault_password_file

Начиная с версии 1.7, этот файл также может быть скриптом. Если вы используете скрипт вместо обычного файла, убедитесь, что он отмечен как исполняемый, и что пароль печатается в стандартный вывод. Если ваш скрипт нуждается в запросе данных, запросы могут отправляться в стандартный вывод ошибки.

Настройки повышения привилегий

Ansible может использовать существующие системы повышения привилегий, чтобы позволить пользователю выполнять задачи от имени другого пользователя. Начиная с версии 1.9, ‘become’ заменяет старые sudo/su, сохраняя при этом обратную совместимость. Настройки находятся в заголовке [privilege_escalation].

become

Эквивалентно добавлению sudo: или su: к выполнению или задаче, установите значение true/yes для активации повышения привилегий. По умолчанию значение no:

become = True

become_method

Установите метод повышения привилегий. По умолчанию sudo, другие варианты — su, pbrun, pfexec, doas, ksu:

become_method = su

become_user

Эквивалентно ansible_sudo_user или ansible_su_user, позволяет задать пользователя, к которому происходит повышение привилегий. По умолчанию ‘root’:

become_user = root

become_ask_pass

Запрашивать пароль повышения привилегий, по умолчанию False:

become_ask_pass = True

become_allow_same_user

В большинстве случаев использование sudo для запуска команды от того же пользователя, который запускает sudo, является избыточным, поэтому Ansible этого не допускает. Однако в зависимости от конфигурации sudo может потребоваться запустить команду от того же пользователя через sudo, например, для переключения контекстов SELinux. По этой причине вы можете установить become_allow_same_user на True и отключить эту оптимизацию.

Настройки Paramiko

Paramiko — это реализация соединения SSH по умолчанию в Enterprise Linux 6 или более ранних версиях и по умолчанию не используется на других платформах. Настройки находятся в заголовке [paramiko_connection].

record_host_keys

Значение по умолчанию yes запишет вновь обнаруженные и одобренные (если проверка ключей хостов включена) хосты в файл хостов пользователя. Эта настройка может быть неэффективной для большого числа хостов, и в таких ситуациях настоятельно рекомендуется использовать транспорт ssh. Установка значения False улучшит производительность и рекомендуется, когда проверка ключей хостов отключена:

record_host_keys = True

proxy_command

Новая функция в версии 2.1.

Используйте OpenSSH-подобную команду ProxyCommand для проксирования всех соединений Paramiko SSH через бастион или хост перехода. Требуется минимальная версия Paramiko 1.9.0. В Enterprise Linux 6 это обеспечивается python-paramiko1.10 в репозитории EPEL:

proxy_command = ssh -W "%h:%p" bastion

Настройки OpenSSH

В заголовке [ssh_connection] можно настраивать следующие параметры для SSH-соединений. OpenSSH является типом соединения по умолчанию для Ansible на ОС, достаточно новых для поддержки ControlPersist. (Это означает практически все операционные системы, кроме Enterprise Linux 6 или более ранних версий).

ssh_args

При установке этого значения будут переданы определенные параметры Ansible, а не обычные значения по умолчанию:

ssh_args = -o ControlMaster=auto -o ControlPersist=60s

В частности, пользователям может потребоваться увеличить время ControlPersist для повышения производительности. Может подойти значение в 30 минут. Если -o ControlPath установлено в ssh_args, настройка control_path не используется.

control_path

Это расположение для сохранения сокетов ControlPath. По умолчанию:

control_path=%(directory)s/ansible-ssh-%%h-%%p-%%r

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

control_path = %(directory)s/%%h-%%r

Ansible 1.4 и более поздние версии будут инструктировать пользователей запускать его с «-vvvv» в ситуациях, когда возникает эта проблема, и в таком случае легко определить, что имя файла сокета ControlPath слишком длинное. Это часто встречается на EC2. Эта настройка игнорируется, если -o ControlPath установлено в ssh_args.

control_path_dir

Новая функция в версии 2.3.

Это базовая директория сокетов ControlPath. Это часть %(directory)s в параметре control_path . По умолчанию:

control_path_dir=~/.ansible/cp

retries

Добавляет возможность повторных попыток при неудачных выполнении ssh, если ошибка возникает в самом ssh, а не в удаленной команде. Это может быть полезно при временных проблемах с сетью. Включается путем установки retries на целое число больше 1. По умолчанию:

retries = 0

scp_if_ssh

Иногда пользователи управляют удаленной системой, на которой не включен SFTP. Если установить значение True, мы можем заставить scp использоваться для передачи удаленных файлов вместо этого:

scp_if_ssh = False

На самом деле нет причин изменять это, если не возникнут проблемы, а затем нет реального недостатка в управлении переключением. Большинство сред поддерживают SFTP по умолчанию, и обычно это не требует изменения.

pipelining

Включение pipelining уменьшает количество операций SSH, необходимых для выполнения модуля на удаленном сервере, путем выполнения многих модулей ansible без фактической передачи файлов. Это может привести к значительному улучшению производительности при включении, однако при использовании операций «sudo:», необходимо сначала отключить «requiretty» в /etc/sudoers на всех управляемых хостах.

По умолчанию этот параметр отключен для сохранения совместимости с конфигурациями sudoers, которые имеют requiretty (по умолчанию во многих дистрибутивах), но его настоятельно рекомендуется включить, если это возможно, устраняя необходимость в Ускоренном режиме:

pipelining = False

ssh_executable

Новая функция в версии 2.2.

Это местоположение бинарника ssh. По умолчанию ssh , который будет использовать первый доступный бинарник ssh в $PATH. Эта конфигурация также может быть перезаписана переменной инвентаризации ansible_ssh_executable:

ssh_executable="/usr/local/bin/ssh"

Этот параметр обычно не требуется, он может быть полезен, когда доступ к системному ssh ограничен или при использовании оболочек ssh для подключения к удаленным хостам.

Настройки Ускоренного режима

В заголовке [accelerate] можно настраивать следующие параметры для Ускоренного режима. Ускорение — полезная функция производительности, если вы не можете включить pipelining в вашей среде, но, вероятно, не нужна, если вы можете.

accelerate_port

Новая функция в версии 1.3.

Это порт для использования в ускоренном режиме:

accelerate_port = 5099

accelerate_timeout

Новая функция в версии 1.4.

Эта настройка контролирует таймаут для получения данных от клиента. Если данные не получены в течение этого времени, соединение сокета будет закрыто. Пакет keepalive отправляется обратно контроллеру каждые 15 секунд, поэтому этот таймаут не должен быть меньше 15 (по умолчанию таймаут составляет 30 секунд):

accelerate_timeout = 30

accelerate_connect_timeout

Новая функция в версии 1.4.

Эта настройка контролирует таймаут вызова соединения сокета и должна быть относительно низкой. Подключение к accelerate_port будет выполняться 3 раза, прежде чем Ansible вернется к ssh или paramiko (в зависимости от вашей настройки соединения по умолчанию), чтобы попытаться запустить демона ускорения удаленно. Значение по умолчанию составляет 1,0 секунду:

accelerate_connect_timeout = 1.0

Обратите внимание, что это значение может быть меньше одной секунды, однако, вероятно, это не хорошая идея, если вы не работаете в очень быстрой и надежной локальной сети. Если вы подключаетесь к системам через Интернет, может потребоваться увеличить этот таймаут.

accelerate_daemon_timeout

Новая функция в версии 1.6.

Эта настройка контролирует таймаут ускоренного демона, измеряемый в минутах. Таймаут демона по умолчанию составляет 30 минут:

accelerate_daemon_timeout = 30

Обратите внимание, что до версии 1.6 таймаут был жестко закодирован с момента запуска демона. Для версии 1.6+ таймаут теперь основан на последней активности демона и настраивается с помощью этого параметра.

accelerate_multi_key

Новая функция в версии 1.6.

Если включено, это значение позволяет загружать несколько закрытых ключей в демон. Любые клиенты, подключающиеся к демону, также должны включить этот параметр:

accelerate_multi_key = yes

Новые клиенты сначала подключаются к целевому узлу по SSH для загрузки ключа, что выполняется через локальный файл сокета, поэтому они должны иметь тот же доступ, что и пользователь, который первоначально запустил демон.

Настройки SELinux

Это настройки, контролирующие взаимодействие с SELinux.

special_context_filesystems

Новая функция в версии 1.9.

Это список файловых систем, которые требуют специального обращения при работе с контекстом безопасности. Обычное поведение — копирование существующего контекста или использование пользовательского значения по умолчанию, это изменяет его на использование контекста, зависящего от файловой системы. Список по умолчанию: nfs,vboxsf,fuse,ramfs:

special_context_filesystems = nfs,vboxsf,fuse,ramfs,myspecialfs

libvirt_lxc_noseclabel

Новая функция в версии 2.1.

Это настройка, заставляющая libvirt подключаться к контейнерам lxc, передавая –noseclabel в virsh. Это необходимо при запуске на системах без SELinux. По умолчанию значение no:

libvirt_lxc_noseclabel = True

show_custom_stats

Новая функция в версии 2.3.

При включении эта настройка отобразит пользовательские статистические данные (установленные плагином set_stats) при использовании обратного вызова по умолчанию.

Настройки Galaxy

Следующие параметры можно установить в разделе [galaxy] файла ansible.cfg:

server

Переопределите значение сервера Galaxy по умолчанию https://galaxy.ansible.com. Полезно, если у вас есть размещенная версия веб-приложения Galaxy или вы хотите указать тестовый сайт https://galaxy-qa.ansible.com. Это не работает с частными, размещенными репозиториями, которые Galaxy может использовать для извлечения и установки ролей.

ignore_certs

Если значение равно yes, ansible-galaxy не будет проверять сертификаты TLS. Это может быть полезно для тестирования на сервере с самоподписанным сертификатом.

© 2012–2018 Michael DeHaan
© 2018–2019 Red Hat, Inc.
Licensed under the GNU General Public License version 3.
https://docs.ansible.com/ansible/2.4/intro_configuration.html