SaltStack: управление конфигурациями 100+ серверов из единой точки

Меня зовут Семёнов Евгений Сергеевич, директор АйТи Фреш. За 15+ лет в корпоративной IT я видел все подходы к управлению конфигурациями — от тетрадки админа с паролями до enterprise Puppet. И когда клиентский парк переваливает за 50 серверов, а команда — за 3 человека, нужна автоматизация. SaltStack у нас закрывает эту задачу на сотнях узлов в дата-центрах МТС и клиентских локациях. Покажу, как мы строим Salt-инфраструктуру с нуля.

Зачем нужен configuration management

Пока у вас 5-10 серверов, ручная настройка через SSH работает. С ростом парка появляются типовые проблемы:

• На двух серверах разная версия PHP, и баг воспроизводится только на одном.
• Уволился админ — конфиги nginx на 80 серверах разные, никто не помнит почему.
• Новый аудит ФСТЭК требует sshd_config единого образца на всех узлах.
• Деплой приложения занимает 2 часа ручной работы, вместо 2 минут автоматической.

Salt это решает декларативным описанием желаемого состояния — файлы SLS с нужной конфигурацией. Minion проверяет и приводит систему к этому состоянию.

Архитектура: master и minion

Центральный сервер — Salt Master. На управляемых серверах крутится salt-minion, который держит постоянное ZeroMQ-соединение с мастером через порты 4505 (pub/sub) и 4506 (req/rep). Команды летят в миллисекунды.

Для малой инфраструктуры (до 100 minions) хватает одного master на 4 vCPU / 8 ГБ RAM. Для больших — Syndic (промежуточный мастер) или multi-master. У нас на практике продакшен стоит на Dell PowerEdge с Xeon Platinum 8280 и 40G Mellanox — master обслуживает ~1200 minion без заметной нагрузки.

Установка master на Ubuntu 24.04

curl -fsSL https://repo.saltproject.io/salt/py3/ubuntu/24.04/amd64/SALT-PROJECT-GPG-PUBKEY-2023.pub | \
  sudo gpg --dearmor -o /usr/share/keyrings/salt-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/salt-archive-keyring.gpg] \
  https://repo.saltproject.io/salt/py3/ubuntu/24.04/amd64/latest noble main" | \
  sudo tee /etc/apt/sources.list.d/salt.list

apt update && apt install -y salt-master
systemctl enable --now salt-master

Базовый /etc/salt/master:

interface: 0.0.0.0
worker_threads: 10
timeout: 10
file_roots:
  base:
    - /srv/salt
pillar_roots:
  base:
    - /srv/pillar
auto_accept: False
fileserver_backend:
  - roots
  - git

Установка minion и принятие ключей

# На каждом управляемом сервере
apt install -y salt-minion
echo "master: salt.corp.example.ru" > /etc/salt/minion.d/master.conf
echo "id: web01.corp.example.ru" >> /etc/salt/minion.d/id.conf
systemctl enable --now salt-minion

# На master принимаем ключи
salt-key -L                  # список
salt-key -a 'web01.corp.example.ru'
salt-key -A                  # принять все

# Проверка связи
salt '*' test.ping
salt 'web*' cmd.run 'uptime'

States: декларативное описание конфигурации

SLS-файл в YAML описывает, что должно быть на сервере. Пример для nginx:

# /srv/salt/nginx/init.sls
nginx-pkg:
  pkg.installed:
    - name: nginx

nginx-config:
  file.managed:
    - name: /etc/nginx/nginx.conf
    - source: salt://nginx/files/nginx.conf.j2
    - template: jinja
    - user: root
    - group: root
    - mode: 644
    - require:
      - pkg: nginx-pkg
    - watch_in:
      - service: nginx-service

nginx-service:
  service.running:
    - name: nginx
    - enable: True
    - require:
      - file: nginx-config

Применение:

