Настройка централизованного управления конфигурацией через SaltStack

Представьте: у вас 500 хостов, и каждое утро надо обновить конфигурацию Nginx на всех. Ansible по SSH делает это за 15 минут — SaltStack решает задачу за 2-3 секунды. Его асинхронный транспорт на ZeroMQ даёт push-модель с миллисекундной задержкой, а event-driven реактор автоматически применяет конфигурацию при появлении новой ноды. Мы внедрили SaltStack в десятках проектов с инфраструктурой до 5000 хостов. В этой статье разберём, как настроить Master-Minion кластер, написать State-файлы и использовать Reactor для автоматизации. Получите консультацию нашего инженера — разберём вашу инфраструктуру и подберём оптимальную архитектуру SaltStack.

Почему SaltStack до 300 раз быстрее Ansible?

SaltStack использует push-модель через ZeroMQ, отправляя команды на все миньоны одновременно. Ansible работает через SSH — каждое соединение создаётся последовательно. Для 1000 нод SaltStack применяет конфигурацию за 1-2 секунды, Ansible — за 15 минут. Это делает SaltStack незаменимым для динамической инфраструктуры с частыми изменениями.

Ключевые проблемы, которые решает SaltStack

Проблема 1: Синхронизация тысяч серверов. При push-модели Salt мастер может разослать конфигурацию на 5000 нод за 2-3 секунды. Никакого SSH-цикла.

Проблема 2: Гибкая маршрутизация по окружениям. Grains и Pillar позволяют применять конфигурацию только к нужным ролям (web, db, monitoring) без создания отдельных inventory.

Проблема 3: Реакция на события в реальном времени. Reactor ловит события с Event Bus и автоматически запускает действия — например, при появлении новой ноды сразу применить hardening.

Как мы настраиваем SaltStack: кейс из практики

Однажды мигрировали инфраструктуру из 300 хостов с ручного управления на Salt. За 2 недели развернули Master (выделенный сервер с 8 vCPU), настроили auto_accept: false и применили ключи через salt-key. Настроили базовые state для установки Zabbix agent, hardening SSH, монтирования NFS. Использовали salt-run state.orch для оркестрации — позволило применить изменения на все ноды за 1 минуту.

Детали кейса: типы нод и сложности. Были ноды на CentOS 7, Ubuntu 20.04 и Debian 11. Для разных ОС пришлось разделить состояния через grains: {% if grains['os'] == 'CentOS' %}...{% endif %}. Pillar использовали для хранения паролей от Zabbix и SSH-ключей. Основная сложность — legacy-серверы с нестандартными путями к логам. Описали каждый вручную, затем вынесли в Pillar, упростив поддержку.

Архитектура: Master, Minion, ZeroMQ

Salt работает через ZeroMQ: Salt Master слушает на портах 4505 (publish) и 4506 (return). Minion-демон на каждом хосте подписывается на 4505 и ждёт команд. Это даёт push-модель с практически нулевой задержкой. Базовая установка Master и Minion:

# На мастере (RHEL/CentOS)
rpm --import https://repo.saltproject.io/salt/py3/redhat/9/x86_64/SALT-PROJECT-GPG-PUBKEY-2023.gpg
curl -fsSL https://repo.saltproject.io/salt/py3/redhat/9/x86_64/latest.repo | tee /etc/yum.repos.d/salt.repo
dnf install salt-master
# На каждом управляемом хосте
dnf install salt-minion

/etc/salt/master — основной конфиг. Ключевые параметры:

interface: 0.0.0.0
file_roots:
  base:
    - /srv/salt
  production:
    - /srv/salt/production
    - /srv/salt/base
pillar_roots:
  base:
    - /srv/pillar
auto_accept: false # принимать ключи минионов только вручную
worker_threads: 10

На каждом minion: /etc/salt/minion:

master: salt-master.internal id: web-01.internal 

После старта minion отправляет публичный ключ мастеру. Принять все ожидающие ключи: salt-key -A. Команда salt '*' test.ping должна вернуть True со всех нод.

Как написать свой первый State-файл?

