Рано или поздно перед любой растущей ИТ-компанией встаёт задача оптимизации ресурсов, которая с точки зрения системного администрирования обязательно предполагает максимальную автоматизацию всех процессов. Нужно это по многим причинам: сокращение затрат времени, минимизация влияния человеческого фактора, повышение за счёт этого масштабируемости и надёжности систем в целом.
Наша компания занимается разработкой ПО (SaaS), которое работает на ASP и .NET, а в качестве базы данных использует MS SQL Server. Поэтому львиная доля инфраструктуры у нас работает под управлением Windows, преимущественно Server 2012 R2. Соответственно, отделу сисопов периодически приходится поднимать новые машины с ней, а иногда и разворачивать целые фермы, как на живом окружении, так и на тестовом. В настоящее время у нас порядка 20 гипервизоров и, соответственно, более сотни разнообразных машин, из которых абсолютное большинство — это ВМ с Windows. Сейчас планируется установка ещё полудюжины девелоперских окружений, каждое из которых состоит из десятка компонент, которые желательно изолировать друг от друга. Для решения подобных задач мы и задумали автоматизацию всего процесса. Описание всего пути я сделал довольно детальным, так что статья разрослась и поэтому я решил разделить её на три части. В этой части я постараюсь затронуть общие общие вопросы, объяснить выбор инструментов и рассказать, как подготовить окружение для дальнейшей работы.
Почему Windows, почему Hyper-V?
Исторически сложилось, что все новые ВМ у нас находятся под управлением гипервизора Microsoft Hyper-V.
- За последние годы он достаточно сильно развился и в целом обладает достаточным функционалом для наших задач. Самое главное — его начал по человечески поддерживать Vagrant, о чём я подробнее расскажу чуть попозже. Также появилась поддержка множества Linux дистрибутивов, что позволяет с некоторыми оговорками хостить на Hyper-V зоопарк разных машин, в случае, если используется несколько операционок (а у кого-то не так?);
- Им удобно управлять при помощи нативных инструментов (MMC остнастки и Powershell), встроенных как в серверные, так и клиентские операционки от Microsoft;
- Роль Hyper-V очень легко добавляется серверу, и в целом установка доступна более широкому кругу администраторов (нежели, скажем, в случае с KVM или ESXi), имеется множество документации, гидов, виртуальных лабораторий и так далее, многое из этого доступно и на русском языке. Это позволяет легко установить его не только администраторам, но и разработчикам или тестировщикам (которым также часто нужно быстро поднять среду для своих целей), что расширяет спектр возможных применений;
Миграция физических машин в виртуальные происходит очень легко и быстро при помощи простенькой утилиты Disk2VHD — она использует механизм снапшотов и за счёт этого позволяет сделать VHD образ даже рабочей системы, запущенной в живом окружении. Это сильно помогло, когда мы виртуализовывали нашу инфраструктуру. Этим же способом мы мигрировали хосты VMWare. - Microsoft Hyper-V Server не нужно покупать, он бесплатен. Для нас это было не очень актуально, однако это прекрасная возможность “поиграться” с ней без каких-либо дополнительных затрат.
- Из Hyper-V позже при желании можно будет легко мигрировать на облачную платформу Azure, продолжая управлять ей при помощи тех же инструментов.
Цели
Передо мной стояла задача автоматизации создания новых виртуальных машин. Необходимо в короткий срок поднять на гипервизоре операционную систему со всем необходимым софтом и настройками. Всё это есть по сути первый шаг к полноценной системе непрерывного развёртывания с системой управления конфигурациями, которую мы и планируем внедрить. Это сильно выходит за рамки этой статьи, но материалов по этой теме достаточно, а я собираюсь продолжить рассказ обо всех нюансах работы в мире продуктов Microsoft в следующей статье, если этот материал окажется интересным и полезным. В итоге поставленную задачу удалось успешно решить при помощи довольно традиционного набора инструментов, многие из которых уже давно известны в мире открытого ПО, однако применить их полноценно в мире Windows получилось не так просто из-за обилия разного рода подводных камней. В результате мы остановились на следующем “тулките”:
- Chocolatey;
- Vagrant;
- Boxstarter;
- Chef.
В этой статье речь зайдёт про первые три пункта списка.
Почему Vagrant и Chef, Chocolatey и Boxstarter?
Итак, что же они делают и почему были выбраны именно они?
- Chocolatey — это менеджер пакетов для Windows. Конечно, Microsoft анонсировал, что в Windows Server 10 будет свой, интегрированный менеджер пакетов, однако до её внедрения в наш продакшн ещё далеко и пока вполне успешно можно использовать и шоколатье. Он позволяет автоматизировать установку нужного ПО вместе со всеми зависимостями. Для этого используются NuGet пакеты, которые можно вполне успешно создавать самому, что очень удобно, когда нужно установить собственный серверный софт.
- Vagrant позволяет создать и использовать бокс — образец виртуальной машины, чтобы впоследствии из него автоматически разворачивать одну (или несколько, или несколько десятков) виртуалок, настраивать необходимые параметры, а также осуществлять так называемый провижионинг — процесс установки и настройки необходимого ПО. Например, там могут ставиться IIS и Chef-client, устанавливаться последние обновления Windows, настраиваться внешний вид папок (чтобы были видны расширения файлов и скрытые файлы), открываться порты на файерволе, настраиваться учётные записи пользователей и так далее — и всё это без непосредственного участия администратора, с автоматическими перезагрузками при необходимости, согласно заранее описанному сценарию.
Из аналогов сразу приходит на ум System Center, который также позволяет создавать шаблон и выкатывать из него несколько виртуальных машин. Однако, я по многим причинам предпочёл Vagrant — он легче, не требует тяжёлого центрального сервера, а диск новой виртуалки не становится зависимым от диска оригинального шаблона. К тому же Vagrant работает из обычной командной строки, что позволяет легко его использовать на гипервизорах без GUI.
В статье будет довольно много отсылок на различные подводные камни — хочу сразу сказать, что рассматривается последняя на данный момент версия — 1.7.2, соответственно в последующих версиях (я надеюсь) многие проблемы будут исправлены и ненужные костыли отвалятся. Зато наверняка добавят новых багов, что позволит мне сделать целый цикл статей. - Boxstarter — набор полезных скриптов, позволяющих сильно упростить настройку как готовых машин, так и только что поднятых. Он достаточно тесно работает с Chocolatey и позволяет настроить конечную систему одной командой, загружая сценарий с веб-узла или сетевой папки. К тому же под него есть уже готовые рецепты для Chef от автора.
- Chef используется для централизованного управления конфигурациями в самом широком смысле, включая как первоначальную инициализацию, так и поддержанием их в актуальном состоянии. Вместо него можно использовать и другие системы, однако я остановился на нём из-за его распространённости, мощному сообществу и активному развитию: например, совсем недавно появилась новая, значительно улучшенная версия комьюнити кукбуков для IIS. Ну и, конечно, повлияло то, что с ним уже был небольшой опыт работы до этого.
Использование этого инструментария позволяет в результате получить всё волшебство Continuous Delivery в одном флаконе под привычную систему.
Основные этапы развёртывания
Что ж, давайте приступим к самому интересному, к прикладной технической части развёртывания.
Установка Hyper-V и ПО для управления
Для начала необходимо подготовить хост — ту систему, на которой будут разворачиваться виртуальные машины. В случае если они нужны для локальных тестов и всё будет крутиться на том же компьютере, где вы сидите — всё просто и прозрачно. Однако, зачастую получается ситуация, когда виртуалки нужны в итоге в совершенно другом месте — в датацентре на живом окружении, на соседнем сервере или на бабушкином нетбуке. Дело в том, что из коробки скрипты Vagrant делают все операции на локалхосте. В принципе, никто не мешает сначала развернуть это у себя, настроить-поиграться, а потом смигрировать на далёкий гипервизор, но тут оказывается, что это занимает прилично времени даже когда сервер находится в одном сегменте сети с вами. В случае же, когда надо разворачиваться через VPN в датацентре на другом краю земли — это может занимать больше часа на каждый инстанс, и при этом может понадобиться совершать лишние действия: экспорт-импорт в моём случае, плюс перенастройка сети, если виртуальные коммутаторы называются по разному.
Поэтому оптимальным решением я для себя выбрал поднятие Vagrant на всех гипервизорах, где планируется его частое использование. Это ускоряет процесс (даже для одной машины — ведь бокс весит значительно меньше VHD файла развёрнутого образа), однако добавляет лишнего софта на сервера. К счастью, Chocolatey и Vagrant не требуют GUI, так что их легко можно установить даже на бесплатном Hyper-V Server.
Задача эта в целом довольно тривиальная:
- Установка роли Hyper-V в Windows 8 или Server 2012 требует перезагрузки и делается через Server Manager для любителей GUI (ссылка есть в материалах в конце статьи) или при помощи PowerShell c административными привилегиями:
Install-WindowsFeature –Name Hyper-V -IncludeManagementTools
- Шоколатье ставится из Powershell одной командой:
iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))
- Ну, а Vagrant поднимается уже из Chocolatey:
choco install vagrant
Вообще, если вы не любите засорять сервера лишними программами или предпочитает всегда использовать наисвежайшие версии (следует понимать, что, несмотря на то, что в репозитарии обычно лежит самая последняя версия — появляется она там не мгновенно) — можно вполне обойтись без Шоколатье, установив Vagrant вручную из дистрибутива. Он поставляется в виде msi-пакета, так что проблем с установкой из консоли быть не должно. Но лично я предпочитаю первый вариант не только потому, что люблю шоколад — просто я привык так ставить вообще весь софт, даже на домашнем ноутбуке.
В этот момент мы сталкиваемся с первым подводным камнем (я уже предупреждал, что путь будет тернист?). Дело в том, что наш бродяга (а именно так переводится “vagrant”) от версии к версии ставит себя в разные каталоги, и в последнем на данный момент релизе он снова начал устанавливаться прямо в корень системного диска в папку C:HashiCorpVagrant. Всё бы ничего, но он периодически забывает прописывать путь к своей папке в переменную окружения, поэтому система может не находить его, если не вводить полный путь к бинарнику. Лечится это простой командой в Powershell:
$env:Path+=”;C:HashiCorpVagrantbin”
Для командной строки нужно использовать команду setx c ключом /M. Например, если нужно поменять расположение папки, где он будет хранить боксы (по умолчанию он хранит их на своей папке на диске C, что может не очень понравится, когда на системном диске немного места):
setx VAGRANT_HOME «X:/your/path» /M
На этом подготовка хоста закончена. О том, как сделать базовый бокс для развёртывания и как с ним работать дальше — я расскажу в следующих частях. Там же там будет отдельная глава со списком полезных материалов и ссылок.
Автор: Uburwator