salt 'web*' state.apply nginx
salt 'web*' state.apply nginx test=True   # dry-run

Pillars: безопасные параметры

Секреты нельзя хранить в states — их видит любой minion. Для этого есть pillar: master отдаёт данные только тому minion, которому они адресованы.

# /srv/pillar/top.sls
base:
  'web*':
    - web
  'db*':
    - db

# /srv/pillar/web.sls
nginx:
  worker_processes: auto
  worker_connections: 2048
ssl:
  cert_password: 'SuperSecret123'

# Использование в state
{% set nginx = salt['pillar.get']('nginx') %}
worker_processes {{ nginx.worker_processes }};

Highstate — массовое применение всех ролей

Top-файл связывает minion и их роли. После salt '*' state.highstate каждый сервер применяет свою конфигурацию:

# /srv/salt/top.sls
base:
  '*':
    - common.base
    - common.users
    - common.ssh
  'web*':
    - nginx
    - php-fpm
  'db*':
    - postgres
  'role:mail':
    - match: grain
    - postfix
    - dovecot

Реактор и события

Salt event bus — это стрим событий (minion started, state failed, custom). Реактор слушает и реагирует. Например, при загрузке нового minion — автоматически применить базовую конфигурацию:

# /etc/salt/master.d/reactor.conf
reactor:
  - 'salt/minion/*/start':
    - /srv/reactor/onboard.sls

# /srv/reactor/onboard.sls
onboard_new_minion:
  local.state.apply:
    - tgt: {{ data['id'] }}
    - arg:
      - common

Реальный кейс: управление парком веб-хостинга

В апреле 2025 мы внедрили Salt в хостинговой компании — 230 серверов Linux, разнородные дистрибутивы (Debian 11/12, Ubuntu 20/22, Rocky 9). Раньше админы делали всё через скрипты и Ansible — выкатка апдейта PHP занимала целую неделю.

Что сделали:

• Master на Dell R640 с Xeon Platinum 8280 (2 socket), 128 ГБ RAM, 4 NVMe в RAID10, сеть 40G Mellanox в дата-центре МТС.
• Описали 34 роли в states (nginx, php, mysql, postgres, redis, backup-agent, monitoring и т.д.).
• Pillars с шифрованием GPG для паролей и API-ключей.
• Реактор на регистрацию нового сервера — автоматически накатывает базовую конфигурацию.
• Git-backed file_roots — все состояния в GitLab с код-ревью через MR.

Результат: обновление PHP на 180 веб-серверах теперь занимает 12 минут вместо пяти дней. Массовая смена sshd_config — 4 минуты. Стоимость проекта — 480 000 ₽ за 3 недели работ. Окупилось за 2 месяца.

Типовые грабли при работе с Salt

• auto_accept: True в продакшене. Любой с доступом к сети может подкинуть minion и получить pillar.
• Секреты в states, а не в pillars. Видны всем minion, даже тем, кому не положено.
• Без require/watch_in. Порядок выполнения непредсказуем, сервис не рестартится после правки конфига.
• state.apply без test=True. Запустили — снесли прод.
• Игнорирование master_tops и pillar_cache. На 500+ minion master начинает тормозить.
• Нет бэкапа /etc/salt/pki. Потеряли мастер-ключ — перевыписываете все minion вручную.

Мониторинг master и minion

Я всегда настраиваю мониторинг через Zabbix или Prometheus:

FAQ — частые вопросы по SaltStack

Чем SaltStack лучше Ansible?

Salt работает с постоянным агентом через ZeroMQ — на порядок быстрее при управлении сотнями хостов.

Сколько серверов можно обслуживать?

Один master — до 1000-5000 minion.

Работает ли Salt под Windows?

Да, Windows Server 2016+.

Что такое pillar и чем отличается от grains?

Grains — факты minion. Pillars — секретные параметры от master.

Можно ли управлять сетевым оборудованием?

Да, через salt-proxy-minion и NAPALM.