پرو هوسٽر > بلاگ > انتظاميه > اسپرنگ بوٽ ايپليڪيشن لاءِ آپٽمائزڊ ڊڪر تصويرون ٺاهڻ

اسپرنگ بوٽ ايپليڪيشن لاءِ آپٽمائزڊ ڊڪر تصويرون ٺاهڻ

ڪنٽينر هڪ ايپليڪيشن کي پيڪنگ ڪرڻ جو پسنديده وسيلو بڻجي چڪا آهن ان جي سڀني سافٽ ويئر ۽ آپريٽنگ سسٽم جي انحصار سان ۽ پوءِ انهن کي مختلف ماحول ۾ پهچائڻ.

هي آرٽيڪل اسپرنگ بوٽ ايپليڪيشن کي ڪنٽرول ڪرڻ لاءِ مختلف طريقن تي مشتمل آهي:

  • ڊاکر فائل استعمال ڪندي ڊڪر تصوير ٺاهڻ،
  • Cloud-Native Buildpack استعمال ڪندي ذريعن مان هڪ OCI تصوير ٺاهڻ،
  • ۽ رن-ٽائم تصويري اصلاح جي ذريعي JAR جي حصن کي مختلف تہن ۾ الڳ ڪري گھڻن سطحن جا اوزار استعمال ڪندي.

 ڪوڊ مثال

هي آرٽيڪل ڪم ڪندڙ ڪوڊ مثال سان گڏ آهي GitHub تي .

ڪنٽينر اصطلاحات

اسان مضمون ۾ استعمال ٿيل ڪنٽينر اصطلاحن سان شروع ڪنداسين:

  • ڪنٽينر جي تصوير: مخصوص فارميٽ جي فائل. اسان بلڊ ٽول کي هلائڻ سان اسان جي ايپليڪيشن کي ڪنٽينر جي تصوير ۾ تبديل ڪنداسين.
  • ڪنٽرول: ڪنٽينر جي تصوير جو هڪ قابل عمل مثال.
  • ڪنٽينر انجڻ: ڊيمون عمل ڪنٽينر کي هلائڻ لاء ذميوار آهي.
  • ڪنٽينر ميزبان: ميزبان ڪمپيوٽر جنهن تي ڪنٽينر انجڻ هلندي آهي.
  • ڪنٽينر رجسٽري: عام جڳھ جيڪو ڪنٽينر جي تصوير کي شايع ڪرڻ ۽ ورهائڻ لاءِ استعمال ڪيو ويو.
  • OCI معيار: اوپن ڪنٽينر جي شروعات (OCI) لينڪس فائونڊيشن جي اندر ٺهيل هڪ هلڪو وزن، اوپن گورننس ڍانچي آهي. OCI تصويري وضاحت ڪنٽينر جي تصوير ۽ رن ٽائم فارميٽ لاءِ صنعت جي معيار کي بيان ڪري ٿي انهي کي يقيني بڻائڻ لاءِ ته سڀئي ڪنٽينر انجڻ هلائي سگھن ٿيون ڪنٽينر تصويرون ڪنهن به بلڊ ٽول پاران ٺاهيل.

ايپليڪيشن کي ڪنٽرول ڪرڻ لاءِ، اسان پنهنجي ايپليڪيشن کي ڪنٽينر واري تصوير ۾ لپيٽيون ٿا ۽ ان تصوير کي شيئر ٿيل رجسٽري ۾ شايع ڪريون ٿا. ڪنٽينر رن ٽائيم هن تصوير کي رجسٽري مان ٻيهر حاصل ڪري ٿو، ان کي پيڪ ڪري ٿو، ۽ ان جي اندر ايپليڪيشن کي هلائي ٿو.

اسپرنگ بوٽ جو نسخو 2.3 OCI تصويرون ٺاهڻ لاءِ پلگ ان مهيا ڪري ٿو.

