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

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

Архитектура ADCM основана на следующих компонентах:

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

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

  • Статус-сервер (Status Server). Принимает hearbeats от хостов, сервисов и их компонентов, а также события (events) от веб-интерфейса. Отправляет веб-сокеты на веб-интерфейс. Статус-сервис реализован на Go.

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

  • База данных (Database). Хранит различные данные, зашифрованные с помощью Ansible Vault, в виде Ansible secrets.

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

  • Исполнитель процесса (Ad hoc job runner). Готовит окружение для запуска Ansible, формируя inventory-файл, после чего вызывает команду Ansible. Для кластера и хостпровайдера исполнитель процесса запускает какой-либо набор команд на хосте, которые в итоге влияют на работу кластера в целом (например, запуск сервиса, конфигурирование файлов, установка пакетов). Работа исполнителя процесса происходит асинхронно — браузер с ADCM не блокируется, а после отработки результат работы процесса записывается в базу данных, откуда его забирает бэкенд-сервер. Исполнитель процесса готовит окружение из inventory-файла при каждом запуске Ansible-команд, что отражено в префиксе Ad hoc — "только для данного случая". Каждый исполнитель процесса — это не поток (thread), а отдельный процесс в терминологии UNIX.

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