Обновление OpenSSL на 300 серверах за 2 недели: внедряем SaltStack

Задача клиента: 300 серверов и ручное управление

В январе 2026 года к нам в АйТи Фреш обратился хостинг-провайдер «НордХост» из Санкт-Петербурга. Компания предоставляла услуги VPS и dedicated-серверов для 1 200 клиентов, управляя парком из 300 физических и виртуальных серверов в двух дата-центрах.

Непосредственным поводом для обращения стала критическая уязвимость CVE-2024-9143 в OpenSSL. Команда из четырёх системных администраторов потратила 2 недели на обновление OpenSSL вручную, подключаясь к каждому серверу по SSH. При этом 18 серверов были пропущены, а на 7 обновление сломало конфигурацию nginx из-за несовместимости версий.

«Мы тратили 60% рабочего времени на рутину — обновление пакетов, создание пользователей, раскатку конфигов. При этом у нас не было единого источника правды: что стоит на каждом сервере, какие конфиги, какие версии. Каждый администратор настраивал серверы по-своему» — руководитель IT-отдела «НордХост».

Аудит инфраструктуры и выбор инструмента

Наши инженеры провели аудит и выявили масштаб проблемы:

  • 300 серверов: 180 Ubuntu 22.04, 80 Debian 12, 40 CentOS Stream 9
  • 4 администратора, каждый со своим стилем настройки
  • Bash-скрипты — «автоматизация» через набор bash-скриптов с захардкоженными IP-адресами
  • Нет инвентаря — список серверов в Google Sheets, обновлялся раз в квартал
  • SSH-ключи — у каждого админа свой ключ на каждом сервере, ротации не было 3 года

Мы рассмотрели три системы управления конфигурациями:

КритерийAnsiblePuppetSaltStack
Скорость на 300 узлахМедленно (SSH последовательно)Средне (agent pull)Быстро (ZeroMQ push)
Порог входаНизкийВысокий (свой DSL)Средний (YAML+Jinja)
Real-time executionНетИнтервал 30 минДа (мгновенный push)
Event-driven реакцииНет (без AWX)ОграниченоReactors + Beacons
Масштабируемость~500 узловТысячиДесятки тысяч

Для хостинг-провайдера критичны скорость выполнения (экстренные патчи) и event-driven реакции (автоматическое реагирование на проблемы). SaltStack победил.

Установка Salt Master и Minion

Архитектура Salt проста: Master — центральный сервер управления, Minion — агент на каждом управляемом сервере. Коммуникация через ZeroMQ (порты 4505/4506), шифрование AES-256.

Установка и конфигурация Salt Master

Мы выделили отдельный сервер для Salt Master (Ubuntu 22.04, 8 CPU, 16 GB RAM, SSD):

# Установка Salt 3006 LTS (Sulfur)
curl -o /tmp/bootstrap-salt.sh -L https://bootstrap.saltproject.io
sudo sh /tmp/bootstrap-salt.sh -M -x python3 stable 3006

# Проверяем версию
salt --version
# salt 3006.8 (Sulfur)

# Конфигурация Master
sudo vim /etc/salt/master

Конфигурация /etc/salt/master:

# /etc/salt/master

# Интерфейс — слушаем на внутреннем IP
interface: 10.0.0.1

# Worker threads — по 1 на каждые 50-100 minion
worker_threads: 8

# Таймауты
timeout: 30

# File server
file_roots:
  base:
    - /srv/salt
    - /srv/salt/formulas

# Pillar data
pillar_roots:
  base:
    - /srv/pillar

# Auto-accept minions по определённому паттерну (для автоматизации)
# В продакшене лучше ручной accept
autosign_grains_dir: /etc/salt/autosign_grains

# Nodegroups для удобного targeting
nodegroups:
  webservers: 'G@role:webserver'
  databases: 'G@role:database'
  ubuntu: 'G@os:Ubuntu'
  debian: 'G@os:Debian'
  centos: 'G@os:CentOS Stream'
  dc1: 'G@datacenter:dc1'
  dc2: 'G@datacenter:dc2'

# Reactor — автоматические реакции на события
reactor:
  - 'salt/auth':  # Новый minion подключается
    - /srv/reactor/new_minion.sls
  - 'salt/beacon/*/inotify/*':  # Изменение файла
    - /srv/reactor/file_changed.sls
  - 'salt/beacon/*/diskusage/*':  # Диск заполнен
    - /srv/reactor/disk_alert.sls

