वसन्त बुट अनुप्रयोगको लागि अनुकूलित डकर छविहरू सिर्जना गर्दै

कन्टेनरहरू अनुप्रयोगलाई यसको सबै सफ्टवेयर र अपरेटिङ सिस्टम निर्भरताहरूसँग प्याकेज गर्ने र त्यसपछि तिनीहरूलाई विभिन्न वातावरणमा डेलिभर गर्ने रुचाइएको माध्यम बनेको छ।

यस लेखले वसन्त बुट अनुप्रयोगलाई कन्टेनराइज गर्ने विभिन्न तरिकाहरू समावेश गर्दछ:

• डकर फाइल प्रयोग गरेर डकर छवि सिर्जना,
• क्लाउड-नेटिभ बिल्डप्याक प्रयोग गरेर स्रोतबाट OCI छवि सिर्जना गर्दै,
• र बहु-स्तरीय उपकरणहरू प्रयोग गरेर JAR को भागहरू विभिन्न तहहरूमा अलग गरेर रन-टाइम छवि अनुकूलन।

 नमूना कोड

यो लेख काम कोड उदाहरण संग छ GitHub मा .

कन्टेनर शब्दावली

हामी लेखमा प्रयोग गरिएको कन्टेनर शब्दावलीको साथ सुरु गर्नेछौं:

• कन्टेनर छवि: विशिष्ट ढाँचाको फाइल। हामी निर्माण उपकरण चलाएर हाम्रो अनुप्रयोगलाई कन्टेनर छविमा रूपान्तरण गर्नेछौं।
• कंटेनर: कन्टेनर छविको कार्यान्वयन योग्य उदाहरण।
• कन्टेनर इन्जिन: कन्टेनर चलाउन जिम्मेवार डेमन प्रक्रिया।
• कन्टेनर होस्ट: होस्ट कम्प्युटर जसमा कन्टेनर इन्जिन चल्छ।
• कन्टेनर रजिस्ट्री: कन्टेनर छवि प्रकाशित र वितरण गर्न प्रयोग गरिने सामान्य स्थान।
• OCI मानक: खुला कन्टेनर पहल (OCI) लिनक्स फाउन्डेशन भित्र बनाइएको एक हल्का, खुला शासन संरचना हो। OCI छवि विशिष्टताले कन्टेनर छवि र रनटाइम ढाँचाहरूको लागि उद्योग मापदण्डहरू परिभाषित गर्दछ कि सबै कन्टेनर इन्जिनहरूले कुनै पनि निर्माण उपकरणद्वारा सिर्जना गरिएका कन्टेनर छविहरू चलाउन सक्छन्।

एप्लिकेसनलाई कन्टेनराइज गर्नको लागि, हामी हाम्रो एप्लिकेसनलाई कन्टेनर छविमा बेर्छौं र त्यो छवि साझा रजिस्ट्रीमा प्रकाशित गर्छौं। कन्टेनर रनटाइमले यो छविलाई रजिस्ट्रीबाट पुन: प्राप्त गर्छ, यसलाई अनप्याक गर्छ, र यसको भित्रको अनुप्रयोग चलाउँछ।

स्प्रिंग बुटको संस्करण २.३ ले OCI छविहरू सिर्जना गर्न प्लगइनहरू प्रदान गर्दछ।

डकर सबैभन्दा सामान्य रूपमा प्रयोग गरिएको कन्टेनर कार्यान्वयन हो, र हामी हाम्रा उदाहरणहरूमा डकर प्रयोग गर्दछौं, त्यसैले यस लेखमा सबै पछिल्ला कन्टेनर सन्दर्भहरूले डकरलाई सन्दर्भ गर्नेछ।

कन्टेनर छवि पारंपरिक तरिका निर्माण गर्दै

वसन्त बुट अनुप्रयोगहरूको लागि डकर छविहरू सिर्जना गर्न डकर फाइलमा केही निर्देशनहरू थपेर धेरै सजिलो छ।

