Внешние pillar

External pillar — механизм, который позволяет собирать pillar-данные не из SLS-файлов на диске мастера, а из внешних систем: git-репозитория, HashiCorp Vault, Consul, etcd, SQL-базы, HTTP-эндпоинта, отдающего JSON. Модель доступа при этом не меняется: внешний модуль выполняется на мастере, получает id конкретного миньона и возвращает словарь именно для него — миньон по-прежнему видит только своё и не может дотянуться до внешней системы напрямую. Это ключевое отличие от «скачать конфиг 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