Привет, Хабр! Продолжу серию третьей статьей об эффективном использовании Ansible для развертывания больших инфраструктур в компаниях. В этом тексте я расскажу, какую архитектуру приложения на основе Ansible мы сформировали, и остановлюсь на модулях Deployer и Inventory.

Техническое задание

Задача стояла все та же — быстро развертывать любую цифровую инфраструктуру, что включает:

быстрое конфигурирование
быстрое развертывание
быструю разработку
длительную поддержку старого кода
интеграцию с внешними системами

Архитектурное решение

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

Было принято решение:

Вынести Inventory в отдельный модуль.
Вынести A-service в отдельные модули.
Создать модуль запуска развертывания — Deployer.
Зафиксировать точки входа и выхода для внешних служебных сервисов.

Получилась следующая схема:

Архитектура приложения на основе Ansible

Deployer — модуль запуска контейнеров для развертывания инфраструктуры.

Запускает модуль Inventory нужной версии;
Запускает модули A-service, указанные в Inventory.

Inventory — кодовая база Ansible inventory. На вход получает YAML-файл с конфигурацией инфраструктуры (который мы рассматривали ранее) и возвращает скоуп переменных, используемых модулями A-service.

Services (A-service) — модуль развертывания игровых сервисов на полигоне. Получает всю информацию из Inventory: данные о платформе, внешних сервисах, инвентаризации. Используя эти сведения, устанавливает сервис.

Как это нам помогло

При отделении Inventory от A-service мы получили:

Изменение YAML-файла конфигурации перестало влиять на A-service. Можем отдельно дорабатывать основные параметры инфраструктуры. Это позволяет быстро оптимизировать YAML-файл для ускорения конфигурирования.
A-service можно разрабатывать отдельно, получая на вход зафиксированные переменные от Inventory. Это позволяет:
- искусственно ограничить сквозное использование переменных Ansible, что ускоряет поиск ошибок и разработку (внутренние переменные Inventory перестают влиять на переменные A-service);
- быстро разрабатывать новые A-service, получая на вход задекларированные переменные, имея отдельный репозиторий (как следствие — быстрый merge, легкое встраивание в процесс разработки);
- управлять запуском выбранных A-service в нужной последовательности через Deployer;
- поставлять заказчику не код, а контейнер, что в разы повышает надежность развертывания (все для установки и настройки уже лежит в контейнере);
- использовать разные версии ПО в разных A-service (Ansible, Python).

Появление отдельного модуля Deployer позволяет управлять последовательностью развертывания, а также легко развивать его и оптимизировать.

Минусы (как же без них)

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

Давайте подробно остановимся на модулях Inventory и Deployer.

Модуль Inventory

Inventory — модуль инвентаризации инфраструктуры на основе Ansible inventory. Особенность модуля в том, что он запускается в отдельном контейнере и отдает на выход папку с Ansible inventory. Это позволяет подключать любые A-service для развертывания, в том числе параллельно.

В Inventory мы настраиваем:

Основной YAML-файл конфигурации.
Параметры платформы (VMware vSphere, OpenStack, различные облака).
Параметры внешних сервисов (зеркала, артефакторий, Git, HashiCorp Vault и т.п.).

На выходе получаем папку формата Ansible inventory c формализованным скоупом переменных для использования в A-service.

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

Модуль Deployer

Deployer — модуль запуска контейнеров для развертывания инфраструктуры. Основной сценарий работы Deployer:

запустить контейнер Deployer + Inventory;
сформировать список всех A-service, которые есть в Inventory;
скачать (в примере — из GitLab) A-service нужных версий по списку;
сформировать последовательность запуска A-service (это, пожалуй, самая важная функция модуля);
запустить выбранные A-service в нужном порядке с информацией о пути к Inventory.

Далее A-service сам возьмет из Inventory то, что нужно, и установит заложенный сценарий.

Итог

Сформирована быстрая и независимая разработка компонентов.
Ansible и системные компоненты обновляются независимо и с минимальными затратами.
Значительно ускорилась реакция на потребности бизнеса в больших изменениях (вариабельность инфраструктур, сервисов большой связности в инфраструктуре, изменение состава внешних сервисов интеграции).

Архитектура приложения. Разбиваем приложение Ansible на модули (Inventory, Deployer)