Docker عام طور تي استعمال ٿيل ڪنٽينر تي عمل درآمد آھي، ۽ اسان پنھنجي مثالن ۾ ڊڪر استعمال ڪندا آھيون، تنھنڪري ھن مضمون ۾ ايندڙ سڀني ڪنٽينر حوالن جو حوالو ڏنو ويندو Docker.

ھڪڙي ڪنٽينر جي تصوير ٺاھيو روايتي طريقي سان

اسپرنگ بوٽ ايپليڪيشنن لاءِ ڊاڪر تصويرون ٺاهڻ تمام آسان آهي Docker فائل ۾ ڪجھ هدايتون شامل ڪندي.

اسان پهريون ڀيرو هڪ قابل عمل JAR فائل ٺاهيو ۽، Docker فائل جي هدايتن جي حصي جي طور تي، ضروري سيٽنگون لاڳو ڪرڻ کان پوء بيس JRE تصوير جي مٿان عمل ڪندڙ JAR فائل کي نقل ڪريو.

اچو ته اسان جي اسپرنگ ايپليڪيشن تي ٺاهي بهار جي شروعات انحصار سان 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"]

اسان جي ڊاکر فائل ۾ بنيادي تصوير شامل آهي adoptopenjdk، جنهن جي چوٽي تي اسان پنهنجي JAR فائل کي نقل ڪريون ۽ پوءِ پورٽ کوليو، 8080جيڪو درخواستن لاءِ ٻڌندو.

ايپليڪيشن جي تعمير

پهرين توهان کي Maven يا Gradle استعمال ڪندي ايپليڪيشن ٺاهڻ جي ضرورت آهي. هتي اسان Maven استعمال ڪريون ٿا:

mvn clean package

هي ايپليڪيشن لاء هڪ قابل عمل JAR فائل ٺاهي ٿو. اسان کي ضرورت آهي ته هن عملدار JAR کي Docker تصوير ۾ Docker انجڻ تي هلائڻ لاءِ.

هڪ ڪنٽينر تصوير ٺاهي

اسان پوءِ هن ايگزيڪيوٽوبل JAR فائل کي ڊاڪر تصوير ۾ ڪمانڊ ذريعي هلائي ڇڏيو docker buildپروجيڪٽ جي روٽ ڊاريڪٽري مان جنهن ۾ 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

هتي ڊيو ڪمانڊ مان نڪرڻ جو حصو آهي: 

اسپرنگ بوٽ ايپليڪيشن لاءِ آپٽمائزڊ ڊڪر تصويرون ٺاهڻ

جئين اسان ڏسي سگهون ٿا، ايپليڪيشن پرت تصوير جي سائيز جو هڪ اهم حصو ٺاهي ٿو. اسان پنهنجي اصلاح جي حصي طور هيٺين حصن ۾ هن پرت جي سائيز کي گهٽائڻ چاهيون ٿا.

Buildpack استعمال ڪندي هڪ ڪنٽينر تصوير ٺاهڻ

اسيمبلي پيڪيجز (ٺاھ جوڙ) ھڪڙو عام اصطلاح آھي جيڪو مختلف پليٽ فارمن پاران استعمال ڪيو ويندو آھي سروس (PAAS) جي آڇ جي طور تي ھڪڙو ڪنٽينر تصوير ٺاھيو ماخذ ڪوڊ مان. اهو 2011 ۾ Heroku پاران شروع ڪيو ويو ۽ ان کان پوء Cloud Foundry، Google App Engine، Gitlab، Knative ۽ ٻيا ڪيترائي اختيار ڪيا ويا.

اسپرنگ بوٽ ايپليڪيشن لاءِ آپٽمائزڊ ڊڪر تصويرون ٺاهڻ

بادل تعمير پيڪيجز جو فائدو

تصويرون ٺاهڻ لاءِ Buildpack استعمال ڪرڻ جي بنيادي فائدن مان هڪ آهي تصويري ترتيب جي تبديلين کي مرڪزي طور تي منظم ڪري سگھجي ٿو (بلڊر) ۽ بلڊر استعمال ڪندي سڀني ايپليڪيشنن تي پروپيگنڊا.

