Virtual Machine Factory

Сообщество Visual Studio ALM Rangers представляет VM Factory

Уилли-Питер Шауб
Брайен Блэкмен
Пол Мейер

Продукты и технологии:

VM Factory, Windows PowerShell, Lab Management, Team Foundation Server, Visual Studio 2010

В статье рассматриваются:

• архитектура VM Factory;

• использование Windows PowerShell;

• администрирование VM Factory;

• расширение VM Factory;

• другие ресурсы.

Исходный код можно скачать по ссылке rangersvsvmfactory.codeplex.com.

 

В этой статье мы углубимся в Virtual Machine Factory (VM Factory), чтобы изучить ее концепции и преимущества.

Данная статья является частью серии, в которой Visual Studio ALM Rangers представляют руководство, помогающее в решении задач в сложных средах. Наша цель — способствовать согласованности и качеству ваших решений и вашего процесса управления жизненным циклом приложений (Application Lifecycle Management, ALM) в целом.

Небольшое отступление: Rangers — это группа экспертов, которая стремится улучшить взаимодействие и сотрудничество между группой разработки продуктов Visual Studio, Microsoft Services и сообществом Microsoft Most Valuable Professional (MVP), чтобы восполнить недостающую функциональность, снять препятствия, мешающие внедрению новых технологий и продуктов, а также содействовать обмену передовым опытом и публикации руководств.

VM Factory (rangersvsvmfactory.codeplex.com) — это эталонная реализация программного решения и связанное с ним руководство, которые позволяют автоматизировать создание виртуальных сред, используя почти полностью автоматизированную и единообразную стратегию фабрики. Общая цель VM Factory — разработка нормативных руководств по виртуализации, особенно для Visual Studio, Team Foundation Server (TFS), Lab Management и соответствующих требований. Основными целями, как показано на рис. 1, являются: (1) гибкая автоматизация, управляемая схемами; (2) простой сценарий создания виртуальной машины (virtual machine, VM) одним щелчком кнопки мыши; (3) повторно используемая фабрика, которая автоматизирует установку и конфигурирование физической и виртуальной сред; (4) согласованные и воспроизводимые среды; (5) возможность повторного использования предварительно сконфигурированных сред.

Рис. 1. Цели VM Factory

Цели, не преследуемые VM Factory, — ускорение времени сборки и конфигурирования. Это называют анти-шаблоном (anti-pattern).

Хотя VM Factory гораздо более эффективна и рациональнее, чем обычная фабрика, на которой работают люди, основное время генерации среды занимает установка, которая не поддается значимому ускорению при автоматизации. Инициатива VM Factory исходит из экосистемы Rangers, которая известна своими возможностями в работе внутри распределенных, отключенных и зачастую ограниченных малой полосой пропускания сред (см. статью «Visual Studio ALM Rangers—Reflections on Virtual Teams» за сентябрь 2011 г. по ссылке msdn.microsoft.com/magazine/hh394152). Несмотря на осуществимость и приемлемость совместного использования и загрузки VM через Интернет, это может оказаться крупной проблемой в тех местах, где полоса пропускания является драгоценным ресурсом. VM Factory позволяет — вместо траты дней или даже недель на скачивание VM — удаленно воссоздавать идентичные образы, используя ресурсы по месту. Каковы бы ни были ограничения у локальных ресурсов, воссоздание образов происходит без вмешательства пользователей или с минимальным их участием.

Доставка согласованных образов — еще одно важное преимущество, о котором мы часто забываем упомянуть, и одна из основных причин, по которой Rangers используют VM Factory. Схемы образа передаются от версии к версии, т. е. когда мы создаем новую версию (v1.1) для исправления какой-либо ошибки, а затем выполняем сборку, чтобы включить новую версию ПО (v2), мы знаем, что исправление и новое ПО перейдут в последующие версии. Это особенно полезно, когда следующая версия (v3) может быть собрана через месяцы или даже годы. Когда между версиями проходит так много времени, проект может продолжить другая группа. При наличии согласованных образов конфигурация и разметка структуры VM Factory Task Sequence действуют как актуализируемый документ (living document), с которым может работать новая группа.

