ڈوکر امیجز کی تعمیر کو تیز کرنے کے بارے میں کچھ نکات۔ مثال کے طور پر، 30 سیکنڈ تک

اس سے پہلے کہ کوئی فیچر تیار ہو جائے، پیچیدہ آرکیسٹریٹرز اور CI/CD کے ان دنوں میں، ٹیسٹ اور ڈیلیوری تک کمٹمنٹ سے لے کر بہت طویل سفر طے کرنا ہے۔ پہلے، آپ FTP کے ذریعے نئی فائلیں اپ لوڈ کر سکتے تھے (اب ایسا کوئی نہیں کرتا، ٹھیک ہے؟)، اور "تعیناتی" کے عمل میں سیکنڈ لگتے تھے۔ اب آپ کو انضمام کی درخواست بنانے کی ضرورت ہے اور فیچر کے صارفین تک پہنچنے کے لیے طویل انتظار کرنا ہوگا۔

اس راستے کا ایک حصہ ڈوکر امیج بنا رہا ہے۔ بعض اوقات اسمبلی منٹوں تک چلتی ہے، کبھی دسیوں منٹ، جسے شاید ہی عام کہا جا سکے۔ اس آرٹیکل میں، ہم ایک سادہ ایپلیکیشن لیں گے جسے ہم ایک تصویر میں پیک کریں گے، تعمیر کو تیز کرنے کے لیے کئی طریقے استعمال کریں گے، اور ان طریقوں کے کام کرنے کی باریکیوں کو دیکھیں گے۔

ہمارے پاس میڈیا ویب سائٹس بنانے اور اس کی حمایت کرنے کا اچھا تجربہ ہے: TASS, بیل, "نیا اخبار", جمہوریہ… کچھ عرصہ قبل ہم نے ایک پروڈکٹ ویب سائٹ جاری کرکے اپنے پورٹ فولیو کو بڑھایا یاد دہانی. اور جب کہ نئی خصوصیات تیزی سے شامل کی گئیں اور پرانے کیڑے ٹھیک کیے گئے، سست تعیناتی ایک بڑا مسئلہ بن گئی۔

ہم GitLab میں تعینات کرتے ہیں۔ ہم تصاویر جمع کرتے ہیں، انہیں GitLab رجسٹری میں دھکیلتے ہیں اور انہیں پروڈکشن کے لیے رول آؤٹ کرتے ہیں۔ اس فہرست میں سب سے لمبی چیز تصاویر کو جمع کرنا ہے۔ مثال کے طور پر: اصلاح کے بغیر، ہر بیک اینڈ کی تعمیر میں 14 منٹ لگے۔

آخر میں، یہ واضح ہو گیا کہ ہم مزید اس طرح نہیں رہ سکتے، اور ہم یہ جاننے کے لیے بیٹھ گئے کہ تصاویر کو جمع کرنے میں اتنا وقت کیوں لگ رہا ہے۔ نتیجے کے طور پر، ہم اسمبلی کے وقت کو 30 سیکنڈ تک کم کرنے میں کامیاب ہو گئے!

اس مضمون کے لیے، یاد دہانی کے ماحول سے منسلک نہ ہونے کے لیے، آئیے ایک خالی انگولر ایپلی کیشن کو جمع کرنے کی ایک مثال دیکھیں۔ تو آئیے اپنی درخواست بنائیں:

ng n app

اس میں PWA شامل کریں (ہم ترقی پسند ہیں):

ng add @angular/pwa --project app

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

FROM node:12.16.2
WORKDIR /app
COPY . .
RUN npm ci
RUN npm run build --prod

ڈاکر فائل ہدایات کا ایک مجموعہ ہے۔ ان میں سے ہر ایک کو کرنے سے، Docker فائل سسٹم میں ہونے والی تبدیلیوں کو محفوظ کرے گا اور ان کو پچھلے پر چڑھائے گا۔ ہر ٹیم اپنی پرت بناتی ہے۔ اور تیار شدہ تصویر ایک ساتھ مل کر تہوں کی ہے۔

