Pull to refresh

Comments 29

Инструмент на первой иллюстрации мне напомнил одновременно УШС (универсальный шаблон сварщика) и квадрат для метания (холодное оружие). Что же это на самом деле?
Это больше выполнение сценариев/скриптов/плейбуков. Просто потыкать команды и красиво увидеть их ответ — удобней будет tmux c кучкой панелей на одном экране. Или iTerm для тех у кого macos. В обоих есть broadcast input и горизонатльное/вертикальное разделение экрана.
UFO just landed and posted this here
Ansible отсюда стоит убрать, он из другой оперы. Им конечно тоже можно выполнить конкретную команду на нескольких серверах, но задуман он не для этого. Сюда скорее чтонить типа python-fabric подойдет, хотя тоже не вполне.

Если есть анчибле то почему бы не добавить соль папки и иже с ними.

Линуксовый терминатор тоже такое может. Делим окно на необходимое количество частей, заходим в каждом на свой сервер, создаём на этих частях терминала широковещательный ввод и пишем команды. По результатам выполнения команд, в каждом «отсеке» терминала виден свой результат. Если что не так, можно шир. ввод выключить, поправить, потом продолжить. Тоже удобно
TMUX'a забыли.
Регулярно рулю виртуалками и серверами в консоли с одновременным вводом. Вся прелесть в том, что режим одновременного ввода включается и выключается по хоткею. Тмукс позволяет очень удобно сравнивать STDOUT на сплитскрине на 2-3 машины.
Хосты будут обрабатываться последовательно, а не параллельно. А теперь представьте что у вас 1к+ хостов и в среднем ваша команда выполняется 10 минут. Вот и посчитайте сколько уйдёт времени при вашем способе
-f Requests ssh to go to background just before command execution. This is useful if ssh is going to ask for passwords or passphrases, but the user wants it in the background. This implies -n. The recommended way to start X11 programs at a remote site is with something like ssh -f host xterm.
Ради интереса проверил простенький скрипт

#!/bin/bash

for HOST in $(cat hosts.txt)
do
    ssh -f ansible@$HOST "date; hostname";
done


На выходе получил
$ time./test.sh > debug.log
real	0m26.477s
user	0m0.408s
sys	0m0.084s

$ cat debug.log 
Fri Oct 19 08:16:48 UTC 2018
edge-eplus-main-3klf
Fri Oct 19 08:16:48 UTC 2018
edge-eplus-main-2x1g
Fri Oct 19 08:16:49 UTC 2018
edge-eplus-main-6t1g
Fri Oct 19 08:16:53 UTC 2018
edge-eplus-main-720h
Fri Oct 19 08:16:54 UTC 2018
edge-eplus-main-86hf
Fri Oct 19 08:16:55 UTC 2018
edge-eplus-main-8jf2
Fri Oct 19 08:16:56 UTC 2018
edge-eplus-main-d8w0
Fri Oct 19 08:16:58 UTC 2018
edge-eplus-main-jkjr
Fri Oct 19 08:17:01 UTC 2018
edge-eplus-main-nsj9
Fri Oct 19 08:17:03 UTC 2018
edge-eplus-main-ph9j
Fri Oct 19 08:17:05 UTC 2018
edge-eplus-main-t2g1
Fri Oct 19 08:17:06 UTC 2018
edge-eplus-main-t9jb
Fri Oct 19 08:17:07 UTC 2018
edge-eplus-main-x3c4
Fri Oct 19 08:17:10 UTC 2018
edge-eplus-main-x5q0


из того, что я вижу, команды выполняются последовательно. Для сравнения ansible
$ time ansible habrahabr -u ansible -m shell -a "date; hostname" > debug.log
real	0m15.962s
user	0m3.820s
sys	0m1.768s


$ time ansible habrahabr -u ansible -f 15 -m shell -a "date; hostname" > debug.log
real	0m8.568s
user	0m3.012s
sys	0m1.328s


Как бы разница налицо. И это было всего лишь 15 хостов. На 500+ разница будет очень заметной.
Интересно. У меня на долгих операциях разница между -f и без форка весьма заметна. Решил проверить ещё раз.

Итак, эталон с последовательным выполнением:
$ for HOST in `cat hosts.txt`; do ssh $HOST "sleep 5s; date"; done
19 октября 2018 г., 10:51:58 CEST
19 октября 2018 г., 10:52:06 CEST
19 октября 2018 г., 10:52:11 CEST
19 октября 2018 г., 10:52:17 CEST
19 октября 2018 г., 10:52:23 CEST
19 октября 2018 г., 10:52:29 CEST
19 октября 2018 г., 10:52:35 CEST
19 октября 2018 г., 10:52:40 CEST
19 октября 2018 г., 10:52:47 CEST
19 октября 2018 г., 10:52:53 CEST
19 октября 2018 г., 10:52:59 CEST
19 октября 2018 г., 10:53:04 CEST
19 октября 2018 г., 10:53:10 CEST
19 октября 2018 г., 10:53:16 CEST
19 октября 2018 г., 10:53:22 CEST
19 октября 2018 г., 10:53:27 CEST
19 октября 2018 г., 10:53:33 CEST
19 октября 2018 г., 10:53:39 CEST
19 октября 2018 г., 10:53:45 CEST
19 октября 2018 г., 10:53:50 CEST
19 октября 2018 г., 10:53:56 CEST


