2024-02-14, Мысли по установке бэкенда

Локально

Разработчик

git clone ...
cp .env.dist .env
docker compose -f docker-compose.dev.yaml up -d

Здесь проблемы в целом отсутствуют, единственное немного неудобно что используется не дефолтное имя docker-compose файла.

Пользователь

Что-то вроде
set SELENOID_PARALLEL_SESSIONS_COUNT=%NUMBER_OF_PROCESSORS%&& docker rm --force jdi-qasp-ml-api && docker image rm ghcr.io/jdi-testing/jdi-qasp-ml:rc --force && curl.exe --output docker-compose.yaml --url <https://raw.githubusercontent.com/jdi-testing/jdi-qasp-ml/rc/docker-compose-rc.yaml> && curl.exe --output browsers.json --url <https://raw.githubusercontent.com/jdi-testing/jdi-qasp-ml/rc/browsers.json> && docker compose up

Проблемы

Команда тяжело читается
Трудности с поддержкой с учетом того, что есть шесть таких однострочников, которые отличаются лишь в деталях

Как можно исправить

Сделать два установочных скрипта, один для Windows, второй для macOS и Linux (отличия между ними минимальны).

На сервере

docker compose down
curl --output docker-compose.yaml <https://raw.githubusercontent.com/jdi-testing/jdi-qasp-ml/rc/docker-compose-rc.yaml>
curl --output browsers.json <https://raw.githubusercontent.com/jdi-testing/jdi-qasp-ml/rc/browsers.json>
curl --output .env <https://raw.githubusercontent.com/jdi-testing/jdi-qasp-ml/rc/.env.dist>
docker compose up -d --build --pull=always

Проблемы

Выполняется вручную
В docker-compose файлах для развертывания на сервере есть монтирование томов из домашнего каталога пользователя, что не очень хорошо с той точки зрения что для разных пользователей, запускающих сервис, этот каталог будет разным ⇒ если приложение будут запускать разные пользователи, данные монги будут распиханы по нескольким местам, при этом не будет места, содержащего все накопленные данные.

Как можно исправить

Деплоить по событию мержа в develop и main ветки (при условии успешной сборки и прохождения тестов). Судя по всему это можно организовать с помощью EPAM Jenkins. Возможно проще всего будет весь пайплайн перенести с GitHub Actions на Jenkins.

Общие проблемы

Большое количество docker-compose файлов, являющихся практически копипастой ⇒ сложности в поддержке.
Их использование не задокументировано хотя бы в самих файлах ⇒ не сразу можно разобраться для чего конкретно используется каждый из них.
Захардкоженные имена контейнеров в docker-compose файлах. Имеет бонус виде невозможности запустить два инстанса приложения. Обратная сторона бонуса: невозможно запустить два инстанса приложения без манипуляций 😀.

Как решать

Использовать возможности шаблонизации и объединения файлов, предоставляемые Docker Compose. PoC можно посмотреть в ветке new-docker-compose-configuration
Не использовать константные имена для контейнеров? Можно обсудить. С моей точки зрения их минусы перевешивают плюсы. Две копии проекта в конфигурации по умолчанию пользователь всё равно не сможет запустить из-за того что нельзя один порт занять двумя программами.