Последнее, но не менее важное — VM Factory позволяет создавать образы по запросу. Это уменьшает требования к дисковому пространству как на настольных, так и на переносных компьютерах, а также избавляет от «неуверенности» в том, что образ, извлеченный из хранилища, является наиболее свежей версией.

Виртуализация в Lab Management предоставляет автоматизированный рабочий процесс для сборки, развертывания и тестирования ПО. Создание этих виртуальных сред требует уймы ручной работы. В настоящее время вы должны установить библиотеку виртуальных машин и шаблонов для Microsoft System Center Virtual Machine Manager (VMM). Кроме того, вы должны работать в рамках топологии Lab Management.

Применение VM Factory значительно уменьшает объем работ, необходимых для создания VM и шаблонов VM. Еще важнее, что VM Factory облегчает изменение ОС или приложения, используемого для VM или шаблона VM. С VM Factory легко работать, потому что от вас требуется лишь изменение последовательности задач и последующий запуск автоматизированного воссоздания образа. В VM Factory такие образы называются золотыми, и они работают как источник виртуальных машин для Lab Management.

При создании VM вам предлагается выбрать последовательность задач, подлежащих выполнению. Мы предоставляем две последовательности задач для Visual Studio ALM Rangers Lab Management, о которых мы расскажем подробнее немного позже.

Краткий обзор архитектуры фабрики

Как показано на рис. 2 (с соответствующими числовыми обозначениями), архитектуру VM Factory можно разместить на любой Windows-платформе (1) с минимальными требованиями, например не менее 1 Гб оперативной памяти и 100 Гб свободного дискового пространства, выделенного под VM Factory. Эта архитектура основана на Microsoft Deployment Toolkit (MDT) (2) — одном из ускорителей решений от Microsoft (bit.ly/tp5QX4). Этот инструментальный набор предоставляет общую административную консоль и внушительный инструментарий и документацию для определения и управления развертыванием операционных систем и приложений (3). Используя последовательности задач (4), мы определяем последовательность этапов установки и конфигурирования, необходимых для развертывания ОС и приложений, таких как Microsoft Office и Visual Studio, используем собственные скрипты Windows PowerShell (5), о которых мы поговорим позже, и указываем носитель (6) для ОС и приложений. В настоящее время в VM Factory предполагается, что весь носитель (media) физически присутствует в VM Factory. Однако мы исследуем варианты, которые позволят ссылаться на другие источники, например для скачивания из MSDN, чтобы повысить гибкость и расширить повторное использование существующих ресурсов.

Рис. 2. Архитектура VM Factory

Каждая VM Factory поставляется с ISO-образами Litetouch CD Boot (7). Это позволяет инициировать новую установку и подключиться к общему сетевому ресурсу развертывания, размещенному в VM Factory. В процессе загрузки и установки выбирается соответствующая последовательность задач (8). Эта последовательность определяет ПО, конфигурацию и скрипты, применяемые на целевой машине (9) в ходе установки, управляемой Litetouch.

Visual Studio ALM Rangers VM Factory является предварительно заполненным (prepopulated) экземпляром MDT с предопределенными Factory Task Sequences. Они опираются на шаблоны последовательностей задач MDT для развертывания новой машины и включают все этапы, необходимые для создания новой машины, вплоть до «голого железа» (или «голого виртуального железа» в случае VM Factory). Эти этапы начинаются с форматирования диска и установки ОС и продолжаются до установки приложений включительно.

Последовательности задач, включенные в VM Factory, используются Rangers, чтобы создавать образы в демонстрационных целях, для экспериментов, практических лабораторных занятий и тестирования. Ниже дано описание этих последовательностей задач.