تعميراتي پيڪيجز مضبوط طور تي پليٽ فارم سان ڳنڍيل هئا. Cloud-Native Buildpacks 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>

اڳيون، اسان هلائيندا آهيون Jib پلگ ان کي استعمال ڪندي Maven ڪمانڊ ايپليڪيشن ٺاهڻ ۽ هڪ ڪنٽينر تصوير ٺاهي. اڳي وانگر، اسان هتي ڪا به ڊڪر فائلون استعمال نه ڪري رهيا آهيون:

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

ٻاھر ڏيکاري ٿو ته ڪنٽينر جي تصوير ٺاھي وئي آھي ۽ رجسٽري ۾ رکيل آھي.

اصلاحي تصويرون ٺاهڻ لاءِ حوصلا ۽ ٽيڪنڪ

اسان وٽ اصلاح جا ٻه مکيه سبب آهن:

  • پيداوار: هڪ ڪنٽينر آرڪيسٽريشن سسٽم ۾، هڪ ڪنٽينر جي تصوير ٻيهر حاصل ڪئي ويندي آهي تصويري رجسٽري کان ميزبان کي ڪنٽينر انجڻ کي هلائيندڙ. اهو عمل پلاننگ سڏيو ويندو آهي. رجسٽري مان وڏيون تصويرون ڪڍڻ جي نتيجي ۾ ڪنٽينر آرڪيسٽريشن سسٽم ۾ ڊگھي شيڊولنگ جي وقت ۽ سي آءِ پائپ لائنن ۾ ڊگھي تعمير وقت.
  • حفاظت: وڏين تصويرن ۾ به ڪمزورين لاءِ وڏو علائقو هوندو آهي.

هڪ Docker تصوير تہن جي اسٽيڪ تي مشتمل آھي، جن مان ھر ھڪ اسان جي Dockerfile ۾ ھدايت جي نمائندگي ڪري ٿو. هر پرت هيٺئين پرت ۾ تبديلين جي ڊيلٽا جي نمائندگي ڪري ٿي. جڏهن اسان رجسٽري مان ڊاکر تصوير ڪڍون ٿا، اهو پرت ۾ ڇڪيو ويندو آهي ۽ ميزبان تي ڪيش ڪيو ويندو آهي.

اسپرنگ بوٽ استعمال ڪري ٿو "ٿلهي JAR" ۾ ڊفالٽ پيڪيجنگ فارميٽ جي طور تي. جڏهن اسان ٿلهي JAR تي نظر وجهون ٿا، اسان ڏسون ٿا ته ايپليڪيشن سڄي JAR جو تمام ننڍڙو حصو ٺاهيندي آهي. هي اهو حصو آهي جيڪو اڪثر تبديل ڪري ٿو. باقي بهار جي فريم ورڪ جي انحصار تي مشتمل آهي.

اصلاح وارو فارمولا اسپرنگ فريم ورڪ جي انحصار کان الڳ سطح تي ايپليڪيشن کي الڳ ڪرڻ جي چوڌاري مرڪز آهي.

انحصار واري پرت، جيڪا ٿلهي JAR فائل جو وڏو حصو ٺاهيندي آهي، صرف هڪ ڀيرو ڊائونلوڊ ڪيو ويندو آهي ۽ ميزبان سسٽم تي ڪيش ڪيو ويندو آهي.

ايپليڪيشن اپڊيٽ ۽ ڪنٽينر شيڊولنگ دوران ايپليڪيشن جي صرف هڪ پتلي پرت ڇڪي ويندي آهي. جيئن هن تصوير ۾ ڏيکاريل آهي:

اسپرنگ بوٽ ايپليڪيشن لاءِ آپٽمائزڊ ڊڪر تصويرون ٺاهڻ

ھيٺين حصن ۾، اسان ڏسنداسين ته ڪيئن ٺاھيو انھن اصلاحي تصويرن کي اسپرنگ بوٽ ايپليڪيشن لاءِ.

Buildpack استعمال ڪندي اسپرنگ بوٽ ايپليڪيشن لاءِ هڪ اصلاحي ڪنٽينر تصوير ٺاهڻ

