Налаштування централізованого управління конфігурацією через 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 команд в секунду.