हामीले पहिले कार्यान्वयनयोग्य JAR फाइल सिर्जना गर्छौं र, डकर फाइल निर्देशनहरूको भागको रूपमा, आवश्यक सेटिङहरू लागू गरेपछि कार्यान्वयनयोग्य JAR फाइललाई आधार JRE छविको शीर्षमा प्रतिलिपि गर्छौं।

हाम्रो वसन्त अनुप्रयोग सिर्जना गरौं वसन्त प्रारम्भिक निर्भरता संग 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, जसको शीर्षमा हामी हाम्रो JAR फाइल प्रतिलिपि गर्छौं र त्यसपछि पोर्ट खोल्छौं, 8080जसले अनुरोधहरू सुन्नेछ।

आवेदन निर्माण

पहिले तपाईंले Maven वा Gradle प्रयोग गरेर एउटा अनुप्रयोग सिर्जना गर्न आवश्यक छ। यहाँ हामी Maven प्रयोग गर्छौं:

mvn clean package

यसले अनुप्रयोगको लागि कार्यान्वयन योग्य JAR फाइल सिर्जना गर्दछ। हामीले यो कार्यान्वयनयोग्य JAR लाई डकर इन्जिनमा चलाउनको लागि डकर छविमा रूपान्तरण गर्न आवश्यक छ।

कन्टेनर छवि सिर्जना गर्दै

त्यसपछि हामीले यो कार्यान्वयनयोग्य JAR फाइललाई आदेश चलाएर डकर छविमा राख्यौं 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

यहाँ डाइभ आदेशबाट आउटपुटको अंश हो: 

हामीले देख्न सक्छौं, अनुप्रयोग तहले छवि आकारको महत्त्वपूर्ण भाग बनाउँछ। हामी हाम्रो अनुकूलनको भागको रूपमा निम्न खण्डहरूमा यस तहको आकार घटाउन चाहन्छौं।

Buildpack प्रयोग गरेर कन्टेनर छवि सिर्जना गर्दै

विधानसभा प्याकेजहरू (निर्माण प्याकहरू) स्रोत कोडबाट कन्टेनर छवि सिर्जना गर्न सेवा (PAAS) प्रस्तावहरूको रूपमा विभिन्न प्लेटफर्मले प्रयोग गरेको सामान्य शब्द हो। यो 2011 मा Heroku द्वारा लन्च गरिएको थियो र त्यसपछि क्लाउड फाउन्ड्री, Google एप इन्जिन, Gitlab, Knative र अन्य धेरै द्वारा अपनाएको छ।

क्लाउड निर्माण प्याकेजहरूको फाइदा

छविहरू सिर्जना गर्न बिल्डप्याक प्रयोग गर्ने मुख्य फाइदाहरू मध्ये एक हो छवि कन्फिगरेसन परिवर्तनहरू केन्द्रीय रूपमा व्यवस्थित गर्न सकिन्छ (बिल्डर) र बिल्डर प्रयोग गरेर सबै अनुप्रयोगहरूमा प्रचार गर्न सकिन्छ।

निर्माण प्याकेजहरू प्लेटफर्ममा कडा रूपमा जोडिएका थिए। क्लाउड-नेटिभ बिल्डप्याक्सले OCI छवि ढाँचालाई समर्थन गरेर प्लेटफर्महरूमा मानकीकरण प्रदान गर्दछ, जसले छवि डकर इन्जिनद्वारा चलाउन सकिन्छ भन्ने सुनिश्चित गर्दछ।

वसन्त बुट प्लगइन प्रयोग गर्दै

स्प्रिंग बुट प्लगइनले बिल्डप्याक प्रयोग गरेर स्रोतबाट OCI छविहरू बनाउँछ। छविहरू प्रयोग गरेर सिर्जना गरिन्छ bootBuildImageकार्यहरू (ग्रेडल) वा spring-boot:build-imageलक्ष्य (Maven) र स्थानीय डकर स्थापना।

