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

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

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

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

• быстрое конфигурирование

• быстрое развертывание

• быструю разработку

• длительную поддержку старого кода

• интеграцию с внешними системами

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

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

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

• Вынести Inventory в отдельный модуль.

• Вынести A-service в отдельные модули.

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

• Зафиксировать точки входа и выхода для внешних служебных сервисов.

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

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 и системные компоненты обновляются независимо и с минимальными затратами.

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