Теперь с форком:
$ for HOST in `cat hosts.txt`; do ssh -f $HOST "sleep 5s; date"; done
19 октября 2018 г., 10:55:58 CEST
19 октября 2018 г., 10:55:58 CEST
19 октября 2018 г., 10:55:59 CEST
19 октября 2018 г., 10:55:59 CEST
19 октября 2018 г., 10:56:00 CEST
19 октября 2018 г., 10:56:01 CEST
19 октября 2018 г., 10:56:01 CEST
19 октября 2018 г., 10:56:02 CEST
19 октября 2018 г., 10:56:02 CEST
19 октября 2018 г., 10:56:03 CEST
19 октября 2018 г., 10:56:03 CEST
19 октября 2018 г., 10:56:04 CEST
19 октября 2018 г., 10:56:04 CEST
19 октября 2018 г., 10:56:05 CEST
19 октября 2018 г., 10:56:06 CEST
19 октября 2018 г., 10:56:06 CEST
19 октября 2018 г., 10:56:07 CEST
19 октября 2018 г., 10:56:07 CEST
19 октября 2018 г., 10:56:08 CEST
19 октября 2018 г., 10:56:08 CEST
19 октября 2018 г., 10:56:09 CEST


Как видим, есть примерно секундная задержка на запуск нового фонового процесса. На пяти сотнях хостов это, возможно, будет критично. Таки да, согласен. Посыпаю голову пеплом.
Но теперь сделаем финт ушами:

$ for HOST in `cat hosts.txt`; do ssh -f $HOST "sleep 5s; date"& done
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST
19 октября 2018 г., 10:58:43 CEST


Спасибо за наводку. До сих пор мне хватало просто -f, но теперь буду знать как сделать реально ОДНОВРЕМЕННО на всех хостах.
Думаю сильно будет зависеть от удаленности хостов. Если у вас, например, все тестовые хосты в пределах локальной сети, то разница будет не такой заметной. У меня тестовые хосты были распределены по всем регионам в пределах GCP
Не локалка. Расстояние до хостов ~1700 км. Пинг ~70мс.
Фоновое выполнение не сильно удобно когда хостов очень много. Удобней ограничить количество потоков. Например завернув параллельность в xars

#!/bin/bash

rcmd () {
  ssh root@$1 "date;hostname;"
}
export -f rcmd
cat hosts.txt | xargs -n1 -P20 -I {} bash -c 'rcmd "$@"' _ {}

тут параметр -P20 — ограничивает выполнение 20 потоками.
Тоже интересно, но я предпочитаю простые однострочники. Чем проще, тем лучше.
Иначе получаются велосипеды, описанные в статье.
Обратите внимание на то, что интерфейс командной строки ansible позволяет выполнять команды лишь по одной.

Ansible, как написали выше, инструмент несколько другой направленности. Но тем не менее, лично я его использую в т.ч. и для кейса данной статьи.
Поэтому хочется скорректировать выделенное выше утверждение.
В Ansible куча модулей (-m module_name) со своими аргументами (-a arguments).
Поэтому легко и просто выполнить и несколько команд.
Например:


ansible the_cluster -f 4 -m shell -a "free -h; df -h /"

"-f X" — полезный параметр, делает "fork", т.е. порождает X параллельных процессов и команды выполняются параллельно на хостах.

GNU parallel в сочетании с xargs можно для этих целей использовать.
Для нестандартног использования типа выстрелил и забыл или если нужно обрабатывать/агрегировать выхлоп команд я пишу обычно на связке python + paramiko небольшой скрипт.
Очень неплохо выходит.

Есть супер утилита PAC manager. Фантастически удобная. По удаленному управлению умеет все и еще чуть-чуть:)! В том числе в ней очень удобно делать различную оркестрацию. Интеграция с кипасам и прочая и прочая…
Жалко только с 2016-го она не обновляется. Со временем, в системе обновилось пара-тройка зависимостей (например xfreerdp) и некоторый функционал стал глючить. Дописать-то, наверное, легко. Вот только Perl знать надо, а мне он все никак не дается…
Такой подход, с одной стороны, повышает безопасность сервера, а с другой — облегчает работу с ним.


Понимать как написано или if {} else {}?
github.com/reconquest/orgalorg
Zero-configuration.
Running SSH commands or shell scripts on any number of hosts in parallel.
Synchronizing files and directories across cluster with prior global cluster locking.
and more…
А почему забыли про:
for i in $(<srv.list); do (ssh $i «df -h» &); done
Sign up to leave a comment.