# Включаем git fileserver для GitOps
fileserver_backend:
  - roots
  - gitfs

gitfs_remotes:
  - https://git.nordhost.local/infra/salt-states.git:
    - mountpoint: salt://git

# Логирование
log_level: warning
log_file: /var/log/salt/master
# Создаём структуру каталогов
sudo mkdir -p /srv/{salt,pillar,reactor}
sudo mkdir -p /srv/salt/{users,packages,services,monitoring,security}
sudo mkdir -p /srv/pillar/{users,servers}
sudo mkdir -p /etc/salt/autosign_grains

# Запускаем Salt Master
sudo systemctl enable salt-master
sudo systemctl start salt-master

# Открываем порты
sudo ufw allow from 10.0.0.0/16 to any port 4505 comment "Salt publish"
sudo ufw allow from 10.0.0.0/16 to any port 4506 comment "Salt return"

Массовая установка Minion через salt-ssh

Проблема курицы и яйца: чтобы установить Salt Minion на 300 серверов, нужен инструмент автоматизации. Решение — salt-ssh, который работает без агента через SSH:

# Устанавливаем salt-ssh
sudo apt install -y salt-ssh

# Создаём roster — инвентарь серверов для SSH
# /etc/salt/roster
sudo bash -c 'cat > /etc/salt/roster << EOF
# Формат: minion_id : host, user, port, sudo
web-01:
  host: 10.0.1.11
  user: deploy
  sudo: True
  minion_opts:
    grains:
      role: webserver
      datacenter: dc1

web-02:
  host: 10.0.1.12
  user: deploy
  sudo: True
  minion_opts:
    grains:
      role: webserver
      datacenter: dc1

db-01:
  host: 10.0.1.21
  user: deploy
  sudo: True
  minion_opts:
    grains:
      role: database
      datacenter: dc1
EOF'

# Для 300 серверов генерируем roster из CSV
#!/bin/bash
# generate_roster.sh
while IFS=, read -r hostname ip role dc; do
  cat >> /etc/salt/roster << EOF
${hostname}:
  host: ${ip}
  user: deploy
  sudo: True
  minion_opts:
    grains:
      role: ${role}
      datacenter: ${dc}
EOF
done < servers.csv

# Устанавливаем minion на все серверы через salt-ssh
salt-ssh '*' state.apply install_minion

# State для установки minion:
# /srv/salt/install_minion.sls
install-salt-minion:
  cmd.run:
    - name: |
        curl -o /tmp/bootstrap-salt.sh -L https://bootstrap.saltproject.io
        sh /tmp/bootstrap-salt.sh -x python3 stable 3006
    - unless: salt-minion --version | grep 3006

configure-minion:
  file.managed:
    - name: /etc/salt/minion
    - contents: |
        master: 10.0.0.1
        grains:
          role: {{ grains['role'] }}
          datacenter: {{ grains['datacenter'] }}
    - require:
      - cmd: install-salt-minion

start-minion:
  service.running:
    - name: salt-minion
    - enable: True
    - require:
      - file: configure-minion

После установки minion на все серверы принимаем ключи на master:

# Смотрим ожидающие ключи
sudo salt-key -L
# Unaccepted Keys:
# web-01
# web-02
# ...(298 keys)

# Принимаем все
sudo salt-key -A -y

# Проверяем связь
salt '*' test.ping
# web-01: True
# web-02: True
# ...
# 300 minions responded

Grains и Pillars: данные об инфраструктуре

Grains — это факты о minion (ОС, IP, RAM, роль), а Pillars — конфиденциальные данные, передаваемые с master только нужным minion. Вместе они формируют полную картину инфраструктуры.

Настройка Grains для классификации серверов

Мы определили кастомные grains для каждого сервера:

# /etc/salt/grains на каждом minion (или через конфигурацию)
# Пример для web-сервера:
role: webserver
datacenter: dc1
rack: A3
customer_tier: premium
services:
  - nginx
  - php-fpm
  - node-exporter

# Используем grains для сбора информации
salt '*' grains.item os osrelease mem_total num_cpus
# web-01:
#   mem_total: 32768
#   num_cpus: 8
#   os: Ubuntu
#   osrelease: 22.04

# Фильтрация по grains
salt -G 'os:Ubuntu' test.ping       # Все Ubuntu
salt -G 'role:webserver' test.ping   # Все веб-серверы
salt -G 'datacenter:dc1' test.ping   # Все в DC1

