Comments 5
Основная причина — преемственность статьи из спрингового блога. Я специально не трогал базовый образ, чтобы не вводить новых сущностей.
В целом вопрос выбора базового образа вопрос отдельный, но статья больше про оптимизацию разницы между образами, как вы можете видеть из графика в последнем разделе — какой бы базовый образ не был, мы получаем очень мелкие диффы. Это конечно не отменяет необходимость первичной загрузки на сервера, но при условии что прилаг много и все они шарят базовый образ его загрузка будет выполнена один раз.
Если вы используете Gradle или Maven, как альтернативу можно использовать jib плагин (https://github.com/GoogleContainerTools/jib), он упаковывает приложения по слоями как у вас описано
Когда изучали проблему невоспроизводимости на билд агентах, эта версия рассматривалась и даже некоторое время после исправления настоящей проблемы использовали строчку find . -exec touch -t 200001010101 {} \; на распакованных файлах, но позже выяснили что она ничего не улучшает (по крайней мере на тех сценариях что у нас есть).
Jib наверное стоит действительно посмотреть, выглядит интересно. Спасибо за наводку.
Целью оптимизации является сокращение разницы между получаемыми образами от сборки к сборке
Дело как раз в дополнительных модулях: они являются источниками постоянных изменений для слоя, даже если вы не вносите в код модуля никаких правок
На правах рекламы: попробуйте сборку werf-ом (https://github.com/flant/werf), в ней можно указать зависимость сборки от изменений в файлах в git. Поменялись исходники модуля — будет собираться, не поменялись, возьмётся из кэша. Была статья про сборку именно Java приложений https://habr.com/ru/company/flant/blog/348436/. Это ещё старая версия программы (dapp), но идеи почерпнуть можно.
Еще один способ оптимизации docker-образов для Java приложений