Зачем две папки с переменными в роли Ansible нужны

Роль папок defaults и vars в Ansible

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

Основное назначение и приоритет

Главное различие между ними заключается в приоритете (precedence) и назначении переменных, которые в них хранятся. Ansible имеет строгую иерархию загрузки переменных, где vars имеют более высокий приоритет, чем defaults.

Приоритет (низший -> высший):
defaults/ <--- (1) Значения по умолчанию, самые низкие
vars/     <--- (2) Фактические значения роли, переопределяют defaults
... (далее идут более высокие приоритеты, например, group_vars, host_vars, extra_vars в playbook)

Таким образом, переменные из vars/ всегда переопределят переменные с тем же именем из defaults/. Это не баг, а фича, заложенная в дизайн системы.

Детальное сравнение

1. Директория defaults/main.yml

Это значения по умолчанию для вашей роли. Их основная цель — обеспечить работоспособность роли "из коробки" с минимальной конфигурацией.

• Низкий приоритет: Они предназначены для того, чтобы их переопределяли.
• Документация: Фактически, defaults/main.yml служит документом, описывающим все настраиваемые параметры роли. При просмотре этого файла пользователь сразу видит, что можно изменить.
• Безопасность: Сюда помещаются безопасные значения, которые подходят для большинства сред. Например, порт веб-сервера или версия пакета.
• Пример (roles/nginx/defaults/main.yml):

  # Эти значения ДОЛЖНЫ быть переопределены для продакшена
  nginx_port: 80
  nginx_worker_processes: "auto"
  nginx_install_from_repo: true
  nginx_package_name: "nginx"
  

2. Директория vars/main.yml

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

• Высокий приоритет: Они переопределяют defaults и должны быть окончательными для внутренней работы роли.
• Внутренняя логика: Сюда выносится сложная логика, например, определение имени пакета в зависимости от ОС, или статические значения, которые не должны меняться.
• Защита от изменений: Если переменная критична для работы роли (например, путь к конфигурационному файлу или имя системного пользователя), её помещают в vars/, чтобы пользователь не переопределил её случайно на низкоуровневом уровне (defaults или group_vars). Для переопределения таких переменных ему придётся использовать механизмы с более высоким приоритетом (например, extra_vars через -e в командной строке), что является сознательным и явным действием.
• Пример (roles/nginx/vars/main.yml):

  # Эти переменные определяют внутреннюю работу роли
  nginx_config_path: "/etc/nginx/nginx.conf"
  nginx_service_name: "nginx"
  # Динамическое определение для разных ОС
  nginx_package_map:
    RedHat: "{{ nginx_package_name }}"
    Debian: "{{ nginx_package_name }}"
    Suse: "nginx-{{ nginx_version }}"
  

Практический паттерн использования

Стандартный паттерн, который иллюстрирует мощь этого разделения:

1. В defaults/main.yml вы объявляете пользовательскую настройку:

   app_version: "1.0.0"
   

2. В vars/main.yml вы вычисляете на её основе внутренние параметры, которые используете в задачах:

   app_download_url: "https://example.com/app-{{ app_version }}.tar.gz"
   app_install_dir: "/opt/app-{{ app_version }}"
   

3. В tasks/main.yml вы используете переменную из vars:

   - name: Download application
     ansible.builtin.get_url:
       url: "{{ app_download_url }}"  # Используется вычисленная переменная
       dest: "/tmp/"
   

Почему это работает? Пользователь может легко изменить app_version в group_vars или extra_vars. Это новое значение будет подставлено в формулу app_download_url, определённую в vars/, и задача скачает нужную версию. При этом сама логика формирования URL защищена от случайного изменения, так как находится в vars/.

Заключение

Разделение на defaults и vars — это фундаментальный принцип разработки хороших ролей Ansible:

• defaults — это публичный API вашей роли, интерфейс для пользователя. Всё, что здесь есть, можно и нужно менять.
• vars — это приватная логика роли, её "движок". Эти переменные задают внутреннюю работу, и их изменение должно быть осознанным действием.

Это разделение приводит к:

• Повышенной поддерживаемости: Чёткое разделение ответственности.
• Удобству для пользователя: Все "крутилки" и "настройки" роли видны в одном файле.
• Надёжности: Критичная для работы логика защищена от случайного переопределения.
• Гибкости: Роль можно кастомизировать в очень широких пределах, не ломая её внутреннюю механику.

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