Удалённое выполнение

Тема дорожной карты · SaltStack

Удалённое выполнение (remote execution) — исторически первая и до сих пор центральная возможность Salt: запуск произвольной функции на тысячах машин одной командой с мастера. Именно из неё выросло всё остальное — states, оркестрация, событийная модель. Команда salt '*' test.ping — это удалённое выполнение в чистом виде: мастер публикует задание, все подключённые миньоны выполняют функцию локально и возвращают результат. Ключевое отличие от подхода «цикл по SSH»: мастер не ходит на каждую машину по очереди, а рассылает задание один раз через шину сообщений, после чего миньоны работают параллельно. Поэтому выполнение на 10 и на 1000 машин занимает сопоставимое время.

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

Мастер держит два порта: 4505 (publish) и 4506 (request/return). Миньоны сами подключаются к мастеру и подписываются на publish-канал — входящих соединений к миньонам не требуется, что упрощает работу через NAT и файрволы. Когда вы запускаете salt '*' cmd.run 'uptime', мастер публикует в канал задание с целевым выражением и именем функции. Каждый миньон сам проверяет, подходит ли он под таргет; подходящие выполняют функцию execution-модуля локально, своим процессом, и отправляют результат на порт 4506. Полезная нагрузка шифруется AES-ключом, а доверие устанавливается через RSA-ключи миньонов (salt-key). Транспорт по умолчанию — ZeroMQ; есть альтернативы (TCP, websocket). Каждому заданию присваивается JID, результаты складываются в job cache: асинхронный запуск salt '*' pkg.install nginx --async вернёт JID сразу, а результат можно забрать позже командой salt-run jobs.lookup_jid <jid>.

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

Удалённое выполнение — инструмент для ad-hoc-операций: разово перезапустить сервис на группе машин (salt 'web*' service.restart nginx), собрать факты (salt '*' grains.item os), проверить доступность парка (salt '*' test.ping), раскатать срочный пакет (salt -G 'os:Ubuntu' pkg.install nginx). Это же основной канал диагностики: salt '*' cmd.run 'df -h' быстрее, чем логин на каждую машину. Для воспроизводимой конфигурации, которая должна переживать перезагрузки и дрейф, используйте states — они декларативны и идемпотентны, тогда как выполнение команды — разовое действие. Практичное правило: всё, что вы запускаете руками больше двух раз, стоит оформить как state. На больших парках учитывайте нагрузку возвратов: тысячи миньонов, отвечающих одновременно, нагружают мастер, поэтому существует batch-режим (--batch-size 10%), выполняющий задание волнами.

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

Частая ошибка — считать, что «нет ответа» значит «команда не выполнилась». Таймаут клиента (-t) ограничивает только ожидание ответа: миньон мог принять задание и продолжать его выполнять — проверяйте через salt-run jobs.lookup_jid. Вторая — злоупотребление cmd.run для изменения конфигурации вместо states: получаются неидемпотентные «однострочники», о которых через месяц никто не помнит. Третья — таргет '*' для тяжёлых операций без batch-режима: одновременный pkg.upgrade на всём парке — это шторм на репозитории и мастер. Наконец, не забывайте про кавычки: глоб web* без кавычек раскроет ваш локальный shell, а не Salt.

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

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

Проверить знания (2)

Загрузка вопросов…