Создавање оптимизирани Docker слики за апликација за пролетно подигање

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

Оваа статија опфаќа различни начини за контејнеризирање на апликацијата Spring Boot:

• креирање на Docker слика со помош на датотека Docker,
• создавање на OCI слика од изворот користејќи Cloud-Native Buildpack,
• и оптимизација на сликата за време на извршување со одвојување на делови од JAR во различни слоеви користејќи алатки со повеќе нивоа.

 Примерок код

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

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

Ќе започнеме со терминологијата за контејнери што се користи во статијата:

• Слика од контејнер: датотека со специфичен формат. Ќе ја претвориме нашата апликација во слика на контејнер со извршување на алатката за градење.
• Контејнер: Извршна инстанца од сликата на контејнерот.
• Мотор за контејнер: Демонскиот процес одговорен за водење на контејнерот.
• Домаќин на контејнер: Домаќин компјутер на кој работи моторот на контејнерот.
• Регистар на контејнери: Општата локација што се користи за објавување и дистрибуција на сликата на контејнерот.
• OCI стандард: Иницијатива за отворен контејнер (OCI) е лесна, отворена структура за управување формирана во рамките на Фондацијата Linux. Спецификацијата за слика OCI ги дефинира индустриските стандарди за формати на слики од контејнер и време на траење за да се осигура дека сите мотори на контејнери можат да извршуваат слики од контејнери создадени од која било алатка за градење.

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

Верзијата 2.3 на Spring Boot обезбедува приклучоци за креирање OCI слики.

пристанишен работник е најчесто користената имплементација на контејнер, и ние го користиме Docker во нашите примери, така што сите последователни референци за контејнери во оваа статија ќе се однесуваат на Docker.

Изградба на слика на контејнер на традиционален начин

Создавањето Docker слики за апликациите Spring Boot е многу лесно со додавање на неколку инструкции во датотеката Docker.

Прво создаваме извршна датотека JAR и, како дел од упатствата за датотеката Docker, ја копираме извршната датотека JAR на врвот на основната слика JRE откако ќе ги примените потребните поставки.

Ајде да ја создадеме нашата пролетна апликација Пролетна иницијализр со зависности web, lombokи actuator. Додаваме и контролер за одмор за да обезбедиме API GETметод.

Креирање на Dockerfile

Потоа ја контејнеризираме оваа апликација со додавање Dockerfile:

FROM adoptopenjdk:11-jre-hotspot
ARG JAR_FILE=target/*.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од root директориумот на проектот што го содржи Dockerfile создаден порано:

docker build  -t usersignup:v1 .

Можеме да ја видиме нашата слика во списокот користејќи ја командата:

docker images 

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

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

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

Ајде да го погледнеме купот слоеви во внатрешноста на сликата. Ние ќе користиме алатка  нурне за да ги видите овие слоеви:

dive usersignup:v1

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

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

Создавање слика на контејнер користејќи Buildpack

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

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

Една од главните придобивки од користењето на Buildpack за создавање слики е тоа Промените на конфигурацијата на сликата може да се управуваат централно (градител) и да се пропагираат на сите апликации со помош на билдер.

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

Користење на приклучокот Spring Boot

Приклучокот Spring Boot гради OCI слики од изворот користејќи Buildpack. Сликите се создаваат со користење bootBuildImageзадачи (Gradle) или spring-boot:build-imageцели (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 за да ја изградиме апликацијата и да создадеме слика на контејнер. Како и досега, овде не користиме никакви датотеки на Docker:

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 од регистарот, таа се влече во слоеви и се кешира на домаќинот.

Користи пролетни чизми „дебела тегла“ во како стандарден формат на пакување. Кога ќе го погледнеме дебелиот JAR, ќе видиме дека апликацијата сочинува многу мал дел од целиот JAR. Ова е делот кој најчесто се менува. Остатокот се состои од зависности од пролетната рамка.

Формулата за оптимизација се фокусира на изолирање на апликацијата на посебно ниво од зависностите од 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Мејвен цел за создавање слика на контејнер:

mvn spring-boot:build-image

Ако го извршиме Dive за да ги видиме слоевите на добиената слика, можеме да видиме дека слојот на апликација (оцртан со црвено) е многу помал во опсегот на килобајти во споредба со она што го добивме користејќи го дебелиот формат JAR:

Создавање оптимизирана слика на контејнер за апликација за пролетно подигање со помош на Docker

Наместо да користиме приклучок Maven или Gradle, можеме да создадеме и слоевит Docker JAR слика со датотека Docker.

Кога користиме 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

секоја зависност чија верзија не содржи СНИМКА

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 е креирана со ID на слика и потоа е означена.

Конечно, ја извршуваме командата Dive како порано за да ги провериме слоевите во генерираната слика на Docker. Можеме да обезбедиме ID на слика или ознака како влез во командата 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, а потоа спакувајте ја во слика на контејнер со наведување на инструкции во датотеката Docker.

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

Можете да го најдете целиот изворен код користен во статијата на Github .

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

Еве брз преглед на командите што ги користевме во оваа статија.

Расчистување на контекстот:

docker system prune -a

Создавање слика на контејнер користејќи датотека Docker:

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

Ние ја градиме сликата на контејнерот од изворниот код (без Dockerfile):

mvn spring-boot:build-image

Прикажи ги слоевите на зависност. Пред да ја изградите датотеката JAR на апликацијата, проверете дали е овозможена функцијата за слоевитост во пролетта-boot-maven-приклучокот:

java -Djarmode=layertools -jar application.jar list

Извлекување на слоеви на зависност. Пред да ја изградите датотеката JAR на апликацијата, проверете дали е овозможена функцијата за слоевитост во пролетта-boot-maven-приклучокот:

 java -Djarmode=layertools -jar application.jar extract

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

docker images

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

dive <image ID or image tag>

Извор: www.habr.com