🥇 Skapa optimerade Docker-images för Spring Boot-applikationen

Containrar har blivit det föredragna sättet att paketera applikationen med alla mjukvaru- och operativsystemberoenden, och sedan leverera dem till olika miljöer.

Denna artikel behandlar olika sätt att containerisera en Spring Boot-applikation:

skapa en Docker-image med hjälp av en Dockerfil,
skapa en OCI-image från källkoden med hjälp av Cloud-Native Buildpack,
och optimera bilden vid körning genom att segmentera JAR-filer i olika lager med hjälp av flerlagersverktyg.

Kodexempel

Denna artikel åtföljs av ett exempel på arbetskod på GitHub .

Terminologi för containrar

Vi börjar med terminologin för containrar som används i artikeln:

Container image: en fil av ett visst format. Vi konverterar vår applikation till en container image genom att köra ett byggverktyg.
Container: en körbar instans av containerbilden.
Container engine: en daemonprocess som ansvarar för att köra containern.
Container host: värddatorn där containerverket körs.
Container registry: en gemensam plats som används för att publicera och distribuera containerbilder.
Standard OCI: Open Container Initiative (OCI) är en lättviktig öppen styrstruktur som bildades inom ramen för Linux Foundation. OCI-specifikationen för containerbilder definierar branschstandarder för format av containerbilder och körmiljöer för att säkerställa att alla containerverktyg kan köra containerbilder skapade av något byggverktyg.

För att placera en applikation i en container kapslar vi in vår applikation i en container image och publicerar denna bild i en gemensam registry. Container runtime hämtar denna bild från registryn, packar upp den och kör applikationen inuti.

Version 2.3 av Spring Boot erbjuder plugins för att skapa OCI-bilder.

Docker den mest använda implementeringen av containern, och vi använder Docker i våra exempel, så alla efterföljande referenser till containern i denna artikel kommer att syfta på Docker.

Bygga containerbilder på det traditionella sättet

Att skapa Docker-bilder för Spring Boot-applikationer är mycket enkelt genom att lägga till några instruktioner i Docker-filen.

Först skapar vi en körbar JAR-fil och, som en del av instruktionerna i Docker-filen, kopierar vi den körbara JAR-filen över basbilden JRE efter att nödvändiga inställningar har använts.

Låt oss skapa vår Spring-applikation på Spring Initializr med beroenden web, lombokoch aktuator. Vi lägger också till en restkontroller för att tillhandahålla API med GETmetod.

Skapa Docker-fil

Sedan placerar vi denna applikation i en behållare genom att lägga till Dockerfile:

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

Vår Docker-fil innehåller en basbild, från adoptopenjdk, över vilken vi kopierar vår JAR-fil och sedan öppnar en port, 8080som kommer att lyssna på förfrågningar.

Bygg applikationen

Först behöver vi skapa applikationen med Maven eller Gradle. Här använder vi Maven:

mvn clean package

Detta skapar den körbara JAR-filen för applikationen. Vi behöver konvertera denna körbara JAR till en Docker-bild för att köra i Docker-motorn.

Skapa behållarens bild

Sedan placerar vi den här körbara JAR-filen i Docker-bilden genom att köra kommandot docker buildfrån rotkatalogen för projektet som innehåller Docker-filen som skapades tidigare:

docker build -t usersignup:v1 .

Vi kan se vår bild i listan med kommandot:

docker images

Resultatet av att köra det ovanstående kommandot inkluderar vår bild usersignuptillsammans med basbilden, adoptopenjdk, angiven i vår Docker-fil.

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

Visa lagren inuti behållarbilden

Låt oss titta på stapeln av lager inuti bilden. Vi kommer att använda verktyg dive, för att visa dessa lager:

dive usersignup:v1

Här är en del av resultaten från att köra Dive-kommandot:

Som vi kan se utgör applikationslagret en betydande del av bildens storlek. Vi vill minska storleken på detta lager i de följande avsnitten i vår optimering.

Skapa behållarbilder med hjälp av Buildpack

Byggpaket (Buildpacks) – är en allmän term som används av olika erbjudanden av "Plattform som tjänst" (PAAS) för att skapa behållarbilder från källkoden. Det startades av Heroku 2011 och har sedan dess antagits av Cloud Foundry, Google App Engine, Gitlab, Knative och några andra.

Fördelar med molnbaserade byggpaket

En av de stora fördelarna med att använda Buildpack för att skapa bilder är att Med konfigurationsändringar kan man centralt hantera (builder) och distribuera till alla applikationer som använder builder.

Byggpaketen var nära kopplade till plattformen. Cloud-Native Buildpacks säkerställer standardisering mellan plattformar genom att stödja OCI-bildformatet, vilket garanterar att bilden kan köras på Docker-motorn.

Använda Spring Boot-plugin

