Когда говорят про DevOps обычно всегда подразумевают работу с Linux. Но есть большое количество решений под Windows. Как осуществлять сборку Windows c помощью Packer в своем блоге поделился Netflix (Джастин Фелпс и Мануэль Корреа - Applying Netflix DevOps Patterns to Windows). Предлагаю перевод статьи.

В Netflix настройка образов Windows происходила вручную, были ошибки и это был трудоемкий процесс. В этой статье мы описываем, как мы улучшили методологию, какие технологии мы использовали, и как это улучшило развертывание и согласованность сервисов.

Artisan Crafted Images

В культуре DevOps в Netflix группа, ответственная за создание сервиса, также отвечает за развертывание, тестирование, инфраструктуру и работу этой службы. Основная обязанность инженеров Netflix - выявление пробелов и болевых точек при разработке и эксплуатации сервисов. Хотя большинство наших сервисов работают на Linux Amazon Machine Images (AMI), все еще существует множество сервисов, критически важных для Netflix Playback Experience, работающих на инстансах Windows Elastic Compute Cloud (EC2).

Мы изучили наш процесс создания образов Windows AMI и обнаружили, что он подвержен ошибкам и полон утомительных усилий. Сначала инженер запускал инстанс EC2 и ждал, пока он перейдет в режим онлайн. Как только экземпляр оказывался доступен, инженер использовал инструмент удаленного администрирования, такой как RDP, для входа в экземпляр для установки программного обеспечения и настройки параметров. Затем этот образ сохранялся как AMI и использовался в Auto Scale Group для развертывания кластера инстансов. Поскольку этот процесс занимал много времени и был долгим, в наших экземплярах Windows обычно отсутствовали последние обновления безопасности от Microsoft.

В прошлом году мы решили улучшить этот процесс.

Были следующие проблемы:

устаревшая документация.
обновления ОС.
высокие когнитивные издержки.
отсутствие непрерывного тестирования.

Масштабирование создания образов.

Наш существующий инструмент создания AMI - Aminator - не поддерживает Windows, поэтому нам пришлось использовать другие инструменты.

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

Конфигурация как код
Использование Spinnaker для непрерывной доставки
Исключение трудоемкости операций - Eliminate Toil

Конфигурация как код

Первая часть нашего нового решения для создания образов Windows - Packer. Packer позволяет описать процесс настройки образов в виде файла JSON. Мы используем конструктор amazon-ebs Packer для запуска инстанса EC2. После подключения Packer использует WinRM для копирования файлов и выполнения сценариев PowerShell для экземпляра. Если все шаги настройки выполнены успешно, Packer сохраняет новый AMI. Файл конфигурации, сценарии, на которые имеются ссылки, и описание зависимостей артефактов находятся во внутреннем репозитории git. Теперь у нас есть конфигурация инстанса и программного обеспечения в виде кода. Это означает, что эти изменения можно отслеживать и просматривать, как и любые другие изменения кода.

Packer требуется специфическая информация для вашей среды создания образов и расширенные разрешения AWS IAM. Чтобы упростить использование Packer для наших разработчиков программного обеспечения, мы объединили специфичную для Netflix информацию о среде AWS и вспомогательные сценарии. Изначально мы сделали это с репозиторием git и файлами переменных Packer. Также был специальный экземпляр EC2, где Packer выполнялся как задания Jenkins. Эта установка была лучше, чем создание образов вручную, но у нас все же были некоторые проблемы с эргономикой. Например, стало сложно гарантировать, что пользователи Packer получают обновления.

Последняя часть нашего решения - найти способ упаковать наше программное обеспечение для установки в Windows. Это позволит повторно использовать вспомогательные сценарии и инструменты инфраструктуры, не требуя от каждого пользователя копировать это решение в свои сценарии Packer. В идеале это должно работать аналогично тому, как приложения упаковываются в процессах Animator. Мы решили эту проблему, используя Chocolatey, менеджер пакетов для Windows. Пакеты Chocolatey создаются и затем сохраняются во внутреннем репозитории артефактов. Этот репозиторий добавлен в качестве источника для команды choco install. Это означает, что мы можем создавать и повторно использовать пакеты, которые помогают интегрировать Windows в экосистему Netflix.

Использование Spinnaker для непрерывной доставки

Базовый Dockerfile позволяет обновлениям Packer, вспомогательным скриптам и конфигурациям среды распространяться через весь процесс создания образов Windows. — Базовый Dockerfile позволяет ��бновлениям Packer, вспомогательным скриптам и конфигурациям среды распространяться через весь процесс создания образов Windows.

Чтобы сделать процесс создания образов более надежным, мы решили использовать образ Docker, содержащий Packer, конфигурацию нашей среды и вспомогательные скрипты. В дальнейшем пользователи создают свои собственные образы Docker на основе этого базового образа. Это означает, что мы можем обновить базовый образ, добавив в него новую информацию о среде и вспомогательные сценарии, и пользователи будут получать эти обновления автоматически. Со своим новым образом Docker пользователи запускают свои задания по созданию образов Packer с помощью Titus, нашей системы управления контейнерами. Задание Titus создает файл свойств как часть пайплайна Spinnaker. Полученный файл содержит AMI ID и используется на более поздних этапах пайплайна для деплоя. Создание образа в Titus сняло ограничение на использование одного экземпляра EC2, что позволило выполнять задания. Теперь каждое изменение в инфраструктуре тестируется, обрабатывается и развертывается, как и любое другое изменение кода. Этот процесс автоматизирован с помощью пайплайна Spinaker:

пример пайплайна Spinaker, показывающий этапы создания, сборки и развертывания образов. — пример пайплайна Spinaker, показывающий этапы со��дания, сборки и развертывания образов.

На этапе сборки Kayenta используется для сравнения показателей между базовым образом (текущий AMI) и тем что собирается (новый AMI). На сборочном этапе оценка будет определяться на основе таких показателей, как CPU, threads, latency и GC pause. Если эта оценка находится в пределах допустимого порога, AMI развертывается в каждой среде. Запуск сборки для каждого изменения и тестирование AMI в производственной среде позволяет нам получить представление о влиянии обновлений Windows, изменений скриптов, настройки конфигурации веб-сервера и т. д.

Избавление от тяжелого труда (Eliminate Toil)

Автоматизация этих утомительных рабочих задач позволяет командам работать быстрее. Нашим инженерам больше не нужно вручную обновлять Windows, Java, Tomcat, IIS и другие службы. Мы можем легко протестировать изменения настройки сервера, обновления программного обеспечения и другие модификации среды выполнения. Каждое изменение кода и инфраструктуры проходит через один и тот же конвейер тестирования и развертывания.

Получение преимуществ

Изменения, которые раньше требовали нескольких часов ручной работы, теперь легко модифицировать, тестировать и развертывать. Другие группы могут быстро развернуть безопасные и воспроизводимые инстансы в автоматическом режиме. Услуги более надежны, тестируемы и документированы. Изменения в инфраструктуре теперь рассматриваются, как и любые другие изменения кода. Это снимает ненужную когнитивную нагрузку и документирует наши знания. Исключение тяжелого труда позволило команде сосредоточиться на других функциях и исправлениях ошибок. Все эти преимущества снижают риск сбоя, который может повлиять на клиента. Принятие шаблона Immutable Server для Windows с использованием Packer и Chocolatey принесло большие преимущества.

Применение паттернов Netflix DevOps к Windows