اسپرنگ بوٹ ایپلی کیشن کے لیے آپٹمائزڈ ڈوکر امیجز بنانا

کنٹینرز کسی ایپلیکیشن کو اس کے تمام سافٹ ویئر اور آپریٹنگ سسٹم کے انحصار کے ساتھ پیک کرنے اور پھر انہیں مختلف ماحول میں پہنچانے کا ترجیحی ذریعہ بن چکے ہیں۔

اس مضمون میں اسپرنگ بوٹ ایپلی کیشن کو کنٹینرائز کرنے کے مختلف طریقوں کا احاطہ کیا گیا ہے:

• ڈوکر فائل کا استعمال کرتے ہوئے ڈوکر امیج بنانا،
• Cloud-Native Buildpack کا استعمال کرتے ہوئے ذریعہ سے OCI امیج بنانا،
• اور JAR کے حصوں کو کثیر درجے کے ٹولز کا استعمال کرتے ہوئے مختلف تہوں میں الگ کرکے رن ٹائم امیج آپٹیمائزیشن۔

 کوڈ کی مثال

یہ مضمون ورکنگ کوڈ کی مثال کے ساتھ ہے۔ GitHub پر .

کنٹینر اصطلاحات

ہم مضمون میں استعمال ہونے والی کنٹینر اصطلاحات سے شروعات کریں گے:

• کنٹینر کی تصویر: ایک مخصوص فارمیٹ کی فائل۔ ہم بلڈ ٹول چلا کر اپنی ایپلیکیشن کو کنٹینر امیج میں تبدیل کر دیں گے۔
• کنٹینر: کنٹینر امیج کی ایک قابل عمل مثال۔
• کنٹینر انجن: کنٹینر چلانے کے لیے ذمہ دار ڈیمون عمل۔
• کنٹینر میزبان: میزبان کمپیوٹر جس پر کنٹینر کا انجن چلتا ہے۔
• کنٹینر رجسٹری: کنٹینر کی تصویر کو شائع اور تقسیم کرنے کے لیے استعمال ہونے والا عمومی مقام۔
• OCI معیار: اوپن کنٹینر انیشی ایٹو (OCI) لینکس فاؤنڈیشن کے اندر تشکیل پانے والا ایک ہلکا پھلکا، اوپن گورننس ڈھانچہ ہے۔ OCI امیج سپیکیفیکیشن کنٹینر امیج اور رن ٹائم فارمیٹس کے لیے صنعت کے معیارات کی وضاحت کرتا ہے تاکہ یہ یقینی بنایا جا سکے کہ تمام کنٹینر انجن کسی بھی تعمیراتی ٹول کے ذریعے تخلیق کردہ کنٹینر امیجز کو چلا سکتے ہیں۔

کسی ایپلیکیشن کو کنٹینرائز کرنے کے لیے، ہم اپنی ایپلیکیشن کو کنٹینر کی تصویر میں لپیٹتے ہیں اور اس تصویر کو مشترکہ رجسٹری میں شائع کرتے ہیں۔ کنٹینر رن ٹائم اس تصویر کو رجسٹری سے بازیافت کرتا ہے، اسے کھولتا ہے، اور اس کے اندر ایپلیکیشن چلاتا ہے۔

اسپرنگ بوٹ کا ورژن 2.3 OCI امیجز بنانے کے لیے پلگ ان فراہم کرتا ہے۔

میں Docker سب سے زیادہ استعمال شدہ کنٹینر کا نفاذ ہے، اور ہم اپنی مثالوں میں Docker کا استعمال کرتے ہیں، لہذا اس مضمون میں کنٹینر کے بعد کے تمام حوالہ جات Docker کا حوالہ دیں گے۔

روایتی طریقے سے کنٹینر کی تصویر بنانا

ڈوکر فائل میں چند ہدایات شامل کرکے اسپرنگ بوٹ ایپلی کیشنز کے لیے ڈوکر امیجز بنانا بہت آسان ہے۔

