Мы уже познакомились со множеством способов использования модуля subprocess. Создание новых инструментов командной строки путем обертывания существующих команд сценариями на языке Python и изменения их API, или путем включения одной или нескольких команд UNIX в сценарии на языке Python представляет собой весьма интересную область для исследований. Нет ничего сложного в том, чтобы обернуть инструмент командной строки сценарием на языке Python и изменить ее поведение так, чтобы оно полнее отвечало нашим требованиям. Можно было бы, например, интегрировать в сценарий конфигурационный файл, в котором определить значения аргументов для некоторых параметров или задавать в сценарии значения по умолчанию для других аргументов. Какие бы требования не предъявлялись, с помощью модулей subprocess и optparse можно без особых проблем изменить поведение инструментов командной строки UNIX.

С другой стороны, смешивание инструментов командной строки со сценарием на языке Python позволяет создавать интересные инструменты, которые не так-то просто написать на языке С или bash. Что вы скажете насчет смешивания команды dd с многопоточным сценарием, где используются очереди, -tcpdump с библиотекой регулярных выражений для языка Python или использования специализированной версии rsync? Все эти «смешанные» команды UNIX 2.0 очень напоминают особенности, присутствующие в web 2.O. Смешивание Python с утилитами UNIX приводит к появлению новых идей и к решению проблем различными способами. В этом разделе мы исследуем некоторые из этих приемов.

Шаблон проектирования «кудзу»: обертывание инструментов сценариями на языке Python

Иногда используемый инструмент командной строки не совсем точно соответствует тому, что требуется вам. Он может требовать слишком большого числа параметров или порядок следования аргументов отличается от того, к которому вы привыкли. Используя язык программирования Python, можно очень легко изменить поведение утилиты и заставить ее делать именно то, что вам необходимо. Мы назвали это шаблоном проектирования «Кудзу». Для тех, кто не знает, поясним, что кудзу - это быстрорастущее вьющееся растение, завезенное на юг Соединенных Штатов из Японии. Кудзу часто поглощает естественный ландшафт, совершенно меняя его внешний вид. С помощью языка Python вы можете делать то же самое со средой UNIX.

В следующем примере мы обернули команду snmpdf сценарием на языке Python, чтобы упростить ее использование. Для начала посмотрим, как выглядит обычный запуск команды:

Для тех, кто не знаком с командой snmpdf, поясним, что она предназначена для удаленного выполнения в системах, обладающих поддержкой SNMP и настроенных для получения информации из раздела MIB, имеющего отношение к дискам. Часто инструменты командной строки, использующие протокол SNMP, обладают большим числом параметров, что осложняет их использование. Справедливости ради следует заметить, что создатели вынуждены разрабатывать инструменты, которые могли бы работать с версиями 1, 2 и 3 протокола SNMP, и дополнительно разрешать целый ворох других проблем. А что, если эти проблемы к вам не относятся и к тому же вы достаточно ленивы? Вы можете создать собственную кудзу-версию утилиты snmpdf, которая принимает в качестве аргумента только имя машины. Без всяких сомнений, это возможно. В примере 13.10 показано, как могла бы выглядеть такая утилита.

Часто, чтобы изменить поведение утилиты UNIX с помощью языка Python, приходится писать больше строк программного кода, чем на языке bash. Но, несмотря на это, мы отдаем предпочтение языку Python, потому что он позволяет использовать более богатый набор средств для расширения инструментов под свои нужды. Кроме того, вы можете протестировать этот программный код точно так же, как вы тестируете другие свои сценарии, поэтому часто дополнительный программный код - это правильный выбор в долгосрочной перспективе.

Пример 13.10. Обертка для команды snmpdf на языке Python

Этот сценарий уместился примерно в двадцать строк программного кода, но он делает нашу жизнь намного проще. Использование волшебных особенностей модуля optparse помогло предусмотреть значения по умолчанию для некоторых аргументов, наилучшим образом соответствующие нашим потребностям. Например, мы определили, что по умолчанию будет использоваться версия 2 протокола SNMP, так как мы знаем, что в нашем вычислительном центре используется только эта версия протокола. Кроме того, для параметра community мы выбрали в качестве значения по умолчанию строку "public", потому что именно это значение определено в нашей лаборатории исследований и разработки, например. Самое замечательное, что использование модуля optparse позволило нам гибко изменять значения параметров, не изменяя сам сценарий.

