ოპტიმიზებული დოკერის სურათების შექმნა საგაზაფხულო ჩატვირთვის აპლიკაციისთვის

კონტეინერები გახდა უპირატესი საშუალება აპლიკაციის შეფუთვის ყველა მისი პროგრამული და ოპერაციული სისტემის დამოკიდებულებით და შემდეგ მათი მიწოდების სხვადასხვა გარემოში.

ეს სტატია მოიცავს Spring Boot აპლიკაციის კონტეინერიზაციის სხვადასხვა გზებს:

• Docker სურათის შექმნა Docker ფაილის გამოყენებით,
• OCI გამოსახულების შექმნა წყაროდან Cloud-Native Buildpack-ის გამოყენებით,
• და გაშვების დროს გამოსახულების ოპტიმიზაცია JAR-ის ნაწილების სხვადასხვა ფენებად გამოყოფით მრავალსართულიანი ხელსაწყოების გამოყენებით.

 კოდის მაგალითი

ამ სტატიას ახლავს სამუშაო კოდის მაგალითი GitHub-ზე .

კონტეინერის ტერმინოლოგია

ჩვენ დავიწყებთ სტატიაში გამოყენებული კონტეინერის ტერმინოლოგიით:

• კონტეინერის სურათი: კონკრეტული ფორმატის ფაილი. ჩვენ გადავიყვანთ ჩვენს აპლიკაციას კონტეინერის სურათად build ინსტრუმენტის გაშვებით.
• კონტეინერი: კონტეინერის გამოსახულების შესრულებადი მაგალითი.
• კონტეინერის ძრავა: დემონური პროცესი, რომელიც პასუხისმგებელია კონტეინერის გაშვებაზე.
• კონტეინერის მასპინძელი: მასპინძელი კომპიუტერი, რომელზეც მუშაობს კონტეინერის ძრავა.
• კონტეინერის რეესტრი: ზოგადი მდებარეობა, რომელიც გამოიყენება კონტეინერის გამოსახულების გამოსაქვეყნებლად და გასავრცელებლად.
• OCI სტანდარტი: Open Container Initiative (OCI) არის მსუბუქი, ღია მმართველობის სტრუქტურა, რომელიც ჩამოყალიბდა Linux Foundation-ის ფარგლებში. OCI გამოსახულების სპეციფიკაცია განსაზღვრავს ინდუსტრიის სტანდარტებს კონტეინერის გამოსახულების და გაშვების ფორმატებისთვის, რათა უზრუნველყოს, რომ კონტეინერის ყველა ძრავს შეუძლია აწარმოოს კონტეინერის სურათები, რომლებიც შექმნილია ნებისმიერი კონსტრუქციის ხელსაწყოთი.

აპლიკაციის კონტეინერიზაციისთვის, ჩვენ ვახვევთ ჩვენს აპლიკაციას კონტეინერის სურათში და ვაქვეყნებთ ამ სურათს საერთო რეესტრში. კონტეინერის გაშვების დრო ამოიღებს ამ სურათს რეესტრიდან, ხსნის მას და გაუშვებს აპლიკაციას მასში.

Spring Boot-ის 2.3 ვერსია გთავაზობთ დანამატებს OCI სურათების შესაქმნელად.

docker არის ყველაზე ხშირად გამოყენებული კონტეინერის დანერგვა და ჩვენ ვიყენებთ Docker-ს ჩვენს მაგალითებში, ამიტომ ამ სტატიაში ყველა შემდგომი კონტეინერის მითითება ეხება Docker-ს.

კონტეინერის გამოსახულების აშენება ტრადიციული გზით

Spring Boot აპლიკაციებისთვის Docker სურათების შექმნა ძალიან მარტივია 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 ძრავზე.

კონტეინერის სურათის შექმნა

ჩვენ შემდეგ ამ შესრულებად JAR ფაილს ვათავსებთ Docker სურათში ბრძანების გაშვებით docker buildპროექტის root დირექტორიადან, რომელიც შეიცავს ადრე შექმნილ Dockerfile-ს:

docker build  -t usersignup:v1 .

ჩვენ შეგვიძლია დავინახოთ ჩვენი სურათი სიაში ბრძანების გამოყენებით:

docker images 

ზემოთ მოყვანილი ბრძანების გამომავალი მოიცავს ჩვენს სურათს usersignupსაბაზისო სურათთან ერთად, adoptopenjdkმითითებულია ჩვენს Docker ფაილში.

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-ის გამოყენებით.

კონსტრუქციის პაკეტები მჭიდროდ იყო დაკავშირებული პლატფორმასთან. 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-pluginpom.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" in როგორც ნაგულისხმევი შეფუთვის ფორმატი. როდესაც ვუყურებთ სქელ 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-imageMaven სამიზნე კონტეინერის გამოსახულების შესაქმნელად:

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

ნებისმიერი დამოკიდებულება, რომლის ვერსია არ შეიცავს SNAPSHOT-ს

spring-boot-loader

JAR Loader კლასები

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 კბ-ია და დამოკიდებულებები ინახება ცალკეულ ფენებში. 

ცალკეულ ფენებზე შიდა დამოკიდებულების ამოღება

ჩვენ შეგვიძლია კიდევ უფრო შევამციროთ აპლიკაციის დონის ზომა, ჩვენი ნებისმიერი მორგებული დამოკიდებულების ცალკე ფენად ამოღებით, ნაცვლად იმისა, რომ შევფუთოთ ისინი აპლიკაციით, მათი გამოცხადებით 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 ფაილის შექმნამდე, დარწმუნდით, რომ ფენების ფუნქცია ჩართულია 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