ہم سب سے پہلے ایک قابل عمل JAR فائل بناتے ہیں اور، Docker فائل کی ہدایات کے حصے کے طور پر، ضروری ترتیبات کو لاگو کرنے کے بعد ایگزیکیوٹیبل JAR فائل کو بیس JRE امیج کے اوپر کاپی کرتے ہیں۔

آئیے اپنی اسپرنگ ایپلیکیشن کو آن بنائیں بہار کی ابتداء انحصار کے ساتھ web, lombokи actuator. ہم ایک API فراہم کرنے کے لیے ایک ریسٹ کنٹرولر بھی شامل کر رہے ہیں۔ 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 کو Docker امیج میں تبدیل کرنے کی ضرورت ہے۔

کنٹینر کی تصویر بنانا

پھر ہم کمانڈ چلا کر اس قابل عمل JAR فائل کو Docker امیج میں ڈال دیتے ہیں۔ 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

یہاں Dive کمانڈ سے آؤٹ پٹ کا حصہ ہے: 

جیسا کہ ہم دیکھ سکتے ہیں، ایپلی کیشن پرت تصویر کے سائز کا ایک اہم حصہ بناتی ہے۔ ہم اپنی اصلاح کے حصے کے طور پر درج ذیل حصوں میں اس پرت کے سائز کو کم کرنا چاہتے ہیں۔

Buildpack کا استعمال کرتے ہوئے کنٹینر کی تصویر بنانا

اسمبلی پیکجز (تعمیر پیک) ایک عام اصطلاح ہے جسے مختلف پلیٹ فارمز بطور سروس (PAAS) پیشکش کے ذریعہ استعمال کیا جاتا ہے تاکہ سورس کوڈ سے کنٹینر امیج بنایا جا سکے۔ اسے ہیروکو نے 2011 میں لانچ کیا تھا اور اس کے بعد سے کلاؤڈ فاؤنڈری، گوگل ایپ انجن، گٹ لیب، کنٹیو اور کئی دوسرے لوگوں نے اسے اپنایا ہے۔

کلاؤڈ بلڈ پیکجز کا فائدہ

تصاویر بنانے کے لیے Buildpack استعمال کرنے کا ایک اہم فائدہ یہ ہے۔ تصویری ترتیب کی تبدیلیوں کو مرکزی طور پر منظم کیا جا سکتا ہے (بلڈر) اور بلڈر کا استعمال کرتے ہوئے تمام ایپلی کیشنز پر پھیلایا جا سکتا ہے۔

تعمیراتی پیکجوں کو مضبوطی سے پلیٹ فارم سے جوڑا گیا تھا۔ Cloud-Native Buildpacks OCI امیج فارمیٹ کو سپورٹ کرتے ہوئے تمام پلیٹ فارمز پر معیاری کاری فراہم کرتے ہیں، جو اس بات کو یقینی بناتا ہے کہ تصویر کو Docker انجن کے ذریعے چلایا جا سکتا ہے۔

اسپرنگ بوٹ پلگ ان کا استعمال

اسپرنگ بوٹ پلگ ان Buildpack کا استعمال کرتے ہوئے ماخذ سے 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ایپلی کیشن بنانے اور کنٹینر کی تصویر بنانے کے مقاصد۔ ہم اس وقت کوئی ڈاکر فائلز استعمال نہیں کر رہے ہیں۔

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 پلگ ان چلاتے ہیں۔ پہلے کی طرح، ہم یہاں کوئی بھی 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 پائپ لائنوں میں طویل تعمیراتی وقت ہوتا ہے۔
• سیکورٹی: بڑی تصاویر میں بھی کمزوریوں کا ایک بڑا علاقہ ہوتا ہے۔

ایک ڈاکر امیج تہوں کے ڈھیر پر مشتمل ہوتا ہے، جن میں سے ہر ایک ہماری ڈاکر فائل میں ایک ہدایت کی نمائندگی کرتا ہے۔ ہر پرت بنیادی پرت میں ہونے والی تبدیلیوں کے ڈیلٹا کی نمائندگی کرتی ہے۔ جب ہم رجسٹری سے ڈوکر امیج کھینچتے ہیں تو اسے تہوں میں کھینچ کر میزبان پر کیش کر دیا جاتا ہے۔

