Энн ГраббШирокие возможности PowerShell

Специалист в области IT Алекс Ангелопулос питает слабость к составлению сценариев. За 10 лет работы в должности консультанта и сетевого администратора он написал сотни сценариев, обеспечивающих автоматизацию самых разных задач административного управления. А в качестве автора, чьи статьи регулярно публиковались на страницах издания Scripting Pro VIP (www.scriptingprovip.com ), Алекс помогал ИТ-специалистам по Windows изучать достоинства сценариев и успешно создавать их. Недавно я побеседовала с Алексом о том, что он думает об эффективности такого инструмента, как PowerShell, и о том, как с помощью этой оболочки администраторы Windows могут облегчить себе задачу создания собственных решений.

С чего вы начинали свою работу в сфере ИТи чем занимаетесь в настоящее время?

Я начинал еще в эпоху Windows 95 с поддержки предприятий малого и среднего бизнеса. В последние годы пишу статьи об автоматизации задач административного управления и разрабатываю специализированные решения в сфере администрирования.

Что подтолкнуло вас к написанию сценариев?

Я начал писать сценарии в 1992 году в среде UNIX. Что касается системы Windows, то здесь стимулом послужила работа с локальной сетью, управлять которой я помогал с 1997 по 1999 год. «Волшебного» средства для решения всех проблем мы тогда так и не нашли, зато сумели резко сократить рабочую нагрузку с помощью средств автоматизации. Кстати, в ходе этой работы сформировался мой взгляд на то, какой должна быть среда для составления сценариев.

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

Что пробудило в вас интерес к использованию оболочки PowerShell?

Я начал работать с этой оболочкой, как только появилась возможность загрузить по каналам Internet ее бета-версию; эта идея уже давно меня увлекала. Ведь, в сущности, PowerShell — это оболочка, разработанная «с нуля» группой специалистов, имеющих огромный опыт работы с bash, csh, Perl, VMS DCL, а также с другими оболочками и языками сценариев. Их совокупный опыт работы с этими продуктами составляет сотни лет!

Ничего похожего для Windows раньше не было. Оболочка cmd.exe появилась более или менее «сама по себе», и разработчики, совершенствовавшие ее впоследствии, всегда были ограничены такими факторами, как требования совместимости и имеющаяся инфраструктура Windows. Разработчики Windows Script Host (WSH) действительно явным образом проектировали WSH для администрирования среды Windows, но они создавали машину сценариев, а не оболочку. И вновь разработчики были ограничены, во-первых, другими ролями, которые должны были играть эти языки, во-вторых — предшествующей историей языков и опять-таки инфраструктурой Windows.

Какие особенности делают оболочку PowerShell особенно полезной для администраторов Windows? Насколько просто писать сценарии в среде PowerShell по сравнению с другими языками сценариев?

В краткосрочной перспективе первостепенное значение имеет тот факт, что речь идет об оболочке и что вы можете работать интерактивно 15-секундными фрагментами. То же можно сказать и о другом обстоятельстве: продукт спроектирован для того, чтобы с легкостью «склеивать» элементы; ведь почти все реальные проблемы администраторов решаются не столько путем разработки решений, сколько путем их объединения.

В долгосрочной перспективе важно то, что в PowerShell используются принципы оболочек администрирования, которые годами совершенствовались в средах UNIX/Linux, VMS и Windows, а это «непреходящие ценности». Что же касается простоты написания сценариев, то ответ на этот вопрос подчеркивает одну особенность PowerShell. Когда вам известны базовые принципы, задачи пакетной обработки данных выполняются исключительно легко. Некоторые задачи PowerShell пока не позволяет выполнять с высокой эффективностью, и, может быть, никогда не будет этого делать. Например, сложные задачи автоматизации с использованием объектной модели программных компонентов, достаточно просто решаемые в среде WSH, иногда исключительно трудны для PowerShell в связи с ограничениями .NET. Для их решения в среде PowerShell нужно использовать сценарий WSH или даже непосредственно помещать в оболочку код на языках VBScript/JScript. Это не состязания по принципу «чье средство лучше», речь идет о том, чтобы выполнить работу имеющимися средствами самым простым способом.

Расскажите о написанных вами полезных сценариях PowerShell. Насколько успешно такие сценарии решают коммерческие или технические задачи?

Как я убедился, главное преимущество PowerShell состоит в том, что пользователи этой оболочки могут обходиться без подготовки сценариев. Вы можете импровизировать, что называется, на ходу. В отличие от моих сценариев WHS, почти все мои длинные сценарии PowerShell связаны со сложными проблемами тех или иных организаций. Повседневные задачи — это другая история.

