Създаване на оптимизирани Docker образи за Spring Boot приложение

Контейнерите станаха предпочитано средство за опаковане на приложения с всички софтуерни зависимости и операционна система и след това се доставят в различни среди.

В тази статия се разглеждат различни методи за контейнеризиране на Spring Boot приложения:

• създаване на Docker образ чрез Docker файл,
• създаване на OCI образ от изходен код с помощта на Cloud-Native Buildpack,
• и оптимизиране на изображението по време на изпълнението чрез разделяне на части от JAR на различни нива с многослойни инструменти.

 Примерен код

Тази статия е придружена от пример за работен код в GitHub .

Терминология на контейнерите

Започваме с терминологията на контейнерите, използвана в статията:

• Образ на контейнер (Container image): файл с определен формат. Превръщаме приложението си в образ на контейнер, като стартираме инструмента за изграждане.
• Контейнерът: изпълним екземпляр на образа на контейнера.
• Двигател на контейнера (Container engine): демон процес, отговорен за стартирането на контейнера.
• Хост на контейнера (Container host): хост компютър, на който работи механизмът на контейнера.
• Регистър на контейнери (Container registry): общо местоположение, използвано за публикуване и разпространение на образа на контейнера.
• Стандарт OCI: Open Container Initiative (OCI) — това е лека отворена структура за управление, формирана в рамките на Linux Foundation. Спецификацията на образите OCI определя индустриални стандарти за формати на изображения на контейнери и среда за изпълнение, за да гарантира, че всички механизми на контейнери могат да стартират образи на контейнери, създадени с всякакъв инструмент за изграждане.

За да поставим приложението в контейнер, опаковаме приложението в образ на контейнер и публикуваме този образ в общ регистър. Средата за изпълнение на контейнера извлича този образ от регистъра, разопакова го и стартира приложението в него.

Версия 2.3 на Spring Boot предлага плъгини за създаване на OCI образи.

Docker — най-често използваната имплементация на контейнера, и ние използваме Docker в нашите примери, така че всички последващи препратки към контейнер в тази статия ще се отнасят за Docker.

Създаване на образ на контейнер по традиционния начин

Създаването на Docker образи за приложения Spring Boot е много лесно, като добавим няколко инструкции в Docker файла.

Първо създаваме изпълним файл JAR и, като част от инструкциите на Docker файла, копираме изпълнимия файл JAR върху базовия образ JRE след прилагането на необходимите настройки.

Нека създадем нашето Spring приложение на Spring Initializr с зависимости web, lombokи actuator. Добавяме също REST контролер, за да предоставим API с ИЗИСКВАНЕметод.

Създаване на Docker файл

След това поставяме това приложение в контейнер, добавяйки Dockerfile:

FROM adoptopenjdk:11-jre-hotspot
ARG JAR_FILE=targetonts/**/*.jar
COPY ${JAR_FILE} application.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","/application.jar"]

Нашият Docker файл съдържа базов образ, от adoptopenjdk, върху който копираме нашия JAR файл, и след това отваряме порт, 8080който ще прослушва заявки.

Сглобяване на приложението

Първо трябва да създадем приложението с помощта на Maven или Gradle. Тук използваме Maven:

mvn clean package

Това създава изпълним JAR файл на приложението. Трябва да преобразуваме този изпълним JAR в Docker образ за работа в Docker двигателя.

Създаване на образ на контейнер

След това поставяме този изпълним файл JAR в Docker образ, изпълнявайки команда docker buildот кореновата директория на проекта, съдържаща предварително създадения Docker файл:

docker build  -t usersignup:v1 .

Можем да видим нашето изображение в списъка с помощта на командата:

docker images 

Резултатът от изпълнението на гореспоменатата команда включва нашия образ usersignupзаедно с базовия образ, adoptopenjdk, посочен в нашия Docker файл.

REPOSITORY          TAG                 SIZE
usersignup          v1                  249MB
adoptopenjdk        11-jre-hotspot      229MB

Преглед на слоевете в контейнерния образ

Нека да видим наслояването на слоевете в образа. Ще използваме инструментът  dive, за да прегледаме тези слоеве:

dive usersignup:v1

Ето част от резултатите от изпълнението на команди Dive: 