Spring Boot-pluginet skapar OCI-bilder från källkod med hjälp av Buildpack. Bilderna skapas med bootBuildImageuppgifter (Gradle) eller spring-boot:build-imagemål (Maven) och den lokala Docker-installationen.

Vi kan ställa in namnet på bilden som behövs för att skicka till Docker-registret genom att ange namnet i image tag:

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

Låt oss använda Maven för att köra build-imagemålet för att bygga applikationen och skapa containerbilden. Just nu använder vi inga Docker-filer.

mvn spring-boot:build-image

Resultatet kommer att se ut ungefär så här:

[INFO] --- spring-boot-maven-plugin:2.3.3.RELEASE:build-image (default-cli) @ usersignup ---
[INFO] Bygger bild 'docker.io/pratikdas/usersignup:v1'
[INFO] 
[INFO]  > Hämtar builder-bild 'gcr.io/paketo-buildpacks/builder:base-platform-api-0.3' 0%
.
.
.. [skapare]     Lägger till etikett 'org.springframework.boot.version'
.. [skapare]     *** Bilder (c311fe74ec73):
.. [skapare]           docker.io/pratikdas/usersignup:v1
[INFO] 
[INFO] Framgångsrikt byggd bild 'docker.io/pratikdas/usersignup:v1'

Från utdata ser vi att paketo Cloud-Native buildpackanvänds för att skapa en fungerande OCI-bild. Precis som tidigare kan vi se bilden angiven som Docker-bild genom att köra kommandot:

docker images

Slutsats:

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

Skapa containerbild med Jib

Jib är en bildskapande plugin från Google som erbjuder ett alternativt sätt att skapa en containerbild från källkod.

Vi konfigurerar jib-maven-plugini pom.xml:

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

Därefter kör vi Jib-pluginet med hjälp av Maven-kommandot för att bygga applikationen och skapa containerbilden. Som tidigare använder vi inga Docker-filer här:

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

Efter att ha kört ovanstående Maven-kommando får vi följande utdata:

[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

Utdatans visar att containermedlet har skapats och lagts i registret.

Motivationer och metoder för att skapa optimerade bilder

Vi har två huvudsakliga skäl för optimering:

Performance: i systemet för orkestrering av containrar hämtas containermedlet från bildregistret till den värd där containermekanismen körs. Denna process kallas schemaläggning. Att hämta stora bilder från registret leder till lång schemaläggningstid i system för orkestrering av containrar och lång byggtid i CI-pipelines.
Säkerhet: stora bilder har också en större yta för säkerhetsrisker.

Dockerbilden består av en stapel av lager, där varje lager representerar en instruktion i vår Dockerfile. Varje lager representerar delta förändringar av det underliggande lagret. När vi hämtar en Dockerbild från registret hämtas den i lager och cachas på värden.

Spring Boot använder "tjock JAR" som standardpaketeringsformat. När vi granskar den tjocka JAR-filen ser vi att applikationen utgör en mycket liten del av hela JAR-filen. Det är den del som oftast ändras. Återstående del består av beroenden från Spring Framework.

Optimeringsformeln fokuserar på att isolera applikationen på en egen nivå från beroenden av Spring Framework.

Lagret med beroenden som utgör huvuddelen av den tjocka JAR-filen laddas endast en gång och cachas i värdsystemet.

Endast det tunna lagret av applikationen hämtas under applikationsuppdateringar och schemaläggning av containrar, som visas i detta diagram:

I de följande avsnitten kommer vi att titta på hur man skapar dessa optimerade bilder för Spring Boot-applikationen.

Skapa en optimerad containerbild för Spring Boot-applikationen med hjälp av Buildpack

Spring Boot 2.3 stöder flerlagersstruktur genom att extrahera delar av den tjocka JAR-filen i separata lager. Flerlagringsfunktionen är inaktiverad som standard och måste aktiveras explicit med hjälp av Spring Boot Maven-plugin:

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

Vi kommer att använda denna konfiguration för att skapa vår containerbild först med Buildpack och sedan med Docker i de följande avsnitten.

Låt oss köra build-imageMaven-mål för att skapa en containerbild:

mvn spring-boot:build-image

Om vi kör Dive för att se lagren i den resulterande bilden kommer vi att se att applikationslagret (markerat i rött) är mycket mindre, inom kilobytes, jämfört med vad vi fick med hjälp av det tjocka JAR-formatet:

Skapa en optimerad containerbild för en Spring Boot-applikation med Docker

Istället för att använda Maven- eller Gradle-plugin kan vi också skapa en flerlagers JAR Docker-bild med en Docker-fil.

När vi använder Docker måste vi utföra två ytterligare steg för att extrahera lagren och kopiera dem till den slutliga bilden.

Innehållet i den resulterande JAR-filen efter byggande med Maven med aktiverad lagringsfunktion kommer att se ut på följande sätt:

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

I utdata visas en ytterligare JAR med namnet spring-boot-jarmode-layertoolsoch layersfle.idxfil. Denna ytterligare JAR-fil ger möjlighet för flerlagershantering, som beskrivs i nästa avsnitt.

Extrahera beroenden på separata lager

För att visa och extrahera lager från vår flerlagers JAR använder vi systemegenskapen -Djarmode=layertoolsför att köra spring-boot-jarmode-layertoolsJAR istället för applikationen:

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

Att köra detta kommando ger utdata som innehåller tillgängliga kommandoparametrar:

Användning:
  java -Djarmode=layertools -jar usersignup-0.0.1-SNAPSHOT.jar

Tillgängliga kommandon:
  list     Lista lager från jar-filen som kan extraheras
  extract  Extraherar lager från jar-filen för bildskapande
  help     Hjälp om något kommando

Utdata visar kommandon list, extractoch helpmed helpvara som standard. Låt oss köra kommandot med listalternativet:

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

dependencies
spring-boot-loader
snapshot-dependencies
application

Vi ser en lista med beroenden som kan läggas till som lager.

Standardlager:

Lagnamn

Innehåll

dependencies

något beroende vars version inte innehåller SNAPSHOT

spring-boot-loader

JAR-laddarens klasser

snapshot-dependencies

något beroende vars version innehåller SNAPSHOT

application

applikationsklasser och resurser

Skikten definieras i layers.idxfilen i den ordning de ska läggas till i Docker-avbildningen. Dessa skikt cachas på värden efter den första hämtningen, eftersom de inte ändras. Endast det uppdaterade lagret av applikationen laddas upp till värden, vilket går snabbare på grund av den minskade storleken. .

Byggandet av avbildningen med beroenden hämtade i separata skikt.

Vi kommer att bygga den slutliga avbildningen i två steg, med en metod som kallas multistep-bygge . I det första steget hämtar vi beroenden och i det andra steget kopierar vi de hämtade beroendena till den slutliga avbildningen.

Låt oss modifiera vår Docker-fil för multistep-bygge:

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

Vi sparar denna konfiguration i en separat fil — Dockerfile2.

Vi bygger Docker-avbildningen med kommandot:

docker build -f Dockerfile2 -t usersignup:v1 .

Efter att ha kört detta kommando får vi följande utdata:

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

Vi ser att Docker-avbildningen skapas med ett avbildnings-ID och sedan taggas.

Till sist kör vi Dive-kommandot, precis som tidigare, för att kontrollera skikten inne i den genererade Docker-avbildningen. Vi kan ange avbildnings-ID eller tagg som indata för Dive-kommandot:

dive userssignup:v1

Som framgår av utdata tar lagret som innehåller applikationen nu bara 11 KB, och beroendena cachas i separata skikt.

Hämtar interna beroenden i separata skikt.

Vi kan ytterligare minska storleken på applikationslagret genom att hämta några av våra anpassade beroenden i ett separat lager istället för att packa dem tillsammans med applikationen genom att deklarera dem i ymlen sådan fil med namnet 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/"

I denna fil layers.idxhar vi lagt till ett anpassat beroende med namnet, io.myorgsom innehåller organisationsberoenden hämtade från det gemensamma arkivet.

Utdata

I den här artikeln har vi granskat användningen av Cloud-Native Buildpacks för att skapa en container-image direkt från källkoden. Detta är ett alternativ till att använda Docker för att skapa en container-image på det traditionella sättet: först skapas en stor JAR-exekverbar fil, som sedan packas i en container-image med instruktioner i en Docker-fil.

Vi har också undersökt optimeringen av vår container genom att inkludera ett lager-funktion som extraherar beroenden i separata nivåer, som cachas på värden, medan det tunna applikationslagret laddas under schemaläggningen i behållarens körningsmekanismer.

Du kan hitta all källkod som användes i artikeln på Github .

Kommandoguide

Här är en sammanfattning av de kommandon vi använde i den här artikeln för snabb referens.

Rensa kontext:

docker system prune -a

Skapa en container-image med Docker-filen:

docker build -f  -t  .

Bygger container-images från källkoden (utan Dockerfile):

mvn spring-boot:build-image

Visa beroendens lager. Innan du bygger JAR-filen för applikationen, se till att lager-funktionen är aktiverad i spring-boot-maven-plugin:

java -Djarmode=layertools -jar application.jar list

Extrahera beroendens lager. Innan du bygger JAR-filen för applikationen, se till att lager-funktionen är aktiverad i spring-boot-maven-plugin:

 java -Djarmode=layertools -jar application.jar extract

Visa listan över container-images

docker images

Visa lagren inne i container-imagen (se till att verktyget för djupdykning är installerat):

dive

Källa: habr.com

Skapa optimerade Docker-bilder för din Spring Boot-applikation