Как написать dockerfile для добавления сборки maven в существующий весенний загрузочный проект, содержащий jdk

Question

Мой босс ушел в отпуск на несколько дней, я java разработчик, я не очень много знаю о docker (только основы c знание)

У меня java Spring boot проект, в котором есть Dockerfile в root проекта.

FROM openjdk:8-jdk-alpine
VOLUME /tmp
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]

Я хочу добавить maven в то же самое, без изменения структуры. и maven должен очистить упаковку .?

например. docker build -t user / myimage.

он должен установить maven и автоматически очистить мой проект. без необходимости явно запускать пакет mvn clean

До этого у меня было мало ресурсов из stackoverflow , но я не могу провести эксперимент, мне нужен код, который может запускаться с учетом указанного выше сценария jdk.

FROM maven:3.6.0-jdk-11-slim AS build
COPY src /home/app/src
COPY pom.xml /home/app
RUN mvn -f /home/app/pom.xml clean package

Прошу вас дать эквивалентный скрипт для чистого пакета Maven, чтобы я мог добавить его в файл docker, который создает мой образ.

Answer 1

Обычно это 2 шага:

1. build jar.
2. run docker build для создания образа, содержащего jar.

Там это плагины maven / gradle, которые помогают вам автоматизировать процесс из вашей сборки maven, но посмотрите dockerfile-maven, это, вероятно, то, что вы ищете: https://github.com/spotify/dockerfile-maven

Answer 2

У меня до этого было мало ресурсов от stackoverflow, но я не могу провести эксперимент, мне нужен код, который может запускаться, если упомянутый выше скрипт jdk упоминается ранее.

Если я правильно понимаю, ваша проблема если вы хотите добавить шаг упаковки maven в сборку docker, продолжая использовать точную версию JDK: FROM openjdk:8-jdk-alpine во время выполнения и не зависеть от этого базового образа: FROM maven:3.6.0-jdk-11-slim AS build.

Первое: не беспокойтесь о зависимости от другого базового docker образа в Docker сборке.
Docker сборка имеет многоступенчатую сборку , поскольку версия 17.05 Docker (05/2017), которая позволяет определять несколько этапов сборки и соответствует вашим потребностям.
Действительно, на первом этапе вы можете полагаться на образ maven docker для создания своего При запуске приложения на втором этапе вы можете положиться на изображение JDK docker.
Функция многоэтапного построения имеет и другое преимущество: оптимизация размера изображения, поскольку промежуточные слои, созданные предыдущими шагами, не сохраняются в окончательный размер изображения.
Для среды, подобной интеграции / производству, я, вероятно, так и буду использовать.

Чтобы вернуться к вашей проблеме, если вы хотите использовать ответ что вы связали, главное, что вам нужно изменить, это тег JDK конечного базового образа, чтобы он соответствовал вашим требованиям, и вам также следует адаптировать некоторые мелочи.
A Примечание: в настоящее время вы копируете JAR на root изображения. Это не очень хорошая практика по соображениям безопасности. Вам лучше скопировать его в папку, например /app.

Когда вы ссылаетесь на jar, созданный maven, также предпочтительно префикс jar его artifactId / final name без его версии, а не рассматривать любой jar в целевой папке как толстый jar, как вы делаете здесь: ARG JAR_FILE=target/*.jar.

Таким образом, это даст:

# Build stage
FROM maven:3.6.0-jdk-11-slim AS build
COPY pom.xml /app/
COPY src /app/src
RUN mvn -f /app/pom.xml clean package

# Run stage
FROM openjdk:8-jdk-alpine # Use your target JDK here !
COPY --from=build /app/target/app*.jar /app/app.jar
ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app/app.jar"]

Обратите внимание, что предлагаемое решение очень простое, достаточно во многих случаях, но может не соответствовать вашему конкретному c контексту.
Там действительно несколько подходов для решения вашего вопроса. В зависимости от вашей целевой среды ваши требования не совпадают, и стратегия будет отличаться.
Этими требованиями могут быть скорость сборки, оптимизация окончательного размера изображения, быстрая обратная связь для местных разработчиков. И все это не обязательно совместимо.
Область построения Docker действительно очень большая тема. Я настоятельно советую вам изучить больше, чтобы иметь возможность приспособить решение для сборки docker к вашим реальным потребностям.