Внешние pillar

External pillar — механизм, который позволяет собирать pillar-данные из внешних систем, таких как git-репозиторий, HashiCorp Vault, Consul, etcd, SQL-база или HTTP-эндпоинт, отдающий JSON, вместо использования SLS-файлов на диске мастера. Внешний модуль выполняется на мастере, получает id конкретного миньона и возвращает словарь только для него. Миньон не может дотянуться до внешней системы напрямую. Это отличает external pillar от прямого скачивания конфига с помощью curl в state: учётные данные для доступа к Vault или базе есть только у мастера, миньоны ими не обладают. External pillar превращает pillar из статического дерева файлов в интерфейс: SLS-файлы остаются для рукописных данных, а всё, что уже живёт в CMDB, хранилище секретов или инвентори, подключается на лету.

Как это работает

Внешние источники объявляются в конфигурации мастера списком ext_pillar:

ext_pillar:
  - git:
      - main https://git.example.com/pillar.git
  - vault: path=secret/salt

Каждый элемент — имя pillar-модуля и его параметры. Модулей в комплекте десятки (их перечень — в индексе salt.pillar.* документации). При компиляции pillar мастер сначала рендерит обычное дерево из pillar_roots, затем по порядку вызывает каждый ext_pillar-модуль, передавая ему minion id и уже собранный словарь. Результаты сливаются в общую структуру. Порядок можно обратить опцией ext_pillar_first: True — тогда файловый pillar накладывается поверх внешнего и может переопределять его значения. Для миньона всё прозрачно: pillar.items показывает объединённый результат, и saltutil.refresh_pillar нужен после изменений во внешнем источнике точно так же, как после правки файлов. Свой источник пишется как Python-модуль с функцией ext_pillar(minion_id, pillar, *args), возвращающей словарь; кладётся он в каталог из extension_modules мастера.

Когда применять

Подключайте external pillar, когда данные уже имеют другой источник истины и копировать их в SLS-файлы означало бы вечную рассинхронизацию. Типовые сценарии: секреты в Vault (ротация и аудит на стороне хранилища), pillar-репозиторий в git без выкладки файлов на мастер (модуль git — фактический стандарт для команд с ревью через PR), параметры хостов из CMDB или базы, динамические списки из service discovery. Если же данные статичны и правятся руками, обычные SLS проще: их видно целиком, они не зависят от доступности внешних сервисов. Смешанная схема — норма: файлы для структуры и несекретных значений, Vault для паролей.

Типичные ошибки

Главный риск — доступность: недоступный Vault или битый git-репозиторий означает неполный pillar, и state.apply начнёт падать на недостающих ключах (или, что хуже, молча применит дефолты из pillar.get). Закладывайте мониторинг источников и осмысленные default'ы. Вторая ошибка — конфликты ключей между файловым и внешним pillar: кто кого перезапишет, зависит от ext_pillar_first и стратегии слияния, и отлаживать это вслепую мучительно — держите пространства ключей раздельными. Третья — медленный внешний источник: он вызывается при каждой компиляции pillar каждого миньона, и task-очередь мастера деградирует; смотрите в сторону кэширования. Наконец, не забывайте, что refresh_pillar нужен и после изменений во внешней системе.

Связанные понятия

• Pillar
• Секреты в pillar
• Интеграция с Vault
• GitFS
• Конфигурация master