کیا جاننا ضروری ہے: ہر ڈوکر پرت کیش کر سکتی ہے۔ اگر آخری تعمیر کے بعد سے کچھ نہیں بدلا ہے، تو کمانڈ پر عمل کرنے کے بجائے، ڈاکر ایک ریڈی میڈ پرت لے گا۔ چونکہ تعمیر کی رفتار میں بنیادی اضافہ کیش کے استعمال کی وجہ سے ہو گا، اس لیے تعمیر کی رفتار کی پیمائش کرتے وقت ہم خاص طور پر ریڈی میڈ کیشے کے ساتھ تصویر بنانے پر توجہ دیں گے۔ تو، قدم بہ قدم:

1. ہم تصاویر کو مقامی طور پر حذف کر دیتے ہیں تاکہ پچھلے رنز ٹیسٹ کو متاثر نہ کریں۔
   docker rmi $(docker images -q)
2. ہم پہلی بار تعمیر شروع کرتے ہیں۔
   time docker build -t app .
3. ہم src/index.html فائل کو تبدیل کرتے ہیں - ہم ایک پروگرامر کے کام کی نقل کرتے ہیں۔
4. ہم دوسری بار تعمیر چلاتے ہیں۔
   time docker build -t app .

اگر امیجز بنانے کا ماحول صحیح طریقے سے ترتیب دیا گیا ہے (نیچے اس پر مزید)، پھر جب تعمیر شروع ہوتی ہے، تو ڈوکر کے پاس پہلے سے ہی بورڈ پر کیچز کا ایک گروپ ہوگا۔ ہمارا کام یہ سیکھنا ہے کہ کیشے کو کیسے استعمال کیا جائے تاکہ تعمیر جلد سے جلد ہو جائے۔ چونکہ ہم یہ فرض کر رہے ہیں کہ کیشے کے بغیر بلڈ کو چلانا صرف ایک بار ہوتا ہے — پہلی بار — اس لیے ہم اس بات کو نظر انداز کر سکتے ہیں کہ پہلی بار کتنا سست تھا۔ ٹیسٹوں میں، تعمیر کا دوسرا رن ہمارے لیے اہم ہوتا ہے، جب کیچز پہلے ہی گرم ہو جاتے ہیں اور ہم اپنا کیک پکانے کے لیے تیار ہوتے ہیں۔ تاہم، کچھ تجاویز بھی پہلی تعمیر کو متاثر کرے گی.

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

$ time docker build -t app .
Sending build context to Docker daemon 409MB
Step 1/5 : FROM node:12.16.2
Status: Downloaded newer image for node:12.16.2
Step 2/5 : WORKDIR /app
Step 3/5 : COPY . .
Step 4/5 : RUN npm ci
added 1357 packages in 22.47s
Step 5/5 : RUN npm run build --prod
Date: 2020-04-16T19:20:09.664Z - Hash: fffa0fddaa3425c55dd3 - Time: 37581ms
Successfully built c8c279335f46
Successfully tagged app:latest

real 5m4.541s
user 0m0.000s
sys 0m0.000s

ہم src/index.html کے مواد کو تبدیل کرتے ہیں اور اسے دوسری بار چلاتے ہیں۔

$ time docker build -t app .
Sending build context to Docker daemon 409MB
Step 1/5 : FROM node:12.16.2
Step 2/5 : WORKDIR /app
 ---> Using cache
Step 3/5 : COPY . .
Step 4/5 : RUN npm ci
added 1357 packages in 22.47s
Step 5/5 : RUN npm run build --prod
Date: 2020-04-16T19:26:26.587Z - Hash: fffa0fddaa3425c55dd3 - Time: 37902ms
Successfully built 79f335df92d3
Successfully tagged app:latest

real 3m33.262s
user 0m0.000s
sys 0m0.000s

یہ دیکھنے کے لیے کہ آیا ہمارے پاس تصویر ہے، کمانڈ چلائیں۔ docker images:

REPOSITORY   TAG      IMAGE ID       CREATED              SIZE
app          latest   79f335df92d3   About a minute ago   1.74GB

تعمیر کرنے سے پہلے، ڈوکر موجودہ سیاق و سباق میں تمام فائلوں کو لیتا ہے اور انہیں اپنے ڈیمون پر بھیجتا ہے۔ Sending build context to Docker daemon 409MB. بلڈ سیاق و سباق کو بلڈ کمانڈ کی آخری دلیل کے طور پر بیان کیا گیا ہے۔ ہمارے معاملے میں، یہ موجودہ ڈائرکٹری ہے - "."، - اور Docker اس فولڈر میں موجود ہر چیز کو گھسیٹتا ہے۔ 409 MB بہت ہے: آئیے سوچتے ہیں کہ اسے کیسے ٹھیک کیا جائے۔

