.dockerignore влияет на контекст, передаваемый во время билда. а вот команды вида COPY ./ ./ уже тянут в контейнер всё подряд.
Multi-stage build нужно применять с умом: некоторые CI/CD поддерживают кэширование зависимостей (Bitbucket), подтягивают результаты билдов, например результаты юнит тестов. да и в целом внутри докера работает медленнее.
Что касается сборки Python приложений, то на примере с Poetry компактный образ можно получить так:
для локальной разработки достаточно и кэширования слоёв; да и путь выглядит так, что под виндой ожидаем проблемы. в случае клауд билда - кэш всё равно пустой.
пару лет назад столкнулся с периодическими ошибками сборки проектов в Google Cloud Build. В основе лежит вызов контейнеров, поэтому вместо ванильного maven:3-eclipse-temurin-17-alpine стал использовать образ с закешированными зависимостями (требует пересборки при значительных изменениях зависимостей): RUN mvn dependency:go-offline
связка maven-dependency-plugin + maven-jar-plugin с соответствующей конфигурацией подготавливает приложения для запуски и не зависит от версий/фич/багов spring-boot-maven-plugin
так и было задумано. при конфигурации версия зависимостей фиксируется на мажорной-минорной версии. простая пересборка контейнера подтянет новую патч версию при наличии
.dockerignoreвлияет на контекст, передаваемый во время билда. а вот команды видаCOPY ./ ./уже тянут в контейнер всё подряд.Multi-stage build нужно применять с умом: некоторые CI/CD поддерживают кэширование зависимостей (Bitbucket), подтягивают результаты билдов, например результаты юнит тестов. да и в целом внутри докера работает медленнее.
Что касается сборки Python приложений, то на примере с Poetry компактный образ можно получить так:
Poetry билдер
приложение
10
насколько данные рекомендации подойдут для случая cloud sql proxy, когда соединение происходит по сути локалько к sidecar контейнеру?
не Spring’ом единым жив мир Java разработки. но если есть опыт использования, то нескоторые шаги могут упростить разработку и улучшить показатели:
упрощение управления версиями зависимостей
подготовка thin jar без spring-boot-maven-plugin
запуск через
java -jar app.jarисключение неиспользуемых зависимостей
если REST сервис отдаёт MediaType.TEXT_PLAIN_VALUE, то Jackson можно исключить
Ещё один небольшой плюс для производительности связан с размером uber-jar, который вы собираете.скорость запуска увеличится, если перейти к thin jar без оспользования
spring-boot-maven-pluginVolumeSource: OCI Artifact and/or Image: в статусе беты был включён по умолчанию в 1.35. было бы удобно видеть статус по умолчанию для новых фич
стоит упомянуть ограничения AoT :
The classpath is fixed and fully defined at build time
The beans defined in your application cannot change at runtime, meaning:
The Spring
@Profileannotation and profile-specific configuration have limitations.Properties that change if a bean is created are not supported (for example,
@ConditionalOnPropertyand.enabledproperties).deprecation notice на докер хабе висит очень давно. странно, что кто-то ещё ими пользуется
для экранирования
для локальной разработки достаточно и кэширования слоёв; да и путь выглядит так, что под виндой ожидаем проблемы. в случае клауд билда - кэш всё равно пустой.
wget https://repo1.maven.org/maven2/[...].jar && [...]
если уже используется PostgreSQL - логично использовать расширение pg_partman
программисту только дай повод написать очередной велосипед. используйте cron - и руки не будут уставаить писать
развитие собственного велосипеда конечно хорошо, но удивляет игнорирование сущемтвующей спеки Jakarta JAX-RS
разрешение "terraform apply" только из мейна (ну и в дев окружении)
пару лет назад столкнулся с периодическими ошибками сборки проектов в Google Cloud Build. В основе лежит вызов контейнеров, поэтому вместо ванильного maven:3-eclipse-temurin-17-alpine стал использовать образ с закешированными зависимостями (требует пересборки при значительных изменениях зависимостей):
RUN mvn dependency:go-offlineв контейнерах часто отсутствует bash, поэтому лучше по возможности делать скрипты на sh
С помощью maven-jar-plugin зависимости добавляются в манифест, отлично сочетается с maven-dependency-plugin:copy-dependencies
связка maven-dependency-plugin + maven-jar-plugin с соответствующей конфигурацией подготавливает приложения для запуски и не зависит от версий/фич/багов spring-boot-maven-plugin
так и было задумано. при конфигурации версия зависимостей фиксируется на мажорной-минорной версии. простая пересборка контейнера подтянет новую патч версию при наличии