# Compound matching — комбинация условий
salt -C 'G@role:webserver and G@datacenter:dc1' test.ping
salt -C 'G@os:Ubuntu and not G@role:database' test.ping

Pillars для секретов и per-server конфигурации

Pillars хранят данные, которые должны быть разными для каждого сервера или группы:

# /srv/pillar/top.sls — маршрутизация pillars к minions
base:
  '*':
    - common
    - users.admins
  'G@role:webserver':
    - match: compound
    - nginx
    - certificates
  'G@role:database':
    - match: compound
    - postgresql
  'web-01':
    - servers.web-01

# /srv/pillar/common.sls
ntp_servers:
  - 10.0.0.5
  - 10.0.0.6
dns_servers:
  - 10.0.0.3
  - 10.0.0.4
monitoring:
  prometheus_server: 10.0.0.50
  node_exporter_port: 9100

# /srv/pillar/users/admins.sls
admins:
  ivanov:
    uid: 1001
    ssh_key: "ssh-ed25519 AAAAC3Nza... ivanov@nordhost"
    sudo: True
  petrov:
    uid: 1002
    ssh_key: "ssh-ed25519 AAAAC3Nza... petrov@nordhost"
    sudo: True
  sidorov:
    uid: 1003
    ssh_key: "ssh-ed25519 AAAAC3Nza... sidorov@nordhost"
    sudo: False

# /srv/pillar/nginx.sls
nginx:
  worker_processes: auto
  worker_connections: 4096
  ssl_protocols: "TLSv1.2 TLSv1.3"
  ssl_ciphers: "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256"

# Применяем и проверяем
salt 'web-01' pillar.items
salt 'web-01' pillar.get admins:ivanov:ssh_key

States: инфраструктура как код

States (SLS-файлы) описывают желаемое состояние серверов. Salt приводит сервер к этому состоянию идемпотентно — можно запускать многократно без побочных эффектов.

top.sls и структура states

Файл top.sls определяет, какие states применяются к каким серверам:

# /srv/salt/top.sls
base:
  '*':                          # Все серверы
    - common.packages
    - common.ntp
    - common.dns
    - common.sysctl
    - users
    - security.ssh
    - security.firewall
    - monitoring.node-exporter

  'G@role:webserver':           # Веб-серверы
    - match: compound
    - nginx
    - nginx.vhosts
    - certbot

  'G@role:database':            # Серверы БД
    - match: compound
    - postgresql
    - postgresql.backup

  'G@role:mailserver':          # Почтовые серверы
    - match: compound
    - postfix
    - dovecot

Практические states: пользователи, пакеты, сервисы

Вот реальные states, которые мы написали для «НордХост»:

# /srv/salt/users/init.sls — управление пользователями
{% for username, user in pillar.get('admins', {}).items() %}
user_{{ username }}:
  user.present:
    - name: {{ username }}
    - uid: {{ user.uid }}
    - shell: /bin/bash
    - home: /home/{{ username }}
    - groups:
      - sudo
      {% if user.get('sudo', False) %}
      - adm
      {% endif %}

ssh_key_{{ username }}:
  ssh_auth.present:
    - user: {{ username }}
    - name: {{ user.ssh_key }}
    - require:
      - user: user_{{ username }}

{% if user.get('sudo', False) %}
sudoers_{{ username }}:
  file.managed:
    - name: /etc/sudoers.d/{{ username }}
    - contents: "{{ username }} ALL=(ALL) NOPASSWD: ALL"
    - mode: 440
    - require:
      - user: user_{{ username }}
{% endif %}
{% endfor %}

# Удаляем бывших сотрудников
{% for username in pillar.get('removed_users', []) %}
remove_{{ username }}:
  user.absent:
    - name: {{ username }}
    - purge: True
{% endfor %}

# /srv/salt/common/packages.sls — базовые пакеты
base_packages:
  pkg.installed:
    - pkgs:
      - htop
      - iotop
      - tmux
      - curl
      - wget
      - vim
      - net-tools
      - dnsutils
      - unattended-upgrades
      - fail2ban
      {% if grains['os_family'] == 'Debian' %}
      - apt-transport-https
      {% elif grains['os_family'] == 'RedHat' %}
      - epel-release
      {% endif %}