• Последовательности задач базовых образовTeamFoundationServer определяют образы всех Visual Studio, содержащие клиент и сервер TFS. Также включаются Word 2007, Excel 2007, PowerPoint 2007 и, как необязательное дополнение, Microsoft Office SharePoint Server (MOSS) 2007. В VM Factory входят последовательности задач как для x86 (на основе Windows Server 2008), так и для x64 (Windows Server 2008 R2).
• Последовательность задач образаLabManagementHands-onLab определяет комплексную демонстрационную среду для Lab Management. Этот образ основан на базовом образе x64 TFS, но также содержит Active Directory, DHCP и VMM. DHCP полностью сконфигурирован, но отключен по соображениям безопасности. VMM и Visual Studio Lab Management полностью сконфигурированы и требуют лишь добавления присоединяемого к домену хоста Hyper-V в группу хостов по умолчанию (default host group) в VMM.
• Последовательность задач базового образаLabManagement полезна для создания образов с целью тестирования вашего ПО с использованием Visual Studio Lab Management. Она определяет образ на основе Windows Server 2008 R2 и устанавливает Visual Studio Test Agent, Visual Studio Test Controller, Visual Studio Lab Management Agent и Visual Studio Team Foundation Build. Большинство тестовых конфигураций потребует комбинации этих агентов.

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

Автоматизация с помощью Windows PowerShell

VM Factory содержит скрипты Windows PowerShell, разработанные для автоматизации установки, конфигурирования и тонкой настройки базовых образов Visual Studio ALM Rangers. В дополнение к скриптам Windows PowerShell и CMD-файлам мы используем и другие сервисы или приложения Microsoft, такие как ntrights.exe, stsadm.exe, psconfig.exe и iisreset.exe.

Начальные планы фабрики вызываются только для скриптов Windows PowerShell. Однако мы используем MDT в качестве фабрики базовых образов Visual Studio ALM Rangers и вызываем скрипты Windows PowerShell для создания особых конфигураций, тонкой настройки и оптимизации установки на основе MDT.

Для успешного выполнения скриптов Windows PowerShell вам нужно сначала установить Windows PowerShell. Эти скрипты рассчитаны на выполнение в Windows Server 2008 или более поздних версиях. Поскольку они не подписаны, а для внесения системных изменений требуются повышенные привилегии, вы должны выполнить команду Windows PowerShell «Set-ExecutionPolicy Unrestricted».

Если вы используете утилиту PowerGUI от powergui.org, которая представляет собой редактор GUI и скриптов для Windows PowerShell, то скрипты не будут запускаться в отладочном режиме. Вы должны запускать их либо в Windows PowerShell, либо нажатием Alt+F5 в PowerGUI. И наконец, скрипт 1-pre.ps1 требует утилиты NTRights.exe, которая устанавливается из Windows Server 2003 Resource Kit. Без NTRights.exe вам придется отключить вызовы в последних нескольких строках скрипта в функции createTFSAccounts и вручную задать права Interactive Logon для учетных записей сервисов TFSSERVICE и TFSBUILD (рис. 3). Windows Server 2003 Resource Kit Tools можно скачать по ссылке bit.ly/fbafh.

Рис. 3. ИспользованиеNTRights.exe в скриптеWindows PowerShell

Скрипты Windows PowerShell, устанавливаемые до и после фабрики, содержат несколько функций, которые используют различные объекты и адаптеры типов, такие как адаптер типов Active Directory Services Interface (ADSI), показанный на рис. 4.

Рис. 4. Использование адаптера типов ADSI в Windows PowerShell

Адаптер типов ADSI в Windows PowerShell используется для создания учетных записей пользователей, задания паролей и установки пароля администратора, срок действия которого никогда не истекает. Для манипуляций с реестром при настройке VM Factory, например для включения Prefetch, указания приоритета программы и отключения некоторых функций отказоустойчивости Windows Server 2003, активно используются командлеты Windows PowerShell Set-ItemProperty и New-ItemProperty. Внесение этих изменений в реестр сводит к минимуму задачи конфигурирования вручную, что необходимо для достижения всех преимуществ автоматизации (рис. 5).

Рис. 5. Манипулирование механизмом отслеживания событий завершения

Мы рекомендуем изучить полный исходный код, чтобы вы понимали, как мы автоматизируем с помощью Windows PowerShell многие другие задачи, в том числе отключение экранной заставки, отключение входящих соединений через брандмауэр, включение удаленного рабочего стола, отключение IE Enhanced Security, изменение имени сервера и т. д.

Администрирование