Както виждаме, приложният слой съставлява значителна част от размера на изображението. Искаме да намалим размера на този слой в следващите секции в хода на нашата оптимизация.

Създаване на образ на контейнер с помощта на Buildpack

Сглобявания (Buildpacks) - това е общ термин, използван от различни предложения „Платформа като услуга“ (PAAS) за създаване на образ на контейнер от изходен код. Той е създаден от Heroku през 2011 г. и оттогава е приет от Cloud Foundry, Google App Engine, Gitlab, Knative и някои други.

Предимството на облачните Buildpacks

Едно от основните предимства на използването на Buildpack за създаване на образи е, че Управлението на конфигурацията на изображението може да бъде централизирано (builder) и разпределено на всички приложения, използващи builder.

Сборните пакети бяха тясно свързани с платформата. Cloud-Native Buildpacks осигуряват стандартизация между платформите, поддържайки OCI формат на изображението, който гарантира, че изображението може да бъде стартирано от Docker двигателя.

Използване на плагина Spring Boot

Плагинът Spring Boot създава OCI изображения от изходния код с помощта на Buildpack. Изображенията се създават с помощта на bootBuildImageзадачи (Gradle) или spring-boot:build-imageцели (Maven) и локална инсталация на Docker.

Можем да конфигурираме името на изображението, необходимо за изпращане в Docker регистъра, като посочим името в image tag:

org.springframework.boot
  spring-boot-maven-plugin
  
    
      docker.io/pratikdas/${project.artifactId}:v1

Нека да използваме Maven, за да изпълним build-imageцелта за изграждане на приложението и създаване на контейнерно изображение. В момента не използваме никакви Docker файлове.

mvn spring-boot:build-image

Резултатът ще изглежда приблизително така:

[INFO] --- spring-boot-maven-plugin:2.3.3.RELEASE:build-image (default-cli) @ usersignup ---
[INFO] Изграждане на изображение 'docker.io/pratikdas/usersignup:v1'
[INFO] 
[INFO]  > Изтегляне на изображение builder 'gcr.io/paketo-buildpacks/builder:base-platform-api-0.3' 0%
.
.
.. [creator]     Добавяне на етикет 'org.springframework.boot.version'
.. [creator]     *** Изображения (c311fe74ec73):
.. [creator]           docker.io/pratikdas/usersignup:v1
[INFO] 
[INFO] Успешно изградено изображение 'docker.io/pratikdas/usersignup:v1'

От изходните данни виждаме, че paketo Cloud-Native buildpackсе използва за създаване на работещо изображение OCI. Както и преди, можем да видим изображението, определено като Docker изображение, като изпълним командата:

docker images 

Извод:

REPOSITORY                             SIZE
paketobuildpacks/run                  84.3MB
gcr.io/paketo-buildpacks/builder      652MB
pratikdas/usersignup                  257MB

Създаване на контейнерно изображение с Jib

Jib е плагин за изграждане на изображения от Google, който предоставя алтернативен метод за създаване на контейнерно изображение от изходния код.

Настройваме jib-maven-pluginв pom.xml:

      com.google.cloud.tools
        jib-maven-plugin
        2.5.2

След това стартираме плагина Jib с помощта на командата Maven, за да изградим приложението и създадем контейнерно изображение. Както и преди, тук не използваме никакви Docker файлове:

mvn compile jib:build -Dimage=/usersignup:v1

След изпълнението на горната команда Maven получаваме следния изход:

