Windows Server 2012, PowerShell 3.0 и DevOps (ч.2)

Это заключительная часть моей серии статей. В первой статье я дал некоторую вводную информацию по PowerShell и DevOps. В этой статье я расскажу вам о них более подробно. PowerShell 3.0, как и Windows Server 2012, включает в себя множество новых функций и улучшений, так что мой рассказ затронет лишь некоторые из них.

Джеффри

Хотя PowerShell всегда была ориентирована на задачи DevOps, PowerShell 3.0 и Windows Server 2012 поднимает это на новый уровень. В Windows Server 2012 мы сместили стратегию по созданию превосходной ОС для сервера в сторону облачной ОС для множества серверов и устройств, которые соединяют их, вне зависимости от того, являются ли они физическими или виртуальными, локальными или удаленными. Чтобы добиться этого, нам нужно было многое сделать для:

• Автоматизации всех процессов
• Надежной и быстрой автоматизации
• Упрощения процесса автоматизации для эксплуатационщиков
• Упрощения процесса создания инструментов для разработчиков

Автоматизация всех процессов
Windows Server 2008/R2 поставлялся с 230 наборами команд. Windows Server 2012 увеличивает это количество более чем в 10 раз, предлагая порядка 2430 командлетов. Теперь вы можете автоматизировать почти каждый аспект работы сервера. Здесь есть наборы команд для сети, хранилищ данных, кластеризации, RDS, DHCP, DNS, файловых серверов, принт-серверов, SMI-S и т.д. - список можно продолжать еще долго. Если вы читали статьи о Windows Server 2012, то вы знаете, как много вещей можно сделать с помощью PowerShell. Если вы не следили за новостями, прочитайте публикации Хосе Баррето (Jose Barreto) о файловом сервере, Йигала Эдери (Yigal Edery) о частном облаке, блог Бена Армстронга (Ben Armstrong) Virtual PC Guy’s Blog, публикации в блоге Clustering and High-Availability или статьи Натальи Макевичус (Natalia Mackevicius) в блоге Partner and Customer, и вы узнаете, что я имею ввиду. Windows Server 2012, безусловно, является наиболее автоматизируемой версией Windows за всю ее историю.

Многие наши партнеры-производители аппаратного и программного обеспечения уже предлагают свои наборы команд PowerShell, а есть и такие, кто еще не выпустил их, усердно работая над тем, чтобы выпустить их с новыми версиями своих продуктов. Это было очевидно на недавно прошедшей в Лас-Вегасе конференции MMS, и я думаю, что мы увидим еще большую поддержку на TechEd. Вы обязательно должны удостовериться, что любой продукт, который вы собираетесь купить, предлагает полный комплект наборов команд PowerShell. Если это не так, то вам стоит дважды подумать и убедиться в том, что вы получите продукт, который актуален и в разработку которого продолжают делать инвестиции. Если они не уделяют внимание PowerShell, что еще они могли упустить? Хорошие новости в том, что многие продукты будут поддерживать PowerShell к моменту релиза Windows Server 2012, а также то, что продукты, которые уже поставляются с командлетами, хорошо с ними работают и имеют много положительных отзывов. КАЖДЫЙ продукт, который поставляется с наборами команд PowerShell, увеличивает свои инвестиции в PowerShell в его будущих релизах.


Надежная и быстрая автоматизация

Рабочий процесс
Мы интегрировали механизм Windows Workflow Foundation в PowerShell, чтобы упростить автоматизацию процессов, которые занимают много времени, выполняются в очень больших масштабах или которые требуют координирования множества шагов на нескольких машинах. Традиционно Windows Workflow был инструментом только для разработчиков, требуя для своей работы Visual Studio и большие объемы кода для создания решения. Мы сделали его "in-the-box"-решением, который эксплуатационщики могут использовать создания своих решений, используя свои навыки в написании скриптов PowerShell. Рабочий процесс обеспечивает прямую поддержку для параллельных вычислений, повторных операций и возможность приостанавливать и возобновлять операции. Например, рабочий процесс может обнаружить проблему, которая требует ручного вмешательства, уведомить об этом эксплуатационщика и затем приостановить операцию до тех пор, пока он не исправит ситуацию и не возобновит процесс.

