Proxy minions

Proxy minion позволяет управлять устройствами, на которые нельзя установить агент, такими как коммутаторы, маршрутизаторы, файрволы и специализированное оборудование с закрытой прошивкой. Вместо установки salt-minion на устройство, процесс salt-proxy запускается на обычном сервере, подключается к мастеру и транслирует команды устройству через его родной протокол: CLI по SSH, REST API, NETCONF или SNMP. Для мастера и состояний proxy minion выглядит как обычный миньон: у него есть идентификатор, ключ, grains и pillar, и к нему можно применять state.apply и таргетинг.

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

Каждому управляемому устройству соответствует отдельный процесс salt-proxy --proxyid=switch01. При запуске процесс читает ключ proxy из pillar устройства, где задан тип proxy-модуля и параметры подключения: адрес, учётные данные, протокол. Proxy-модуль обеспечивает связь с устройством, а поверх него работают execution- и state-модули, которые знают, что «локальные» вызовы на самом деле уходят по сети на устройство. Для сетевого оборудования часто используется NAPALM — библиотека с единым интерфейсом к оборудованию разных вендоров. Модули NAPALM позволяют забирать факты устройства в grains и управлять конфигурацией через состояния. Ключи proxy принимаются через salt-key, как у обычных миньонов, а test.ping проверяет цепочку мастер → proxy-процесс → устройство.

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

Главный кейс — автоматизация сетевой инфраструктуры единым инструментом с серверами: один top file, один pillar, одна событийная шина и на серверы, и на коммутаторы. Это особенно полезно, когда команда уже использует Salt и не хочет отдельного стека для сети. Proxy также подходит для любых API-управляемых систем, где установка агента невозможна. Сравнивая с salt-ssh, учитывайте: proxy держит постоянное соединение, поэтому работают beacons, Reactor и регулярные состояния по расписанию; salt-ssh — только разовые прогоны. Цена — операционная: proxy-процессы нужно запускать и супервизировать (обычно на выделенном хосте или нескольких), а для сотен устройств заранее считайте память и CPU на процесс.

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

Первая ошибка — недооценка стоимости процессов: «добавим все 500 свитчей» превращается в 500 процессов на одном хосте, который никто не мониторит; распределяйте proxy по нескольким хостам и следите за ними как за обычным сервисом. Вторая — секреты: учётные данные устройств живут в pillar proxy — ограничивайте их видимость ровно тем идентификатором, которому они нужны, и не коммитьте в открытые репозитории. Третья — считать proxy живым, если жив процесс: salt-proxy может отвечать мастеру, пока само устройство недоступно; проверяйте связность до железки, а не только до процесса. Наконец, не все модули осмысленны для устройств: pkg.install на коммутаторе не сделает того, что вы ожидаете, — работайте через модули соответствующего proxy-типа.

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

• Salt SSH и Proxy Minion
• salt-ssh (agentless)
• Архитектура master–minion
• Ключи и salt-key
• Секреты в pillar