Обзор архитектуры

Михаил Серов, Аделя Звягинцева

Базовая идея ADCM заключается в том, чтобы предоставить простой пользовательский интерфейс, который обеспечивает достаточно данных для запуска скриптов Ansible на некотором числе хостов.

ADCM может быть развернут с использованием основного контейнера и внешних компонентов:

  • Основной контейнер ADCM — включает компоненты, обеспечивающие работу пользовательского интерфейса, обработку API-запросов, планирование задач и выполнение операций управления кластерами и хостпровайдерами.

  • Внешние компоненты — развертываются вне контейнера ADCM:

    • Обязательные: база данных (Database).

    • Опциональные: Celery Worker, Vault и Consul.

Ниже приведены схемы архитектуры ADCM.

Основной контейнер

Следующие компоненты входят в состав основного контейнера ADCM:

  • Nginx — обеспечивает доступность ADCM, принимая входящие запросы пользователей. Nginx запускается на порте 8000. Основное назначение Nginx в архитектуре ADCM — выступать в роли обратного прокси, маршрутизирующего запросы между веб-интерфейсом и бэкенд-сервером.

  • Веб-интерфейс (Web UI) — принимает запросы пользователя, перенаправленные от Nginx.

  • Статус-сервер (Status Server) — принимает сигналы о состоянии (heartbeat) от хостов, сервисов и их компонентов, а также отправляет и обрабатывает события по протоколу WebSocket. Статус-сервер реализован на языке программирования Go.

  • Бэкенд-сервер (Backend Server) — обрабатывает API-запросы от веб-интерфейса, записывает и считывает данные из базы данных, а также обращается к статус-серверу с использованием REST API для получения информации о состоянии хостов, сервисов и компонентов.

  • Планировщик задач (Job Scheduler) — опрашивает базу данных на наличие новых задач, формирует из них цепочки подзадач и инициирует их выполнение — локально через Local Executor или асинхронно через Celery Worker, в зависимости от конфигурации ADCM.

  • Фоновый процесс (Background job) — выполняет различные фоновые задачи, например удаление устаревших данных из базы данных. Периодичность запуска определяется значениями, которые хранятся в базе данных.

  • Local Executor — встроенный компонент ADCM, который инициирует выполнение операций управления кластерами и хостпровайдерами непосредственно внутри контейнера ADCM. Для каждой операции Local Executor подготавливает окружение, включая формирование inventory-файла, после чего запускает команду Ansible. Каждый запуск Ansible представляет собой отдельный процесс в терминологии UNIX, а не поток. Выполнение происходит асинхронно, результат по завершении записывается в базу данных.

Внешние компоненты

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

Обязательный внешний компонент:

  • База данных (Database) — хранит данные ADCM, включая информацию о кластерах, хостах, сервисах, компонентах, задачах и результатах их выполнения.

Опциональные внешние компоненты:

  • Celery Worker — в отличие от Local Executor, развертывается как отдельный внешний компонент и использует Celery tasks chain (цепочку последовательно выполняемых задач Celery) для асинхронного выполнения операций управления кластерами и хостпровайдерами. Это позволяет распределять выполнение задач между несколькими экземплярами Celery Worker. Как и Local Executor, Celery Worker подготавливает окружение, включая формирование inventory-файла, после чего запускает команду Ansible. Результаты выполнения операций сохраняются в базе данных.

    ВАЖНО

    • Celery Worker должен использовать тот же том (volume), что и бэкенд-сервер.

    • Для корректной работы Celery Worker необходимо развернуть Consul.

  • Vault — обеспечивает безопасное хранение и предоставление секретов, необходимых для работы ADCM. Бэкенд-сервер, статус-сервер и Celery Worker обращаются к Vault для получения токенов и чувствительных данных, необходимых для работы компонентов ADCM.

    ПРИМЕЧАНИЕ
    В качестве Vault ADCM поддерживает HashiCorp Vault, OpenBao и другие совместимые решения.

  • Consul — используется как внешний инфраструктурный сервис для регистрации компонентов ADCM и контроля их доступности.

Архитектура ADCM с Local Executor
Архитектура ADCM с Local Executor
Архитектура ADCM с Local Executor
Архитектура ADCM с Local Executor
Архитектура ADCM с внешними компонентами
Архитектура ADCM с внешними компонентами
Архитектура ADCM с внешними компонентами
Архитектура ADCM с внешними компонентами
Нашли ошибку? Выделите текст и нажмите Ctrl+Enter чтобы сообщить о ней