Администрирование VM Factory осуществляется достаточно прямолинейно. Поскольку VM Factory, по сути, является предварительно заполненным общим ресурсом MDT-развертывания, в вашем распоряжении все возможности MDT для адаптации или расширения. Основной инструмент администрирования общих ресурсов MDT-развертывания — Deployment Workbench. Этот инструмент очень хорошо документирован в справочных разделах, но документацию, подготовленную к печати, можно скачать по ссылке go.microsoft.com/?linkid=9707467. Мы дадим лишь краткое описание, чтобы вы могли быстро приступить к работе.

После запуска Deployment Workbench выводится привычный Management Console UI, как показано на рис. 6. В левой секции раскройте узел Deployment Shares. Если вы правильно следовали инструкциям из руководства на CodePlex, то должен быть доступен VSTS Rangers Deployment Share. Если его нет, откройте его сейчас, используя подходящее действие в крайней справа секции.

Рис. 6. Административный интерфейс Deployment Workbench

Давайте посмотрим на рис. 6. Раскрыв VSTS Rangers Deployment Share, вы можете просмотреть содержимое этого ресурса развертывания. В подкаталоге Control каталога ресурса развертывания на диске есть дружественное к пользователю представление XML-файлов. Нас главным образом интересуют Applications, Operating Systems и Task Sequences. Всякий раз, когда вы вносите изменения в настройки Deployment Share, вы должны выбирать Update Deployment Share. Это приводит к повторной генерации загрузочных образов, которые используются вами для запуска любой последовательности задач.

Определения приложений описывают, где в Deployment Share находятся исходные файлы приложения и как установить приложение, используя команду установки Quiet (без вывода запросов) (рис. 7). Эта команда не требует никакого участия пользователя в процессе установки. Иногда для этого нужно выполнить подготовительную работу, создав скрипт необслуживаемой установки. Там, где это требуется, Rangers уже сделали это для приложений в VM Factory.

Рис. 7. Детали последовательности задач

В случае определений операционных систем MDT позволяет извлекать всю необходимую информацию из источника установки ОС. Обычно один набор исходных файлов будет содержать файлы для нескольких версий ОС. Все эти версии перечисляются под Operating Systems и могут быть выбраны для установки в Task Sequences.

Последовательности задач, включенные в VM Factory и описанные ранее, находятся в узле Task Sequences. Свойства последовательности задач позволяют модифицировать саму последовательность. На рис. 8 показано, что последовательности задач делятся на несколько фаз. Важный фазы — Install, на которой устанавливается ОС, и State Restore, на которой обрабатывается установка всех приложений после установки ОС. Панель инструментов дает возможность добавлять или удалять этапы из последовательности задач. MDT предоставляет несколько других этапов. На рис. 8 также показаны свойства задачи Install Applications.

Рис. 8. Свойства последовательности задач

Расширение VM Factory

Расширить VM Factory также несложно. Рассмотрим базовые этапы для добавления другой утилиты в образ. В качестве примера мы добавим к последовательности задач Code Metrics Power Tool (microsoft.com/download/en/details.aspx?id=9422). Эта утилита устанавливается исполняемым файлом MetricsSetup.exe. Процесс состоит из следующих этапов.

1. Определение командной строки необслуживаемой установки для приложения.
2. Копирование приложения в Deployment Share.
3. Запуск MDT Deployment Workbench.
4. Создание нового определения приложения (Application Definition).
5. Добавления приложения в Task Sequence.
6. Тестирование обновленной Task Sequence.

Этап 1 — выяснить, как установить эту утилиту без участия пользователя (подготовить необслуживаемую установку). Мы могли бы изучить документацию на продукт и найти там информацию о необслуживаемой установке. Другой способ, который обычно дает нам подсказку, — запуск файла с аргументом /? или –?. При запуске MetricsSetup.exe /? из командной строки появляется диалоговое окно Usage, показанное на рис. 9. Мы видим, что для необслуживаемой установки нужно ввести команду MetricsSetup.exe/q.

Рис. 9. Результат выполнения MetricsSetup.exe /?