# /srv/salt/security/ssh.sls — хардеринг SSH
sshd_config:
  file.managed:
    - name: /etc/ssh/sshd_config
    - source: salt://security/files/sshd_config.jinja
    - template: jinja
    - mode: 644
    - check_cmd: sshd -t -f

sshd_service:
  service.running:
    - name: sshd
    - enable: True
    - watch:
      - file: sshd_config

# /srv/salt/security/files/sshd_config.jinja
Port 22
ListenAddress {{ grains['ip_interfaces']['eth0'][0] }}
Protocol 2
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
AllowTcpForwarding no
{% for username in pillar.get('admins', {}).keys() %}
AllowUsers {{ username }}
{% endfor %}

State для обновления OpenSSL — та самая задача

А теперь — state, ради которого всё затевалось. Обновление OpenSSL на 300 серверах:

# /srv/salt/security/openssl_update.sls

# Обновляем OpenSSL
openssl_update:
  pkg.latest:
    - name: openssl
    - refresh: True

libssl_update:
  pkg.latest:
    - pkgs:
      {% if grains['os_family'] == 'Debian' %}
      - libssl3
      {% elif grains['os_family'] == 'RedHat' %}
      - openssl-libs
      {% endif %}
    - refresh: True

# Перезапускаем сервисы, зависящие от OpenSSL
{% set ssl_services = salt['service.get_all']() %}
{% for svc in ['nginx', 'apache2', 'httpd', 'postfix', 'dovecot', 'sshd'] %}
{% if svc in ssl_services %}
restart_{{ svc }}:
  service.running:
    - name: {{ svc }}
    - watch:
      - pkg: openssl_update
      - pkg: libssl_update
{% endif %}
{% endfor %}

# Проверяем версию после обновления
verify_openssl:
  cmd.run:
    - name: openssl version
    - require:
      - pkg: openssl_update

Запускаем обновление на всех 300 серверах:

# Сначала dry-run (test=True)
salt '*' state.apply security.openssl_update test=True

# Результат: 300 серверов, 300 OK, 0 failed
# Все 300 серверов покажут, что будет обновлено

# Поэтапная раскатка — сначала DC1, потом DC2
salt -C 'G@datacenter:dc1' state.apply security.openssl_update
# 152 servers responded. All succeeded.
# Duration: 3 min 47 sec

salt -C 'G@datacenter:dc2' state.apply security.openssl_update
# 148 servers responded. All succeeded.
# Duration: 3 min 22 sec

# Проверяем версию на всех
salt '*' cmd.run 'openssl version'
# web-01: OpenSSL 3.0.13 30 Jan 2024
# web-02: OpenSSL 3.0.13 30 Jan 2024
# ...(все 300 одинаковые)

# Итого: 7 минут 9 секунд вместо 2 недель

Reactors и Beacons: event-driven автоматизация

Salt Reactor — одна из самых мощных возможностей SaltStack. Он позволяет автоматически реагировать на события: диск заполнен — очищаем логи, файл изменён — перезагружаем сервис, новый сервер появился — настраиваем базовую конфигурацию.

Beacons для мониторинга событий на minions

Beacons работают на minion и генерируют события, на которые реагирует master через reactor:

# /etc/salt/minion.d/beacons.conf (на всех серверах)
beacons:
  diskusage:
    - /:
        percent: 90%
    - /var/log:
        percent: 85%
    - interval: 60  # Проверка каждые 60 секунд

  inotify:
    - files:
        /etc/ssh/sshd_config:
          mask:
            - modify
            - delete
        /etc/passwd:
          mask:
            - modify
    - interval: 5

  service:
    - services:
        nginx:
          onchangeonly: True
        sshd:
          onchangeonly: True
    - interval: 30

Reactor: автоматические реакции

На master настраиваем реакции на события от beacons:

# /srv/reactor/disk_alert.sls
# Автоматическая очистка при заполнении диска
{% set data = data.get('data', {}) %}
{% if data.get('percent', 0) >= 90 %}
auto_cleanup:
  local.state.apply:
    - tgt: {{ data['id'] }}
    - arg:
      - maintenance.disk_cleanup

notify_admins_disk:
  runner.http.query:
    - url: "https://api.telegram.org/bot/sendMessage"
    - method: POST
    - data:
        chat_id: "-100123456789"
        text: "Disk alert: {{ data['id'] }} — {{ data.get('mount', '/') }} at {{ data.get('percent', '?') }}%"
{% endif %}

