Konteneryzacja aplikacji na obrazie JDK17

Siema
Uczę się Dockera i patrzyłem po necie jak skoneteneryzować podstawową apkę Spring Boot

Widziałem dwa główne podejścia:

1. Odpalenie builda Mavena
   Np.:

FROM eclipse-temurin:17-jdk-focal
 
WORKDIR /app
 
COPY .mvn/ .mvn
COPY mvnw pom.xml ./
RUN ./mvnw dependency:go-offline
 
COPY src ./src
 
CMD ["./mvnw", "spring-boot:run"]

2. Zbudowanie pliku JAR lokalnie i skopiowanie do obrazu
   Np.:

FROM amazoncorretto:11-alpine-jdk
MAINTAINER baeldung.com
COPY target/docker-message-server-1.0.0.jar message-server-1.0.0.jar
ENTRYPOINT ["java","-jar","/message-server-1.0.0.jar"]

Którego powinno się używać?

A i jeszcze pytanie - czy to normalne że przy użyciu mvnw dependency:go-offline w Dockerfile (podejście 1) najpierw instaluje to wszystko przy budowaniu obrazu, ale potem i tak pobiera jeszcze jakieś pojedyncze pomy i jary po odpaleniu kontenera?

dziwne jakieś to pierwsze podejście. Nie widziałem nigdy czegoś takiego

Nie użyłbym żadnego z powyższych. Raczej:

1. multi stage build, żeby zbudować *. jar
2. entry point w oparciu o serwisy (np. dumb-init)

Pierwsze jest o tyle bez sensu, że masz uruchomieniowy obraz w którym są wszystkie zależności potrzebne do zbudowania apki - całkiem niepotrzebnie bo lepiej mieć minimalny możliwy obraz. Unikasz ewentualnych podatności w modułach których nie używasz w runtime.

Cyckoben napisał(a):

A i jeszcze pytanie - czy to normalne że przy użyciu mvnw dependency:go-offline w Dockerfile (podejście 1) najpierw instaluje to wszystko przy budowaniu obrazu, ale potem i tak pobiera jeszcze jakieś pojedyncze pomy i jary po odpaleniu kontenera?

Tak na szybko: dependency:go-offline ma excludeReactor ustawione na true - więc pewnie to jest sprawcą.

To pierwsze podejście jest bardzo dziwne. Może ktoś, miał jakiś konkretny powód, żeby je zastosować, ale nie przychodzi mi do głowy jaki. Masz w kontenerze narzędzia do budowania i kod źródłowy, co samo w sobie niesie pewne ryzyko.
W dodatku możliwe jest, że za każdym buildem kontenera, otrzymasz inny artefakt.

Najlepsze podejście jest takie:

Dodajesz do MVN plugin do generowania obrazu Dockera. Wywołujesz target mvn który wypluje obraz dockerowy.

Ja teraz na Gradle siedzę więc nie mam gotowca, ale tutaj jest jakiś przykład: https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin

0xmarcin napisał(a):

Najlepsze podejście jest takie:

Dodajesz do MVN plugin do generowania obrazu Dockera. Wywołujesz target mvn który wypluje obraz dockerowy.

Ja teraz na Gradle siedzę więc nie mam gotowca, ale tutaj jest jakiś przykład: https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin

JIB plugin jest spoko. Domyślnie kompilaty wrzuca do obrazu a przy starcia kontenera jest wołane java -cp .... JIB ma bardzo fajną rzecz, akurat u mnie się to przydało, że na maszynce, która buduje nie potrzeba mieć Dockera. Słyszałem też, że build plugin od Spring Boota całkiem spoko sobie radzi. Tutaj linkuje fajny artykuł, gdzie pokazane jest jak można ręcznie budować, trochę o Jarze i że ma warstwy , niżej jest kilka użyć pluginów.