[P.....y]

#docker #java #spring #programowanie

Pomóżcie koledze,
chcę zrobić prostego Dockerfile który będzie uruchamiał mi moją aplikację w springu, jaki jest najlepszy sposób żeby uruchamiać JARke bez zawierania w Dockerfile numeru wersji? (żeby nie zmieniać wersji w Dockerfile za każdym razem)

[fiolkins]

@Piterowsky: Nie dać numeru wersji w nazwie pliku.

[P.....y]

@fiolkins: Tak, to bardzo dobra praktyka XD, poważne odpowiedzi proszę

[Bairei]

@Piterowsky: https://spring.io/guides/gs/spring-boot-docker/ to nie jest to, czego potrzebujesz?

[P.....y]

@Bairei: Dziękuję ci (｡◕‿‿◕｡) Nie wiedziałem że jest guide do dockera

[Bairei]

@Piterowsky: Akurat do springa to jest całkiem dużo materiałów, jeśli chodzi o stawianie aplikacji w kontenerze (również przy pomocy docker-compose, który jest znacznym udogodnieniem przy stawianiu powiązanych ze sobą kontenerów, np. aplikacja + baza danych), trzeba tylko wiedzieć, co chce się w google wyszukać

[P.....y]

@Bairei: Wpisywałem hasła typu "Dockerfile best practice to run jar with version in filename". Już pisząc te pytanie wiedziałem że nie znajdę tego czego szukam, dlatego napisałem na wykopie :P

[globalbus]

@Piterowsky: odnośnie wersji, w dockerze build powinien być reproducible. Czyli te same źródła mają zawsze generować ten sam binarny obraz. Jest mnóstwo softu, który łamie tą zasadę, np. dodając do binariów timestampy w domyślnej konfiguracji (xjc, mapstruct, itd).

[P.....y]

@globalbus Jeszcze numer wersji się wpisuje w tę zasadę ale faktycznie timestampy już nie. Nie wiedziałem że mapstruct dodaje timestampy do binów. Wiesz może w jakim celu?

[fiolkins]

@Piterowsky: To poważna odpowiedz. Wersja wynika z manifestu i z repo mavenowego a nie z wara/jara

[globalbus]

@Piterowsky: dunno, wyłączenie tego gówna tutaj
https://mapstruct.org/documentation/stable/reference/html/#configuration-options

[P.....y]

@globalbus z punktu widzenia dockera jest sens to wyłączać? Używamy mapstructa w projekcie ale bez dockera i chyba nie wyłączyliśmy tego (ale ręki sobie uciąć nie dam)

[globalbus]

@Piterowsky: zawsze warto wyłączyć. Timestampy i informacje związane ze środowiskiem kompilacji psują incremental builds, bo zmieniają checksumę binarek -> gradle widzi zmianę zależności i będzie kompilował zależne moduły od nowa. To jest rak z którym należy walczyć na wszelkie sposoby, jeśli tylko gdzieś się go wykryje.

[P.....y]

@globalbus aaa z tego powodu, no to ma sens. Dzięki za rozjaśnienie. Jesteś super (⌒(oo)⌒)

[globalbus]

@Piterowsky: i jeszcze
https://dzone.com/articles/reproducible-builds-in-java

[globalbus]

@Piterowsky: w dużej skali jest to cholernie ważne - duża aplikacja z setkami modułów. Poprzez sprawdzanie sum kontrolnych zależności mogę na tej podstawie automatycznie podbijać wersję artefaktów (jeśli zmienił się artefakt lub jego zależności). Gradle używa tego wewnętrznie do cacheowania tasków (suma kontrolna wejść to marker danych wyjścia).
Druga kwestia, jeśli rozsądnie podzieli się obraz dockerowy na warstwy, chroni to przed zasraniem repozytorium niepotrzebnymi warstwami przy każdym wydaniu wersji. Wydajemy