Где в Ansible хранить переменные?

Подход к хранению переменных в Ansible

В Ansible переменные могут храниться в различных местах, и понимание их иерархии приоритетов — ключ к грамотной организации конфигурации. Места хранения переменных можно разделить на группы по их назначению и контексту использования. Я всегда ориентируюсь на принцип «от общего к частному» и логическую структуру данных.

Основные источники переменных

Уровень проекта (Playbook)

• Файлы переменных .yml в директориях group_vars/ и host_vars/. Это основной и наиболее структурированный способ.

  # group_vars/all/app_settings.yml
  app_name: "my_application"
  app_version: "2.5.1"
  users:
    - name: alice
      role: admin
    - name: bob
      role: user
  

• Инлайн-переменные в самом Playbook (vars:), удобно для небольших, локальных значений.

  - hosts: webservers
    vars:
      http_port: 80
      max_clients: 200
    tasks:
      - name: Ensure Apache is at the latest version
        ansible.builtin.yum:
          name: httpd
          state: latest
  

• Файлы переменных, подключаемые директивой vars_files:. Хорошо подходит для чувствительных данных, вынесенных в отдельные файлы (но не для секретов!).

Уровень инвентари (Inventory)

• Переменные, объявленные прямо в файлах инвентари (INI или YAML формат).

  [web:vars]
  nginx_listen_port=8080
  deployment_env=staging
  
  [db]
  db01.example.com ansible_host=192.168.1.10 db_role=master
  

• Специальные папки, привязанные к группам и хостам: group_vars/webservers.yml, group_vars/db.yml, host_vars/hostname.yml. Ansible автоматически загружает их при запуске плейбука.

Уровень выполнения (Runtime)

• Файлы с паролями и секретами (--extra-vars @vars.yml). Никогда не храните пароли или ключи в plain text файлах, используйте ansible-vault.

  # Командная строка
  ansible-playbook deploy.yml --extra-vars "deploy_tag=v1.4"
  
  # Из файла (удобно для CI/CD)
  ansible-playbook deploy.yml --extra-vars "@production_vars.yml"
  
  # Использование vault
  ansible-playbook deploy.yml --extra-vars "@secrets.yml" --ask-vault-pass
  

  # secrets.yml (зашифрован с помощью ansible-vault encrypt secrets.yml)
  db_password: !vault |
        $ANSIBLE_VAULT;1.1;AES256
        366537306261623862336334...
  

Уровень системы и пользователя

• Facts, собираемые модулем setup. Это системная информация о целевом хосте (ОС, память, сеть). Используются как есть или дополняются через custom facts.

  - name: Print distribution
    debug:
      msg: "Это {{ ansible_distribution }} версии {{ ansible_distribution_version }}"
  

• Ролевые переменные (Role variables), определенные в roles/myrole/vars/main.yml и roles/myrole/defaults/main.yml. Переменные из defaults имеют самый низкий приоритет и предназначены для значений по умолчанию, которые легко переопределить. Переменные из vars — фиксированные для роли.

Моя практика и рекомендации

При работе с крупными проектами я устанавливаю строгие соглашения:

1. Структура каталогов:

   inventory/
   ├── production/
   │   ├── group_vars/
   │   │   ├── all/
   │   │   │   ├── common.yml
   │   │   │   └── vault.yml
   │   │   └── webservers.yml
   │   └── host_vars/
   ├── staging/
   ├── hosts
   ... 
   

2. Разделение по типам данных:

    *   **`group_vars/all/common.yml`** — общие настройки проекта (версии пакетов, пути установки).
    *   **`group_vars/app/environment.yml`** — настройки, специфичные для окружения (`staging`, `prod`).
    *   **`group_vars/*/vault.yml`** — все чувствительные данные, зашифрованные через `ansible-vault`. Файл `.gitignore` должен включать незашифрованные файлы с паролями.

1. Управление версиями и окружениями: Я использую разные инвентари-файлы (production, staging) для полного разделения окружений. Это безопаснее, чем полагаться на одну переменную env.
2. Использование ansible-vault для секретов — это обязательное требование безопасности. Ключи или пароли от vault передаются через защищенные переменные окружения CI/CD (например, ANSIBLE_VAULT_PASSWORD_FILE).
3. Переменные из командной строки (--extra-vars) я применяю для:

    *   Экстренного переопределения в дебаге.
    *   Передачи динамических параметров из скриптов или пайплайнов сборки (например, номера сборки `build_number`).

Выбор места зависит от области видимости (хост, группа, все), чувствительности данных и типа окружения. Главное — соблюдать консистентность и документировать принятую структуру в README.md проекта, чтобы команда могла легко в ней ориентироваться.