State-файлы — основа SaltStack. Пример установки и настройки nginx:

# /srv/salt/nginx/init.sls
nginx:
  pkg.installed:
    - name: nginx
  service.running:
    - enable: True
    - watch:
      - file: /etc/nginx/nginx.conf
/etc/nginx/nginx.conf:
  file.managed:
    - source: salt://nginx/files/nginx.conf.j2
    - template: jinja
    - user: root
    - group: root
    - mode: 644

Шаблон nginx.conf.j2 использует Jinja2 и переменные из Pillar. Pillar хранит чувствительные данные, специфичные для хостов. Привязка через top.sls:

# /srv/pillar/top.sls base: 'web-*': - nginx 'db-*': - postgresql 'G@role:kubernetes-worker': - k8s-worker 

Применить state на группу:

salt 'web-*' state.apply nginx salt -G 'role:webserver' state.highstate 

What is Pillar and how to configure it?

Pillar — это secure data store для конфиденциальных данных: паролей, ключей, настроек, специфичных для хостов. Pillar-файлы пишутся в YAML, привязываются к minion по ID или grains через top.sls. Например, можно хранить разные пароли БД для разных окружений. В отличие от Grains, Pillar не отправляется на minion автоматически — мастер передаёт только те данные, которые разрешены для конкретного minion.

Grains и таргетинг

Grains — факты о minion: OS, CPU, память, IP-адреса, кастомные атрибуты. Таргетинг по grains:

salt -G 'os:Ubuntu' cmd.run 'apt-get update' salt -C 'G@os:CentOS and I@role:database' state.apply postgresql 

Кастомные grains размечают серверы по ролям, окружениям, датацентрам — применяйте конфигурацию точечно.

Reactor: событийная автоматизация

Реактор подписывается на события Salt Event Bus и запускает actions. Пример: новый minion аутентифицировался — автоматически применить базовый hardening:

# /etc/salt/master.d/reactor.conf
reactor:
  - 'salt/auth':
    - /srv/reactor/auth.sls

# /srv/reactor/auth.sls
{% if data['act'] == 'accept' %}
apply_base_state:
  local.state.apply:
    - tgt: {{ data['id'] }}
    - arg:
      - base-hardening
{% endif %}

Сравнение SaltStack и Ansible

Почему стоит доверять настройку профессионалам?

SaltStack — мощный, но требовательный к проектированию. Наши инженеры с 10+ летним опытом в DevOps гарантируют отказоустойчивую архитектуру, правильную сегментацию окружений и оптимальную производительность. Мы предоставляем:

• Полную документацию: схемы, конфиги, runbook по инцидентам.
• Обучение команды: 3-дневный воркшоп по написанию State-файлов и использованию Reactor.
• SLA поддержки: реагирование на сбои в течение 1 часа.

Средний ROI внедрения SaltStack составляет 6-12 месяцев за счёт сокращения времени простоев и автоматизации рутинных задач.

Сроки и что входит в работу

Ориентировочные сроки: от 2 до 3 недель на инфраструктуру до 500 нод. Стоимость рассчитывается индивидуально — свяжитесь с нами для точной оценки. Получите консультацию нашего DevOps-инженера: разберём вашу инфраструктуру и предложим оптимальное внедрение SaltStack. Закажите пилотный проект на 10 хостах уже сегодня.

Типичные ошибки при самостоятельной настройке

• Auto_accept: true — опасная уязвимость: любой поднятый minion получит доступ к мастеру. Всегда используйте ручное принятие ключей.
• Плохая структура Pillar — смешивание секретов и ролей приводит к утечкам. Используйте отдельные корни для разных сред.
• Игнорирование reactor — без него Salt лишь половина возможностей. Настройте хотя бы базовые события.

Чтобы избежать этих проблем, доверьте настройку нашей команде. Мы уже реализовали успешные проекты в финансовом секторе и ритейле. Свяжитесь с нами, чтобы обсудить ваши задачи.

Согласно документации SaltStack, архитектура через ZeroMQ обеспечивает производительность до 10000 команд в секунду.