اسپرنگ بوٹ استعمال کرتا ہے۔ "چربی جار" میں پہلے سے طے شدہ پیکیجنگ فارمیٹ کے طور پر۔ جب ہم موٹے JAR کو دیکھتے ہیں، تو ہم دیکھتے ہیں کہ ایپلی کیشن پورے JAR کا ایک بہت چھوٹا حصہ بناتی ہے۔ یہ وہ حصہ ہے جو اکثر بدلتا ہے۔ بقیہ اسپرنگ فریم ورک کے انحصار پر مشتمل ہے۔

اصلاح کا فارمولہ اسپرنگ فریم ورک کے انحصار سے الگ سطح پر ایپلیکیشن کو الگ تھلگ کرنے پر مرکوز ہے۔

انحصار پرت، جو کہ موٹی JAR فائل کا بڑا حصہ بناتی ہے، صرف ایک بار ڈاؤن لوڈ کی جاتی ہے اور میزبان سسٹم پر کیش کی جاتی ہے۔

ایپلی کیشن اپ ڈیٹس اور کنٹینر شیڈولنگ کے دوران ایپلی کیشن کی صرف ایک پتلی پرت کھینچی جاتی ہے۔ جیسا کہ اس خاکہ میں دکھایا گیا ہے:

مندرجہ ذیل حصوں میں، ہم دیکھیں گے کہ اسپرنگ بوٹ ایپلی کیشن کے لیے ان بہتر تصاویر کو کیسے بنایا جائے۔

Buildpack کا استعمال کرتے ہوئے اسپرنگ بوٹ ایپلی کیشن کے لیے ایک آپٹمائزڈ کنٹینر امیج بنانا

اسپرنگ بوٹ 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-imageکنٹینر امیج بنانے کا Maven کا مقصد:

mvn spring-boot:build-image

اگر ہم نتیجے میں آنے والی تصویر میں تہوں کو دیکھنے کے لیے Dive چلاتے ہیں، تو ہم دیکھ سکتے ہیں کہ ایپلی کیشن لیئر (سرخ رنگ میں بیان کردہ) کلو بائٹ رینج میں اس کے مقابلے میں بہت چھوٹی ہے جو ہم نے fat JAR فارمیٹ کا استعمال کرتے ہوئے حاصل کی ہے۔

ڈوکر کا استعمال کرتے ہوئے اسپرنگ بوٹ ایپلی کیشن کے لیے ایک آپٹمائزڈ کنٹینر امیج بنانا

Maven یا Gradle پلگ ان استعمال کرنے کے بجائے، ہم Docker فائل کے ساتھ پرتوں والی 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

ہم انحصار کی ایک فہرست دیکھتے ہیں جو تہوں کے طور پر شامل کیے جا سکتے ہیں۔

پہلے سے طے شدہ پرتیں:

پرت کا نام

مواد

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 کمانڈ کو ان پٹ کے طور پر ایک تصویری 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 کا استعمال کرتے ہوئے دیکھا۔ یہ معمول کے مطابق کنٹینر امیج بنانے کے لیے Docker کا استعمال کرنے کا ایک متبادل ہے: پہلے ایک موٹی ایگزیکیوٹیبل JAR فائل بنانا اور پھر اسے Docker فائل میں ہدایات بتا کر کنٹینر امیج میں پیک کرنا۔

ہم نے ایک لیئرنگ فیچر کو فعال کرکے اپنے کنٹینر کو بہتر بنانے پر بھی غور کیا جو انحصار کو الگ الگ پرتوں میں کھینچتی ہے جو میزبان پر کیش ہوتی ہیں اور ایپلی کیشن کی ایک پتلی پرت کنٹینر کے ایگزیکیوشن انجنوں میں شیڈولنگ کے وقت لوڈ ہوتی ہے۔

آپ مضمون میں استعمال ہونے والے تمام سورس کوڈ کو یہاں پر حاصل کر سکتے ہیں۔ 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