для локальной разработки достаточно и кэширования слоёв; да и путь выглядит так, что под виндой ожидаем проблемы. в случае клауд билда - кэш всё равно пустой.
пару лет назад столкнулся с периодическими ошибками сборки проектов в Google Cloud Build. В основе лежит вызов контейнеров, поэтому вместо ванильного maven:3-eclipse-temurin-17-alpine стал использовать образ с закешированными зависимостями (требует пересборки при значительных изменениях зависимостей): RUN mvn dependency:go-offline
связка maven-dependency-plugin + maven-jar-plugin с соответствующей конфигурацией подготавливает приложения для запуски и не зависит от версий/фич/багов spring-boot-maven-plugin
так и было задумано. при конфигурации версия зависимостей фиксируется на мажорной-минорной версии. простая пересборка контейнера подтянет новую патч версию при наличии
базой должно быть понимание того, что благодаря CRI в K8S Docker не является рантаймом по умолчанию, и большинство упомянутых уязвимостей не будет актуально при использовании другого рантайма
примечательно, что в категориях "Постоянное улучшение продукта" и "Программы, основанные на социальной значимости" примеров компаний нет. Что лишний раз подчёркивает, что бизнес должен зарабатывать деньги, а не заниматься благотворительностью. Лично для себя выбираю упомянутую "осознанность" - надеюсь, это как-нибудь повлияет на тенденции
стоит упомянуть ограничения 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
так и было задумано. при конфигурации версия зависимостей фиксируется на мажорной-минорной версии. простая пересборка контейнера подтянет новую патч версию при наличии
можно использовать Multi-stage сборку. Образ билдера:
ARG PYTHON_VERSION=3.13FROM python:${PYTHON_VERSION}-alpineENV PIP_DEFAULT_TIMEOUT=100PIP_DISABLE_PIP_VERSION_CHECK=1
PIP_NO_CACHE_DIR=1
POETRY_VERSION=2.1.1
PYTHONUNBUFFERED=1
ENV PATH="/root/.local/bin:${PATH}"RUN apk add --no-cache gcc alpine-sdk linux-headers &&wget https://install.python-poetry.org -O - | python3 - &&
poetry self add poetry-plugin-bundle
Образ приложения:
ARG PYTHON_VERSION=3.13FROM python-poetry-builder:python${PYTHON_VERSION} AS builderWORKDIR /usr/src/appCOPY pyproject.toml ./COPY src/. ./src
RUN poetry lock &&
poetry bundle venv --only=main /venv -vvv
FROM python:${PYTHON_VERSION}-alpineCOPY --from=builder /venv /venv
ENTRYPOINT ["/venv/bin/app"]много интересного нашёл на https://studio.code.org/
может проблема в задачах?
базой должно быть понимание того, что благодаря CRI в K8S Docker не является рантаймом по умолчанию, и большинство упомянутых уязвимостей не будет актуально при использовании другого рантайма
DevOps из вас так себе
примечательно, что в категориях "Постоянное улучшение продукта" и "Программы, основанные на социальной значимости" примеров компаний нет. Что лишний раз подчёркивает, что бизнес должен зарабатывать деньги, а не заниматься благотворительностью.
Лично для себя выбираю упомянутую "осознанность" - надеюсь, это как-нибудь повлияет на тенденции