ان کان اڳ جو ڪا خاصيت پيداوار ۾ اچي، پيچيده آرڪيسٽرن ۽ سي آءِ سي ڊي جي انهن ڏينهن ۾، ٽيسٽ ۽ ترسيل تائين ڪمٽمينٽ کان وٺي وڃڻ جو هڪ ڊگهو رستو آهي. اڳي، توهان FTP ذريعي نيون فائلون اپلوڊ ڪري سگهو ٿا (هاڻي ڪو به نٿو ڪري، صحيح؟)، ۽ "تعميراتي" عمل سيڪنڊن ۾ ورتو. هاڻي توهان کي ضم ڪرڻ جي درخواست ٺاهڻ جي ضرورت آهي ۽ خصوصيت جي صارفين تائين پهچڻ لاء هڪ ڊگهو وقت انتظار ڪريو.
هن رستي جو حصو هڪ ڊاکر تصوير ٺاهي رهيو آهي. ڪڏهن اسيمبلي ڪجهه منٽن تائين رهي ٿي، ڪڏهن ڏهن منٽن جي، جنهن کي شايد ئي عام چئي سگهجي. هن آرٽيڪل ۾، اسان هڪ سادي ايپليڪيشن وٺي سگهون ٿا جيڪو اسان هڪ تصوير ۾ پيڪيج ڪنداسين، تعمير کي تيز ڪرڻ لاء ڪيترن ئي طريقن کي لاڳو ڪريو، ۽ انهن طريقن جي ڪم جي نونسن کي ڏسو.
اسان وٽ ميڊيا ويب سائيٽ ٺاهڻ ۽ سپورٽ ڪرڻ ۾ سٺو تجربو آهي:
اسان GitLab تي ترتيب ڏيون ٿا. اسان تصويرون گڏ ڪريون ٿا، انهن کي GitLab رجسٽري ڏانهن ڌڪيو ۽ انهن کي پيداوار ڏانهن وڌايو. هن لسٽ تي سڀ کان ڊگهي شيء تصويرون گڏ ڪرڻ آهي. مثال طور: بغير اصلاح جي، هر پس منظر جي تعمير 14 منٽ ورتي.
آخر ۾، اهو واضح ٿي ويو ته اسان هاڻي هن وانگر نه رهي سگهون ٿا، ۽ اسان اهو معلوم ڪرڻ لاء ويٺا آهيون ته تصويرن کي گڏ ڪرڻ ۾ ايترو ڊگهو ڇو پيو. نتيجي طور، اسان 30 سيڪنڊن کي اسيمبليء جو وقت گھٽائڻ ۾ مدد ڪئي!
هن آرٽيڪل لاءِ، ياد ڏياريندڙ جي ماحول سان ڳنڍڻ جي لاءِ، اچو ته هڪ مثال ڏسون هڪ خالي Angular ايپليڪيشن کي گڏ ڪرڻ جو. سو، اچو ته اسان جي ايپليڪيشن ٺاهي:
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
هڪ Dockerfile هدايتن جو هڪ سيٽ آهي. انهن مان هر هڪ ڪرڻ سان، ڊڪر فائل سسٽم ۾ تبديلين کي بچائيندو ۽ انهن کي پوئين تي اوورلي ڪندو. هر ٽيم پنهنجي پرت ٺاهي. ۽ ختم ٿيل تصوير هڪ ٻئي سان گڏ پرت آهي.
ڇا ڄاڻڻ ضروري آهي: هر Docker پرت ڪيش ڪري سگهي ٿو. جيڪڏهن آخري تعمير کان ڪجھ به تبديل نه ڪيو ويو آهي، پوء حڪم تي عمل ڪرڻ جي بدران، ڊاکر هڪ تيار ٿيل پرت وٺندو. جيئن ته تعمير جي رفتار ۾ بنيادي اضافو ڪيش جي استعمال جي ڪري ٿيندو، جڏهن تعمير جي رفتار کي ماپڻ لاء اسان خاص طور تي ڌيان ڏينداسين هڪ تصوير ٺاهڻ لاء تيار ڪيل ڪيش سان. تنهن ڪري، قدم قدم:
- اسان تصويرن کي مقامي طور تي حذف ڪريون ٿا ته جيئن پوئين رنسون ٽيسٽ کي متاثر نه ڪن.
docker rmi $(docker images -q)
- اسان پهريون ڀيرو تعمير شروع ڪيو.
time docker build -t app .
- اسان src/index.html فائل تبديل ڪريون ٿا - اسان ھڪڙي پروگرامر جي ڪم کي نقل ڪريون ٿا.
- اسان هڪ ٻيو ڀيرو تعمير کي هلائيندا آهيون.
time docker build -t app .
جيڪڏهن تصويرن جي تعمير لاءِ ماحول صحيح ترتيب ڏنل آهي (هن تي وڌيڪ هيٺ ڏنل)، پوءِ جڏهن تعمير شروع ٿئي ٿي، ڊاڪر وٽ اڳ ۾ ئي ڪيش جو هڪ گروپ هوندو. اسان جو ڪم اهو سکڻ آهي ته ڪيش ڪيئن استعمال ڪجي ته جيئن تعمير جلدي ٿي سگهي. جيئن ته اسان اهو فرض ڪري رهيا آهيون ته ڪيش کان سواءِ تعمير هلائڻ صرف هڪ ڀيرو ٿئي ٿو- بلڪل پهريون ڀيرو- تنهنڪري اسان نظرانداز ڪري سگهون ٿا ته اهو پهريون ڀيرو ڪيترو سست هو. تجربن ۾، تعمير جو ٻيو رن اسان لاء اهم آهي، جڏهن ڪيچ اڳ ۾ ئي گرم ٿي ويا آهن ۽ اسان اسان جي ڪيڪ کي پڪڙڻ لاء تيار آهيون. بهرحال، ڪجهه ٽوٽڪا به پهرين تعمير تي اثر انداز ٿيندا.
اچو ته مٿي بيان ڪيل Dockerfile کي پروجيڪٽ فولڊر ۾ رکون ۽ تعمير شروع ڪريو. پڙهڻ جي آسانيءَ لاءِ سڀني لسٽن کي ڳنڍيو ويو آهي.
$ 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
. تعمير جي حوالي سان بيان ڪيو ويو آهي آخري دليل جي طور تي تعمير ڪرڻ واري حڪم کي. اسان جي حالت ۾، هي موجوده ڊاريڪٽري آهي - "."، - ۽ ڊڪر هر شيء کي ڇڪي ٿو جيڪو اسان وٽ هن فولڊر ۾ آهي. 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
Dockerfile ۾. اسان جي حالت ۾، اسان استعمال ڪري رهيا آهيون Ubuntu-based تصوير جيڪا اڳ ۾ ئي نصب ٿيل آهي nodejs. ۽ اهو وزن آهي ...
$ 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
اچو ته اڃا اڳتي وڌون.
Multistage اسيمبلي
هر شي ناهي جيڪا تصوير ۾ آهي جيڪا اسان کي پيداوار ۾ گهربل آهي.
$ 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
. انهي حالت ۾، فائلن کي ڪنهن به صورت ۾ ٻاهر ڏيڻ جي ضرورت آهي. توھان ھلائي سگھوٿا ڪجھ HTTP سرور nodejs تي. پر اسان ان کي آسان بڻائينداسين. هڪ روسي لفظ جو اندازو لڳايو جنهن ۾ چار اکر آهن "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;
}
}
ملٽي اسٽيج تعمير اسان کي اهو سڀ ڪجهه ڪرڻ ۾ مدد ڪندي. اچو ته اسان جي 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 . .
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 ڏانهن ڪنٽينر اندر موڪليو جتي نينڪس هلندو آهي. برائوزر ۾ کوليو
تصوير جي سائيز کي 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.338s. ڇو انحصار کي هر ڀيري ٻيهر انسٽال ڪريو جيڪڏهن اهي تمام گهٽ تبديل ٿين ٿا؟ اچو ته ڄاڻون ته اهي ڪيش ڇو نه ڪيا ويا. نقطو اهو آهي ته ڊاکر پرت ذريعي پرت کي جانچيندو ته ڏسڻ لاءِ ته ڇا ڪمانڊ ۽ ان سان لاڳاپيل فائلون تبديل ٿي ويون آهن. چوٿين قدم تي، اسان اسان جي پروجيڪٽ جي سڀني فائلن کي نقل ڪريون ٿا، ۽ انهن مان، يقينا، تبديليون آهن، تنهن ڪري ڊاکر نه رڳو هن پرت کي ڪيش کان وٺي، پر سڀني کان پوء پڻ! اچو ته 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 حل استعمال ڪندا آهيون، پوء مقامي ڊاکر ڪيش صاف ۽ تازو ٿي سگهي ٿو. ڊاکر کي پڪل پرت حاصل ڪرڻ لاء هڪ جڳهه ڏيڻ لاء، هن کي اڳئين ٺهيل تصوير ڏيو.
اچو ته هڪ مثال وٺون اسان جي ايپليڪيشن ٺاهڻ جو 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
. حقيقت اها آهي ته هڪ multistage اسيمبلي ۾ نتيجو تصوير آخري اسٽيج کان تہن جو هڪ سيٽ ٿيندو. انهي حالت ۾، پوئين تہن مان تہون تصوير ۾ شامل نه ٿينديون. تنهن ڪري، جڏهن پوئين تعمير مان حتمي تصوير استعمال ڪندي، ڊڪرر نوڊجز (بلڊر اسٽيج) سان تصوير کي تعمير ڪرڻ لاء تيار پرت ڳولڻ جي قابل نه هوندا. هن مسئلي کي حل ڪرڻ لاء، هڪ وچولي تصوير ٺاهي وئي آهي $IMAGE_NAME-builder-stage
۽ GitHub پيڪيجز ڏانهن ڌڪيو ويو آهي ته جيئن اهو ايندڙ تعمير ۾ ڪيش ماخذ طور استعمال ڪري سگهجي.
مجموعي اسيمبليءَ جو وقت گهٽجي هڪ اڌ منٽ ڪيو ويو. پوئين تصويرن کي ڇڪڻ ۾ اڌ منٽ لڳندو آهي.
اڳڪٿي ڪرڻ
صاف ڊاکر ڪيش جي مسئلي کي حل ڪرڻ جو هڪ ٻيو طريقو اهو آهي ته ڪجهه پرت کي ٻئي ڊاڪر فائل ۾ منتقل ڪيو وڃي، ان کي الڳ ٺاهيو، ان کي ڪنٽينر رجسٽري ۾ ڌڪيو ۽ ان کي والدين طور استعمال ڪريو.
اسان هڪ Angular ايپليڪيشن ٺاهڻ لاء اسان جي پنهنجي nodejs تصوير ٺاهي. پروجيڪٽ ۾ 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
هاڻي اسان جي مکيه Dockerfile ۾ اسان مڪمل تصوير استعمال ڪندا آهيون:
FROM exsmund/node-for-angular:latest as builder
...
اسان جي مثال ۾، تعمير جو وقت گهٽ نه ٿيو، پر اڳ ۾ ٺهيل تصويرون ڪارائتو ٿي سگهن ٿيون جيڪڏهن توهان وٽ ڪيترائي منصوبا آهن ۽ انهن مان هر هڪ ۾ ساڳئي انحصار کي نصب ڪرڻو پوندو.
اسان ڊاکر تصويرن جي تعمير کي تيز ڪرڻ لاء ڪيترن ئي طريقن کي ڏٺو. جيڪڏھن توھان چاھيو ٿا ته تعیناتي جلدي وڃڻ لاءِ، پنھنجي منصوبي ۾ ھن کي استعمال ڪرڻ جي ڪوشش ڪريو:
- حوالن کي گھٽائڻ؛
- ننڍي والدين جي تصويرن جو استعمال؛
- multistage اسيمبلي؛
- ڪيش جو موثر استعمال ڪرڻ لاءِ Dockerfile ۾ هدايتن جي ترتيب کي تبديل ڪرڻ؛
- CI/CD سسٽم ۾ ڪيش قائم ڪرڻ؛
- تصويرن جي شروعاتي تخليق.
مون کي اميد آهي ته مثال اهو واضح ڪندو ته ڊڪر ڪيئن ڪم ڪندو آهي، ۽ توهان پنهنجي ترتيب کي بهتر طور تي ترتيب ڏيڻ جي قابل هوندا. آرٽيڪل مان مثالن سان راند ڪرڻ لاء، هڪ مخزن ٺاهيو ويو آهي
جو ذريعو: www.habr.com