Help

Почему FQDN — это стандарт?

Защита от конфликтов (Изоляция): Ansible начиная с 4-й версии стал модульным. Все встроенные модули уехали в коллекцию ansible.builtin. Если ты скачаешь стороннюю коллекцию (например, для работы с облаком или Docker) и там окажется модуль с названием copy, Ansible без FQDN может запутаться, какой именно модуль ты имел в виду. FQDN четко говорит: «Возьми именно встроенный модуль Ansible»

Скорость работы (Парсинг): Когда ты пишешь ansible.builtin.file, Ansible сразу знает, где искать этот модуль. Если написать просто file, движку приходится тратить время и перебирать все установленные коллекции в поисках совпадения

Ansible Lint (Линтеры): Все современные автоматические проверяльщики кода (линтеры) будут ругаться и сыпать варнингами, если увидят короткие имена. В приличных компаниях такой код просто не пройдет CI/CD проверку

Исключение из правил: Короткие имена до сих пор часто пишут в личных быстрых плейбуках, статьях в интернете или в ad-hoc командах в консоли (ansible all -m ping), просто чтобы экономить время на наборе текста. Но в продакшн-код пиши строго FQDN

Эта строчка включает сбор фактов об удаленных хостах перед выполнением задач. В этот момент Ansible автоматически запускает специальный модуль (обычно setup), который собирает кучу полезной информации о целевой системе:

• IP-адреса, сетевые интерфейсы и хостнейм
• Операционную систему, ее версию и семейство (например, Ubuntu, Debian, RedHat)
• Данные о железе: объем оперативки, количество ядер процессора, размер дисков
• Переменные окружения и конфигурацию сети

Все эти данные сохраняются в переменные (например, ansible_facts.os_family) и их можно использовать в плейбуке, чтобы гибко настраивать условия (например: «если ОС — Ubuntu, ставь через apt, если CentOS — через dnf»). По умолчанию эта опция всегда true. Отключают ее (gather_facts: false) только ради экономии времени, когда эти данные в процессе выполнения не нужны