Развертывание
Тема дорожной карты · Spring Boot
Развёртывание Spring Boot — это процесс упаковки, распространения и запуска Spring Boot-приложения в целевой среде: от простого автономного JAR на физическом сервере до контейнеризированной нагрузки в Kubernetes. Стандартный артефакт развёртывания — исполняемый «fat JAR», создаваемый командой ./mvnw package или ./gradlew bootJar, который включает встроенный сервер Tomcat (или Undertow/Jetty) и все зависимости, требуя лишь java -jar app.jar для запуска. Для контейнеризированного развёртывания Dockerfile обычно использует многоэтапную сборку: JDK-образ для компиляции и сборки, затем компактный JRE-образ (например, eclipse-temurin:21-jre) для запуска приложения, что значительно уменьшает размер итогового образа. Spring Boot также поддерживает cloud-native buildpacks через ./mvnw spring-boot:build-image, создавая OCI-совместимый Docker-образ без написания Dockerfile вручную. В развёртывании Spring Boot в Kubernetes liveness- и readiness-пробы указывают на эндпоинты /actuator/health/liveness и /actuator/health/readiness, предоставляемые Spring Boot Actuator, а корректное завершение включается через server.shutdown=graceful для обработки сигналов завершения Kubernetes.
Как это работает
Развертывание: Docker-образы через Spring Boot bootBuildImage (Cloud Native Buildpacks — layered, secure, маленькие образы) или hand-written Dockerfile. GraalVM native image (./gradlew nativeCompile) — static binary с sub-100ms startup + меньше памяти, отлично для serverless, дорого по build time + framework support. Graceful shutdown (server.shutdown=graceful) даёт in-flight запросам завершиться на SIGTERM. Production-ready config: тюньте JVM, выставьте heap, включите Actuator, log JSON, конфигурируйте connection pools (HikariCP дефолты обычно ок).
Когда применять
Buildpacks для большинства случаев — layered cache, security patches, без Dockerfile в поддержке. Native image — для serverless или fast-start workloads; верифицируйте что все зависимости поддерживают. Всегда graceful shutdown в K8s деплоях — abrupt termination дропает in-flight запросы. Memory limits + JVM tuning явно (не полагайтесь на auto-detect в контейнерах).
Типичные ошибки
Ловушки Развертывание: деплой fat jar без health checks (K8s не может безопасно роутить трафик); 1GB+ Docker-образы со build artefacts (Buildpacks или multi-stage builds); нет graceful shutdown (rolling deploy дропает пользовательские запросы); JVM heap не выставлен, OOMKilled по K8s memory limit.