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-команд, -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-режиме либо ограничено, либо недоступно.

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

• Roster-файл
• Salt SSH и Proxy Minion
• Архитектура master–minion
• salt-call и masterless-режим
• Ansible