Изграждане на оптимизирани изображения на Docker за приложение за пролетно зареждане

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

Тази статия обхваща различни начини за контейнеризиране на приложение Spring Boot:

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

 Примерен код

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

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

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

• Изображение на контейнер: файл със специфичен формат. Преобразуваме нашето приложение в изображение на контейнер, като стартираме инструмента за изграждане.
• контейнер: Изпълним екземпляр на изображението на контейнера.
• Контейнер двигател: Процесът на демон, отговорен за стартирането на контейнера.
• Контейнер хост: Хост машината, на която работи контейнерният двигател.
• Регистър на контейнери: Общото местоположение, използвано за публикуване и разпространение на изображението на контейнера.
• OCI стандарт: Инициатива за отворени контейнери (OCI) е лека рамка за управление с отворен код, създадена от Linux Foundation. Спецификацията на изображения на OCI определя индустриални стандарти за формати на изображения на контейнери и време за изпълнение, за да гарантира, че всички двигатели на контейнери могат да изпълняват изображения на контейнери, създадени от всеки инструмент за изграждане.

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

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

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

Изграждане на изображение на контейнер по традиционния начин

Изграждането на Docker изображения за Spring Boot приложения е много лесно чрез добавяне на няколко инструкции към вашия Dockerfile.

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

Нека създадем нашето приложение Spring на Пролетно инициализиране със зависимости web, lombokи actuator. Ние също така добавяме контролер за почивка, за да предоставим API GETметод.

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

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

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

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

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

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

mvn clean package

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

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

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

docker build  -t usersignup:v1 .

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

docker images 

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

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

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

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

dive usersignup:v1

Ето част от изхода на командата Dive: 

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

Изграждане на изображение на контейнер с Buildpack

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

Предимство на пакетите за изграждане на облак

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

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

Използване на Spring Boot Plugin

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

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

<plugin>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-maven-plugin</artifactId>
  <configuration>
    <image>
      <name>docker.io/pratikdas/${project.artifactId}:v1</name>
    </image>
  </configuration>
</plugin>

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

mvn spring-boot:build-image

Резултатът ще бъде нещо подобно:

[INFO] --- spring-boot-maven-plugin:2.3.3.RELEASE:build-image (default-cli) @ usersignup ---
[INFO] Building image 'docker.io/pratikdas/usersignup:v1'
[INFO] 
[INFO]  > Pulling builder image 'gcr.io/paketo-buildpacks/builder:base-platform-api-0.3' 0%
.
.
.. [creator]     Adding label 'org.springframework.boot.version'
.. [creator]     *** Images (c311fe74ec73):
.. [creator]           docker.io/pratikdas/usersignup:v1
[INFO] 
[INFO] Successfully built image '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:

      <plugin>
        <groupId>com.google.cloud.tools</groupId>
        <artifactId>jib-maven-plugin</artifactId>
        <version>2.5.2</version>
      </plugin>

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

mvn compile jib:build -Dimage=<docker registry name>/usersignup:v1

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

[INFO] Containerizing application to pratikdas/usersignup:v1...
.
.
[INFO] Container entrypoint set to [java, -cp, /app/resources:/app/classes:/app/libs/*, io.pratik.users.UsersignupApplication]
[INFO] 
[INFO] Built and pushed image as pratikdas/usersignup:v1
[INFO] Executing tasks:
[INFO] [==============================] 100.0% complete

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

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

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

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

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

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

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

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

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

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

Изграждане на оптимизирано изображение на контейнер за пролетно стартиращо приложение с Buildpack

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

<plugin>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-maven-plugin</artifactId>
  <configuration>
    <layers>
      <enabled>true</enabled>
    </layers>
  </configuration> 
</plugin>

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

Да бягаме build-imageЦелта на Maven за създаване на изображение на контейнер:

mvn spring-boot:build-image

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

Изграждане на оптимизирано изображение на контейнер за пролетно стартиращо приложение с Docker

Вместо да използваме плъгин Maven или Gradle, можем също да създадем многослойно Docker JAR изображение с 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

Изходът показва командите list, extractи helpс helpбъде по подразбиране. Нека изпълним командата с listопция:

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. Тези слоеве се кешират на хоста след първото извличане, защото не се променят. Само актуализираният слой на приложението се изтегля на хоста, което е по-бързо поради намаления размер .

Изграждане на изображение със зависимости, извлечени в отделни слоеве

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

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

# 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 .

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

Sending build context to Docker daemon  20.41MB
Step 1/12 : FROM adoptopenjdk:14-jre-hotspot as builder
14-jre-hotspot: Pulling from library/adoptopenjdk
.
.
Successfully built a9ebf6970841
Successfully tagged userssignup:v1

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

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

dive userssignup:v1

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

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

Можем допълнително да намалим размера на слоя на приложението, като извлечем всяка от нашите персонализирани зависимости в отделен слой, вместо да ги пакетираме с приложението, като ги декларираме в 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 файл и след това се пакетира в изображение на контейнер чрез посочване на инструкциите в Dockerfile.

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

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

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

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

Изчистване на контекста:

docker system prune -a

Изграждане на изображение на контейнер с Dockerfile:

docker build -f <Docker file name> -t <tag> .

Създайте изображение на контейнер от източник (без 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 <image ID or image tag>

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