Этап 8 - Docker для Spring Boot разработчиков

Для Spring Boot разработчика Docker полезен тогда, когда делает application, database и tests повторяемыми. Главный artifact обычно executable JAR, собранный Maven или Gradle.

От JAR к container

Самый простой путь containerization: собрать JAR, скопировать его в Java runtime image и запустить java -jar. Это легко понять и подходит для первого production-like image.

mvn package
copy JAR into runtime image
run app with Compose database
run Testcontainers integration tests

Почему важны layered JARs

Optimization начинается, когда builds становятся медленными. Spring Boot layered JARs разделяют dependencies, loader, snapshot dependencies и application classes. Docker может переиспользовать dependency layers, когда меняется только controller или service code.

Тесты с реальной database

Testcontainers переносит ту же идею в integration tests. Вместо mock PostgreSQL behavior test запускает реальный PostgreSQL container. Repository tests выполняются на настоящем database engine с реальным SQL behavior.

Что должно быть в image

Spring Boot runtime image должен содержать Java runtime и application artifact. Он не должен содержать весь local Gradle cache, IDE files, test reports или developer credentials. Multi-stage builds помогают отделить build tools от runtime files.

Самый простой image может напрямую копировать JAR. Более продвинутый image может извлекать layers из Spring Boot JAR, чтобы dependencies и application code кешировались отдельно. Правильный выбор зависит от размера проекта и требований к CI speed.

Новичку лучше начать просто. Сначала соберите корректный image, затем оптимизируйте после того, как можете объяснить, что именно изменилось.

Compose как local infrastructure

Большинство Spring Boot services бесполезны сами по себе. Им нужна database, иногда Redis, иногда Kafka, иногда migration tool. Compose позволяет описать эту local infrastructure рядом с application.

Важная часть — connection configuration. Внутри Compose database host обычно service name, а не localhost. JDBC URLs должны отражать это: jdbc:postgresql://db:5432/app внутри Compose network.

Это готовит разработчиков к реальному deployment thinking: application configuration должна быть externalized, repeatable и visible.

Где выполняется Spring Boot workflow

Docker workflow для Spring Boot имеет два разных места: Java build environment и Docker runtime environment. Maven или Gradle создает JAR из source code. Docker затем упаковывает этот JAR в image и запускает его как container.

Локально оба шага могут выполняться на ноутбуке. В CI оба шага могут выполняться на CI runner. В production server обычно должен пропускать build step и только скачивать image, который создал CI. Это разделение делает production предсказуемее.

Testcontainers тоже требует Docker environment. Когда tests запускаются локально, Testcontainers общается с local Docker. Когда tests запускаются в CI, он общается с Docker, доступным в CI environment. Если Docker там недоступен, такие integration tests не смогут стартовать containers.

Команды: запустить и проверить

Выполняйте эти commands в terminal той машины, где установлен Docker. Для локального обучения это terminal на вашем ноутбуке. Для VPS сначала подключитесь к server по SSH, затем запускайте commands там. Не вставляйте commands вслепую: запустите одну command, посмотрите, что изменилось, затем переходите к следующей.

./mvnw clean package
docker build -t spring-api:dev .
docker compose up -d db api
./mvnw test

Таблица для ориентира

Checklist Spring Boot container

Полезный Spring Boot image отвечает на четыре вопроса: какой JDK или JRE используется, откуда берется JAR, какой port слушает app и как передаются database settings. Если ответы скрыты, image будет трудно эксплуатировать.

Для tests используйте Testcontainers, когда behavior зависит от реальной external system. Mocking подходит для service logic, но database mappings, SQL constraints и transaction behavior рано или поздно требуют real database.

Контрольная точка

Идите дальше, когда можете описать путь от Maven или Gradle build к Docker image, затем к Compose environment и integration test.

Практика: Spring Boot image

Соберите Spring Boot JAR, затем дважды соберите Docker image. Сначала измените только сообщение в controller. Потом измените dependency version. Сравните, какие build steps переиспользуются. Вывод: image optimization — не абстрактная performance-тема; она напрямую влияет на скорость проверки небольших code changes в development и CI.

Короткий вывод

Главный ориентир для Spring Boot: Docker image должен запускать уже собранный application artifact, а не превращаться в неявную замену всей build system. Чем яснее путь от JAR к container, тем проще CI и local debugging.