سیاق و سباق کو کم کرنا

سیاق و سباق کو کم کرنے کے لیے، دو اختیارات ہیں۔ یا اسمبلی کے لیے درکار تمام فائلوں کو الگ فولڈر میں رکھیں اور اس فولڈر کی طرف ڈاکر سیاق و سباق کی نشاندہی کریں۔ یہ ہمیشہ آسان نہیں ہوسکتا ہے، لہذا مستثنیات کی وضاحت کرنا ممکن ہے: سیاق و سباق میں کن چیزوں کو نہیں گھسیٹا جانا چاہیے۔ ایسا کرنے کے لیے، .dockerignore فائل کو پروجیکٹ میں ڈالیں اور اس بات کی نشاندہی کریں کہ تعمیر کے لیے کیا ضرورت نہیں ہے:

.git
/node_modules

اور دوبارہ تعمیر کو چلائیں:

$ time docker build -t app .
Sending build context to Docker daemon 607.2kB
Step 1/5 : FROM node:12.16.2
Step 2/5 : WORKDIR /app
 ---> Using cache
Step 3/5 : COPY . .
Step 4/5 : RUN npm ci
added 1357 packages in 22.47s
Step 5/5 : RUN npm run build --prod
Date: 2020-04-16T19:33:54.338Z - Hash: fffa0fddaa3425c55dd3 - Time: 37313ms
Successfully built 4942f010792a
Successfully tagged app:latest

real 1m47.763s
user 0m0.000s
sys 0m0.000s

607.2 KB 409 MB سے بہت بہتر ہے۔ ہم نے تصویر کا سائز بھی 1.74 سے کم کر کے 1.38 GB کر دیا ہے۔

REPOSITORY   TAG      IMAGE ID       CREATED         SIZE
app          latest   4942f010792a   3 minutes ago   1.38GB

آئیے تصویر کے سائز کو مزید کم کرنے کی کوشش کرتے ہیں۔

ہم الپائن استعمال کرتے ہیں۔

تصویر کے سائز کو بچانے کا دوسرا طریقہ والدین کی چھوٹی تصویر کا استعمال کرنا ہے۔ والدین کی تصویر وہ تصویر ہے جس کی بنیاد پر ہماری تصویر تیار ہوتی ہے۔ نیچے کی پرت کمانڈ کے ذریعہ بیان کی گئی ہے۔ FROM ڈاکر فائل میں۔ ہمارے معاملے میں، ہم اوبنٹو پر مبنی تصویر استعمال کر رہے ہیں جس میں پہلے سے ہی نوڈجز انسٹال ہیں۔ اور اس کا وزن...

$ docker images -a | grep node
node 12.16.2 406aa3abbc6c 17 minutes ago 916MB

... تقریباً ایک گیگا بائٹ۔ آپ الپائن لینکس پر مبنی تصویر کا استعمال کرکے حجم کو نمایاں طور پر کم کرسکتے ہیں۔ الپائن ایک بہت چھوٹا لینکس ہے۔ الپائن پر مبنی نوڈج کے لیے ڈوکر امیج کا وزن صرف 88.5 MB ہے۔ تو آئیے گھروں میں اپنی جاندار تصویر بدل دیں:

FROM node:12.16.2-alpine3.11
RUN apk --no-cache --update --virtual build-dependencies add 
    python 
    make 
    g++
WORKDIR /app
COPY . .
RUN npm ci
RUN npm run build --prod

ہمیں کچھ چیزیں انسٹال کرنی تھیں جو ایپلی کیشن بنانے کے لیے ضروری ہیں۔ ہاں، Angular Python ¯(°_o)/¯ کے بغیر نہیں بنتا

لیکن تصویر کا سائز 150 MB تک گر گیا:

REPOSITORY   TAG      IMAGE ID       CREATED          SIZE
app          latest   aa031edc315a   22 minutes ago   761MB

آئیے اور بھی آگے چلتے ہیں۔

