Proxy minions
Тема дорожной карты · SaltStack
Proxy minion — это способ управлять через Salt устройствами, на которые нельзя поставить агента: коммутаторами, маршрутизаторами, файрволами, специализированными устройствами с закрытой прошивкой. Идея проста: раз демон salt-minion не может работать на самом устройстве, пусть работает рядом — процесс salt-proxy запускается на обычном сервере, подключается к мастеру как полноценный миньон, а команды транслирует устройству по его родному протоколу: CLI по SSH, REST API, NETCONF, SNMP. Для мастера и для ваших состояний разницы нет: у proxy есть идентификатор, ключ, grains и pillar, к нему применяются state.apply и таргетинг — сетевая железка становится «ещё одним миньоном» в общем парке.
Как это работает
Каждому управляемому устройству соответствует отдельный процесс: salt-proxy --proxyid=switch01. При старте процесс читает из pillar устройства ключ proxy, где задан тип proxy-модуля и параметры подключения — адрес, учётные данные, протокол. Proxy-модуль отвечает за трансляцию: он реализует связь с устройством, а поверх него работают привычные execution- и state-модули, зная, что «локальные» вызовы на самом деле уходят по сети на железку. Для сетевого оборудования исторически сложился стек на базе 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-типа.
Связанные понятия
Полезные ресурсы
Проверить знания (2)
Загрузка вопросов…