[INFO] Контейнеризация приложения в pratikdas/usersignup:v1...
.
.
[INFO] Точка входа контейнера установлена на [java, -cp, /app/resources:/app/classes:/app/libs/*, io.pratik.users.UsersignupApplication]
[INFO] 
[INFO] Образ построен и загружен как pratikdas/usersignup:v1
[INFO] Выполнение задач:
[INFO] [==============================] 100.0% завершено

Изходните данни показват, че образът на контейнера е създаден и поставен в регистъра.

Мотивации и методи за оптимизация на изображения

Имаме две основни причини за оптимизация:

• Производителност: в системата за оркестрация на контейнери, образът на контейнера се извлича от регистъра на хоста, на който е стартиран механизма на контейнера. Този процес се нарича планиране. Извличането на големи образи от регистъра води до дълго време за планиране в системите за оркестрация на контейнери и дълго време за изграждане в CI конвейерите.
• Сигурност: големите изображения също предлагат голямо поле за уязвимости.

Образът на Docker се състои от стек от слоеве, всеки от които представлява инструкция в нашия Dockerfile. Всеки слой представлява делта на промените от долния слой. Когато извличаме образа на Docker от регистъра, той се извлича на слоеве и кешира на хоста.

Spring Boot използва „дебел JAR“ в като формат за опаковане по подразбиране. Когато разглеждаме дебелия JAR, виждаме, че приложението е много малка част от целия JAR. Това е частта, която се променя най-често. Останалата част съдържа зависимости от Spring Framework.

Формулата за оптимизация е съсредоточена около изолацията на приложението на отделно ниво от зависимостите на Spring Framework.

Слоят на зависимостите, който образува основната част от дебелия JAR файл, се зарежда само веднъж и се кешира в хост системата.

Само тънкият слой на приложението се извлича по време на актуализации на приложението и планиране на контейнери, както е показано на тази диаграма:

В следващите раздели ще разгледаме как да създадем тези оптимизирани образи за приложението Spring Boot.

Създаване на оптимизиран образ на контейнер за приложението Spring Boot с помощта на Buildpack

Spring Boot 2.3 поддържа многостепенност, извличайки части от дебелия JAR файл в отделни слоеве. Функцията за наслояване по подразбиране е деактивирана и трябва да бъде явно активирана с помощта на Spring Boot Maven плагин:

org.springframework.boot
  spring-boot-maven-plugin
  
    
      true

Ние ще използваме тази конфигурация, за да създадем нашия контейнерен образ първо с помощта на Buildpack, а след това и с Docker в следващите секции.

Нека стартираме build-imageMaven цел за създаване на контейнерен образ:

mvn spring-boot:build-image

Ако стартираме Dive, за да видим слоевете в полученото изображение, ще видим, че слойът на приложението (обозначен с червено) е значително по-малък в диапазона килобайти в сравнение с това, което получихме, използвайки дебелия формат JAR:

Създаване на оптимизиран контейнерен образ за приложение Spring Boot с помощта на Docker

Вместо да използваме Maven или Gradle плъгин, ние също можем да създадем многоуровнев JAR Docker образ с Dockerfile.

Когато използваме Docker, трябва да изпълним две допълнителни стъпки за извличане на слоевете и копирането им в окончателния образ.

Съдържанието на полученото JAR след компилиране с Maven с включена функция наслоения ще изглежда по следния начин:

META-INF/
.
BOOT-INF/lib/
.
BOOT-INF/lib/spring-boot-jarmode-layertools-2.3.3.RELEASE.jar
BOOT-INF/classpath.idx
BOOT-INF/layers.idx

В изходните данни се показва допълнителен JAR с името spring-boot-jarmode-layertoolsи layersfle.idxфайл. Този допълнителен JAR файл предоставя възможност за многоуровнево обработване, както е описано в следващата секция.

Извличане на зависимости на отделни слоеве

За да прегледаме и извлечем слоевете от нашия многоуровнев JAR, използваме системното свойство -Djarmode=layertoolsза стартиране на spring-boot-jarmode-layertoolsJAR вместо приложението:

java -Djarmode=layertools -jar target/usersignup-0.0.1-SNAPSHOT.jar

Изпълнението на тази команда дава изход, съдържащ наличните опции на командния ред:

Usage:
  java -Djarmode=layertools -jar usersignup-0.0.1-SNAPSHOT.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и helpс helpда бъде по подразбиране. Нека стартираме командата с списъкопцията:

java -Djarmode=layertools -jar target/usersignup-0.0.1-SNAPSHOT.jar list

dependencies
spring-boot-loader
snapshot-dependencies
application

Виждаме списък с зависимости, които могат да се добавят като слоеве.

Слоеве по подразбиране:

Име на слой

Съдържание

dependencies

всяка зависимост, чиято версия не съдържа SNAPSHOT

spring-boot-loader

Класове на JAR зареждача

snapshot-dependencies

всяка зависимост, чиято версия съдържа SNAPSHOT

application

класове на приложения и ресурси

Слоевете са определени в layers.idxфайла в реда, в който трябва да бъдат добавени в образа Docker. Тези слоеве се кешират на хоста след първоначалното извличане, тъй като не се променят. На хоста се зарежда само актуализираният слой на приложението, което се случва по-бързо поради намаления размер. .

Създаване на образ с зависимости, извлечени в отделни слоеве.

Ще изградим финалния образ на два етапа, използвайки метод, наречен многоетапно изграждане. . В първия етап ще извлечем зависимостите, а на втория ще копираме извлечените зависимости в окончателния образ.

Нека модифицираме нашия Docker файл за многоетапно изграждане:

# the first stage of our build will extract the layers
FROM adoptopenjdk:14-jre-hotspot as builder
WORKDIR application
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
RUN java -Djarmode=layertools -jar application.jar extract

# the second stage of our build will copy the extracted layers
FROM adoptopenjdk:14-jre-hotspot
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"]

Запазваме тази конфигурация в отделен файл — Dockerfile2.

Създаваме Docker образ с командата:

docker build -f Dockerfile2 -t usersignup:v1 .

След изпълнението на тази команда получаваме следния изход:

Изпращане на контекста на изграждане към Docker демон  20.41MB
Стъпка 1/12 : ОТ adoptopenjdk:14-jre-hotspot като builder
14-jre-hotspot: Изтегляне от библиотеката/adoptopenjdk
.
.
Успешно изградена a9ebf6970841
Успешно етикетирана userssignup:v1

Виждаме, че образът Docker се създава с идентификатор на изображението, а след това се етикетира.

Накрая стартираме командата Dive, както преди, за да проверим слоевете в генерирания образ Docker. Можем да укажем идентификатора на изображението или етикета като входни данни за командата Dive:

dive userssignup:v1

Както се вижда от изходните данни, слойът, съдържащ приложението, сега заема само 11 КБ, а зависимостите са кеширани в отделни слоеве. 

Извличане на вътрешни зависимости в отделни слоеве.

Можем допълнително да намалим размера на слоя на приложението, извличайки част от нашите потребителски зависимости в отделен слой вместо да ги опаковаме заедно с приложението, като ги обявим в ymlподобен файл с име layers.idx:

- "dependencies":
  - "BOOT-INF/lib/"
- "spring-boot-loader":
  - "org/"
- "snapshot-dependencies":
- "custom-dependencies":
  - "io/myorg/"
- "application":
  - "BOOT-INF/classes/"
  - "BOOT-INF/classpath.idx"
  - "BOOT-INF/layers.idx"
  - "META-INF/"

В този файл layers.idxдобавихме настраиваема зависимост с име, io.myorgсъдържаща зависимости от организацията, получени от общ репозиторий.

Извод

В тази статия разгледахме използването на Cloud-Native Buildpacks за създаване на контейнерен образ директно от изходния код. Това е алтернатива на използването на Docker за създаване на контейнерен образ по обикновения начин: първо се създава голям изпълним файл JAR, а след това се пакетира в контейнерен образ, като се задават инструкции в Docker файла.

Също така разгледахме оптимизацията на нашия контейнер, включвайки функция за наслояване, която извлича зависимости в отделни слоеве, които се кешират на хоста, а тънкият слой на приложението се зарежда по време на планирането в механизмите за изпълнение на контейнера.

Можете да намерите целия изходен код, използван в статията на Github .

Справочник на командите

Ето кратко резюме на командите, които използвахме в тази статия за бързо запознаване.

Почистване на контекста:

docker system prune -a

Създаване на контейнерен образ с помощта на Docker файл:

docker build -f  -t  .

Сглобяване на контейнерен образ от изходния код (без Dockerfile):

mvn spring-boot:build-image

Преглед на слоевете на зависимостите. Преди да съберете JAR файла на приложението, уверете се, че функцията за наслояване е включена в spring-boot-maven-plugin:

java -Djarmode=layertools -jar application.jar list

Извличане на слоевете на зависимостите. Преди да съберете JAR файла на приложението, уверете се, че функцията за наслояване е включена в spring-boot-maven-plugin:

 java -Djarmode=layertools -jar application.jar extract

Преглед на списъка с контейнерни изображения

docker images

Преглед на слоевете в контейнерния образ (уверете се, че инструментът за потапяне е инсталиран):

dive

Източник: habr.com