gathering facts ansible что это
Discovering variables: facts and magic variables
With Ansible you can retrieve or discover certain variables containing information about your remote systems or about Ansible itself. Variables related to remote systems are called facts. With facts, you can use the behavior or state of one system as configuration on other systems. For example, you can use the IP address of one system as a configuration value on another system. Variables related to Ansible are called magic variables.
Ansible facts
Ansible facts are data related to your remote systems, including operating systems, IP addresses, attached filesystems, and more. You can access this data in the ansible_facts variable. By default, you can also access some Ansible facts as top-level variables with the ansible_ prefix. You can disable this behavior using the INJECT_FACTS_AS_VARS setting. To see all available facts, add this task to a play:
To see the ‘raw’ information as gathered, run this command at the command line:
Facts include a large amount of variable data, which may look like this:
You can reference the model of the first disk in the facts shown above in a template or playbook as:
To reference the system hostname:
You can use facts in conditionals (see Conditionals ) and also in templates. You can also use facts to create dynamic groups of hosts that match particular criteria, see the group_by module documentation for details.
Package requirements for fact gathering
On some distros, you may see missing fact values or facts set to default values because the packages that support gathering those facts are not installed by default. You can install the necessary packages on your remote hosts using the OS package manager. Known dependencies include:
Caching facts
Like registered variables, facts are stored in memory by default. However, unlike registered variables, facts can be gathered independently and cached for repeated use. With cached facts, you can refer to facts from one system when configuring a second system, even if Ansible executes the current play on the second system first. For example:
Caching is controlled by the cache plugins. By default, Ansible uses the memory cache plugin, which stores facts in memory for the duration of the current playbook run. To retain Ansible facts for repeated use, select a different cache plugin. See Cache plugins for details.
Fact caching can improve performance. If you manage thousands of hosts, you can configure fact caching to run nightly, then manage configuration on a smaller set of servers periodically throughout the day. With cached facts, you have access to variables and information about all hosts even when you are only managing a small number of servers.
Disabling facts
By default, Ansible gathers facts at the beginning of each play. If you do not need to gather facts (for example, if you know everything about your systems centrally), you can turn off fact gathering at the play level to improve scalability. Disabling facts may particularly improve performance in push mode with very large numbers of systems, or if you are using Ansible on experimental platforms. To disable fact gathering:
Adding custom facts
The setup module in Ansible automatically discovers a standard set of facts about each host. If you want to add custom values to your facts, you can write a custom facts module, set temporary facts with a ansible.builtin.set_fact task, or provide permanent custom facts using the facts.d directory.
facts.d or local facts
You can add static custom facts by adding static files to facts.d, or add dynamic facts by adding executable scripts to facts.d. For example, you can add a list of all users on a host to your facts by creating and running a script in facts.d.
Make sure the file is not executable as this will break the ansible.builtin.setup module.
The next time fact gathering runs, your facts will include a hash variable fact named general with asdf and bar as members. To validate this, run the following:
And you will see your custom fact added:
The ansible_local namespace separates custom facts created by facts.d from system facts or variables defined elsewhere in the playbook, so variables will not override each other. You can access this custom fact in a template or playbook as:
You can also use facts.d to execute a script on the remote host, generating dynamic custom facts to the ansible_local namespace. For example, you can generate a list of all users that exist on a remote host as a fact about that host. To generate dynamic custom facts using facts.d:
Write and test a script to generate the JSON data you want.
Save the script in your facts.d directory.
Make sure your script is executable by the Ansible connection user.
Gather facts to execute the script and add the JSON output to ansible_local.
By default, fact gathering runs once at the beginning of each play. If you create a custom fact using facts.d in a playbook, it will be available in the next play that gathers facts. If you want to use it in the same play where you created it, you must explicitly re-run the setup module. For example:
If you use this pattern frequently, a custom facts module would be more efficient than facts.d.
Information about Ansible: magic variables
If you want to configure your database server using the value of a ‘fact’ from another node, or the value of an inventory variable assigned to another node, you can use hostvars in a template or on an action line:
You can use groups and hostvars together to find all the IP addresses in a group.
You can use this approach to point a frontend proxy server to all the hosts in your app servers group, to set up the correct firewall rules between servers, and so on. You must either cache facts or gather facts for those hosts before the task that fills out the template.
Other useful magic variables refer to the current play or playbook. These vars may be useful for filling out templates with multiple hostnames or for injecting the list into the rules for a load balancer.
ansible_play_hosts is the list of all hosts still active in the current play.
ansible_play_batch is a list of hostnames that are in scope for the current ‘batch’ of the play.
ansible_playbook_python is the path to the python executable used to invoke the Ansible command line tool.
inventory_dir is the pathname of the directory holding Ansible’s inventory host file.
inventory_file is the pathname and the filename pointing to the Ansible’s inventory host file.
playbook_dir contains the playbook base directory.
role_path contains the current role’s pathname and only works inside a role.
Ansible version
© Copyright Ansible project contributors. Last updated on Dec 01, 2021.
Модуль setup и Gathers facts в Ansible
В системе управления конфигурациями Ansible есть специальный модуль setup. Он выполняется первым, собирая информацию (Gathers facts) обо всех подключённых узлах (нодах). При выполнении модуля на хосте он собирает разные факты, включая дисковое пространство, версию и тип операционной системы, hostname машины, количество доступной памяти, архитектуру процессора, IP-адреса, сетевые интерфейсы и их состояние.
Собранная системная информация фиксируется в виде переменных, которые доступны только для чтения. Полученные факты можно в дальнейшем использовать в коде и сценариях плейбуков в своих целях. Например, вы можете писать условия в коде, при которых будут вноситься те либо иные изменения в зависимости от типа и версии операционной системы.
Посмотреть, какая информация собирается модулем setup и в какие переменные она упаковывается, можно следующим образом (вывод частично обрезан):
В целом модуль setup — очень полезный инструмент
Однако нельзя не учитывать, что на выполнение сбора системной информации уходит определённое время. И если код плейбука, который будет применяться на сервере, никак не будет использовать эти факты, модуль лучше отключить. В результате чего переменные собираться не будут в рамках выполнения всего плейбука, что сэкономит время. Это может быть важно, например, если вы используете Ansible для деплоя, когда каждые пару секунд влияют на скорость внесения изменений.
Отключение модуля setup не вызывает сложностей, причём управление включением/выключением выполняется на уровне всего плейбука. Кроме того, в ansible.cfg можно управлять его поведением по умолчанию.
А как вы используете Gathers facts? Пишите в комментариях!
И если хотите узнать об Ansible более подробно, записывайтесь на курс «DevOps практики и инструменты» в OTUS!
Ansible. Переменные, факты и регистры Ansible
Главное меню » Linux » Ansible. Переменные, факты и регистры Ansible
В этой статье вы узнаете, как определять переменные Ansible и ссылаться на них. Вы также узнаете, как использовать факты Ansible для получения информации о ваших управляемых узлах.
Кроме того, вы также узнаете, как использовать регистры для записи вывода задачи.
Часть 1: Работа с переменными в Ansible
Начнем сначала с переменных. Имейте в виду, что все это записано в вашем YML-файле.
Определение и ссылка на переменные
Вы можете использовать ключевое слово vars для определения переменных непосредственно внутри playbook.
Например, вы можете определить переменную fav_color и установить ее значение на желтый следующим образом:
Как теперь использовать (ссылаться) на переменную fav_color? Ansible использует систему шаблонов Jinja2 для работы с переменными.
Чтобы получить значение переменной fav_color ; вам нужно окружить его парой фигурных скобок следующим образом:
Обратите внимание, что если ваша переменная является первым элементом (или единственным элементом) в строке, то использование кавычек обязательно, как показано ниже:
Теперь давайте напишем книгу с именем variables-playbook.yml, которая объединит все это вместе:
Мы использовали модуль отладки вместе с параметром модуля msg, чтобы распечатать значение переменной fav_color.
Теперь запустите playbook, и вы увидите, что ваш любимый цвет отображается следующим образом:
Создание списков и словарей
Вы также можете использовать списки и словари для определения многозначных переменных. Например, вы можете определить список с именем port_nums и установить его значение следующим образом:
Вы также могли использовать следующий способ определения port_nums, что эквивалентно:
Вы можете распечатать все значения в port_nums следующим образом:
Вы также можете получить доступ к определенному элементу списка:
Обратите внимание, что вы используете индекс (позицию) для доступа к элементам списка.
Вы также можете определить словарь с именем users следующим образом:
Есть два разных способа доступа к элементам словаря:
Обратите внимание, что вы используете ключ для доступа к элементам словаря.
Теперь вы можете редактировать playbook – variables-playbook.yml, чтобы показать списки и словари в действии:
Теперь вы можете запустить playbook, чтобы отобразить второй элемент в port_nums и показать uid bob:
Включая внешние переменные
Точно так же, как вы можете импортировать (или включать) задачи в playbook. То же самое можно сделать и с переменными. То есть в playbook вы можете включать переменные, определенные во внешнем файле.
Теперь вы можете использовать ключевое слово vars_files в вашем файле variables-playbook.yml, чтобы включить переменные в myvars.yml следующим образом:
Имейте в виду, что vars_files выполняет предварительную обработку и загружает переменные прямо в начале playbook. Вы также можете использовать модуль include_vars для динамической загрузки ваших переменных в playbook:
Получение пользовательского ввода
Вы можете использовать ключевое слово vars_prompt, чтобы предложить пользователю установить значение переменной во время выполнения.
Например, следующий сборник программ greet.yml просит запущенного пользователя ввести свое имя, а затем отображает персонализированное приветственное сообщение:
Обратите внимание, что я использовал private: no, чтобы вы могли видеть свой ввод на экране по мере его ввода; по умолчанию он скрыт.
Теперь запустите playbook и введите свое имя:
Установка переменных хоста и группы
Вы можете установить переменные, специфичные для ваших управляемых хостов. Поступая так, вы можете создавать гораздо более эффективные playbooks, поскольку вам не нужно писать повторяющиеся задачи для разных узлов или групп.
Для демонстрации отредактируйте файл инвентаризации так, чтобы управляемые узлы были сгруппированы в следующие три группы:
Теперь создадим переменные, специфичные для ваших управляемых узлов; Во- первых, вам нужно создать каталог с именем host_vars. Затем внутри host_vars вы можете создать файлы переменных с именами файлов, соответствующими именам хостов вашего узла:
Теперь давайте создадим книгу с именем motd.yml, которая демонстрирует, как работают host_vars :
Мы использовали модуль копирования, чтобы скопировать содержимое переменной сообщения в файл /etc/motd на всех узлах. Теперь после запуска playbook; вы должны увидеть, что содержимое /etc/motd было обновлено на всех узлах с соответствующим значением сообщения :
Потрясающие! Точно так же вы можете создать каталог group_vars, а затем включить все связанные с группой переменные в имя файла, которое соответствует имени группы, как показано ниже:
Мы позволили вам создать playbook, который работает на всех узлах; каждый узел установит пакет, заданный в соответствующей групповой переменной узла pkg.
Понимание приоритета переменных
Как вы уже видели; Переменные Ansible могут быть установлены на разных уровнях (или уровнях).
Если одна и та же переменная установлена на разных уровнях; самый конкретный уровень получает приоритет. Например, переменная, установленная на уровне воспроизведения, имеет приоритет над той же переменной, установленной на уровне хоста ( host_vars ).
Более того, переменная, заданная в командной строке с помощью –extra-vars, имеет наивысший приоритет, то есть она перезапишет все остальное.
Чтобы продемонстрировать это, давайте создадим книгу с именем variable-Priordence.yml, которая содержит следующий контент:
Обратите внимание на то, что значение «CentOS» в командной строке fav_distro имеет приоритет над значением «Ubuntu» в fav_distro.
Часть 2: Сбор и демонстрация фактов
Вы можете получить или обнаружить переменные, которые содержат информацию о ваших управляемых хостах. Эти переменные называются фактами, и Ansible использует модуль настройки для сбора этих фактов. IP-адрес одного из ваших управляемых узлов является примером факта.
Вы можете запустить следующую специальную команду, чтобы собрать и показать все факты о node1:
Это только часть всех фактов, связанных с node1, которые вы увидите на своем терминале. Обратите внимание, как факты хранятся в словарях или списках, и все они принадлежат словарю ansible_facts.
По умолчанию модуль настройки автоматически вызывается плейбуками для обнаружения фактов. Возможно, вы заметили, что обнаружение фактов происходит с самого начала, когда вы запускаете любой из ваших playbooks:
Вы можете отключить сбор фактов, установив для параметра gather_facts логическое значение false прямо в заголовке воспроизведения следующим образом:
Если вы снова запустите motd.yaml playbook; он пропустит сбор фактов:
Таким же образом вы показываете значение переменной; вы также можете использовать, чтобы показать ценность факта. В следующем сборнике show-fact.yml показана ценность нескольких фактов на node1 :
Теперь запустите playbook, чтобы отобразить значения фактов:
Создание постоянных фактов
Вы можете создать свои собственные пользовательские факты. Для этого вы можете использовать модуль set_fact для временного добавления фактов или каталог /etc/ansible/facts.d для добавления постоянных фактов на ваши управляемые узлы.
Мы собираемся показать вам, как добавить постоянные факты к вашим управляемым узлам. Это трехэтапный процесс:
Итак, сначала давайте создадим файл cool.fact на вашем управляющем узле, который включает некоторые интересные факты:
Обратите внимание, что имя файла фактов должно иметь расширение.fact.
В следующем сборнике custom-fact.yml сочетаются шаги 2 и 3:
Теперь запустите playbook:
В cool теперь постоянно часть NODE1 фактов; вы можете проверить с помощью следующей специальной команды:
Теперь вы можете отобразить факт octupus в учебнике следующим образом:
Часть 3: Захват вывода с помощью регистров в Ansible
Вы можете использовать регистр для захвата вывода задачи и сохранения его в переменной. Это позволяет вам использовать вывод задачи в другом месте книги, просто обращаясь к зарегистрированной переменной.
Следующий файл register-playbook.yml показывает вам, как записать вывод задачи в зарегистрированной переменной, а затем отобразить его содержимое:
Playbook запускается с выполнения команды uptime на хостах группы прокси (node1) и регистрирует выходные данные команды в переменной server_uptime.
Затем вы используете модуль отладки вместе с параметром var module для проверки переменной server_uptime. Обратите внимание, что здесь не нужно заключать переменную в фигурные скобки.
Наконец, последняя задача в playbook показывает вывод (stdout) зарегистрированной переменной server_uptime.
Запустите playbook, чтобы увидеть все это в действии:
Обратите внимание, что зарегистрированная переменная server_uptime на самом деле является словарем, содержащим множество других ключей помимо ключа stdout. Она также содержит другие ключи, такие как rc (код возврата), start (время выполнения команды), end (время завершения команды), stderr (любые ошибки) и т. д.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
15 вещей, которые вы должны знать об Ansible
Предлагаю читателям «Хабрахабра» перевод опубликованной на codeheaven.io статьи «15 Things You Should Know About Ansible» за авторством Marlon Bernardes.
В последнее время я много работал с Ansible и решил поделиться некоторыми вещами, которые выучил по пути. Ниже вы найдете список из 15 вещей, которые, как я думаю, вы должны знать об Ansible. Что-то пропустил? Просто оставьте комментарий и поделитесь вашими личными советами.
1 — Вы можете передавать параметры для ролей
Хорошей практикой является создание ролей для организации ваших плейбуков. Скажем, мы хотим создать роль для установки Jenkins. Структура каталогов для этой роли будет выглядеть как то так:
Каталог defaults используется для хранения переменных по-умолчанию для роли. Внутри него может находиться файл main.yml:
Вы можете переопределить переменные по-умолчанию, передачей различных параметров для роли, вот так:
2 — Как сделать модуль command идемпотентным
Идемпотентность — свойство определенных операций, которые могут быть выполнены многократно, не изменяя результат первоначального применения. Эта концепция присутствует в большинстве модулей Ansible: вы указываете желаемое конечное состояние и Ansible решает, должна ли быть выполнена задача. По-умолчанию этот принцип не распространяется на модуль command. Если у вас в плейбуке есть задача, она всегда будет выполнена:
Для достижения идемпотентности вы можете использовать атрибут creates. Когда он присутствует, Ansible выполнит задачу command, только если заданный в файле шаблон не существует. В качестве альтернативы можно использовать removes, который будет выполнять задание, только если указанный файл существует.
Всегда имейте в виду, что у Ansible много модулей и наиболее распространенные операции не требуют использования модуля command. Например, есть модули для создания файловых систем, изменения правил iptables и управления заданиями cron. По-умолчанию, все эти модули идемпотентны, так что вы всегда должны отдавать предпочтение им.
3 — Использование Ansible модуля setup для сбора информации о ваших хостах
Вероятно, вы видели, что первое, что Ansible делает, когда выполняет плейбук — это что-то типа этого:
Это происходит потому что Ansible вызывает специальный модуль setup перед выполнением первой задачи. Модуль setup коннектится на хост и собирает факты всех видов: IP адрес, дисковое пространство, архитектура процессора, доступная память и многое другое. Может быть полезным вызов этого модуля вручную, как быстрый способ сбора информации о ваших хостах. Чтобы сделать это — просто выполните команду:
4 — Вы можете отобразить все задачи плейбука
Хотите вспомнить, что делает плейбук? Выполните ansible-playbook используя флаг —list-tasks и Ansible отобразит все имещиеся задачи:
5 — Используйте ansible-vault, если вы хотите хранить конфиденциальную информацию
Если одна из ваших задач требует конфиденциальной информации (скажем, доступы в базу данных), хорошей практикой является хранение этой информации в зашифрованном виде, вместо того, чтобы хранить ее открытым текстом.
Ansible поставляется с утилитой командной строки ansible-vault, которая позволяет создавать и управлять шифрованными файлами. Таким образом, вы можете «коммитить» зашифрованный файл в вашу систему управления версиями и только пользователи с паролем дешифрования смогут прочесть его.
Если вы импортируете файл secrets.yml в ваш плейбук, Ansible «зафейлится», так как не будет знать как прочесть зашифрованный файл. Вам необходимо указать аргумент командной строки —ask-vault-pass, который заставит Ansible предложить ввести пароль для зашифрованного файла.
Другой способ заключается в хранении пароля в файле (он не должен быть «закоммичен») и указать путь к файлу, используя аргумент —vault-password-file. Если этот файл исполняемый, Ansible будет запускать его и использовать вывод в качестве пароля.
Узнать больше о ansible-vault можно тут.
6 — Использование with_items может быть хорошей идеей
При использовании with_items, Ansible создаст переменную <
7 — Как работают Local Actions
Иногда вам может понадобиться выполнить задачу на вашем локальном хосте, вместо запуска её на удаленном хосте. Это может быть полезно, если мы хотим подождать, пока сервер загрузится (если он только что запущен), или когда мы хотим добавить некоторые узлы в пул балансировщика (или удалить их):
Пример ниже показывает как запустить EC2 инстанс и дождаться, когда он станет доступен:
8 — Вы можете указать Ansible выполнять задачу только один раз
Иногда вам может понадобиться выполнить задачу только один раз, даже при наличии нескольких хостов. В качестве примера, скажем, у вас есть несколько серверов с приложениями, которые коннектятся к той же базе данных и у вас есть задача, которая производит миграцию базы. В этом случае вам необходимо выполнить эту задачу только один раз.
Что бы добиться этого, вы можете использовать параметр run_once, указывающий Ansible выполнять команду только один раз:
9 — Обработчики (handlers) это специальные типы задач
Обработчики (handlers) это задачи с уникальными именами, которые будут выполняться только в случае уведомления от другой задачи. Они очень удобны для перезапуска сервисов или перезагрузки системы.
Обработчики, которые были уведомлены, будут выполняться один раз в конце плейбука несмотря на то, как много раз они были уведомлены. Вы можете объявить их используя handler и вызвать с помощью notify.
Вот пример того, как перезапустить 2 сервиса, когда содержимое файла изменяется, но только в том случае, если файл изменяется (пример взят из Ansible docs).
Обработчики должны быть объявлены где-нибудь в вашем плейбуке:
10 — Ускорение с помощью конвейеризации (pipelining)
Несколько советов, о том как заставить Ansible выполняться еще быстрее:
Однако, вы должны быть осторожны. Конвейеризация будет работать только если опция requiretty отключена на всех удаленных хостах в файле sudoers (/etc/sudoers).
С другой стороны, если вам необходимо использовать Ansible факты (автоматически собранные модулем setup) вы можете закэшировать их, что бы последующие выполнения были быстрее. Если вы хотите узнать больше, документация Ansible подробно охватывает это здесь.
11 — У Ansible есть несколько модулей для уведомлений
Используете Ansible для автоматизации ваших blue-green деплоев (blue-green deployment)? Запускаете плейбуки для «провиженинга» новых инстансов AWS? Дайте знать об этом вашей команде, с помощью одного из модулей для уведомлений. В качестве примера, задача ниже отправит уведомление в Slack:
Также доступны модули для уведомления в irc, twillio, hipchat, jabber и много других.
12 — EC2 инстансы автоматически группируются по их тегам
При использовании Amazon Web Services и Ansible EC2 скрипта динамической инвентаризации, все инстансы будут сгруппированы основываясь на их характеристиках, таких как тип, кейпары и теги. EC2 теги это просто ключ=значение ассоциированное с вашими инстансами, которые вы можете использовать как вам угодно. Некоторые используют метки, чтобы сгруппировать production/staging сервера, для обозначения web-серверов или «активных» серверов во время blue-green деплоев.
EC2 Dynamic Inventory скрипт использует следующий шаблон (без скобок) при группировке хостов по тегу:
Так что, если вы хотите выполнить задачу на всех узлах с тегом env=staging, просто добавьте это в ваш плейбук:
Чтобы сделать это еще более интересным, вы можете использовать шаблоны Ansible, конкретизировав, какие хосты должны быть затронуты. Например, если вы хотите выполнить определенную задачу на ваших production db серверах (при условии, что они обозначены должным образом), вы можете использовать перекрестный шаблон ( :& ), как здесь:
13 — Вы можете выполнять задачи в режиме «Dry Run»
Ansible поддерживает запуск плейбука в режиме dry run (также называемый Check Mode).
В этом режиме Ansible не будет вносить никаких изменений на вашем хосте, а просто сообщит, какие изменения будут сделаны, если бы плейбук был запущен без этого флага.
Хоть это и полезно в некоторых сценариях, но может не работать должным образом, если ваших задачах используются условия.
14 — Задачи могут выполняться шаг за шагом
Иногда, вы не хотите выполнять все задачи вашего плейбука.
Это распространенное решение, когда вы пишете новый плейбук и хотите проверить его.
Ansible предоставляет способ, который позволит вам решить, какие задачи вы хотите запустить, используя флаг —step.
Это позволит вам выбирать, хотите ли вы выполнить задачу ( y ), пропустить ее ( n ) или ( c ) продолжить не спрашивая.
15 — Можно выполнять задачи основываясь на их тегах
Вы можете добавить один или несколько тегов к задаче или плейбуку.
Чтобы сделать это, просто отметьте, что вы хотите «тегировать» с помощью атрибута tags:
Позже вы можете решить какие теги выполнить или пропустить используя флаг
—tags tagname (или просто -t) и —skip-tags tagnames:
Можно указать более одного тега, разделяя их запятыми.