Готовые формулы

Тема дорожной карты · SaltStack

GitHub-организация saltstack-formulas содержит общественный каталог готовых формул для типового ПО, таких как nginx, PostgreSQL, Docker, users, sudoers и chrony. Каждый репозиторий назван по схеме <имя>-formula и следует официальным конвенциям, поэтому подключение и настройка одинаковы для всех. Готовая формула экономит время, решая уже известные проблемы: различия в именах пакетов и путях между os_family, порядок установки «пакет → конфиг → сервис», перезапуск сервиса при изменении конфигурации. Однако это код от сообщества с неравномерной поддержкой, исполняемый на ваших серверах с правами root, поэтому его стоит подключать осознанно: с ревью, пиннингом версии и настройкой через pillar.

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

Подключение формул осуществляется двумя способами. Первый: клонировать репозитории в каталог на мастере и перечислить каждую формулу в file_roots:

file_roots:
  base:
    - /srv/salt
    - /srv/formulas/nginx-formula

Второй, удобнее для команды: добавить каждый репозиторий в gitfs_remotes — мастер сам будет тянуть код, а версию можно зафиксировать с помощью параметров per-remote. Дальше формула включается в top.sls (- nginx) или через include в ваших SLS. Настройка — только через pillar: в корне формулы лежит pillar.example со всеми поддерживаемыми ключами; его копируют в своё pillar-дерево, подключают в pillar top file и правят значения. Прочитать, как формула превращает pillar в конфиги, можно по её map.jinja и defaults.yaml. Для старта собственных формул есть каркас template-formula — репозиторий-шаблон с уже размеченной структурой и тестами.

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

Брать готовую формулу разумно для распространённого ПО со сложной вариативностью: многодистрибутивные инсталляции, сервисы с десятками настроек, где чужой отлаженный код заведомо полнее наскоро написанного своего. Рабочая практика для продакшена — форкнуть формулу в свою организацию и подключать форк: это защищает от внезапных изменений upstream и от исчезновения репозитория, а обновления затягиваются осознанным merge. Писать своё вместо готового стоит, когда задача простая (один пакет, один шаблон конфига — свой SLS короче, чем изучение опций формулы), когда формула давно не обновлялась под актуальные версии ОС, или когда вам нужно 5% её функциональности — универсальность имеет цену в читаемости.

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

Главная ошибка — не пиннить версию: подключили ветку master чужого репозитория через gitfs, и очередной чужой коммит поменял конфигурацию вашего продакшена. Вторая — не прочитать pillar.example целиком: часть формул требует обязательных ключей и без них падает на рендере, а часть молча применяет дефолты, которые вам не подходят. Третья — править файлы формулы напрямую под свою специфику: локальные патчи делают обновление невозможным; правильный путь — pillar-переопределения, а если их не хватает, то PR в upstream или осознанный форк. И проверяйте активность репозитория перед подключением — дата последнего коммита и открытые issue скажут больше, чем количество звёзд.

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

Полезные ресурсы

🔤 Английские термины в этой теме

Слова из этой темы, которые русскоязычные часто произносят неверно. Кнопка 🔊 произносит голосом браузера.

Весь словарь терминов →