salt-ssh (agentless)

salt-ssh — это agentless-режим Salt: управление хостами по обычному SSH, без установки и запуска демона salt-minion. Синтаксис почти неотличим от привычного: salt-ssh '*' test.ping, salt-ssh 'web*' state.apply nginx — те же execution-модули, те же состояния, те же grains и pillar в шаблонах. Разница внутри: вместо постоянного ZeroMQ-соединения и ключей миньонов используются SSH-сессии и roster-файл, в котором перечислены цели и параметры подключения. Это делает salt-ssh идеальным инструментом для машин, где агента нет и не будет, — и заведомо неоптимальным для повседневного управления большим парком.

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

При запуске salt-ssh подключается к каждому целевому хосту по SSH, разворачивает там временное лёгкое окружение Salt (thin-архив с необходимым Python-кодом), выполняет запрошенную функцию или состояние локально на хосте и возвращает результат в формате обычных возвратов Salt. На целевой машине нужен Python и работающий SSH-доступ — больше ничего. Список целей берётся из roster-файла (по умолчанию /etc/salt/roster): в нём для каждого идентификатора задаются host, user, способ аутентификации и другие параметры. Полезные флаги: -r — выполнить сырую shell-команду без модулей Salt, -i — принять неизвестные host-ключи при первом подключении, --priv — указать SSH-ключ. Файлы состояний и pillar читаются с той же машины, где запущен salt-ssh, поэтому существующее дерево /srv/salt переиспользуется как есть.

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

Типовые ниши salt-ssh: бутстрап — привести свежую машину к базовому состоянию и, если нужно, установить полноценный миньон тем же прогоном; аудит и разовые операции на хостах, где разворачивать агента неоправданно; управление маленьким статичным парком (единицы машин), где master-minion-инфраструктура — лишняя сущность; работа в средах, где политика безопасности запрещает дополнительные демоны, а SSH уже разрешён. Выбирая между режимами, держите в голове три ограничения agentless-подхода: скорость — каждый запуск это SSH-рукопожатие и копирование файлов, что на порядки медленнее постоянного ZeroMQ-канала; отсутствие событийной модели — beacons, Reactor и минионные расписания требуют живого агента; инициатива всегда у управляющей стороны — хост не может ничего сообщить о себе между запусками.

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

Главная ошибка — строить на salt-ssh повседневное управление сотнями машин: прогоны, занимающие секунды через миньонов, растягиваются на минуты и десятки минут. Вторая — забывать про зависимость от Python на целевой стороне: на минималистичных образах его может не быть, и salt-ssh упадёт непонятной для новичка ошибкой. Третья — хранить пароли открытым текстом в roster-файле: используйте SSH-ключи или агент, а сам roster держите под тем же контролем доступа, что и инвентарь. Наконец, не удивляйтесь, что часть функциональности ведёт себя иначе, чем с агентом: всё, что опирается на постоянное соединение и локальный кэш миньона, в agentless-режиме либо ограничено, либо недоступно.

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

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

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

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

Полезные ресурсы