Медленный рабочий процесс разработки / обратная связь l oop для Java с Docker: нужно ли перестраивать JAR и образ после каждого изменения?

Question

Я пытаюсь докеризовать приложение Java, но в настоящее время мои отзывы разработчиков l oop намного медленнее при работе с Docker по сравнению с тем, когда я работаю без Docker. С Docker мне нужно перестраивать мой jar и изображение после каждого изменения (см. Более подробный рабочий процесс ниже), что вызывает медленную обратную связь l oop. Что делают Java разработчики в мире Docker, чтобы избежать этого?

Dockerfile (для справки):

FROM openjdk:8    
WORKDIR /usr/src/app  
COPY /target/my-project.jar .  
CMD ["java",  "-jar",  "my-project.jar"]

Java рабочий процесс разработки с Docker (обратная связь занимает 3-5 минут после каждого изменения):

1. Внести изменения в мою Java кодовую базу локально.
2. Какими бы маленькими ни были изменения в # 1, Мне нужно перестроить банку (используя пакет maven); для моей кодовой базы это занимает 3-4 минуты.
3. Восстановить образ.
4. Запустить контейнер и посмотреть, прошли ли изменения.

Java Рабочий процесс разработки без Docker (обратная связь занимает секунды после каждого изменения):

1. Внести изменения локально в мою Java кодовую базу.
2. Нажмите «Выполнить» в моей конфигурации запуска Intellij , который немедленно запускает мой основной метод и проверяет, были ли внесены изменения.

Насколько я могу судить, мои местные отзывы разработчиков l oop (без Docker) намного быстрее, потому что Intellij может кэшировать весь байт-код (т. е. файлы классов в каталоге "target /"), перестраивает файл (ы) класса только для измененного класса (ов), отслеживает мой путь к классам и запускает мой основной метод. Нет необходимости перестраивать всю банку, поэтому это происходит намного быстрее. Я не уверен, как воспроизвести это в Docker.

UPDATE / ANSWER

Я решил эту проблему с помощью следующего подхода:

1. Прикрепите целевую папку моего проекта к / usr / src / app / target в контейнере, а теперь просто вызовите основной класс в моем CMD Dockerfile, никогда не помещая JAR в контейнер. Благодаря @ kutschkem.

2. Добавлен maven-dependency-plugin к моему pom. xml, так что все мои внешние зависимости jar можно сохранить в одну папку (/ usr / src / app / target / dependency-jars /), который я затем мог бы добавить в свой путь к классам за один раз sw oop в моем CMD Dockerfile ниже. Уловил идею из этой статьи: https://medium.com/holisticon-consultants/dont-build-fat-jars-for-docker-applications-6252a5571248.

Новый файл Dockerfile:

FROM openjdk:8    
WORKDIR /usr/src/app/target
CMD ["java",  "-cp", "/usr/src/app/target/classes:/usr/src/app/target/dependency-jars/*",  "com.me.MainClass"]

Answer 1

Здесь можно улучшить две вещи:

1) Не копируйте файл jar в образ, смонтируйте папку в контейнере как том с -v

2) Если создание фляги является проблемой, не делайте этого! Подготовьте вызов java, который включает необходимый путь к классам и вызывает основной класс. Нет необходимости в банке.

Конечно, это для разработки, но функционально большой разницы быть не должно. Кроме того, есть ли веская причина для тестирования классов внутри контейнера docker? Если бы я сделал это, я бы разделил разработку классов Java и изображения Docker и использовал бы описанный вами рабочий процесс БЕЗ docker для проверки моего кода Java, и только когда я удовлетворен на проявку изображения.