Использование Packer

С началом активного развития Web’а появилась проблема синхронизации набора ПО, его версий и настроек для production- и development-окружений. Создатель Vagrant придумал новый инструмент, который должен помочь решить эту проблему, — Packer.

Боль системных администраторов

Наверное, все знают про набор LAMP для Windows, который распространяется под названием Denwer. Когда-то основная масса девелоперов пользовалась именно им, чтобы эмулировать тестовую среду для своего проекта. Когда проект был готов и тщательно оттестирован на локальном компьютере, наступала пора переместить созданный сайт на хостинг. Но настройки ПО на локалхосте и настройки ПО на хостинге, как правило, разнились. И вот тут-то звучала коронная фраза: «А на Денвере все работало!» Был и ее аналог — когда после переноса с одного хостинга на другой какие-то части проекта переставали работать, клиент/программист восклицал: «А на старом хостинге все работало!» Обе фразы давно стали притчей во языцех. С тех пор как Денвер активно использовался девелоперами, прошло уже много лет, и сейчас у разработчиков в ходу уже совершенно другие инструменты для эмуляции окружения на локальной машине, но проблема различных настроек для development- и production-окружений до сих пор имеет место быть. В этой статье мы рассмотрим одну из новых технологий, которая помогает убрать эту проблему раз и навсегда.

Зачем осваивать работу с Packer?

Митчелл Хашимото, создатель Vagrant, придумал и реализовал проект под названием Packer. Основное назначение данного проекта — автоматизация сборки образов для таких систем, как Amazon EC2, DigitalOcean, Docker, Google Compute Engine, OpenStack, Parallels, QEMU, VirtualBox, VMware. Также возможно расширение списка поддерживаемых провайдеров за счет плагинов.

Одна из ключевых особенностей этой технологии — образы, созданные с помощью одного и того же шаблона Packer для разных провайдеров, будут идентичными. То есть мы можем описать настройки, на базе которых будут созданы идентичные образы, к примеру, для Amazon EC2 и VirtualBox. Что это нам дает?

1. Время создания инстанса в амазоне или виртуалки для разработчика из готового образа значительно меньше, чем время, которое нужно затратить с нуля на подготовку виртуальной машины к работе. Это достаточно критичный момент, так как порой очень важно ввести в работу новый инстанс нужного типа за кратчайшее время для того, чтобы начать пускать на него трафик.
2. Помимо того что образ виртуальной машины для разработчика будет готов заранее, он всегда будет соответствовать по набору ПО и его настройкам тому серверу, который используется в production. Важность этого момента трудно недооценить — крайне желательно, чтобы деплой нового кода на продакшн привел к тому, чтобы сайт продолжал корректную работу с новой функциональностью, а не упал из-за какой-то ошибки, связанной с недостающим модулем PHP или отсутствующим ПО.
3. Автоматизация сборки production- и development-окружений экономит время системного администратора. В глазах работодателя это также должно быть несомненным плюсом, так как это означает, что за то же время администратор сможет выполнить больший объем работы.
4. Время для тестирования набора ПО, его версий, его настроек. Когда мы подготавливаем новый образ заранее, у нас есть возможность (и, что самое главное, время!) для того, чтобы спокойно и вдумчиво проанализировать различные ошибки, которые возникли при сборке образа, и исправить их. Также есть время для тестирования работы приложения на собранном образе и внесения каких-то настроек для оптимизации приложений. В случае же, если мы настраиваем инстанс, который нужно было ввести в работу еще вчера, все возникающие ошибки, как правило, исправляются по факту их возникновения уже на работающей системе — конечно же, это не совсем правильный подход.

Таким образом, мы имеем как минимум четыре причины для того, чтобы начать изучение Packer.

Vagrant

Если кто-то вдруг еще незнаком с таким замечательным инструментом, как Vagrant, советую это поскорее исправить. Vagrant необходим для того, чтобы с легкостью создавать девелоперские виртуальные машины с нужными настройками и с такой же легкостью уничтожать их после того, как они перестают быть нужны. Очень удобное решение, например, когда ты пишешь набор Chef-рецептов или Puppet-манифестов и тебе надо все время их тестировать. Официальный сайт проекта.

Начало работы

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

Итак, сейчас мы разберем, как с помощью Packer подготовить образ для Amazon EC2 — AMI.

Packer предоставляет возможность собирать AMI для амазона тремя способами:

• amazon-ebs — создает EBS-backed AMI путем создания исходного инстанса, применения к нему всех нужных настроек (provisioning) и последующего создания AMI из этого инстанса;