हामी नाम निर्दिष्ट गरेर डकर रजिस्ट्रीमा पुश गर्न आवश्यक छविको नाम अनुकूलन गर्न सक्छौं। 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 images 

निष्कर्ष:

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

Jib प्रयोग गरेर कन्टेनर छवि सिर्जना गर्दै

जिब गुगलबाट छवि सिर्जना गर्ने प्लगइन हो जसले स्रोत कोडबाट कन्टेनर छवि सिर्जना गर्न वैकल्पिक विधि प्रदान गर्दछ।

कन्फिगर गर्दै jib-maven-pluginpom.xml मा:

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

अर्को, हामी एप निर्माण गर्न र कन्टेनर छवि सिर्जना गर्न Maven आदेश प्रयोग गरेर Jib प्लगइन चलाउँछौं। पहिले जस्तै, हामी यहाँ कुनै पनि डकर फाइलहरू प्रयोग गर्दैनौं:

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 पाइपलाइनहरूमा लामो निर्माण समय हुन्छ।
• सुरक्षा: ठूला छविहरूमा पनि कमजोरीहरूको लागि ठूलो क्षेत्र हुन्छ।

डकर छविले तहहरूको स्ट्याक समावेश गर्दछ, जसमध्ये प्रत्येकले हाम्रो डकरफाइलमा निर्देशन प्रतिनिधित्व गर्दछ। प्रत्येक तहले अन्तर्निहित तहमा भएका परिवर्तनहरूको डेल्टा प्रतिनिधित्व गर्दछ। जब हामी रजिस्ट्रीबाट डकर छवि तान्छौं, यो तहहरूमा तानिन्छ र होस्टमा क्यास गरिन्छ।

वसन्त बुट प्रयोग गर्दछ "फ्याट जार" मा पूर्वनिर्धारित प्याकेजिङ्ग ढाँचाको रूपमा। जब हामी बाक्लो JAR हेर्छौं, हामी देख्छौं कि अनुप्रयोगले सम्पूर्ण JAR को धेरै सानो भाग बनाउँछ। यो भाग हो जुन प्राय: परिवर्तन हुन्छ। बाँकी वसन्त फ्रेमवर्क निर्भरताहरू समावेश गर्दछ।

अप्टिमाइजेसन सूत्रले वसन्त फ्रेमवर्क निर्भरताहरूबाट छुट्टै स्तरमा अनुप्रयोगलाई अलग गर्ने वरपर केन्द्रित गर्दछ।

निर्भरता तह, जसले मोटो JAR फाइलको थोक बनाउँछ, एक पटक मात्र डाउनलोड गरिन्छ र होस्ट प्रणालीमा क्यास गरिन्छ।

एप्लिकेसन अपडेट र कन्टेनर शेड्युलिङको बेलामा एप्लिकेसनको पातलो तह मात्र तानिन्छ। यस रेखाचित्रमा देखाइएको रूपमा:

निम्न खण्डहरूमा, हामी वसन्त बुट अनुप्रयोगको लागि यी अनुकूलित छविहरू कसरी सिर्जना गर्ने भनेर हेर्नेछौं।

Buildpack प्रयोग गरेर वसन्त बुट अनुप्रयोगको लागि एक अनुकूलित कन्टेनर छवि सिर्जना गर्दै

Spring Boot 2.3 ले बाक्लो JAR फाइलका भागहरू अलग-अलग तहहरूमा निकालेर लेयरिङलाई समर्थन गर्दछ। लेयरिङ सुविधा पूर्वनिर्धारित रूपमा असक्षम गरिएको छ र स्प्रिंग बुट माभेन प्लगइन प्रयोग गरेर स्पष्ट रूपमा सक्षम हुनुपर्छ:

<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