# /srv/reactor/file_changed.sls
# Кто-то изменил sshd_config — откатываем к нашей версии
revert_ssh_config:
  local.state.apply:
    - tgt: {{ data['id'] }}
    - arg:
      - security.ssh

# /srv/salt/maintenance/disk_cleanup.sls
clean_old_logs:
  cmd.run:
    - name: |
        find /var/log -name '*.gz' -mtime +30 -delete
        find /var/log -name '*.1' -mtime +14 -delete
        journalctl --vacuum-time=7d
        apt clean 2>/dev/null || yum clean all 2>/dev/null
    - shell: /bin/bash

Оркестрация: сложные сценарии развёртывания

Оркестрация позволяет выполнять многоэтапные операции с зависимостями между серверами — например, rolling update nginx без простоя.

Rolling update nginx на всех веб-серверах

Обновляем nginx поэтапно, выводя серверы из балансировки:

# /srv/salt/orch/nginx_rolling_update.sls

# Шаг 1: Обновляем nginx в DC1 (по одному серверу)
{% set dc1_servers = salt.saltutil.runner('manage.up', tgt='G@datacenter:dc1 and G@role:webserver', tgt_type='compound') %}

{% for server in dc1_servers %}
remove_{{ server }}_from_lb:
  salt.function:
    - name: cmd.run
    - tgt: 'lb-01'
    - arg:
      - "echo 'disable server backends/{{ server }}' | socat stdio /var/run/haproxy/admin.sock"

update_nginx_{{ server }}:
  salt.state:
    - tgt: '{{ server }}'
    - sls:
      - nginx
    - require:
      - salt: remove_{{ server }}_from_lb

verify_{{ server }}:
  salt.function:
    - name: cmd.run
    - tgt: '{{ server }}'
    - arg:
      - 'curl -sf http://localhost/health || exit 1'
    - require:
      - salt: update_nginx_{{ server }}

add_{{ server }}_to_lb:
  salt.function:
    - name: cmd.run
    - tgt: 'lb-01'
    - arg:
      - "echo 'enable server backends/{{ server }}' | socat stdio /var/run/haproxy/admin.sock"
    - require:
      - salt: verify_{{ server }}
{% endfor %}

# Запуск оркестрации
# salt-run state.orchestrate orch.nginx_rolling_update

Автоматическое развёртывание нового сервера

Когда «НордХост» вводит в строй новый сервер, Salt автоматически настраивает его от нуля до production-ready:

# /srv/reactor/new_minion.sls
# Реагирует на событие salt/auth (новый minion подключился)
{% if data.get('act') == 'accept' %}
bootstrap_new_server:
  local.state.apply:
    - tgt: {{ data['id'] }}
    - arg:
      - common.packages
      - common.ntp
      - users
      - security.ssh
      - security.firewall
      - monitoring.node-exporter

notify_new_server:
  runner.http.query:
    - url: "https://api.telegram.org/bot/sendMessage"
    - method: POST
    - data:
        chat_id: "-100123456789"
        text: "New server bootstrapped: {{ data['id'] }}"
{% endif %}

# Результат: новый сервер полностью настроен за 4-5 минут
# автоматически, без участия администратора

Salt Cloud: автоматическое создание VM

Для «НордХост» мы также настроили Salt Cloud — модуль для автоматического создания виртуальных машин в облачных провайдерах и на локальных гипервизорах. При поступлении заказа от клиента на VPS, Salt Cloud создаёт виртуальную машину, устанавливает minion и запускает bootstrap-конфигурацию — всё за одну команду:

# /etc/salt/cloud.profiles.d/nordhost.conf
vps-basic:
  provider: proxmox-dc1
  technology: qemu
  clone: template-ubuntu-2204
  vmid: auto
  cores: 2
  memory: 4096
  disk_size: 40
  net:
    net0:
      bridge: vmbr0
  minion:
    master: 10.0.0.1
    grains:
      role: customer-vps
      tier: basic

# Создание VPS одной командой
salt-cloud -p vps-basic client-web-042 -l info

# Результат через 90 секунд:
# [INFO] Salt installed on client-web-042
# [INFO] client-web-042 provisioned successfully
# [INFO] Bootstrap state applied: users, ssh, firewall, monitoring

# Вся цепочка: создание VM → установка ОС → Salt Minion → bootstrap states
# Полная готовность сервера: 2 минуты вместо 4 часов вручную

