Salt SSH и Proxy Minion

Классическая архитектура Salt использует агента: на каждой управляемой машине работает демон salt-minion, подключённый к мастеру по ZeroMQ. Однако в реальной инфраструктуре есть узлы, где установка агента невозможна или нежелательна, такие как коммутаторы, маршрутизаторы, легаси-серверы и машины с жёсткими ограничениями безопасности. Для таких случаев Salt предлагает два режима: salt-ssh и proxy minions. Salt-ssh управляет хостами через SSH без постоянного агента, используя roster-файл, а proxy minions представляют устройства, которые не могут нести агента, через процесс-посредник. Оба режима используют механизмы состояний, grains и pillar, но с определёнными компромиссами.

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

salt-ssh работает на мастере и использует SSH для выполнения команд и состояний на целевых хостах. Он копирует лёгкое окружение Salt, выполняет команду и забирает результат. Список целей и параметры подключения берутся из roster-файла (/etc/salt/roster), так как в этом режиме нет постоянного соединения и регистрации миньонов. Proxy minion, в свою очередь, представляет собой процесс salt-proxy, который работает на любом удобном хосте и держит ZeroMQ-соединение с мастером. Он транслирует команды управляемому устройству по его родному протоколу, например, SSH-CLI сетевой железки, REST API, NETCONF или SNMP. Для мастера proxy minion неотличим от обычного миньона и имеет ключ, grains, pillar и поддерживает состояния.

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

salt-ssh используется, когда агент недопустим или избыточен. Это полезно для аудита и инвентаризации чужих серверов, бутстрапа новой машины (включая установку полноценного миньона), управления небольшим статичным парком, где развертывание master-minion-инфраструктуры нецелесообразно. Однако, за это приходится платить скоростью: каждый запуск требует SSH-сессии и передачи файлов, что значительно медленнее ZeroMQ. Кроме того, отсутствует событийная модель, так как без постоянного соединения нет beacons, Reactor и расписаний на стороне миньона. Proxy minions подходят для устройств, где агента не будет никогда, таких как сетевое оборудование или специализированные устройства с управлением только по API. Поскольку proxy держит постоянное соединение, событийная модель и таргетинг работают как обычно, но ценой потребления памяти и CPU, так как каждый proxy это отдельный процесс.

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

Частая ошибка — воспринимать salt-ssh как полную замену миньонам и удивляться его медленности: на десятках хостов и регулярных прогонах агентная модель выигрывает на порядки. Salt-ssh — инструмент для краёв инфраструктуры, а не для её ядра. Вторая ошибка — ждать от salt-ssh событий: beacons и Reactor в этом режиме не работают. С proxy minions главная проблема — потребление памяти и CPU: сотни управляемых железок означают сотни процессов, которые нужно где-то разместить и мониторить. Также важно защищать учётные данные устройств в pillar proxy-процесса так же строго, как и любой другой секрет.

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

• salt-ssh (agentless)
• Roster-файл
• Proxy minions
• Архитектура master–minion
• Событийная модель