Интеграция с бандлом

При загрузке бандла в ADCM на бэкенд приходит запрос, который запускает следующий процесс.

Все файлы бандла распаковываются и помещаются в файловую систему (<adcm container mount point>/bundle/<bundle hash>). При этом каждый бандл распаковывается в соответствующую ему директорию и обладает уникальным хешем. Это позволяет всем playbook и role разных продуктов не перемешиваться — каждый playbook хранится в соответствующем ему бандле.

После распаковки бандла ADCM обрабатывает (parsing) специальный файл, который называется config.yaml либо config.yml. Этот файл может располагаться в любой директории бандла. Файлов config.yaml может быть несколько — в этом случае ADCM находит все файлы с таким именем, которые содержатся в бандле.

После поиска файлов config.yaml каждый из этих файлов подвергается обработке. Эта обработка подразумевает создание в ADCM сущностей прототипов на основе их описаний в файлах config.yaml. Таким образом создаётся метаинформация об объектах ADCM. Происходит взаимодействие бэкенда с базой данных: в базу данных записываются все описанные прототипы, их action, конфигурации и другая связанная информация.

При запуске какого-либо action на объекте ADCM из базы данных запрашивается метаинформация об этом action (например, содержится ли в нём конфигурация config или config_jinja, которую необходимо запросить у пользователя перед запуском action, или же требуется расположить компоненты на хосте hc_acl). Бэкенд возвращает эту метаинформацию, а UI использует её, чтобы сгенерировать соответствующие формы для взаимодействия с пользователем.

Также на основе метаинформации от бэкенда формируется task для отправки на обработку task runner, который формирует цепочку job, каждую из которых затем запускает job runner. По сути, job runner запускает Ansible playbook, которые указаны в секции script у action или subaction. При запуске эти Ansible playbook могут обращаться к модулям и плагинам Ansible, добавленным на этапе разработки бандла.