docker compose всегда строит Dockerfile, поэтому он не зависит от БД

Question

У меня есть Dockerfile, который на самом деле создает весенний загрузочный проект Maven.Мой docker-compose.yml ниже

version: '3'
services:
  db:
    image: mysql
    restart: always
    environment:
      - MYSQL_DATABASE=calero
      - MYSQL_ROOT_PASSWORD=root
    volumes:
      - ./db:/var/lib/mysql
    ports:
      - "3306:3306"
  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    restart: always
    environment:
      PMA_ARBITRARY: 1
      MYSQL_ROOT_PASSWORD: root
    ports:
      - "8082:80"
    links:
      - "db:db"
  redsparrow:
    build: .
    restart: always
    ports:
      - "8081:8080"
    links:
      - "db:db"
    depends_on:
      - db
volumes:
  db:
    driver: "local"

И Dockerfile - это

FROM maven:3.6.0-jdk-11 as build
WORKDIR /app
COPY . /app 
RUN mvn clean package

FROM tomcat
COPY context.xml /usr/local/tomcat/webapps/manager/META-INF/context.xml
COPY tomcat-users.xml /usr/local/tomcat/conf/tomcat-users.xml
COPY tomcat-users.xml /usr/local/tomcat/conf/tomcat-users.xml
COPY --from=build /app/target/*.war /usr/local/tomcat/webapps

Но то, с чем я сталкиваюсь здесь, docker-compose, всегда стараюсь построить красный воробей перед вращениемКонтейнер mySQL и пакет mvn clean пытаются получить доступ к базе данных, так как она не работает, сборка не завершается успешно.

Мне кажется, что я что-то упустил, поэтому приложение весенней загрузки (redsparrow) всегда должно создаваться после запуска контейнера базы данных.

Пожалуйста, помогите!

Answer 1

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

Подводя итог, можно сказать, что рассматриваемая служба - это докеризированный проект Java / Maven / Spring-Boot, который опирается на докеризированную базу данных MySQL, и доступ к этой базе данныхтребуется для построения вашего проекта с mvn clean package, вероятно, из-за наличия интеграционных тестов на этапе test Maven.

Чтобы преодолеть это, я вижу два возможных подхода (первый подход менее стандартный и менеепроще в реализации, чем второй, поэтому я подробно остановлюсь на последнем):

1. Вы можете положиться на docker-maven-plugin для вращенияMySQL контейнер напрямую от Maven.Смотрите также эту статью блога .Практическая проблема здесь заключается в том, что команды docker не доступны напрямую внутри рассматриваемого контейнера Docker, если вы не используете DinD (Docker-in-Docker).

2. Более простой подход включал бы адаптацию самих тестов, а не изменение настроек докера:

   • это ближе к стандартным соглашениям, предполагая, что mvn test (инициируется mvn package) предназначается для юнит-тестов, в то время какmvn verify (с использованием плагина failsafe Maven) предназначен для интеграционных тестов с привлечением внешних баз данных или служб; по-прежнему
   • , если вы все равно хотите сохранить ряд модульных тестов с использованием базы данныхоперациях, вы можете использовать механизм базы данных в памяти, такой как H2 , который часто используется в контексте модульных тестов Spring Boot (см., например, , туториал );

   • тогда вы можете перенести свои интеграционные тесты в дополнительный сервис docker-compose, следуя схеме подхода в этого урока и эта статья , например:

     integrationtest:
         build: ./integrationtest
         command: ./wait-for-it.sh -h db -p 3306 -s -t 150 -- mvn verify
         depends:
           - db
     

Отметим, что свойство links: теперь устарело .
Обратите также внимание, что приведенный выше отрывок .yml основан на wait-for-it , поскольку свойство depends: ожидает только запуска контейнеров зависимостей, а не их полной готовности.