Как генерировать соурсы jOOQ, когда БД тоже в Docker?

Question

[Орхан Гасанлы]

jooq при старте приложения генерирует соурсы и добавляет их в target.
Весь стэк поднимается в docker compose (БД в том числе). Будет ли доступна БД при старте приложения, чтобы можно было сгенерировать соурсы для jOOQ?
Другой вопрос, как передать значения переменной окружения для конфигурации jooq, чтобы она была доступна в докере?
Пробовал следующие варианты - объявляю args внутри build. Пробовал через environment. А внутри pom.xml уже получаю значение переменной таким образом `${env.XXX}`

Comments

[Алан Гибизов]

Если нет кода, не надо ставить тэг языка.

Answer 1

[Орхан Гасанлы]

Ситуация была в следующем.
Плагин jOOQ срабатывает на этапе `mvn clean package`. Так как на данном этапе в docker compose образы хоть и собраны, но контейнер БД не стартовал, то этап сборки приложения не сработает (connection refused to db).
Почему healthcheck & depends_on не подошли в данном случае:
Так как они сработают в случае, если контейнеры стартовали. К тому же, depends_on не гарантирует то, что стартанет сервис. Он гарантирует, что стартанер контейнер.
Решил проблему следующим образом. В docker compose первоначально выборочно собираю нужные образы и стартую нужные сервисы (БД в том числе). Затем уже собираю образ приложения и стартую приложение.
Т.е. примерно так:
Этап 1
`docker compose up postgres rabbit redis -d`
Этап 2
`docker compose up app -d`

Есть альтернативное решение, тоже хорошее.
Генерация сущности после того, как приложение стартовало при помощи AfterStartupApplicationListener
Подробности тут - https://habr.com/ru/articles/488522/

Answer 2

[Максим Федоров]

Будет ли доступна БД при старте приложения, чтобы можно было сгенерировать соурсы для jOOQ?

Если docker-compose, то можно healthcheck сделать и переподнимать, пока не будет доступно
таже можно настроить переподнятие, если контейнер с приложением зафейлится... а если он при поднятии првоеряет переменные окружения, то будет фейл

Пробовал следующие варианты - объявляю args внутри build. Пробовал через environment. А внутри pom.xml уже получаю значение переменной таким образом `${env.XXX}`

у вас docker-compose есть?
там можно в секции environments указать

Comments

[Орхан Гасанлы]

Если docker-compose, то можно healthcheck сделать и переподнимать, пока не будет доступно

Если память не изменяет, то в версии 3.х docker compose сам не поддерживает healthcheck. Он был в версии 2.х

Хотя, сейчас в версии 3.8 проверяю и вроде бы есть тег healthcheck

у вас docker-compose есть?
там можно в секции environments указать

Указывал. В принципе, для при старте приложение переменные окружения объявленные там видны.
Но в силу того, что мне эти переменные нужны на этапе mvn clean install, то он не хочет их видеть.

Сейчас захардкодил внутри Dockerfile и он увидел эти значения.

ENV DATASOURCE_DRIVER
ENV DATASOURCE_DB
ENV DATASOURCE_U
ENV DATASOURCE_P

Теперь, проблема в том, что он не видит БД. Хоть depends_on прописан, но он гарантирует только старт контейнера и никак не старт приложения (как healthcheck).

[Максим Федоров]

depends_on как раз устарел тоже

мне эти переменные нужны на этапе mvn clean install, то он не хочет их видеть.

если в контейнере это запускается (поднятым в компоуз), то должны быть видны там!

[Орхан Гасанлы]

В общем, решил вопрос чуть иным способом. На этапе билда пока еще ни один контейнер не стартует, потому приложение не может подключиться к БД, чтобы сгенерировать сущности для jooq. Для этого я сделал по-другому. Стартую сервисы из компоуз выборочно. После того, как БД стартанет, запускаю само приложение.

[Максим Федоров]

я все же не понял, почему бы не фелить подъем бекенда, если нет переменных окружения или подключения к БД?

тогда он будет переподниматься, пока БД не станет доступной

[Орхан Гасанлы]

Максим Федоров, потому, что сколько бы я не фейлил подключение к БД, оно не поднимется (это я уже кстати, проверил), ибо у меня возникает ошибка подключения к БД на этапе сборки изображения, а не на этапе старта контейнеров.
Если бы БД не успевала стартовать к моменту старта контейнера приложения, то да, ваш способ сработал бы. А так как ошибка возникает на этапе сборки, то ни один из контейнеров еще не стартовал и не стартует. Видимо, это как "атомарный процесс" либо стартуют все указанные сервисы, либо ни один из них...

[Максим Федоров]

честно, очень странно

сборка если в контейнере, то не может быть вне контейнера, может быть вы что-то локлаьно делаете?

[Орхан Гасанлы]

Максим Федоров, нет, все собирается внутри контейнера)