Креирање оптимизованих Доцкер слика за Спринг Боот апликацију

Контејнери су постали преферирано средство за паковање апликације са свим зависностима од софтвера и оперативног система, а затим њихово испоруку у различита окружења.

Овај чланак покрива различите начине складиштења Спринг Боот апликације:

• креирање Доцкер слике помоћу Доцкер датотеке,
• креирање ОЦИ слике из извора користећи Цлоуд-Нативе Буилдпацк,
• и оптимизацију слике током рада одвајањем делова ЈАР-а у различите слојеве помоћу вишеслојних алата.

 Пример кода

Овај чланак је пропраћен примером радног кода на ГитХуб-у .

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

Почећемо са терминологијом контејнера која се користи у чланку:

• Слика контејнера: датотека одређеног формата. Конвертоваћемо нашу апликацију у слику контејнера покретањем алата за прављење.
• Контејнер: Извршна инстанца слике контејнера.
• Контејнерски мотор: Демонски процес одговоран за покретање контејнера.
• Домаћин контејнера: Главни рачунар на коме ради контејнерски механизам.
• Регистар контејнера: Општа локација која се користи за објављивање и дистрибуцију слике контејнера.
• ОЦИ стандард: Иницијатива за отворене контејнере (ОЦИ) је лагана, отворена структура управљања формирана у оквиру Линук фондације. ОЦИ спецификација слике дефинише индустријске стандарде за слике контејнера и формате времена извршавања како би се осигурало да сви контејнерски мотори могу да покрећу слике контејнера креиране било којим алатом за прављење.

Да бисмо контејнеризовали апликацију, умотавамо нашу апликацију у слику контејнера и објављујемо ту слику у дељеном регистру. Време извођења контејнера преузима ову слику из регистра, распакује је и покреће апликацију унутар ње.

Верзија 2.3 Спринг Боот-а обезбеђује додатке за креирање ОЦИ слика.

лучки радник је најчешће коришћена имплементација контејнера, а ми користимо Доцкер у нашим примерима, тако да ће се све накнадне референце контејнера у овом чланку односити на Доцкер.

Изградња имиџа контејнера на традиционалан начин

Креирање Доцкер слика за Спринг Боот апликације је веома једноставно додавањем неколико упутстава у Доцкер датотеку.

Прво креирамо извршну ЈАР датотеку и, као део упутстава за Доцкер датотеку, копирамо извршну ЈАР датотеку на основну ЈРЕ слику након примене неопходних подешавања.

Хајде да креирамо нашу Спринг апликацију на Спринг Инитиализр са зависностима web, lombokи actuator. Такође додајемо контролер одмора за пружање АПИ-ја GETметодом.

Креирање Доцкерфиле-а

Затим контејнеришемо ову апликацију додавањем Dockerfile:

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

Наша Доцкер датотека садржи основну слику из adoptopenjdk, на врху које копирамо нашу ЈАР датотеку и затим отварамо порт, 8080који ће саслушати захтеве.

Изградња апликације

Прво морате да креирате апликацију користећи Мавен или Градле. Овде користимо Мавен:

mvn clean package

Ово креира извршну ЈАР датотеку за апликацију. Морамо да конвертујемо овај извршни ЈАР у Доцкер слику да би се покренуо на Доцкер машини.

Креирање слике контејнера

Затим стављамо ову извршну ЈАР датотеку у Доцкер слику тако што ћемо покренути команду docker buildиз основног директоријума пројекта који садржи Доцкерфиле креиран раније:

docker build  -t usersignup:v1 .

Нашу слику можемо видети на листи помоћу команде:

docker images 

Излаз горње команде укључује нашу слику usersignupзаједно са основном сликом, adoptopenjdkнаведено у нашој Доцкер датотеци.

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

Прегледајте слојеве унутар слике контејнера

Хајде да погледамо гомилу слојева унутар слике. Користићемо алатка  ронити да видите ове слојеве:

dive usersignup:v1

Ево дела излаза из команде Диве: 

Као што видимо, слој апликације чини значајан део величине слике. Желимо да смањимо величину овог слоја у следећим одељцима као део наше оптимизације.

Креирање слике контејнера помоћу Буилдпацк-а

