Windows Server 2012, PowerShell 3.0 и DevOps (часть 1)
В первой части этой серии статей я поделюсь с вами некоторой вводной информацией о PowerShell и DevOps . Во второй статье я расскажу о них более подробно. PowerShell 3.0, как и WindowsServer 2012, включает в себя множество новых функций и улучшений, так что мой рассказ затронет лишь некоторые из них.
Джеффри
Я впервые услышал о DevOps в подкасте, посвященном конференции Velocity 2009. В то время как большинство представителей ИТ-индустрии боролись за развертывание новых релизов несколько раз в году, Джон Оллспоу (John Allspaw) и Пол Хаммонд (Paul Hammond) рассказывали о «10 развертываниях в день: сотрудничество разработчиков и эксплуатационщиков во Flickr». Они решили достигнуть бизнес-целей с помощью изменения культуры труда и инструментов, в результате чего родился новый термин – DevOps. Проблема состоит в том, что разработчики считают себя ответственными за предоставления функционала, тогда как эксплуатационники отвечают за поддержание сайта в рабочем состоянии. Разрыв между разработчиками и эксплуатационниками приводит к возникновению взаимных обвинений в случаях, когда что-то идет не так. Успешный бизнес требует наличия ИТ-культуры, подразумевающей общую ответственность и взаимное уважение: разработчики думают о нуждах и проблемах эксплуатационников, и эксплуатационники, думают о нуждах и проблемах разработчиков.
Они рассказывают, как различные виды бизнеса требуют проведения быстрых изменений и как эти изменения становятся причиной большинства случаев отказов в работе сайтов. Игнорируя традиционный подход «избегать изменений», они выступили в защиту подхода с минимизацией рисков посредством внесения изменений через автоматизацию. Это и есть работа DevOps – безопасное изменение. Это метод управления качеством Тагучи , примененный к ИТ-операциям. Тагучи заметил, что причиной низкого качества является вариативность. Решение состояло в том, чтобы сначала сделать процесс повторяемым. Как только вы достигали этого, вы могли вносить небольшие изменения, наблюдая за тем, улучшают они объект или ухудшают. Отказывайтесь от изменений, которые ухудшают объект. Продолжайте делать вещи, которые улучшают объект. Ключом является повторяемость. Повторяемость позволяет ставить эксперименты, которые приводят к усовершенствованиям. Мы достигаем повторяемости в ИТ-операциях через автоматизацию.
Мы начали проект PowerShell, выпустив документ MonadManifesto, в котором формулировались проблемы, которые видели, наш подход к их решению и компоненты, которые предоставляли. Мы предполагали появление распределенного механизма автоматизации со скриптовым языком, который будет использоваться начинающими эксплуатационниками и опытными разработчиками. Дизайн PowerShell создавался под влиянием тех же принципов, которые легли в основу DevOps:
- Ориентированность на бизнес
- Обеспечение безопасности изменений посредством автоматизации
- Устранение пропасти между разработчиками и эксплуатационниками
Ориентированность на бизнес
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#. Это обеспечивает некоторую мобильность карьере тех эксплуатационников, которые хотели бы перейти к разработке.
Самым важным является то, что мы хотели разработать инструмент, который мог бы использоваться как эксплуатационниками, так и разработчиками, и который мог бы объединить эти группы и позволить им создавать общие скрипты, учиться друг у друга и работать вместе.
WindowsServer2012 и PowerShell3.0 – превосходные инструменты DevOps
DevOps – это новый термин, и есть некоторые разногласия в отношении того, что он с собой несет, однако, в основе своей, это всегда стремление сделать изменения безопасными посредством автоматизации и ликвидации пропасти между эксплуатационниками и разработчиками. Еще многое предстоит сделать в этой области, но Windows Server 2012 и PowerShell 3.0 делают большие успехи в достижении своих целей. PowerShell не будет единственным инструментом в вашем наборе утилит DevOps, однако он точно будет в каждом наборе утилит DevOps. Скачайте RC -версию сегодня и попробуйте все сами.
Джеффри Снувер,
Ведущий инженер и ведущий архитектор Windows Server