यदि हामीले नतिजाको छविमा तहहरू हेर्न डाइभ चलायौं भने, हामीले देख्न सक्छौं कि एप्लिकेसन तह (रातोमा रेखांकित) किलोबाइट दायरामा हामीले बाक्लो JAR ढाँचा प्रयोग गरेको तुलनामा धेरै सानो छ:

डकर प्रयोग गरेर वसन्त बुट अनुप्रयोगको लागि एक अनुकूलित कन्टेनर छवि सिर्जना गर्दै

Maven वा Gradle प्लगइन प्रयोग गर्नुको सट्टा, हामी डकर फाइलको साथ एक स्तरित डकर JAR छवि पनि सिर्जना गर्न सक्छौं।

जब हामी डकर प्रयोग गर्छौं, हामीले तहहरू निकाल्न र तिनीहरूलाई अन्तिम छविमा प्रतिलिपि गर्न दुई अतिरिक्त चरणहरू प्रदर्शन गर्न आवश्यक छ।

लेयरिङ सक्षम भएको माभेन प्रयोग गरेर निर्माण गरेपछि नतिजाको JAR को सामग्रीहरू यस्तो देखिनेछन्:

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-layertoolsआवेदनको सट्टा JAR:

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 छवि मा थपिनु पर्छ। यी तहहरू पहिलो पुन: प्राप्ति पछि होस्टमा क्यास गरिएका छन् किनभने तिनीहरू परिवर्तन गर्दैनन्। केवल अद्यावधिक गरिएको अनुप्रयोग तह होस्टमा डाउनलोड गरिन्छ, जुन आकार घटेको कारणले छिटो छ .

अलग-अलग तहहरूमा निकालिएका निर्भरताहरूसँग छवि निर्माण गर्दै

भनिने विधि प्रयोग गरेर हामी दुई चरणहरूमा अन्तिम छवि निर्माण गर्नेछौं बहु-चरण विधानसभा । पहिलो चरणमा हामी निर्भरताहरू निकाल्नेछौं र दोस्रो चरणमा हामी निकालिएका निर्भरताहरूलाई अन्तिम छविमा प्रतिलिपि गर्नेछौं।

बहु-चरण निर्माणको लागि हाम्रो डकरफाइल परिमार्जन गरौं:

# 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 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साझा भण्डारबाट पुनःप्राप्त संगठन निर्भरताहरू समावेश।

निष्कर्षमा

यस लेखमा, हामीले स्रोत कोडबाट सीधा कन्टेनर छवि निर्माण गर्न क्लाउड-नेटिभ बिल्डप्याकहरू प्रयोग गरी हेरेका छौं। यो सामान्य तरिकाले कन्टेनर छवि सिर्जना गर्न डकर प्रयोग गर्ने विकल्प हो: पहिले बाक्लो कार्यान्वयनयोग्य JAR फाइल सिर्जना गर्नुहोस् र त्यसपछि डकर फाइलमा निर्देशनहरू निर्दिष्ट गरेर यसलाई कन्टेनर छविमा प्याकेज गर्नुहोस्।

हामीले लेयरिङ सुविधा सक्षम गरेर हाम्रो कन्टेनरलाई अप्टिमाइज गर्ने कुरामा पनि हेर्‍यौं जसले होस्टमा क्यास गरिएका अलग तहहरूमा निर्भरताहरू तान्दछ र कन्टेनरको कार्यान्वयन इन्जिनहरूमा समय तालिकामा अनुप्रयोगको पातलो तह लोड हुन्छ।

तपाईले लेखमा प्रयोग गरिएका सबै स्रोत कोडहरू फेला पार्न सक्नुहुन्छ Github .

आदेश सन्दर्भ

हामीले यस लेखमा प्रयोग गरेका आदेशहरूको द्रुत रनडाउन यहाँ छ।

सन्दर्भ क्लियरिङ:

docker system prune -a

डकर फाइल प्रयोग गरेर कन्टेनर छवि सिर्जना गर्दै:

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

हामी स्रोत कोडबाट कन्टेनर छवि बनाउँछौं (डकरफाइल बिना):

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