Джеффри Сновер весьма наглядно проиллюстрировал эту мысль в своем интервью TechNet (см. channel9.msdn.com/Showpost.aspx?postid=25506), где он разъяснил суть стандартной административной модели. Допустим, вы хотите получить ту или иную информацию. Вы выполняете некоторую команду, результата нет, пробуете другое средство — решение почти найдено. Теперь вы знаете, что нужно делать, и переходите к следующей задаче.

Позвольте мне в качестве иллюстрации привести пример с использованием VBScript, моего любимого языка сценариев. Вот я сижу за подключенным к сети компьютером, и мне нужно определить версию операционной системы компьютера Weeble (я вижу его в сети). Я мог бы просто подойти к интересующему меня компьютеру, но для этого его нужно разыскать. А может быть, он находится в запертом помещении или в другом офисе. Я знаю, что могу выяснить все детали, воспользовавшись классом Win32_OperatingSystem инструмента управления Windows (Windows Management Instrumentation, WMI); теоретически я мог бы получить нужную информацию, написав сценарий на языке VBScript, но мне нужно, помимо прочего, знать свойства этого класса. Имена свойств я тоже могу перечислить на языке VBScript, но на это уйдет еще больше времени. И как бы то ни было, написав этот сценарий, я, скорее всего, никогда не буду выполнять его повторно. Выполнение такого рода задач не относится к сильным сторонам VBScript.

В PowerShell мне пришлось бы просто выполнить следующую команду:

gwmi Win32_OperatingSystem -Computer Weeble

Она отображает базовые сведения об удаленной операционной системе. Отметим, что в ней нужно указать настоящее имя компьютера. Но оказывается, что в формате по умолчанию команда не отображает те данные, которые мне нужны; допустим, я хочу знать, имеет ли система 32-разрядную или 64-разрядную архитектуру, а также какая версия операционной системы на ней установлена. Поэтому я предписываю PowerShell сообщить мне обо всех свойствах компьютера в формате списка:

gwmi Win32_OperatingSystem -Computer | fl *

Просмотрев выходные данные, я вижу, что интересующие меня сведения — это OSArchitecture и Caption. Однако они больше не нужны; я узнал все, что мне требовалось. Я мог бы модифицировать строку команды следующим образом:

gwmi Win32_OperatingSystem -Computer | fl OSArchitecture,Caption

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

Что бы вы посоветовали администраторам Windows, которые приступают к освоению среды PowerShell?

Я предложил бы им начать с малого. Пусть устанавливают PowerShell на той системе, с которой они обычно работают, и начинают использовать продукт как оболочку командной строки и как диалоговое окно Run. Разобраться с PowerShell можно только одним способом: использовать эту среду. Кроме того, я советую администраторам задействовать свои старые инструменты в среде PowerShell, ведь они уже знают, как эти средства работают.

Администраторам нужно постоянно следить за работой сетей и программных пакетов. Когда они сталкиваются с проблемами, не имеющими приемлемых по цене готовых решений, то приступают к поискам «клея» для объединения собственных решений. Эти решения всегда имеют свои ограничения: характеристики проблемы, знания администратора и имеющиеся ресурсы. В течение ближайших лет пользователи начнут лучше разбираться в среде PowerShell, и она получит более широкое распространение. Оболочка войдет в комплекты поставок новых версий Windows, а несовместимые с ней системы Windows 2000 постепенно будут выводиться из эксплуатации. Важно отметить еще одно обстоятельство: PowerShell не будет заменять ныне используемые инструментальные средства; в ней можно без труда выполнять привычные cmd.exe и WSH. Преимущество PowerShell в том, что эта оболочка эффективнее «склеивает» готовые фрагменты. Ее использование не предполагает переделки всего, что администратор наработал за последние десять лет.

Какие ресурсы могли бы вы порекомендовать тем, кто не имеет опыта работы с PowerShell?

Если говорить о PowerShell, то начинать нужно с использования этого пакета в качестве оболочки. Есть вещи, на объяснение которых мы тратим тысячи слов, и все равно остаются неясности. Но стоит попробовать на практике, как все становится понятно. Другие хорошие источники — центр сценариев TechNet, группа новостей PowerShell на Web-узле news.microsoft.com, блог разработчиков PowerShell, а также книги и презентации группы разработчиков PowerShell.