Salt Cloud поддерживает Proxmox, VMware, KVM/libvirt, а также облачные провайдеры — AWS, GCP, Azure, Yandex Cloud, Hetzner. Для «НордХост» это означает унифицированный процесс создания серверов независимо от платформы виртуализации.

Результаты внедрения: от хаоса к порядку

Внедрение SaltStack заняло 18 рабочих дней: 3 дня на аудит и проектирование, 5 дней на установку и настройку Salt, 8 дней на написание states и тестирование, 2 дня на обучение команды.

Измеримые результаты

МетрикаДо SaltStackПосле SaltStack
Обновление OpenSSL на 300 серверах2 недели7 минут
Развёртывание нового сервера4 часа (ручная настройка)5 минут (автоматически)
Создание нового пользователя на всех серверах1 день30 секунд
Дрифт конфигурации47% серверов различаются0% (Salt enforcment)
Рутинные задачи (% времени команды)60%15%
Инцидентов из-за конфигурации12 в квартал1 в квартал

Инженеры АйТи Фреш передали «НордХост» полную документацию и провели двухдневный тренинг для администраторов. Сейчас команда самостоятельно пишет новые states и расширяет автоматизацию.

Долгосрочные преимущества

Помимо мгновенных результатов, внедрение SaltStack дало «НордХост» стратегические преимущества:

  • Infrastructure as Code — вся конфигурация хранится в Git-репозитории. Новый администратор может изучить инфраструктуру по SLS-файлам, а не по памяти коллег
  • Аудируемость — каждое изменение конфигурации проходит через Git (code review, история коммитов). Можно точно узнать, кто и когда изменил настройку SSH на веб-серверах
  • Единообразие — все 300 серверов гарантированно настроены одинаково. Дрифт конфигурации обнаруживается за секунды командой salt '*' state.apply test=True
  • Масштабируемость — добавление 100 новых серверов не увеличивает нагрузку на команду. Salt Cloud создаёт VM, Salt states настраивают их автоматически
  • Compliance — при аудите безопасности достаточно показать SLS-файлы и результаты их применения, вместо проверки каждого сервера вручную

«НордХост» планирует расширить использование Salt на управление конфигурациями клиентских серверов, предлагая это как дополнительную услугу managed hosting.

Часто задаваемые вопросы

Ansible отлично подходит для небольших инфраструктур (до 100 серверов) и разовых операций. Для 300+ серверов с требованием мгновенного push-исполнения и event-driven автоматизации SaltStack значительно производительнее. Salt выполняет команды параллельно через ZeroMQ за секунды, тогда как Ansible последовательно подключается к каждому серверу по SSH. Для хостинг-провайдера, где критичны экстренные патчи безопасности, разница в скорости — решающий фактор.

States пишутся на YAML с Jinja-шаблонами — синтаксис знаком любому, кто работал с Ansible или Docker Compose. Основная сложность — понять модель master-minion и систему targeting (glob, grain, compound). При двухдневном тренинге администраторы начинают писать собственные states к концу первого дня. Полное освоение продвинутых возможностей (reactors, orchestration, custom modules) занимает 2–3 недели практики.

Salt Master — критически важный компонент: компрометация master означает контроль над всей инфраструктурой. Рекомендации: 1) Выделенный сервер, не используемый для других задач; 2) Доступ по SSH только с jump-хоста; 3) Firewall — порты 4505/4506 открыты только для подсети minion; 4) Регулярная ротация master-ключей; 5) Audit log всех команд Salt; 6) Разграничение прав через Salt ACL (External Auth) — разным администраторам разные уровни доступа.

Да, Salt Minion поддерживает Windows. Можно управлять пакетами (через chocolatey), службами, реестром, файлами и пользователями Windows. Однако экосистема states для Windows менее развита, чем для Linux. Для смешанных инфраструктур SaltStack — один из лучших вариантов, так как один master управляет и Linux, и Windows серверами с единым набором pillars и targeting.

Нужна помощь с настройкой?

Специалисты АйТи Фреш помогут с внедрением и настройкой — 15+ лет опыта, обслуживание от 15 000 ₽/мес

📞 Связаться с нами
#SaltStack настройка#Salt master minion#управление конфигурациями#SaltStack states SLS#SaltStack pillars grains#Salt оркестрация#Salt reactor beacons#автоматизация серверов