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

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

Я впервые услышал о DevOps в подкасте, рассказывающем о конференции Velocity 2009 года. Тогда как большинство представителей ИТ-индустрии старались совершать развертывание новых релизов несколько раз в году, Джон Оллспоу (John Allspaw) и Пол Хаммонд (Paul Hammond) рассказывали о "10 развертываниях в день: сотрудничество разработчиков и эксплуатационщиков во Flickr". Они сделали выбор в пользу достижения бизнес-целей через изменение культуры и инструментов для достижения этой цели, в результате чего родился новый термин: DevOps. Проблема состоит в том, что разработчики считают себя ответственными за предоставления функционала, тогда как эксплуатационщики отвечают за поддержание сайта в рабочем состоянии. Разрыв между разработчиками и эксплуатационщиками приводит к возникновению взаимных обвинений в случаях, когда что-то идет не так. Успешный бизнес требует наличия ИТ-культуры, подразумевающей общую ответственность и взаимное уважение: разработчики, думающие о нуждах и проблемах эксплуатационщиков, и эксплуатационщики, думающие о нуждах и проблемах разработчиков.

В их беседе описывается то, как различные виды бизнеса требуют проведения быстрых изменений, однако эти изменения являются первопричиной большинства случаев отказов в работе сайтов. Игнорируя традиционный подход "избегать изменений", они выступали в защиту подхода с минимизацией рисков посредством внесения изменений через автоматизацию. Это и есть работа DevOps - безопасное изменение. Это был метод управления качеством Тагучи, примененный к ИТ-операциям. Тагучи заметил, что первопричиной низкого качества является вариативность. Решением было, во-первых, определение способа сделать какой-либо процесс повторяемым. Как только вы смогли сделать это, вы можете вносить небольшие изменения в этот процесс, наблюдая за тем, улучшают они объект или ухудшают. Отказывайтесь от изменений, которые ухудшают объект. Продолжайте делать вещи, которые улучшают объект. Ключом здесь является повторяемость. Повторяемость позволяет делать эксперименты, которые приводят к усовершенствованиям. Мы достигаем повторяемости в ИТ-операциях через автоматизацию.

Мы дали начало PowerShell, выпустив документ Monad Manifesto, в котором были сформулированы проблемы, которые мы видели, и наш подход к их решению и компоненты, которые мы предоставляли. Мы предполагали появление распределенного механизма автоматизации со скриптовым языком, который будет использоваться начинающими эксплуатационщиками и опытными разработчиками. Дизайн PowerShell создавался под влиянием тех же принципов, которые легли в основу DevOps:

1. Ориентированность на бизнес
2. Обеспечение безопасности изменений посредством автоматизации
3. Устранение пропасти между разработчиками и эксплуатационщиками


Ориентированность на бизнес
PowerShell всегда был ориентирован на людей, использующих компьютеры для ведения бизнеса. PowerShell должен был быть последовательным, безопасным и производительным. Многое было достигнуто благодаря схожести PowerShell и UNIX, однако, в этом отношении мы намного ближе к VMS/DCL и AS400/CL.

Последовательный: Операторы и разработчики не должны тратить много времени на изучение новых функций. Последовательный опыт использования позволяет им один раз получить необходимые навыки и затем использовать их снова и снова. PowerShell использует единый анализатор синтаксиса для всех команд и выполняет общую проверку параметров, обеспечивая полное единообразие в синтаксисе командной строки. Наборы команд PowerShell спроектированы таким образом, чтобы повсеместно используемые параметры обеспечивали схожие функции для всех команд (например, -ErrorAction, -ErrorVariable, -OutputVariable и т.д.).

Безопасный: Один эксплуатационщик однажды сказал мне, что он как-то раз собирался кое-что сделать и понял, что если бы что-то пошло не так, то его бы уволили. В PowerShell если вы выполняете набор команд, у которого могут быть побочные действия, влияющие на систему, вы всегда можете ввести параметр -WhatIf, чтобы проверить, что произойдет, если вы выполните операцию до конца. Мы также поддерживаем параметры -Confirm, -Verbose и -Debug. Несмотря на эти предосторожности, что-то по-прежнему может пойти не так, и когда это происходит, PowerShell прикладывает максимум усилий, чтобы ускорить процесс диагностики и решения проблемы.

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


Обеспечение безопасности изменений посредством автоматизации
Уже было много дискуссий о том, является ли PowerShell языком .Net, скриптовым языком или интерактивной оболочкой. PowerShell - это распределенный механизм автоматизации со скриптовым языком и интерактивной оболочкой (-ами). Интерактивные оболочки и скриптовый язык - это критические важные компоненты, однако фокус всегда был на автоматизации посредством выполнения сценариев. Автоматизация - это процесс сокращения количества и/или устранения операций, выполняемых человеком. Сценарий (или скрипт) - это описание того, что должно произойти. Люди могут просматривать сценарий, и вы можете изменять его, основываясь на обратной связи от них. Вы можете тестировать скрипт, наблюдать за результатом его выполнения, изменять скрипт и, если изменения прошли хорошо, сохранять их, либо, если изменения прошли плохо, отменять их. Другими словами, выполнение сценариев обеспечивает повторяемость, требуемую для применения метода Тагучи к ИТ-операциям. Как только вы автоматизировали процесс, вы можете безопасно выполнять его снова и снова. Эти процессы теперь могут выполняться менее опытными администраторами. Эти шаги невозможны, когда вы используете традиционные инструменты администрирования с графическим пользовательским интерфейсом.


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

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

Вы когда-нибудь задавались вопросом, почему PowerShell использует фигурные скобки {} (и другие конструкции языка C) вместо связки BEGIN/END, как другие скриптовые языки? Мы сделали это потому что мы хотели облегчить принятие PowerShell разработчиками других С-подобных языков программирования: C++, Objective C, Java, JavaScript, Perl, PHP и т.п. Мы провели тестирование и решили, что эксплуатационщики смогли бы легко приспособиться к этому синтаксису. Мы также хотели обеспечить плавный переход между PowerShell и C#. Это обеспечивает некоторую мобильность карьере тех эксплуатационщиков, которые хотели бы перейти к разработке.

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


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

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