compose.yml. По-умолчанию /opt/<имя сервиса>/srv/<имя сервиса>
srv
zulip
datacertspostgres
datastate.env и state не absent
present - создать compose-файл(шаблон), в случае если он уже есть, не менять текущее состояние сервисаenabled - создать compose-файл и запустить сервис (docker compose up -d)disabled - создать compose-файл и остановить сервис (docker compose down)absent - остановить сервис (если присутствует compose файл) и удалить compose-файл
purge: true также удалить все данные сервисаНа данный момент в проекте имеется конфигурация для двух сервисов:
Остановимся на каждой роли поподробнее.
Роль Wiki.js принимает следующие переменные, в случае если обязательные переменные не будут переданы, будет запрошен ввод их значений с клавиатуры.
Все полученные и стандартные переменные переносятся в переменные окружения сохраняемые на диск для того чтобы не запрашивать ввод при повторном обращении к роли. Данные переменные в дальнейшем используются в compose.yml файле приложения.
Основной переменной является состояние сервиса описанное выше исходя из которого принимается решение об изменении состоянии работы роли.
Роль ODOO принимает следующие переменные, в случае если обязательные переменные не будут переданы, будет запрошен ввод их значений с клавиатуры. Логика работы с переменными и директориями для данной роли аналогично ранее описанной для Wiki.js
Приведем пример принципа работы ролей сервисов на примере Wiki.js
Основная логика работы типовой роли установки сервиса следующая:
absent начинаем выполнение основной части роли
enabled выполняем запуск контейнеров с помощью docker-compose, а также выполняем автоматическое завершение установки запросив почту и пароль администратора, а также url инсталяции wiki.js, например, wiki.miem.hse.ru, после этого выполняется HTTP запрос методом пост на указанный урл в указатель /finalize передав указанные в теле запроса в формате JSONabsent или disabled выключаем контейнеры с помощью docker-composeabsent удаляем файл compose.yml из директории назначения и удаляем её