Монтажни пакети (Буилдпацкс) је општи термин који користе различите понуде платформе као услуге (ПААС) за креирање слике контејнера из изворног кода. Покренуо га је Хероку 2011. године и од тада су га усвојили Цлоуд Фоундри, Гоогле Апп Енгине, Гитлаб, Кнативе и неколико других.

Предност пакета за прављење облака

Једна од главних предности коришћења Буилдпацк-а за креирање слика је то Променама конфигурације слике се може управљати централно (буилдер) и преносити на све апликације користећи буилдер.

Пакети израде били су чврсто повезани са платформом. Цлоуд-Нативе Буилдпацкс обезбеђују стандардизацију на различитим платформама подржавајући ОЦИ формат слике, који обезбеђује да слику може да покреће Доцкер механизам.

Коришћење Спринг Боот додатка

Спринг Боот додатак прави ОЦИ слике из извора користећи Буилдпацк. Слике се креирају помоћу bootBuildImageзадаци (Градле) или spring-boot:build-imageциљеви (Мавен) и локална Доцкер инсталација.

Можемо да прилагодимо име слике која је потребна за гурање у Доцкер регистар тако што ћемо навести име у 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>

Хајде да користимо Мавен да то урадимо build-imageциљеви за креирање апликације и креирање слике контејнера. Тренутно не користимо ниједан Доцкерфилес.

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користи се за креирање радне ОЦИ слике. Као и раније, можемо видети слику наведену као Доцкер слика покретањем команде:

docker images 

Закључак:

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

Креирање слике контејнера помоћу Јиб-а

Јиб је Гоогле додатак за креирање слике који пружа алтернативни метод за креирање слике контејнера из изворног кода.

Прилагоди jib-maven-pluginу пом.кмл:

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

Затим покрећемо додатак Јиб користећи команду Мавен да бисмо направили апликацију и креирали слику контејнера. Као и раније, овде не користимо никакве Доцкер датотеке:

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

Након извршења горње Мавен команде, добијамо следећи излаз:

[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

Излаз показује да је слика контејнера креирана и смештена у регистар.

Мотивације и технике за креирање оптимизованих слика

Имамо два главна разлога за оптимизацију:

• Перформансе: У систему оркестрације контејнера, слика контејнера се преузима из регистра слика до хоста који покреће механизам контејнера. Овај процес се зове планирање. Повлачење великих слика из регистра резултира дугим временом планирања у системима оркестрације контејнера и дугим временом изградње у ЦИ цевоводима.
• безбедност: Веће слике такође имају већу површину за рањивости.

Доцкер слика се састоји од хрпе слојева, од којих сваки представља инструкцију у нашем Доцкерфиле-у. Сваки слој представља делту промена у доњем слоју. Када извучемо Доцкер слику из регистра, она се повлачи у слојевима и кешује на хосту.

Спринг Боот користи "дебеле ЈАР" у као подразумевани формат паковања. Када погледамо дебели ЈАР, видимо да апликација чини веома мали део целог ЈАР-а. Ово је део који се најчешће мења. Остатак се састоји од зависности од Спринг Фрамеворк-а.

Формула оптимизације се усредсређује на изоловање апликације на одвојеном нивоу од зависности од Спринг Фрамеворк-а.

Слој зависности, који чини највећи део дебеле ЈАР датотеке, преузима се само једном и кешује на хост систему.

Само танак слој апликације се повлачи током ажурирања апликације и заказивања контејнера. као што је приказано на овом дијаграму:

У следећим одељцима ћемо погледати како да креирамо ове оптимизоване слике за Спринг Боот апликацију.

Креирање оптимизоване слике контејнера за апликацију Спринг Боот помоћу Буилдпацк-а

Спринг Боот 2.3 подржава слојеве тако што издваја делове дебеле ЈАР датотеке у засебне слојеве. Функција слојевитости је подразумевано онемогућена и мора бити експлицитно омогућена помоћу Спринг Боот Мавен додатка:

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

Користићемо ову конфигурацију да направимо слику контејнера прво са Буилдпацк-ом, а затим са Доцкер-ом у следећим одељцима.

Хајде да покренемо build-imageМавен циљ за креирање слике контејнера:

mvn spring-boot:build-image

Ако покренемо Диве да бисмо видели слојеве на резултујућој слици, можемо видети да је слој апликације (означен црвеном бојом) много мањи у опсегу килобајта у поређењу са оним што смо добили користећи дебели ЈАР формат:

Креирање оптимизоване слике контејнера за апликацију Спринг Боот помоћу Доцкер-а

Уместо да користимо Мавен или Градле додатак, такође можемо да креирамо слојевиту Доцкер ЈАР слику са Доцкер датотеком.

Када користимо Доцкер, потребно је да извршимо два додатна корака да издвојимо слојеве и копирамо их у коначну слику.

Садржај резултујућег ЈАР-а након прављења користећи Мавен са омогућеним слојевањем ће изгледати овако:

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

Излаз приказује додатни ЈАР са именом spring-boot-jarmode-layertoolsи layersfle.idxфајл. Ова додатна ЈАР датотека пружа слојевите могућности обраде, као што је описано у следећем одељку.

Издвајање зависности од појединачних слојева

Да бисмо видели и издвојили слојеве из нашег слојевитог ЈАР-а, користимо својство система -Djarmode=layertoolsза почетак spring-boot-jarmode-layertoolsЈАР уместо апликације:

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

свака зависност чија верзија не садржи СНАПСХОТ

spring-boot-loader

Класе ЈАР утоваривача

snapshot-dependencies

било коју зависност чија верзија садржи СНАПСХОТ

application

класе апликација и ресурси

Слојеви су дефинисани у layers.idxдатотеку редоследом којим треба да се додају у Доцкер слику. Ови слојеви се кеширају у хосту након првог преузимања јер се не мењају. На хост се преузима само ажурирани слој апликације, што је брже због смањене величине .

Изградња слике са зависностима издвојеним у засебне слојеве

Коначну слику ћемо изградити у две фазе користећи метод тзв вишестепена монтажа . У првом кораку ћемо издвојити зависности а у другом кораку ћемо копирати извучене зависности у коначну слику.

Хајде да изменимо наш Доцкерфиле за вишестепену градњу:

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

Можемо видети да је Доцкер слика креирана са ИД-ом слике, а затим означена.

Коначно, покрећемо команду Диве као и раније да бисмо прегледали слојеве унутар генерисане Доцкер слике. Можемо да обезбедимо ИД слике или ознаку као улаз за команду Диве:

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који садржи зависности организације преузете из дељеног спремишта.

Излаз

У овом чланку смо погледали коришћење Цлоуд-Нативе Буилдпацкс-а за прављење слике контејнера директно из изворног кода. Ово је алтернатива коришћењу Доцкер-а за креирање слике контејнера на уобичајен начин: прво креирање дебеле извршне ЈАР датотеке, а затим је паковање у слику контејнера навођењем упутстава у Доцкер датотеци.

Такође смо размотрили оптимизацију нашег контејнера тако што смо омогућили функцију слојевитости која повлачи зависности у засебне слојеве који су кеширани на хосту, а танак слој апликације се учитава у време планирања у извршним машинама контејнера.

Можете пронаћи сав изворни код коришћен у чланку на Гитхуб .

Референца команде

Ево кратког прегледа команди које смо користили у овом чланку.

Брисање контекста:

docker system prune -a

Креирање слике контејнера помоћу Доцкер датотеке:

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

Ми градимо слику контејнера из изворног кода (без Доцкерфиле-а):

mvn spring-boot:build-image

Погледајте слојеве зависности. Пре него што направите ЈАР датотеку апликације, уверите се да је функција слојевања омогућена у спринг-боот-мавен-плугин-у:

java -Djarmode=layertools -jar application.jar list

Екстраховање слојева зависности. Пре него што направите ЈАР датотеку апликације, уверите се да је функција слојевања омогућена у спринг-боот-мавен-плугин-у:

 java -Djarmode=layertools -jar application.jar extract

Погледајте листу слика контејнера

docker images

Погледајте са леве стране унутар слике контејнера (уверите се да је алатка за роњење инсталирана):

dive <image ID or image tag>

Извор: ввв.хабр.цом