Этап 2 — перемещение или копирование ПО в правильное место Deployment Share. Чтобы оно было согласовано с остальным ПО в Deployment Share, мы создаем каталог «C:\Deploymentshare\INSTALL – Code Metrics Power Tool\Source\» и копируем исполняемый файл в этот новый каталог.

Теперь, когда файлы находятся в нужном месте, мы запускаем MDT Deployment Workbench (этап 3), чтобы добавить определение приложения (этап 4). В начальном представлении MDT (см. рис. 6) мы находим и выбираем узел Applications в секции слева, а затем указываем New Application. Мастер помогает нам создать определение нового приложения. На первой странице мастера мы выбираем Application without source files or elsewhere on the network, так как мы уже переместили исполняемый файл в нужное место.

На следующей странице мастера нужно ввести Application Name, которое будет появляться во всех интерфейсах, и некоторую дополнительную (необязательную) информацию, которая не используется в этом процессе. Последняя страница мастера в процессе определения приложения предназначена для ввода команды необслуживаемой установки и указания каталога-источника (рис. 10). По завершении работы мастера вы обнаружите в списке новое приложение.

Рис. 10. New Application Wizard: определение деталей команды

Чтобы реально установить приложение, мы должны добавить задачу в последовательность (этап 5). В редакторе последовательности задач найдите место, в которое вы хотите добавить действие установки. В меню Add на панели инструментов выберите General | Install Application, чтобы добавить новое действие в последовательность задач. В секции свойств справа выберите Install a single application и щелкните Browse для выбора приложения Code Metrics Power Tool. Щелкните OK для сохранения последовательности задач. Теперь мы готовы к тестированию (этап 6).

Заключение

Теперь вы знаете все, что нужно для того, чтобы приступить к настройке ресурса развертывания под ваши конкретные требования.

Самую новую версию руководства и шаблоны ресурса развертывания можно найти на CodePlex (bit.ly/aL0mxZ), а список блогов по данной тематике, видеоролики и другую информацию — в блоге Rangers (bit.ly/qEIRPl).

Теперь вы знаете все, что нужно для того, чтобы приступить к настройке ресурса развертывания под ваши конкретные требования.

Доказав правильность концепций и техническую осуществимость автоматизации и единообразия, предлагаемые VM Factory, мы планируем следующие усовершенствования:

• более простую реализацию и администрирование новых фабрик;
• более удобные интерфейсы и расширенное управление сопровождением существующих фабрик, следуя великим принципам инициативы Deployment Hydration;
• возможность планирования автоматизации фабрик:
• возможность использования существующих библиотек носителей (media libraries), таких как MSDN-загрузки, вместо дублирования носителя в каждой фабрике.

Оставайтесь с нами, потому что мы продолжаем совершенствовать этот жизненно важный инструмент.

---

БрайенБлэкмен (Brian Blackman) — ведущий консультант в группе Microsoft Services Partner ISV. Способствует тому, чтобы ISV-партнеры добивались успеха в проектировании и на рынке. Является обладателем сертификатов CSM, MCSD (C++), MCTS и Visual Studio ALM Core Ranger. Пишет код, создает инструментальные наборы и консультирует по различным вопросам, связанным с ALM (управлением жизненным циклом приложений).

Пол Мейер (Paul Meyer) — старший консультант по прикладным платформам в Microsoft Services в Голландии. Основное внимание уделяет процессам разработки и инструментарию. Участвует в проектах Visual Studio ALM Rangers уже несколько лет.

Уилли-Питер Шауб (Willy-Peter Schaub) — старший менеджер программ сообщества Visual Studio ALM Rangers в Microsoft Canada Development Center. Еще с середины 80-х стремился к упрощению проектирования ПО и расширению возможностей в его сопровождении. Читайте его блог blogs.msdn.com/b/willy-peter_schaub и заметки в twitter.com\wpschaub.

Выражаем благодарность за рецензирование этой статьи экспертам Владимиру Гусарову (Vladimir Gusarov), Биллу Хейзу(Bill Heys), Биджану Джавиди (Bijan Javidi), Зейду Каре (Zayd Kara), Виджею Махираджу (Vijay Machiraju), Роберту Маклину (Robert MacLean), Руи Мело (Rui Melo) и Патриции Вагнер (Patricia Wagner).