Обратите внимание, что значения по умолчанию устанавливаются с помощью метода set_default(), который позволяет одним вызовом устанавливать сразу все значения по умолчанию аргументов инструмента командной строки. Мы включили старые параметры, такие как -с, и с помощью модуля optparse обернули их новыми значениями, в данном случае - options.community. Хотелось бы надеяться, что этот пример достаточно наглядно демонстрирует, как прием «кудзу» и широкие возможности языка Python позволяют обернуть инструмент и изменить его так, чтобы он полнее отвечал нашим потребностям.

Шаблон проектирования «гибрид кудзу»: обертывание инструментов сценариями на языке Python с изменением их поведения

В последнем примере мы существенно облегчили использование утилиты snmpdf, но не изменили поведение инструмента. Оба инструмента выводят совершенно идентичную информацию. другой прием, который можно использовать, позволяет не только обернуть утилиту UNIX, но и изменить ее поведение с помощью языка Python.

В следующем примере мы воспользуемся генераторами языка Python и приемами функционального программирования, чтобы отфильтровать результаты нашей команды snmpdf в поисках критически важной информации и затем добавить к ней флаг "CRITICAL". В примере 13.11 показано, как могла бы выглядеть такая утилита.

Пример 13.11. Измененная версия команды snmpdf с применением генераторов

Запустив эту «измененную» версию команды snmpdf, мы получили следующий результат на тестовой машине:

Теперь у нас имеется совершенно другой сценарий, который выводит только значения от 90 процентов и выше, обозначенные нами как критические. Мы могли бы запускать этот сценарий из cron каждую ночь для опроса нескольких сотен машин и отправлять результаты, полученные от нашего сценария, по электронной почте. Кроме того, мы могли бы расширить этот сценарий и отыскивать записи с объемом использования 80 процентов, 70 процентов и выдавать предупреждения по достижении этих уровней. Такой сценарий легко можно было бы объединить, например, с Google App Engine, с целью создания веб-приложения, вbinолняющего мониторинг использования дискового пространства во всей инфраструктуре.

Рассмотрим теперь сам программный код. Здесь есть несколько моментов, отличающих этот сценарий от предыдущих примеров, на которых стоит остановиться. Первое отличие состоит в том, что вместо функции subprocess.call() используется метод subprocess. Popen(). Если вам когда-нибудь потребуется анализировать вывод, получаемый от утилиты UNIX, то subprocess. Popen() - это именно то, что вам нужно. Кроме того, обратите внимание, что мы использовали метод stdout.re-adlines(), который возвращает список строк. Это будет важно позднее, когда эти выходные данные будут пропускаться через серию выражений-rенераторов.

В разделе с конвейером генераторов мы пропускаем наш объект-rенератор через два выражения, вbinолняющих поиск критических значений в соответствии с заданным нами условием. Как отмечалось выше, мы легко могли бы добавить еще пару строк с выражениями-rенераторами, чтобы получить результаты для пороговых значений 70 и 80 процентов.

Этот инструмент, возможно, оказался немного более сложным, чем вам хотелось бы. Возможно, лучше было бы разбить его на несколько небольших и универсальных частей, которые можно было бы импортировать. И все-таки этот сценарий неплохо иллюстрирует наш пример.

Шаблон проектирования «гибрид кудзу»: обертывание инструментов сценариями на языке Python с порождением процессов

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

В примере этого раздела мы создали тестовый сценарий, который создавал файлы образов с помощью команд dd, работающих параллельно. Возьмем эту идею за основу и создадим инструмент командной строки, который можно было бы использовать снова и снова. Как минимум, получим средство создания высокой нагрузки на дисковую подсистему ввода-вывода, которое пригодится для тестирования нового файлового сервера. Исходный текст сценария приводится в примере 13.12.

Пример 13.12. Множественная команда dd

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

Сразу же можно сказать, что этот инструмент мог бы пригодиться для тестирования производительности дисковой подсистемы ввода-вывода на высокоскоростных устройствах Fiьre SAN или NAS. Приложив еще немного усилий, можно было бы добавить функции для создания отчетов в формате PDF и отправки результатов по электронной почте. Следует отметить, что то же самое можно было бы реализовать на основе потоков выполнения, если потоки соответствуют уровню сложности проблемы, которую необходимо решить.

Set as favorite

Bookmark

Email This

Hits: 448

Комментарии (0)

RSS feed Comments

Написать комментарий

Имя

Электронный адрес

Вебсайт

Заголовок

Комментарий

smaller | bigger

Subscribe via email (Registered users only)

I have read and agree to the Terms of Usage.

Добавить комментарий