Salt Mine

Salt Mine — это механизм обмена данными между миньонами через мастера. Проблема, которую он решает, проста: миньоны не видят друг друга. Когда шаблон конфигурации балансировщика должен перечислить IP-адреса всех бэкендов, взять их неоткуда — grains и pillar каждого миньона доступны только ему самому. Mine закрывает этот разрыв: каждый миньон периодически выполняет заранее объявленные функции (например, network.ip_addrs) и отправляет результат в кэш на мастере, а любой другой миньон достаёт эти данные функцией mine.get — чаще всего прямо в Jinja-шаблоне SLS-файла или конфига.

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

Настройка состоит из двух частей. Первая — объявить, что миньон публикует: в конфигурации миньона или, что удобнее, в pillar задаётся mine_functions — словарь функций с аргументами, например network.ip_addrs: [interface: eth0]. Интервал обновления задаёт опция mine_interval (по умолчанию 60 минут); обновить данные принудительно можно командой salt '*' mine.update. Вторая часть — чтение: salt['mine.get']('roles:backend', 'network.ip_addrs', tgt_type='grain') в Jinja вернёт словарь «идентификатор миньона → результат». Таргет в mine.get поддерживает те же типы, что и обычный таргетинг: glob, grains, compound. Ключевой момент: данные приходят из кэша мастера, а не запрашиваются с живых миньонов в момент вызова — поэтому mine.get быстрый и работает даже когда часть источников выключена, но данные настолько свежи, насколько давно было последнее обновление.

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

Канонический случай — автосборка конфигурации балансировщика: миньоны с grain roles: backend публикуют свои адреса, а состояние на балансировщике рендерит upstream-блок через mine.get и пересобирает конфиг при появлении нового бэкенда. Тот же паттерн работает для кластеров (список пиров для распределённых систем), для генерации /etc/hosts или списков мониторинга. Правило выбора такое: grains — факты миньона о себе, pillar — данные мастера для миньона, mine — данные миньонов друг о друге. Если значение статично и известно заранее — кладите его в pillar, mine не нужен; mine оправдан, когда данные динамические и их источник — сами машины. Для реакции на события в реальном времени mine не подходит — это ниша beacons и Reactor.

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

Главный источник недоумения — устаревший кэш: новый бэкенд уже поднялся, а балансировщик его «не видит», потому что mine обновится только через mine_interval; в автоматизации ввода узлов добавляйте явный mine.update. Вторая ошибка — забыть, что mine.get таргетирует по данным кэша: миньон, ни разу не отправивший mine-данные, в выборку не попадёт, и ошибки не будет — просто молчаливо неполный список. Третья — публиковать в mine чувствительные данные: их сможет прочитать любой миньон, которому доступен mine.get; секретам место в pillar с его адресной доставкой. Наконец, не превращайте mine в свалку: каждая функция выполняется на каждом миньоне регулярно, и тяжёлые вызовы умножаются на размер парка.

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

• Grains
• Pillar vs grains
• Jinja в SLS
• Шаблоны file.managed
• Таргетинг миньонов