Изображения контейнеров

Приложения Spring Boot можно контейнеризовать с помощью Dockerfiles или с помощью Cloud Native Buildpacks для создания оптимизированных совместимых с Docker контейнерных образов, которые можно запустить где угодно.

1. Эффективные образы контейнеров

Легко упаковать Spring Boot fat jar в образ Docker. Однако есть несколько недостатков копирования и запуска fat jar как есть в образе Docker. Всегда есть определенная накладная стоимость при запуске fat jar без распаковки, и в контейнерной среде это может быть заметно. Другая проблема заключается в том, что размещение кода приложения и всех его зависимостей в одном слое в образе Docker неэффективно. Поскольку вы, вероятно, чаще перекомпилируете свой код, чем обновляете используемую версию Spring Boot, часто лучше немного разделить вещи. Если вы поместите файлы jar в слой перед классами приложения, Docker часто будет изменять только самый нижний слой и сможет брать другие из кэша.

1.1. Слоение образов Docker

Для облегчения создания оптимизированных образов Docker Spring Boot поддерживает добавление файла индекса слоев в jar. Он предоставляет список слоев и части jar, которые должны быть в них содержатся. Список слоев в индексе упорядочен в соответствии с порядком добавления слоев в Docker/OCI образ. По умолчанию поддерживаются следующие слои:

dependencies (для обычных зависимостей)
spring-boot-loader (для всего, что находится в org/springframework/boot/loader)
snapshot-dependencies (для зависимостей snapshot)
application (для классов и ресурсов приложения)

Следующее демонстрирует пример файла layers.idx.

- "dependencies":
  - BOOT-INF/lib/library1.jar
  - BOOT-INF/lib/library2.jar
- "spring-boot-loader":
  - org/springframework/boot/loader/JarLauncher.class
  - org/springframework/boot/loader/jar/JarEntry.class
- "snapshot-dependencies":
  - BOOT-INF/lib/library3-SNAPSHOT.jar
- "application":
  - META-INF/MANIFEST.MF
  - BOOT-INF/classes/a/b/C.class

Это слоение предназначено для разделения кода на основе вероятности изменений между сборками приложения. Библиотечный код менее подвержен изменениям между сборками, поэтому он помещается в собственные слои для повторного использования инструментами из кэша. Код приложения более подвержен изменениям между сборками, поэтому он изолирован в отдельном слое.

Spring Boot также поддерживает слоение для файлов war с помощью layers.idx.

Для Maven см. раздел упаковки слоистых jar или war для получения дополнительных сведений о добавлении индекса слоев в архив. Для Gradle см. раздел упаковки слоистых jar или war в документации плагина Gradle.

2. Dockerfiles

Хотя можно преобразовать Spring Boot fat jar в образ Docker всего несколькими строками в Dockerfile, мы будем использовать функцию слоения для создания оптимизированного образа Docker. При создании jar, содержащего файл индекса слоев, spring-boot-jarmode-layertools jar будет добавлен в качестве зависимости к вашему jar. При наличии этого jar в классе пути вы можете запустить свое приложение в специальном режиме, который позволяет коду загрузки запускать что-то совершенно отличное от вашего приложения, например, что-то, что извлекает слои.

Режим layertools не может быть использован с полностью исполняемым архивом Spring Boot, который включает скрипт запуска. Отключите конфигурацию скрипта запуска при построении файла jar, предназначенного для использования с layertools .

Вот как вы можете запустить свой jar в режиме layertools jar:

$ java -Djarmode=layertools -jar my-app.jar

Это приведет к следующему выводу:

Usage:
  java -Djarmode=layertools -jar my-app.jar

Available commands:
  list     List layers from the jar that can be extracted
  extract  Extracts layers from the jar for image creation
  help     Help about any command

Команда extract может быть использована для легкого разделения приложения на слои, которые нужно добавить в Dockerfile. Вот пример Dockerfile, использующего jarmode.

FROM eclipse-temurin:17-jre as builder
WORKDIR application
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
RUN java -Djarmode=layertools -jar application.jar extract

FROM eclipse-temurin:17-jre
WORKDIR application
COPY --from=builder application/dependencies/ ./
COPY --from=builder application/spring-boot-loader/ ./
COPY --from=builder application/snapshot-dependencies/ ./
COPY --from=builder application/application/ ./
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]

Предполагая, что вышеуказанный Dockerfile находится в текущей директории, ваш образ Docker можно создать с помощью docker build ., или, по желанию, указав путь к файлу jar вашего приложения, как показано в следующем примере:

$ docker build --build-arg JAR_FILE=path/to/myapp.jar .

Это многоэтапный Dockerfile. Этап сборки извлекает каталоги, которые понадобятся позже. Каждая из команд COPY относится к слоям, извлеченным jarmode.

Конечно, Dockerfile можно написать без использования jarmode. Можно использовать комбинацию unzip и mv для перемещения вещей в нужный слой, но jarmode упрощает это.

3. Cloud Native Buildpacks

Dockerfiles — это всего лишь один способ создания образов Docker. Другой способ создания образов Docker — напрямую из плагина Maven или Gradle, используя buildpacks. Если вы когда-либо использовали платформу приложений, такую как Cloud Foundry или Heroku, то, вероятно, вы использовали buildpack. Buildpacks — это часть платформы, которая берет ваше приложение и преобразует его в то, что платформа может фактически запустить. Например, Java buildpack Cloud Foundry заметит, что вы отправляете файл .jar и автоматически добавит соответствующую JRE.

С помощью Cloud Native Buildpacks можно создавать совместимые с Docker образы, которые можно запускать в любом месте. Spring Boot включает в себя поддержку buildpack напрямую для Maven и Gradle. Это означает, что вы можете просто набрать одну команду и быстро получить разумный образ в локальном Docker демоне.

См. индивидуальную документацию плагина о том, как использовать buildpacks с Maven и Gradle.

Paketo Spring Boot buildpack поддерживает файл layers.idx, поэтому любые внесенные в него изменения будут отражены в созданном buildpack образе.

Для достижения воспроизводимых сборок и кэширования контейнерных образов Buildpacks могут изменять метаданные ресурсов приложения (например, информацию о "последнем изменении" файла). Вы должны убедиться, что ваше приложение не полагается на эти метаданные во время выполнения. Spring Boot может использовать эту информацию при предоставлении статических ресурсов, но это можно отключить с помощью spring.web.resources.cache.use-last-modified .

4. Что читать дальше

После того, как вы узнали, как создавать эффективные контейнерные образы, вы можете узнать о развертывании приложений на облачной платформе, такой как Kubernetes.