Salt SSH и Proxy Minion

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

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

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

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

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

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

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

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

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