• amazon-instance — создает intance-store AMI путем создания исходного инстанса, настройки его и последующей перепаковки его и заливки в S3;

• amazon-chroot — создает EBS-backed AMI из существующего инстанса путем монтирования корневого раздела этого инстанса и последующего chroot’а в точку монтирования для выполнения всех необходимых настроек. Метод не рекомендуется использовать новичкам и хорош тем, что не требует запуска дополнительных инстансов для создания AMI.

Для нашего примера мы выбираем способ создания amazon-ebs.

Создание AMI

Итак, приступим. Если у тебя еще нет аккаунта на aws.amazon.com, то необходимо его создать. Эта процедура проста и не должна вызвать затруднений. После того как аккаунт создан и мы залогинились в панель управления AWS, нужно перейти в раздел IAM. AWS Identity and Access Management (IAM) позволяет нам гибко управлять пользователями и их привилегиями в рамках всего AWS. Для начала создадим себе пользователя, от имени которого Packer будет выполнять все необходимые действия с инстансами/снапшотами/AMI. При создании пользователя обязательно нужно сгенерировать для него Access Key. На рис. 1 можно увидеть пример, как это сделать. На следующей после создания пользователя странице будут указаны очень важные данные: Access Key ID и Secret Access Key. Эти данные необходимо сразу же сохранить — потом подсмотреть их будет негде, только перегенерировать. Теперь нужно выставить необходимые политики для нашего пользователя. Это можно сделать в разделе User Policies в свойствах пользователя. Заходим в свойства созданного нами пользователя, выбираем Attach Policy -> Custom Policy, а далее вводим имя пользователя и набор необходимых разрешений. Список разрешений можно увидеть на рис. 2. В текстовом виде его можно взять из официальной документации Packer. После нажатия на Apply Policy изменения будут применены. Чтобы убедиться, что нам будет доступно создание образов с этим списком разрешений, мы можем открыть IAM Policy Simulator, выбрать нужного пользователя, политику, метод, и после нажатия Run Simulation веб-интерфейс амазона выдаст нам вердикт — позволяют ли привилегии нашего пользователя выполнять нужные нам функции. Следующим этапом нужно написать JSON-шаблон, согласно которому Packer будет выполнять различные действия по созданию AMI. Образец конфига, по которому я создавал AMI в качестве примера для этой статьи, можно увидеть на рис. 3. Стоит отдельно отметить, что многие параметры впоследствии можно переопределять из консоли, передавая необходимые параметры при вызове Packer, например:

$ packer build -var 'aws_access_key=some_key' -var 'aws_secret_key=some_key_2' template.json

В нашем образце мы устанавливаем некоторый набор ПО, делаем это с помощью bash. В серьезных окружениях provisioning выполняется, как правило, с помощью Chef или Puppet. На сайте Packer есть соответствующие инструкции для подключения других систем развертывания. Тип инстанса выбран t1.micro — для тестов можно воспользоваться и им, особенно если учесть, что на него распространяется годовой период бесплатного использования от амазона.

Далее происходит валидация созданного нами шаблона Packer. В примере показано, что с шаблоном все в порядке:
$ packer validate template.json
Template validated successfully.
Процесс сборки образа запускается командой
$ packer build template.json
и выглядит так, как изображено на рис. 4.

В самой последней строке мы увидим результирующую информацию: о том, что собранный AMI имеет ID ami-8cd8fdde и доступен в регионе ap-southeast-1. После этого в панели управления EC2 в разделе AMI появится собранный нами образ, а в разделе Snapshots — снапшот для root-EBS инстансов, которые будут создаваться из этого образа.

В общем-то, на этом все — теперь мы можем создавать инстансы из этого AMI, и они будут содержать все необходимое нам ПО.

Выводы

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

Также хотелось бы отметить, что Packer не может служить полной заменой для того же Vagrant. У них разное назначение. Vagrant незаменим для того, чтобы быстро создавать тестовые окружения с максимально актуальной конфигурацией — например, когда манифесты Puppet были дополнены вчера и сегодня, а образы с помощью Packer собирались вчера, так как в production эти изменения в конфигурации пока что не планировалось выкладывать.

И еще — если вдруг кто-то подумал, что использование Packer отменяет необходимость в Puppet/Chef для автоматизации управления инфраструктурой, то это тоже будет неверным выводом. Packer лишь гармоничное дополнение к этим мощным системам, именно в сочетании с ними он позволит добиться максимально эффективной работы команды разработки и администрирования.

Если возникли какие-либо вопросы или же тебе хочется поделиться своими способами решения подобных задач — пиши на email abaranov@itsumma.ru