В чем разница между директориями vars и defaults в Ansible?

Различие между vars и defaults в Ansible

В Ansible обе директории используются для хранения переменных, но их концептуальное назначение и приоритет в иерархии переменных кардинально различаются. Понимание этой разницы критически важно для построения гибких, поддерживаемых и переиспользуемых ролей (roles).

Концептуальное назначение

Директория defaults/

Переменные, определённые в defaults/main.yml, являются значениями по умолчанию. Их основная цель — предоставить "запасной" вариант, который будет использоваться, если переменная не была переопределена на более высоком уровне приоритета. Они предназначены для безопасного переопределения.

• Пример из роли nginx:

  # roles/nginx/defaults/main.yml
  nginx_port: 80
  nginx_worker_processes: "{{ ansible_processor_vcpus | default(1) }}"
  

    Здесь `nginx_port` задан как 80, но системный администратор может легко изменить его на 443 в `group_vars` или `host_vars`.

Директория vars/

Переменные в vars/main.yml считаются "жёстко заданными" (hard-coded) или внутренними переменными роли. Они определяют поведение роли по умолчанию, и их не предполагается изменять извне (хотя технически это возможно). Их цель — инкапсулировать логику роли.

• Пример из той же роли nginx:

  # roles/nginx/vars/main.yml
  nginx_conf_path: "/etc/nginx/nginx.conf"
  nginx_package_name: "nginx"
  

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

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

Ключевое практическое различие заключается в месте этих переменных в иерархии приоритетов Ansible. Согласно документации, переменные из defaults имеют самый низкий приоритет (они переопределяются почти всем). Переменные из vars имеют значительно более высокий приоритет.

Упрощённый порядок приоритета (от низшего к высшему):

1. defaults из роли (низший приоритет, легко переопределить)
2. Инвентарные переменные (host_vars, group_vars)
3. Факты (gather_facts)
4. Переменные, заданные в playbook (vars: в play)
5. Переменные, заданные при вызове роли (roles: с vars:)
6. vars из роли (высокий приоритет, сложнее переопределить)
7. Extra vars (через -e в командной строке, высший приоритет)

Рекомендации по использованию на практике

Исходя из опыта, вот мои правила:

• В defaults/main.yml помещайте:

    *   Параметры конфигурации приложения (порты, пути к данным, режимы работы).
    *   Версии ПО, которые могут обновляться.
    *   Любые настройки, которые могут различаться в разных окружениях (dev, stage, prod).
    *   **Правило:** "Если есть вероятность, что это значение захотят изменить — оно должно быть в `defaults`".

• В vars/main.yml помещайте:

    *   Имена пакетов в дистрибутивах ОС (например, словарь `pkg_map`).
    *   Внутренние пути в рамках роли.
    *   Статические данные или "магические" константы, необходимые для логики роли.
    *   **Правило:** "Если это техническая деталь работы самой роли и её изменение сломает логику — помещайте в `vars`".

Пример, иллюстрирующий разницу

Рассмотрим роль для установки веб-сервера.

# defaults/main.yml - ЭТО МОЖНО И НУЖНО МЕНЯТЬ
http_port: 8080
enable_ssl: false

# vars/main.yml - ЭТО ВНУТРЕННЯЯ КУХНЯ РОЛИ
# Эти значения переопределять не планируется
service_name: "my_web_app"
config_template: "web.conf.j2"

# playbook.yml - ПЕРЕОПРЕДЕЛЕНИЕ ДЕФОЛТНЫХ ЗНАЧЕНИЙ
- hosts: webservers
  roles:
    - role: webserver
      vars:
        http_port: 443 # Переопределит значение 8080 из defaults
        enable_ssl: true # Переопределит false из defaults
        # Переменную service_name из vars/main.yml здесь переопределить технически можно,
        # но это потребует более высокого приоритета (например, extra_vars).

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