स्प्रिंग बूट ऍप्लिकेशनसाठी ऑप्टिमाइझ डॉकर प्रतिमा तयार करणे

कंटेनर हे सर्व सॉफ्टवेअर आणि ऑपरेटिंग सिस्टम अवलंबित्वांसह अनुप्रयोग पॅकेजिंग आणि नंतर त्यांना वेगवेगळ्या वातावरणात वितरित करण्याचे प्राधान्य साधन बनले आहे.

या लेखात स्प्रिंग बूट ऍप्लिकेशनचे कंटेनर बनवण्याचे विविध मार्ग समाविष्ट आहेत:

• डॉकर फाइल वापरून डॉकर प्रतिमा तयार करणे,
• क्लाउड-नेटिव्ह बिल्डपॅक वापरून स्त्रोतावरून ओसीआय प्रतिमा तयार करणे,
• आणि रन-टाइम इमेज ऑप्टिमायझेशन JAR चे भाग वेगवेगळ्या स्तरांमध्ये विभक्त करून मल्टी-टियर टूल्स वापरून.

 कोड उदाहरण

हा लेख कार्यरत कोड उदाहरणासह आहे GitHub वर .

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

आम्ही लेखात वापरलेल्या कंटेनर शब्दावलीसह प्रारंभ करू:

• कंटेनर प्रतिमा: विशिष्ट स्वरूपाची फाइल. बिल्ड टूल चालवून आम्ही आमच्या ऍप्लिकेशनला कंटेनर इमेजमध्ये रूपांतरित करू.
• कंटेनर: कंटेनर प्रतिमेचे एक्झिक्युटेबल उदाहरण.
• कंटेनर इंजिन: कंटेनर चालविण्यासाठी जबाबदार असलेली डिमन प्रक्रिया.
• कंटेनर होस्ट: होस्ट संगणक ज्यावर कंटेनर इंजिन चालते.
• कंटेनर नोंदणी: कंटेनर प्रतिमा प्रकाशित आणि वितरित करण्यासाठी वापरलेले सामान्य स्थान.
• OCI मानक: ओपन कंटेनर इनिशिएटिव्ह (OCI) लिनक्स फाउंडेशनमध्ये तयार केलेली एक हलकी, मुक्त प्रशासन रचना आहे. ओसीआय इमेज स्पेसिफिकेशन कंटेनर इमेज आणि रनटाइम फॉरमॅटसाठी उद्योग मानके परिभाषित करते हे सुनिश्चित करण्यासाठी की सर्व कंटेनर इंजिन कोणत्याही बिल्ड टूलद्वारे तयार केलेल्या कंटेनर इमेजेस चालवू शकतात.

अनुप्रयोग कंटेनरीकृत करण्यासाठी, आम्ही आमचा अनुप्रयोग कंटेनर प्रतिमेमध्ये गुंडाळतो आणि ती प्रतिमा सामायिक केलेल्या नोंदणीवर प्रकाशित करतो. कंटेनर रनटाइम ही प्रतिमा रेजिस्ट्रीमधून पुनर्प्राप्त करते, ती अनपॅक करते आणि त्यामध्ये अनुप्रयोग चालवते.

स्प्रिंग बूटची आवृत्ती 2.3 OCI प्रतिमा तयार करण्यासाठी प्लगइन प्रदान करते.

गोदी कामगार सर्वात सामान्यतः वापरलेली कंटेनर अंमलबजावणी आहे, आणि आम्ही आमच्या उदाहरणांमध्ये डॉकर वापरतो, म्हणून या लेखातील त्यानंतरचे सर्व कंटेनर संदर्भ डॉकरचा संदर्भ घेतील.

पारंपारिक पद्धतीने कंटेनर प्रतिमा तयार करणे

डॉकर फाइलमध्ये काही सूचना जोडून स्प्रिंग बूट ऍप्लिकेशन्ससाठी डॉकर प्रतिमा तयार करणे खूप सोपे आहे.

आम्ही प्रथम एक एक्झिक्युटेबल JAR फाईल तयार करतो आणि डॉकर फाइल निर्देशांचा भाग म्हणून, आवश्यक सेटिंग्ज लागू केल्यानंतर बेस JRE इमेजच्या वर एक्झिक्युटेबल JAR फाइल कॉपी करतो.

चला आमचे स्प्रिंग ऍप्लिकेशन तयार करूया स्प्रिंग इनिशियलाइजर अवलंबित्वांसह 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

डायव्ह कमांडमधील आउटपुटचा भाग येथे आहे: 

जसे आपण बघू शकतो, ऍप्लिकेशन लेयर प्रतिमा आकाराचा एक महत्त्वपूर्ण भाग बनवते. आम्ही आमच्या ऑप्टिमायझेशनचा भाग म्हणून खालील विभागांमध्ये या लेयरचा आकार कमी करू इच्छितो.

बिल्डपॅक वापरून कंटेनर प्रतिमा तयार करणे

असेंब्ली पॅकेजेस (बिल्डपॅक्स) ही एक सामान्य संज्ञा आहे जी विविध प्लॅटफॉर्मद्वारे सेवा म्हणून वापरली जाते (PAAS) स्त्रोत कोडमधून कंटेनर प्रतिमा तयार करण्यासाठी. हे 2011 मध्ये Heroku द्वारे लॉन्च केले गेले होते आणि तेव्हापासून क्लाउड फाउंड्री, Google App Engine, 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>

ते करण्यासाठी मावेन वापरू 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कार्यरत OCI प्रतिमा तयार करण्यासाठी वापरले जाते. पूर्वीप्रमाणे, आम्ही कमांड चालवून डॉकर प्रतिमा म्हणून सूचीबद्ध केलेली प्रतिमा पाहू शकतो:

docker images 

निष्कर्ष:

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

Jib वापरून कंटेनर प्रतिमा तयार करणे

जिब हे Google चे इमेज क्रिएशन प्लगइन आहे जे स्त्रोत कोडमधून कंटेनर इमेज तयार करण्यासाठी पर्यायी पद्धत प्रदान करते.

सानुकूलित करा 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 चा खूप लहान भाग बनवतो. हा असा भाग आहे जो बर्याचदा बदलतो. उर्वरित स्प्रिंग फ्रेमवर्क अवलंबनांचा समावेश आहे.

ऑप्टिमायझेशन फॉर्म्युला स्प्रिंग फ्रेमवर्क अवलंबनांपासून वेगळ्या स्तरावर ऍप्लिकेशनला वेगळे करण्याभोवती केंद्रीत आहे.

अवलंबित्व स्तर, जो जाड JAR फाईलचा मोठा भाग बनवतो, फक्त एकदाच डाउनलोड केला जातो आणि होस्ट सिस्टमवर कॅशे केला जातो.

अनुप्रयोग अद्यतने आणि कंटेनर शेड्यूलिंग दरम्यान अनुप्रयोगाचा फक्त एक पातळ थर ओढला जातो. या चित्रात दाखवल्याप्रमाणे:

पुढील विभागांमध्ये, स्प्रिंग बूट ऍप्लिकेशनसाठी या ऑप्टिमाइझ केलेल्या प्रतिमा कशा तयार करायच्या ते आम्ही पाहू.

बिल्डपॅक वापरून स्प्रिंग बूट ऍप्लिकेशनसाठी ऑप्टिमाइझ्ड कंटेनर इमेज तयार करणे

स्प्रिंग बूट 2.3 जाड JAR फाईलचे भाग वेगळे लेयरमध्ये काढून लेयरिंगला समर्थन देते. लेयरिंग वैशिष्ट्य डीफॉल्टनुसार अक्षम केले आहे आणि स्प्रिंग बूट मॅवेन प्लगइन वापरून स्पष्टपणे सक्षम केले पाहिजे:

<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

परिणामी प्रतिमेतील लेयर्स पाहण्यासाठी आम्ही डायव्ह चालवल्यास, आम्ही जाड 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फाईल त्या क्रमाने डॉकर इमेजमध्ये जोडल्या जाव्यात. हे स्तर पहिल्या पुनर्प्राप्तीनंतर होस्टमध्ये कॅशे केले जातात कारण ते बदलत नाहीत. केवळ अद्ययावत ऍप्लिकेशन स्तर होस्टवर डाउनलोड केला जातो, जो कमी आकारामुळे जलद आहे .

विभक्त स्तरांमध्ये काढलेल्या अवलंबनांसह प्रतिमा तयार करणे

नावाची पद्धत वापरून आम्ही दोन टप्प्यात अंतिम प्रतिमा तयार करू मल्टी-स्टेज असेंब्ली . पहिल्या चरणात आपण अवलंबन काढू आणि दुसऱ्या चरणात आपण काढलेल्या अवलंबनांना अंतिम प्रतिमेमध्ये कॉपी करू.

मल्टी-स्टेज बिल्डसाठी आमची डॉकरफाइल सुधारित करू:

# 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 कमांड चालवतो. डायव्ह कमांडला इनपुट म्हणून आम्ही इमेज आयडी किंवा टॅग देऊ शकतो:

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 फाईल तयार करा आणि नंतर डॉकर फाइलमध्ये सूचना निर्दिष्ट करून कंटेनर इमेजमध्ये पॅकेज करा.

आम्ही एक लेयरिंग वैशिष्ट्य सक्षम करून आमचे कंटेनर ऑप्टिमाइझ करण्याकडे देखील पाहिले जे होस्टवर कॅशे केलेल्या वेगळ्या स्तरांमध्ये अवलंबित्व काढते आणि कंटेनरच्या अंमलबजावणी इंजिनमध्ये शेड्यूलिंग वेळेवर अनुप्रयोगाचा पातळ थर लोड केला जातो.

लेखात वापरलेले सर्व स्त्रोत कोड तुम्हाला येथे सापडतील जिथूब .

आदेश संदर्भ

आम्ही या लेखात वापरलेल्या कमांड्सचा एक द्रुत रनडाउन येथे आहे.

संदर्भ साफ करणे:

docker system prune -a

डॉकर फाइल वापरून कंटेनर प्रतिमा तयार करणे:

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

आम्ही स्त्रोत कोडमधून कंटेनर प्रतिमा तयार करतो (डॉकरफाइलशिवाय):

mvn spring-boot:build-image

अवलंबित्व स्तर पहा. ऍप्लिकेशन JAR फाइल तयार करण्यापूर्वी, स्प्रिंग-बूट-मावेन-प्लगइनमध्ये लेयरिंग वैशिष्ट्य सक्षम असल्याची खात्री करा:

java -Djarmode=layertools -jar application.jar list

अवलंबित्व स्तर काढत आहे. ऍप्लिकेशन JAR फाइल तयार करण्यापूर्वी, स्प्रिंग-बूट-मावेन-प्लगइनमध्ये लेयरिंग वैशिष्ट्य सक्षम असल्याची खात्री करा:

 java -Djarmode=layertools -jar application.jar extract

कंटेनर प्रतिमांची सूची पहा

docker images

कंटेनर प्रतिमेच्या आत डावीकडे पहा (डायव्ह टूल स्थापित असल्याची खात्री करा):

dive <image ID or image tag>

स्त्रोत: www.habr.com