Эксплуатационщики могут использовать любой доступный конструктор Workflow для создания рабочего процесса. Однако, мы пошли еще дальше и упростили процесс разработки, расширив язык PowerShell ключевыми словами рабочих процессов. Каждый эксплуатационщик или разработчик теперь могут легко создавать рабочий процесс, используя инструменты, которые есть во всех редакциях Windows. Поведение рабочего процесса отличается от поведения функции и подчиняется нескольким дополнительным правилам, однако если вы знаете, как написать функцию PowerShell, то вы на 80% готовы писать рабочий процесс. Создавать рабочие процессы с помощью PowerShell намного легче, чем работать с XAML, и многим из нас намного проще будет освоить PowerShell, чем инструменты конструкторов Workflow. Вы также получаете выгоду от возможности вставлять их в электронные письма, чтобы кто-то другой мог прочитать/просмотреть их без необходимости установки специальных утилит. Ниже приведен пример рабочего процесса, который выполняется на нескольких машинах параллельно, одновременно собирая информацию о конфигурации на нескольких машинах.

Команда, приведенная ниже, получает эту информацию из списка серверов, содержащегося в файле servers.txt, и выводит полученные результаты в файл. Если какой-либо из серверов недоступен, рабочий процесс будет пытаться связаться с ним каждый 60 секунд на протяжении часа.

Рабочий процесс - это именно то, что нужно практикам DevOps для надежного выполнения повторяющихся операций. Одним из ключевых методов DevOps является A/B-тестирование, при котором две версии программного обеспечения развертываются и выполняются на протяжении определенного промежутка времени. Они обследуются на наличие положительных метрик (например, увеличение продаж) и затем выигравшая версия развертывается на все машины. Возможности рабочего процесса позволяют PowerShell выполнять операции на большом количестве машин на протяжении большого отрезка времени, упрощая автоматизацию A/B-тестирования.

Запланированные задания
Мы также интегрировали Планировщик задач (Task Scheduler) и задания PowerShell, чтобы упростить автоматизацию операций, которые либо проводятся на регулярной основе, либо в ответ на появление какого-либо события. Ниже представлен рабочий процесс, который должен работать вечно. Он собирает информацию о конфигурации (информацию о дисках) и затем сам себя приостанавливает. Этот рабочий процесс запущен и ему присвоено имя "CONFIG". Мы возобновим выполнение этого рабочего процесса с помощью планировщика задач. В этом примере мы регистрируем ScheduledJob для его запуска каждую пятницу в 6 часов вечера и после каждого запуска системы. Когда срабатывает один из триггеров, запланированное задание запускается и возобновляет выполнение рабочего процесса с помощью его имени. Затем рабочий процесс собирает информацию о конфигурации, помещает ее в новый файл и снова приостанавливает свою работу.

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

В статье Войтека Козачински (Wojtek Kozaczynski) об основанном на стандартах управлении сервером он рассказал о том, как мы сделали WS-MAN нашим главным протоколом управления и сохранили COM и DCOM для обратной совместимости. WS-MAN - это протокол веб-сервисов, использующий HTTP и HTTPS. Хотя фактически это REST-протокол, PowerShell формирует поверх него сеансовый уровень, чтобы повторно использовать удаленный процесс для улучшения производительности и воспользоваться преимуществами установленного состояния сеанса. Эти сеансы были устойчивы перед лицом кратковременных прерываний работы сети, однако они иногда могут останавливаться, когда эксплуатационщики управляют серверами со своих ноутбуков по Wi-Fi, перемещаясь между зданиями. Мы улучшили сеансовый уровень WS-MAN. По умолчанию он может выдержать падение сети на срок до 3-х минут. Поддержка состояния Disconnected Sessions была добавлена в PowerShell, что дает пользователям возможность отключаться от активной удаленной сессии и затем повторно подключаться к той же самой сессии, не теряя при этом ее состояния и нуждаясь в принудительном завершении выполняемых задач. Вы можете даже подключиться к сеансу с другого компьютера (так же, как и в случае с сеансом удаленного рабочего стола).


