| Создание кросс - платформенного инструмента управления |
|
Решение об использовании ключей ssh в соединении с простой системой управления оказалось недостаточно удобным, потому что его сложно расширять или повторно использовать. Попробуем определить перечень проблем, характерных для предыдущего инструмента, а затем составим список требований, устраняющих эти проблемы. Проблемы: список администрируемых машин определяется жестко, в самом сценарии; выполняемая команда жестко задана в сценарии; допускается запуск только одной команды за раз; один и тот же набор команд выполняется на всех машинах, мы лишены возможности выбора; наш управляющий сценарий ожидает, пока не будет получен ответ на каждую команду. Требования: нам необходим инструмент командной строки, который будет получать IP-адреса и команды, которые надлежит выполнить, из конфигурационного файла; нам необходим интерфейс командной строки с параметрами, чтобы можно было передавать команды машинам; нам необходим инструмент управления, который будет запускать команды в отдельных потоках выполнения, чтобы не блокировать процесс. Похоже, что нам необходимо выработать элементарный синтаксис конфигурационного файла с разделом для машин и с разделом для команд. Взгляните на пример 8.6. Пример 8.6. Конфигурационный файл для управляющего сценария
Теперь нам необходимо написать функцию, которая будет читать содержимое конфигурационного файла и выделять разделы MACHINES и COMMANDS, чтобы можно было выполнять обход этих разделов по очереди, как показано в примере 8.7. Следует заметить, что команды из конфигурационного файла будут импортироваться в случайном порядке. В большинстве случаев это может оказаться неприемлемым и, возможно, было бы лучше просто написать модуль на языке Python, который будет играть роль конфигурационного файла. Пример 8.7. Улучшенный сценарий управления
Эти несложные изменения повысили удобство использования. Мы можем произвольно изменять список команд и машин и выполнять сразу все команды. Если теперь взглянуть на вывод сценария, можно убедиться, что он не изменился:
Хотя это весьма усовершенствованный инструмент, у нас по-прежнему отсутствует механизм выполнения команд в отдельных потоках, наличие которого определено в нашей спецификации. К счастью, мы можем воспользоваться некоторыми приемами. В примере 8.8 показано, что для этого можно сделать. Пример 8.8. Многопоточный инструмент управления командами
Если теперь взглянуть на вывод нового многопоточного механизма управления, можно заметить, что на выполнение всех команд потребовалось около 1,2 секунды. Чтобы увидеть различия в скорости выполнения, нам следует добавить измерение времени в оригинальный управляющий сценарий и сравнить полученные результаты:
После добавления в оригинальный управляющий сценарий простого программного кода, выполняющего замер времени, мы получили следующее:
Исходя из этих результатов, можно сказать, что наша многопоточная версия оказалась примерно в три раза быстрее. Если бы мы использовали этот инструмент для опроса сети, скажем, из 500 машин, а не из 5, разница в производительности могла бы оказаться еще более существенной. Пока разработка нашего кросс-платформенного инструмента управления продвигается достаточно успешно, поэтому сделаем следующий шаг и создадим кросс-платформенный инструмент сборки.
Set as favorite
Bookmark
Email This
Hits: 116 Комментарии (0)RSS feed CommentsНаписать комментарий |