IaC Packer Ansible Teraform
https://habr.com/ru/companies/vk/articles/674842/
Привет, Хабр! Я Алексей Волков, менеджер продукта компании VK Cloud Solutions. Хочу рассказать о подходе IaC (Infrastructure as Code, инфраструктура как код), который позволяет управлять сетями, виртуальными машинами, подсистемами балансировки нагрузки и другими элементами инфраструктуры как кодом с помощью описательной модели. Поговорим о современных принципах управления инфраструктурой, инструментах IaC в облаке и вариантах построения CI/CD-пайплайна.
Традиционный процесс администрирования vs IaC
Чтобы лучше понять суть IaC, удобнее всего сравнить его с традиционным подходом к администрированию инфраструктуры.
При традиционном подходе:
Устанавливают операционную систему (ОС).
Добавляют пользователей.
Ставят нужные пакеты.
Вписывают конфигурации.
Запускают приложение.
Если нужно расширить функциональность образа или перенастроить его, повторяют пункты 3–5. Такой подход еще называют Configuration Drain. Недостаток в том, что при неоднократном обновлении инстанса практически невозможно понять, какая версия пакетов установлена и какие настройки активны. Это нередко приводит к тому, что последующее обновление может не запуститься или сломать всю инфраструктуру.
При IaC-подходе алгоритм отличается:
Готовят шаблон сервера со всеми настройками и пакетами.
Описывают в тексте инфраструктуру с указанием сетей, серверов, прав доступа и других параметров.
Применяют изменения.
В итоге получается «золотой образ», готовый к использованию. Как правило, перед запуском в продакшене его проверяют на стейдже — если он корректно работает во время теста, то и в реальных условиях проблем не будет.
«Золотой образ» можно использовать и в качестве шаблона — например, если нужно внести дополнительные изменения поверх уже активных настроек.
IaC-подход к администрированию повышает предсказуемость системы, ее воспроизводимость и контролируемость. Кроме того, он позволяет быстро исправлять возникающие ошибки: в любой момент можно перезапустить инстанс с корректными настройками из чистого образа. Одновременно с этим можно управлять инфраструктурой как кодом: версионировать, использовать возможности Git для контроля изменений, указывать этапы выкатки и другие нюансы.
На практике для реализации IaC-подхода к администрированию используют разные инструменты. Рассмотрим Packer и Terraform от компании HashiCorp.
Packer
Packer — инструмент для создания одинаковых образов ОС для различных платформ из одного описания. Образ, создаваемый Packer, включает в себя настроенную операционную систему (ОС) и набор программного обеспечения (ПО). Packer умеет создавать образы AMI для EC2, VMDK/VMX-файлы для VMware, OVF для VirtualBox и другие.
Packer не зависит от облачной инфраструктуры — он поддерживает несколько бэкендов и может работать с разными провайдерами «из коробки».
Алгоритм работы с Packer следующий:
Создаем и описываем файл конфигурации базовой виртуальной машины.
Запускаем Packer, который создает виртуальную машину.
Обращаемся в провижинер, например Ansible, для провижинга виртуальной машины.
После провижинга приводим виртуальную машину к нужному состоянию, со всеми настройками и наборами ролей.
Packer идет в облачное хранилище в бэкенде и делает снапшот виртуальной машины, который потом загружает в облако в виде образа.
Схема работы Packer
В результате получается базовый образ, из которого можно развернуть любое количество виртуальных машин. Логика работы Packer похожа на логику Docker, когда из Docker-файла с описанием создают образ виртуальной машины.
Пример использования Packer
Покажу на примере. Возьмем директорию Nginx, она вложена в директорию Packer на GitHub:
Далее соберем базовый образ с Nginx. Для этого:
Берем стандартный образ из облака.
С помощью Ansible ставим в образ Nginx.
Изменяем конфигурацию заменой конфигурационного файла.
Запускаем и включаем Nginx.
Nginx взят исключительно для примера, по аналогии можно сконфигурировать любое приложение, которое запускается на виртуальных машинах.
Приступаем к сборке образа:
Для примера я создал на GitHub директорию Packer. В ней лежит директория Nginx и файл nginx.pkr.hcl.
Файл nginx.pkr.hcl содержит конфигурацию для Packer, эта информация нужна, чтобы Packer понимал, в каком бэкенде и как нужно запустить виртуальную машину.
В конфиге через
source "openstack" и source_image_filter
указываем, какой базовый образ использовать для создания нового. В данном случае — Centos-7.9-202107, который находится в публичном доступе в облаке VK Cloud Solutions.Через
flavor
указываем размер виртуальной машины, например: 1 ядро, 1 ГБ оперативной памяти, 10 ГБ диска. Эти параметры касаются только базовой виртуальной машины, с которой снимается образ. Из нового образа можно будет запускать ВМ любого размера.Здесь же указываем параметры подключения к ВМ по SSH и другие настройки. Доступ по SSH нужен, чтобы Packer мог запустить в облаке ВМ и получить доступ к Ansible, который подключается к ВМ и выполняет нужные действия. Только после этого создается снапшот виртуальной машины.
В переменных указываем название создаваемых образов. Здесь
nginx
— постоянный префикс, $
— переменная версии. Например, nginx 0.0.1
. Для этого в начале описываем, что есть переменная image_tag
типа string
. При старте сборки образа мы запускаем Packer и указываем image_tag
. Алгоритм такой же, как при сборке Docker-образов, то есть у нас будет образ nginx 0.0.1, 0.0.2, 0.0.3, 1.0.0 и так далее — сразу версионируем образы.
В блоке
build
описываем, как запускать провижинер и какой. В данном случаеAnsible
. Тут же указываем файл, который нужен для запуска, —playbook.yml
.В файле playbook.yml указываем, что на всех хостах нужно запустить роль
Nginx
.
В файле роли
Nginx
все довольно просто: указываем минимальную установку Nginx, прикрепляем набор конфигураций, добавляем репозиторий с исходным Nginx и устанавливаем его. После этого копируем конфигурацию в виртуальную машину, стартуем и энейблим сервис с Nginx.
То есть после того, как из этого образа ВМ мы создадим всю инфраструктуру нескольких виртуальных машин, там изначально будет стоять Nginx, сконфигурированный, запущенный и заэнейбленый. После запуска этой виртуальной машины включится Nginx и будет готов обслуживать пользователей.
В файле конфига default.conf просим Nginx при обращении к корню возвращать «200» и свой hostname. Это поможет понять, как работают инстансы и выполняется балансировка.
Это вся конфигурация, которая нужна для запуска Packer. Перед этим важно соблюсти два условия:
Передать в Packer ключи для взаимодействия с API облака, то есть логин и пароль учетной записи.
Локально установить и настроить Ansible.
Запустим Packer.
Выполняем команду
packer build - var
, указываем переменнуюimage_tag
с индексом 1.0.1 и передаем конфигурационный файл nginx.pkr.hcl, который мы использовали раньше.После выполнения команды Packer идет в интерфейс облака и запускает виртуальную машину.
При этом в личном кабинете облака начинает создаваться виртуальная машина с указанным типом. На этом этапе Packer ждет запуск ВМ и последующий запуск SSH. После этого на ВМ запускается Ansible, который снимает с ВМ образ.
После завершения обработки в интерфейсе облака будет создан образ, из которого можно запустить любое количество виртуальных машин.
Вручную добавлять инстансы, конфигурировать и настраивать каждую ВМ в облаке опасно: даже из-за незначительной ошибки могут возникать глобальные сбои в инфраструктуре. Автоматизировать эти процессы и исключить ошибки позволяет Terraform.
Terraform
Terraform — инструмент от компании Hashicorp, который позволяет декларативно управлять инстансами, сетями, группами безопасности и другими компонентами инфраструктуры с помощью файлов конфигураций. Благодаря Terraform можно привести инфраструктуру к нужному состоянию декларативно, сразу указав нужные параметры системы.
Еще в Terraform предусмотрена функция «План». Благодаря ей инструмент сравнивает текущее состояние системы с будущим и отображает пользователю, что именно будет удалено, запущено или изменено в соответствии с новым конфигурационным файлом. Такая проверка помогает исключить ошибки при создании рабочей инфраструктуры.
Конфигурация Terraform
Конфигурация Terraform интереснее, чем у Packer. Для его работы файлы конфигурации должны находиться в директории, из который запускают инструмент. При этом оформление не имеет значения: конфигурацию можно описать как в одном файле, так и в нескольких, разделив на смысловые блоки.
Как правило, описание конфигурации содержит:
Файл с описанием провайдеров. Terraform может работать с разными облаками, поэтому в файле описываем параметры провайдера — название и версию. Подробнее про настройку Terraform-провайдера для VK Cloud Solutions можно посмотреть здесь.
Файл с данными для подключения к облаку. Инструменту надо передать API endpoints, ключи и другие персональные идентификаторы.
Файл с описанием конфигурации виртуальных машин. Terraform работает с двумя типами объектов: Data и Resource. Data — то, что можно получить из облака. Например, конфигурация дефолтной сети облака. А Resource — то, что создаем сами.
В описании Resource указываем тип ресурса: vkcs_compute_instance
. Также указываем внутреннее имя ресурса, которое Terraform будет использовать для автоматического построения зависимостей. С помощью таких имен можно обращаться к свойствам других объектов.
В этом файле конфигурации также указываем переменную с названием ВМ — с префиксом node и переменной count.index
. Прописываем еще две переменные: image_name
и image_tag
, которые будут указывать на название и тег образа, созданного с помощью Packer.
Также описываем и другие параметры.
Файл с описанием сетей. В файле с сетями используется другой тип объектов — Data. Он нужен для запроса данных из облака в переменную
ext-net
. Также в файле прописываем приватную сеть и подсеть, создаем роутер, конфигурируем Security-группы и настраиваем остальные сетевые параметры.
Файл с ключами доступа. В нем прописываем, что Terraform сам автоматически генерирует SSH-ключ: приватную часть после запуска сохранит локально, а публичную часть положит в облако. Впоследствии публичный ключ будет доставлен во все новые ВМ.
Ресурс tls_private_key.ssh.private_key_pem
содержит приватный ключ. В выводе он помечен как sensitive = true
и будет маскирован. Используем следующую команду для сохранения приватного ключа:
Файл с конфигурацией load balancer. Балансировщик нагрузки нужен, если планируется запускать несколько виртуальных машин. Для подготовки в файле создаем Load Balancer и внешний Listener, добавляем в балансировщик виртуальные машины и определяем правила проверки. При правильной настройке балансировщика Terraform обеспечивает Zero Downtime Deployment с плавной для пользователей сменой версии приложения.
Для запуска Terraform и начала создания указанной инфраструктуры нужно выполнить terraform apply
. В ответ на это Terraform выводит весь план создаваемой конфигурации, запрашивает подтверждение и начинает создавать в облаке всю заданную инфраструктуру с сетями, подсетями, роутерами, балансировщиками и другими компонентами.
В итоге IaC-инструменты сводят всю подготовку инфраструктуры к простым действиям:
Описание образа.
Описание состояний виртуальных машин с помощью Ansible.
Установка и настройка Nginx.
Запуск виртуальных машин с помощью Terraform.
При таком подходе не нужно будет катать Ansible по всем создаваемым виртуальным машинам, что упрощает внесение любых изменений.
Обновленный CI/CD-пайплайн
C помощью Packer и Terraform можно реализовать все принципы Docker с неизменяемой инфраструктурой и Kubernetes с выкатыванием новых версий через перезапуск.
Связка инструментов отлично работает с инфраструктурой на виртуальных машинах в облаке и сохраняет привычный алгоритм:
Разработчик выпускает новую версию приложения.
С помощью Packer делаем новый образ ВМ на основе новой версии приложения.
С помощью Terraform автоматизировано повторно разворачиваем всю инфраструктуру без даунтайма с Health Check от балансировщиков.
На нашей
Last updated