اسپرنگ بوٽ 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

جيڪڏهن اسان Dive کي هلون ٿا ته نتيجي ۾ آيل تصوير ۾ پرت ڏسڻ لاءِ، اسان ڏسي سگهون ٿا ته ايپليڪيشن پرت (ڳاڙهي رنگ ۾ بيان ڪيل) ڪلوبائيٽ رينج ۾ تمام ننڍي آهي ان جي مقابلي ۾ جيڪا اسان موٽي JAR فارميٽ کي استعمال ڪندي حاصل ڪئي آهي:

اسپرنگ بوٽ ايپليڪيشن لاءِ آپٽمائزڊ ڊڪر تصويرون ٺاهڻ

ڊاکر استعمال ڪندي اسپرنگ بوٽ ايپليڪيشن لاءِ هڪ بهتر ڪنٽينر تصوير ٺاهڻ

هڪ Maven يا Gradle پلگ ان استعمال ڪرڻ جي بدران، اسان پڻ ٺاهي سگهون ٿا هڪ پرت وارو Docker JAR تصوير هڪ Docker فائل سان.

جڏهن اسان ڊاڪر استعمال ڪندا آهيون، اسان کي ٻه اضافي قدم انجام ڏيڻ جي ضرورت آهي تہن کي ڪڍڻ ۽ انهن کي حتمي تصوير ۾ نقل ڪرڻ لاء.

Maven استعمال ڪندي ليئرنگ فعال ٿيڻ کان پوءِ پيدا ٿيندڙ 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

اسان انحصار جي هڪ فهرست ڏسون ٿا جيڪي شامل ڪري سگھجن ٿيون تہ جيئن.

ڊفالٽ پرت:

پرت جو نالو

Contents

dependencies

ڪو به انحصار جنهن جو نسخو SNAPSHOT تي مشتمل ناهي

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 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 سان ۽ پوءِ ٽيگ ٿيل.

آخرڪار، اسان ٺاهيل ڊاکر تصوير جي اندر جي تہن جو معائنو ڪرڻ لاءِ اڳ وانگر ڊيو ڪمانڊ هلائيندا آهيون. اسان هڪ تصوير جي ID يا ٽيگ مهيا ڪري سگهون ٿا جيئن ان پٽ کي ڊيو ڪمانڊ ۾:

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 هڪ ڪنٽينر تصوير ٺاهڻ لاءِ سڌو ذريعو ڪوڊ مان. هي هڪ متبادل آهي ڊڪر استعمال ڪرڻ لاءِ هڪ ڪنٽينر تصوير ٺاهڻ لاءِ معمولي طريقي سان: پهرين هڪ ٿلهي ايگزيڪيوٽوبل JAR فائل ٺاهڻ ۽ پوءِ ڊاڪر فائل ۾ هدايتون بيان ڪندي ان کي ڪنٽينر جي تصوير ۾ پيڪيج ڪرڻ.

اسان پنهنجي ڪنٽينر کي بهتر ڪرڻ تي پڻ غور ڪيو ته هڪ ليئرنگ فيچر کي چالو ڪندي جيڪو انحصار کي ڌار ڌار پرتن ۾ ڇڪي ٿو جيڪي ميزبان تي ڪيش ٿيل آهن ۽ ايپليڪيشن جي هڪ پتلي پرت کي لوڊ ڪيو ويندو آهي شيڊولنگ وقت تي ڪنٽينر جي عملدرآمد انجڻ ۾.

توھان ڳولي سگھوٿا سڀ ماخذ ڪوڊ آرٽيڪل ۾ استعمال ٿيل آھن تي GitHub .

حڪم جو حوالو

هتي حڪمن جو هڪ تڪڙو سلسلو آهي جيڪو اسان هن آرٽيڪل ۾ استعمال ڪيو آهي.

حوالا صاف ڪرڻ:

docker system prune -a

ڊاکر فائل استعمال ڪندي هڪ ڪنٽينر تصوير ٺاهڻ:

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