Упрощение процесса автоматизации для экплуатационщиков
Мы хотели существенно уменьшить уровень навыков, необходимых для успешной автоматизации сложный решений. В конечном итоге мы хотим создать мир, где эксплуатационщики смогут подумать о том, что они хотят получить, написать это и получить готовый результат. Потребности клиентов и сценарии их работы могут быть очень разными, так что им необходимо иметь возможность написать сценарий для их собственных решений. Наша цель состоит в том, чтобы упростить процесс создания скрипта, объединяя между собой абстракции, ориентированные на высокоуровневые задачи. Одним из аспектов этого процесса является наборы команд. Вот почему наличие 2430 командлетов значительно упрощает автоматизацию работы Windows Server 2012. Многие из этих наборов команд чрезвычайно эффективны при работе с вычислительными центрами. У нас есть командлеты для работы с REST API, объектами JSON и даже для получения, анализа и публикации веб-страниц из управляющих приложений, если это требуется.

PowerShell 3.0 упрощает язык и наборы команд для уменьшения количества шагов и синтаксических конструкций, необходимых для выполнения операций. Ниже приведен пример старого и нового синтаксиса.

PowerShell 3.0 улучшает инструменты разработки, используемые эксплуатационщиками для создания скриптов и рабочих процессов. PowerShell-ISE теперь поддерживает IntelliSense, сниппеты, сторонние расширения, а также окно Show-Command, которое упрощает процесс поиска нужной команды и параметров, необходимых вам для выполнения вашей задачи.

Простой процесс создания утилит разработчиками
Разработчики всегда любили писать скрипты на PowerShell благодаря ее функциональности, возможности использовать синтаксические конструкции языка C и умение работать с объектами .NET. PowerShell 3.0 убирает множество преград во взаимодействии с объектами .NET, а также позволяет разработчикам использовать PowerShell для гораздо больше диапазона сценариев.


Улучшение процесса создания инструментов
PowerShell 3.0 теперь включает в себя Abstract Syntax Tree (AST). Эта функция позволяет использовать новые классы интеллектуальных инструментов для создания, анализа и манипуляции скриптами PowerShell. Один из облачных сервисов Microsoft зависит от очень большого количества скриптов PowerShell для выполнения всех аспектов работы сервиса. Его команда разработчиков использует AST для создания инструмента анализа скриптов с целью внедрения целого набора лучших практик использования скриптов для их эксплуатационщиков. Появление AST является причиной, почему IntelliSense настолько функционален. Он использует AST для анализа действительного поведения программы.

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

Улучшение процесса создания скриптов
PowerShell 3.0 теперь используется технологию .NET Dynamic Language Runtime (DLR). PowerShell следит за тем, как выполняется скрипт и компилирует скрипт или часть скрипта "на лету" для оптимизации производительности. Хотя этот показатель варьируется, некоторые скрипты выполняются на версии 3.0 до шести раз быстрее.

Intellisense (и завершение команд по нажатию кнопки Tab в командной строке) теперь работает с пространством имен и типами .NET.

Это позволяет вам анализировать программу и использовать различные типы данных для улучшения качества IntelliSense.

Мы расширили нашу хэш-таблицу двумя ее вариантами, которые позволяют разработчикам еще проще добиваться от скрипта такого его поведения, которое им нужно:

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

PowerShell 3.0 теперь также доступен как дополнительный компонент WINPE.


Windows Server 2012 и PowerShell 3.0 - превосходные инструменты DevOps
DevOps - это новый термин, и хотя есть некоторые разногласия относительно того, что он собой представляет, в его основе лежит стремление сделать изменения безопасными с помощью средств автоматизации, а также преодолеть пропасть между эксплуатационщиками и разработчиками. Еще многое можно сделать в этой области, однако в Windows Server 2012 и PowerShell 3.0 мы добились значительных успехов в достижении этих целей. PowerShell не будет единственным инструментом на вашей панели DevOps, но она точно должна быть на каждой панели инструментов DevOps. Загрузить RC-версию уже сегодня и откройте для себя мир возможностей PowerShell 3.0.

Источник: http://blogs.technet.com/windowsserver
Перевод: Dazila