Интеграция с бандлом
При загрузке нового бандла в ADCM добавляется информация о прототипах на основе описания, указанного в бандле при его разработке. Ниже описаны этапы процесса интеграции ADCM и нового бандла.
Загрузка бандла
При загрузке бандла в ADCM на бэкенд-сервер приходит запрос, который запускает процесс, описанный ниже.
Все файлы бандла распаковываются и помещаются в файловую систему (<adcm container mount point>/bundle/<bundle hash>). При этом каждый бандл распаковывается в соответствующую ему директорию и обладает уникальным хешем. Это позволяет playbook и role разных продуктов не перемешиваться — каждый playbook хранится в соответствующем ему бандле.
После распаковки бандла ADCM обрабатывает (parsing) специальный файл, который называется config.yaml либо config.yml. Этот файл может располагаться в любой директории бандла. Бандл может содержать несколько файлов config.yaml. В этом случае ADCM находит в бандле все файлы с этими именами.
После поиска файлов config.yaml (или config.yml) каждый из этих файлов подвергается обработке. Эта обработка подразумевает создание в ADCM сущностей прототипов на основе описаний, содержащихся в указанных файлах. Таким образом формируются метаданные об объектах ADCM. Происходит взаимодействие бэкенд-сервера с базой данных: в базу данных записываются все описанные прототипы, их action, конфигурации и другая связанная информация.
Запуск action
Подготовка запуска
После получения запроса на запуск action бэкенд-сервер запрашивает из базы данных метаданные, необходимые для подготовки запуска:
-
правила сопоставления хостов и компонентов (hc_acl);
-
конфигурацию action (config или config_template), если перед запуском требуется запросить у пользователя дополнительные параметры.
Бэкенд-сервер возвращает полученные метаданные в веб-интерфейс, который использует их для создания соответствующих форм взаимодействия с пользователем.
После подтверждения запуска веб-интерфейс передает запрос на бэкенд-сервер. Бэкенд-сервер получает из базы данных метаданные action, формирует job и сохраняет его в базе данных для последующей обработки, после чего возвращает ответ в веб-интерфейс, который выводит пользователю уведомление о старте job.
Планирование цепочки subjob
Периодически Job Scheduler опрашивает базу данных на наличие новых job. В зависимости от используемых компонентов ADCM планирование и распределение цепочки subjob выполняется по одному из двух сценариев:
-
При использовании Local Executor: Job Scheduler формирует цепочку subjob в базе данных и инициирует их выполнение через Local Executor.
-
При использовании Celery Worker: Job Scheduler формирует внутренний объект Celery Chain Runner и сохраняет его в базе данных. Celery Worker получает этот объект и на его основе формирует цепочку Celery tasks, обеспечивающую последовательное выполнение subjob.
ПРИМЕЧАНИЕCelery Chain Runner — внутренний механизм ADCM, который преобразует job в цепочку Celery tasks, обеспечивающую последовательное выполнение subjob экземплярами Celery Worker.
Выполнение subjob
Для каждого subjob выполняется стандартный цикл операций:
-
Подготавливается окружение для запуска Ansible playbook. Процесс включает генерацию inventory-файла, тегов и других параметров. Если используется Celery Worker, на этом этапе Vault дополнительно предоставляет необходимые чувствительные данные и токены.
-
Запускается Ansible playbook, указанный в свойстве script соответствующего action. Запуск происходит внутри каталога бандла как отдельный процесс в терминологии UNIX. В окружении этого процесса Ansible playbook задействует модули и плагины ADCM для Ansible.
-
Полученный от Bundle результат выполнения Ansible playbook сохраняется в базе данных, после чего subjob отмечается как завершенный.
После завершения всей цепочки subjob выполнение job считается завершенным. Статус-сервер фиксирует изменение статуса job и передает соответствующее событие в веб-интерфейс по протоколу WebSocket.