ملٹی اسٹیج اسمبلی

ہر چیز جو تصویر میں ہے وہ نہیں ہے جس کی ہمیں پیداوار میں ضرورت ہے۔

$ docker run app ls -lah
total 576K
drwxr-xr-x 1 root root 4.0K Apr 16 19:54 .
drwxr-xr-x 1 root root 4.0K Apr 16 20:00 ..
-rwxr-xr-x 1 root root 19 Apr 17 2020 .dockerignore
-rwxr-xr-x 1 root root 246 Apr 17 2020 .editorconfig
-rwxr-xr-x 1 root root 631 Apr 17 2020 .gitignore
-rwxr-xr-x 1 root root 181 Apr 17 2020 Dockerfile
-rwxr-xr-x 1 root root 1020 Apr 17 2020 README.md
-rwxr-xr-x 1 root root 3.6K Apr 17 2020 angular.json
-rwxr-xr-x 1 root root 429 Apr 17 2020 browserslist
drwxr-xr-x 3 root root 4.0K Apr 16 19:54 dist
drwxr-xr-x 3 root root 4.0K Apr 17 2020 e2e
-rwxr-xr-x 1 root root 1015 Apr 17 2020 karma.conf.js
-rwxr-xr-x 1 root root 620 Apr 17 2020 ngsw-config.json
drwxr-xr-x 1 root root 4.0K Apr 16 19:54 node_modules
-rwxr-xr-x 1 root root 494.9K Apr 17 2020 package-lock.json
-rwxr-xr-x 1 root root 1.3K Apr 17 2020 package.json
drwxr-xr-x 5 root root 4.0K Apr 17 2020 src
-rwxr-xr-x 1 root root 210 Apr 17 2020 tsconfig.app.json
-rwxr-xr-x 1 root root 489 Apr 17 2020 tsconfig.json
-rwxr-xr-x 1 root root 270 Apr 17 2020 tsconfig.spec.json
-rwxr-xr-x 1 root root 1.9K Apr 17 2020 tslint.json

کے ساتھ docker run app ls -lah ہم نے اپنی تصویر کی بنیاد پر ایک کنٹینر لانچ کیا۔ app اور اس میں حکم پر عمل کیا۔ ls -lahجس کے بعد کنٹینر نے اپنا کام مکمل کر لیا۔

پیداوار میں ہمیں صرف ایک فولڈر کی ضرورت ہے۔ dist. اس صورت میں، فائلوں کو کسی نہ کسی طرح باہر دینے کی ضرورت ہے. آپ nodejs پر کچھ HTTP سرور چلا سکتے ہیں۔ لیکن ہم اسے آسان کر دیں گے۔ ایک روسی لفظ کا اندازہ لگائیں جس کے چار حروف "y" ہیں۔ ٹھیک ہے! Ynzhynyksy. آئیے nginx کے ساتھ ایک تصویر لیں، اس میں ایک فولڈر ڈالیں۔ dist اور ایک چھوٹی سی ترتیب:

server {
    listen 80 default_server;
    server_name localhost;
    charset utf-8;
    root /app/dist;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

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

FROM node:12.16.2-alpine3.11 as builder
RUN apk --no-cache --update --virtual build-dependencies add 
    python 
    make 
    g++
WORKDIR /app
COPY . .
RUN npm ci
RUN npm run build --prod

FROM nginx:1.17.10-alpine
RUN rm /etc/nginx/conf.d/default.conf
COPY nginx/static.conf /etc/nginx/conf.d
COPY --from=builder /app/dist/app .

اب ہمارے پاس دو ہدایات ہیں۔ FROM Dockerfile میں، ان میں سے ہر ایک مختلف تعمیراتی قدم چلاتا ہے۔ ہم نے پہلے کو بلایا builderلیکن آخری FROM سے شروع کرتے ہوئے، ہماری حتمی تصویر تیار کی جائے گی۔ آخری مرحلہ یہ ہے کہ ہماری اسمبلی کے نمونے کو پچھلے مرحلے میں nginx کے ساتھ حتمی تصویر میں کاپی کرنا ہے۔ تصویر کا سائز نمایاں طور پر کم ہو گیا ہے:

REPOSITORY   TAG      IMAGE ID       CREATED          SIZE
app          latest   2c6c5da07802   29 minutes ago   36MB

آئیے اپنی تصویر کے ساتھ کنٹینر چلائیں اور یقینی بنائیں کہ سب کچھ کام کرتا ہے:

docker run -p8080:80 app

-p8080:80 آپشن کا استعمال کرتے ہوئے، ہم نے اپنی میزبان مشین پر پورٹ 8080 کو کنٹینر کے اندر پورٹ 80 پر بھیج دیا جہاں nginx چلتا ہے۔ براؤزر میں کھولیں http://localhost:8080/ اور ہم اپنی درخواست دیکھتے ہیں۔ سب کچھ کام کر رہا ہے!

تصویر کے سائز کو 1.74 GB سے 36 MB تک کم کرنے سے آپ کی ایپلیکیشن کو پروڈکشن تک پہنچانے میں لگنے والے وقت کو نمایاں طور پر کم کر دیا جاتا ہے۔ لیکن آئیے اسمبلی کے وقت پر واپس جائیں۔

$ time docker build -t app .
Sending build context to Docker daemon 608.8kB
Step 1/11 : FROM node:12.16.2-alpine3.11 as builder
Step 2/11 : RUN apk --no-cache --update --virtual build-dependencies add python make g++
 ---> Using cache
Step 3/11 : WORKDIR /app
 ---> Using cache
Step 4/11 : COPY . .
Step 5/11 : RUN npm ci
added 1357 packages in 47.338s
Step 6/11 : RUN npm run build --prod
Date: 2020-04-16T21:16:03.899Z - Hash: fffa0fddaa3425c55dd3 - Time: 39948ms
 ---> 27f1479221e4
Step 7/11 : FROM nginx:stable-alpine
Step 8/11 : WORKDIR /app
 ---> Using cache
Step 9/11 : RUN rm /etc/nginx/conf.d/default.conf
 ---> Using cache
Step 10/11 : COPY nginx/static.conf /etc/nginx/conf.d
 ---> Using cache
Step 11/11 : COPY --from=builder /app/dist/app .
Successfully built d201471c91ad
Successfully tagged app:latest

real 2m17.700s
user 0m0.000s
sys 0m0.000s

تہوں کی ترتیب کو تبدیل کرنا

ہمارے پہلے تین مراحل کیش کیے گئے تھے (اشارہ Using cache)۔ چوتھے مرحلے پر، تمام پروجیکٹ فائلوں کو کاپی کیا جاتا ہے اور پانچویں مرحلے پر انحصار انسٹال ہوتا ہے۔ RUN npm ci - زیادہ سے زیادہ 47.338 سیکنڈ۔ انحصارات کو ہر بار دوبارہ کیوں انسٹال کریں اگر وہ بہت کم تبدیل ہوتے ہیں؟ آئیے معلوم کریں کہ وہ کیش کیوں نہیں ہوئے۔ نقطہ یہ ہے کہ ڈوکر یہ دیکھنے کے لیے تہہ در تہہ جانچ کرے گا کہ آیا کمانڈ اور اس سے وابستہ فائلیں تبدیل ہوئی ہیں۔ چوتھے مرحلے پر، ہم اپنے پروجیکٹ کی تمام فائلوں کو کاپی کرتے ہیں، اور ان میں، یقیناً، تبدیلیاں ہوتی ہیں، اس لیے ڈوکر نہ صرف اس پرت کو کیشے سے نہیں لیتا، بلکہ اس کے بعد کی تمام فائلیں بھی! آئیے Dockerfile میں کچھ چھوٹی تبدیلیاں کرتے ہیں۔

FROM node:12.16.2-alpine3.11 as builder
RUN apk --no-cache --update --virtual build-dependencies add 
    python 
    make 
    g++
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build --prod

FROM nginx:1.17.10-alpine
RUN rm /etc/nginx/conf.d/default.conf
COPY nginx/static.conf /etc/nginx/conf.d
COPY --from=builder /app/dist/app .

پہلے، package.json اور package-lock.json کو کاپی کیا جاتا ہے، پھر انحصار انسٹال ہوتا ہے، اور اس کے بعد ہی پورے پروجیکٹ کو کاپی کیا جاتا ہے۔ اس کے نتیجے میں:

$ time docker build -t app .
Sending build context to Docker daemon 608.8kB
Step 1/12 : FROM node:12.16.2-alpine3.11 as builder
Step 2/12 : RUN apk --no-cache --update --virtual build-dependencies add python make g++
 ---> Using cache
Step 3/12 : WORKDIR /app
 ---> Using cache
Step 4/12 : COPY package*.json ./
 ---> Using cache
Step 5/12 : RUN npm ci
 ---> Using cache
Step 6/12 : COPY . .
Step 7/12 : RUN npm run build --prod
Date: 2020-04-16T21:29:44.770Z - Hash: fffa0fddaa3425c55dd3 - Time: 38287ms
 ---> 1b9448c73558
Step 8/12 : FROM nginx:stable-alpine
Step 9/12 : WORKDIR /app
 ---> Using cache
Step 10/12 : RUN rm /etc/nginx/conf.d/default.conf
 ---> Using cache
Step 11/12 : COPY nginx/static.conf /etc/nginx/conf.d
 ---> Using cache
Step 12/12 : COPY --from=builder /app/dist/app .
Successfully built a44dd7c217c3
Successfully tagged app:latest

real 0m46.497s
user 0m0.000s
sys 0m0.000s

46 منٹ کے بجائے 3 سیکنڈ - بہت بہتر! تہوں کی درست ترتیب اہم ہے: پہلے ہم نقل کرتے ہیں کہ کیا تبدیل نہیں ہوتا، پھر جو شاذ و نادر ہی تبدیل ہوتا ہے، اور آخر میں جو اکثر تبدیل ہوتا ہے۔

اگلا، CI/CD سسٹمز میں امیجز کو جمع کرنے کے بارے میں چند الفاظ۔

کیشے کے لیے پچھلی تصاویر کا استعمال

اگر ہم تعمیر کے لیے کسی قسم کا SaaS حل استعمال کرتے ہیں، تو مقامی Docker cache صاف اور تازہ ہوسکتا ہے۔ ڈوکر کو پکی ہوئی تہوں کو حاصل کرنے کے لیے جگہ دینے کے لیے، اسے پچھلی بنائی گئی تصویر دیں۔

آئیے GitHub ایکشنز میں اپنی ایپلیکیشن بنانے کی ایک مثال لیتے ہیں۔ ہم اس ترتیب کو استعمال کرتے ہیں۔

on:
  push:
    branches:
      - master

name: Test docker build

jobs:
  deploy:
    name: Build
    runs-on: ubuntu-latest
    env:
      IMAGE_NAME: docker.pkg.github.com/${{ github.repository }}/app
      IMAGE_TAG: ${{ github.sha }}

    steps:
    - name: Checkout
      uses: actions/checkout@v2

    - name: Login to GitHub Packages
      env:
        TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        docker login docker.pkg.github.com -u $GITHUB_ACTOR -p $TOKEN

    - name: Build
      run: |
        docker build 
          -t $IMAGE_NAME:$IMAGE_TAG 
          -t $IMAGE_NAME:latest 
          .

    - name: Push image to GitHub Packages
      run: |
        docker push $IMAGE_NAME:latest
        docker push $IMAGE_NAME:$IMAGE_TAG

    - name: Logout
      run: |
        docker logout docker.pkg.github.com

تصویر کو دو منٹ اور 20 سیکنڈ میں جمع کر کے GitHub پیکجز پر دھکیل دیا جاتا ہے:

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

on:
  push:
    branches:
      - master

name: Test docker build

jobs:
  deploy:
    name: Build
    runs-on: ubuntu-latest
    env:
      IMAGE_NAME: docker.pkg.github.com/${{ github.repository }}/app
      IMAGE_TAG: ${{ github.sha }}

    steps:
    - name: Checkout
      uses: actions/checkout@v2

    - name: Login to GitHub Packages
      env:
        TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        docker login docker.pkg.github.com -u $GITHUB_ACTOR -p $TOKEN

    - name: Pull latest images
      run: |
        docker pull $IMAGE_NAME:latest || true
        docker pull $IMAGE_NAME-builder-stage:latest || true

    - name: Images list
      run: |
        docker images

    - name: Build
      run: |
        docker build 
          --target builder 
          --cache-from $IMAGE_NAME-builder-stage:latest 
          -t $IMAGE_NAME-builder-stage 
          .
        docker build 
          --cache-from $IMAGE_NAME-builder-stage:latest 
          --cache-from $IMAGE_NAME:latest 
          -t $IMAGE_NAME:$IMAGE_TAG 
          -t $IMAGE_NAME:latest 
          .

    - name: Push image to GitHub Packages
      run: |
        docker push $IMAGE_NAME-builder-stage:latest
        docker push $IMAGE_NAME:latest
        docker push $IMAGE_NAME:$IMAGE_TAG

    - name: Logout
      run: |
        docker logout docker.pkg.github.com

پہلے ہمیں آپ کو یہ بتانے کی ضرورت ہے کہ دو کمانڈ کیوں لانچ کیے گئے ہیں۔ build. حقیقت یہ ہے کہ ملٹی اسٹیج اسمبلی میں نتیجے میں آنے والی تصویر آخری مرحلے سے پرتوں کا ایک سیٹ ہوگی۔ اس صورت میں، پچھلی پرتوں کی پرتیں تصویر میں شامل نہیں ہوں گی۔ لہذا، پچھلی تعمیر سے حتمی تصویر کا استعمال کرتے وقت، Docker نوڈجز (بلڈر اسٹیج) کے ساتھ امیج بنانے کے لیے تیار پرتیں نہیں ڈھونڈ پائے گا۔ اس مسئلے کو حل کرنے کے لیے ایک انٹرمیڈیٹ امیج بنایا گیا ہے۔ $IMAGE_NAME-builder-stage اور اسے GitHub پیکجز کی طرف دھکیل دیا جاتا ہے تاکہ اسے بعد کی تعمیر میں بطور کیش سورس استعمال کیا جا سکے۔

اسمبلی کا کل وقت ڈیڑھ منٹ رہ گیا۔ پچھلی تصاویر کھینچنے میں آدھا منٹ صرف ہوتا ہے۔

پری امیجنگ

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

Angular ایپلی کیشن بنانے کے لیے ہم اپنی نوڈج امیج بناتے ہیں۔ پروجیکٹ میں Dockerfile.node بنائیں

FROM node:12.16.2-alpine3.11
RUN apk --no-cache --update --virtual build-dependencies add 
    python 
    make 
    g++

ہم Docker Hub میں ایک عوامی تصویر اکٹھا اور آگے بڑھاتے ہیں:

docker build -t exsmund/node-for-angular -f Dockerfile.node .
docker push exsmund/node-for-angular:latest

اب ہماری مرکزی ڈاکر فائل میں ہم تیار شدہ تصویر کا استعمال کرتے ہیں:

FROM exsmund/node-for-angular:latest as builder
...

ہماری مثال میں، تعمیر کا وقت کم نہیں ہوا، لیکن پہلے سے بنی تصاویر مفید ہو سکتی ہیں اگر آپ کے پاس بہت سے پروجیکٹس ہیں اور ان میں سے ہر ایک میں یکساں انحصار انسٹال کرنا ہے۔

ہم نے ڈوکر امیجز کی تعمیر کو تیز کرنے کے کئی طریقوں کو دیکھا۔ اگر آپ چاہتے ہیں کہ تعیناتی تیزی سے ہو، تو اسے اپنے پروجیکٹ میں استعمال کرنے کی کوشش کریں:

• سیاق و سباق کو کم کرنا؛
• چھوٹے والدین کی تصاویر کا استعمال؛
• ملٹی اسٹیج اسمبلی؛
• کیشے کا موثر استعمال کرنے کے لیے ڈاکر فائل میں ہدایات کی ترتیب کو تبدیل کرنا؛
• CI/CD سسٹمز میں کیش ترتیب دینا؛
• تصاویر کی ابتدائی تخلیق

مجھے امید ہے کہ مثال سے یہ واضح ہو جائے گا کہ ڈوکر کیسے کام کرتا ہے، اور آپ اپنی تعیناتی کو بہتر طریقے سے ترتیب دینے کے قابل ہو جائیں گے۔ مضمون سے مثالوں کے ساتھ کھیلنے کے لیے، ایک ذخیرہ بنایا گیا ہے۔ https://github.com/devopsprodigy/test-docker-build.

ماخذ: www.habr.com