Docker tasvirlarini yaratishni tezlashtirish bo'yicha ba'zi maslahatlar. Masalan, 30 soniyagacha

Xususiyat ishlab chiqarishga kirishidan oldin, murakkab orkestrlar va CI/CD-ning hozirgi kunlarida sinov va yetkazib berishgacha bo'lgan uzoq yo'l bor. Ilgari siz FTP orqali yangi fayllarni yuklashingiz mumkin edi (endi buni hech kim qilmaydi, to'g'rimi?) va "tarqatish" jarayoni bir necha soniya davom etdi. Endi siz birlashtirish so'rovini yaratishingiz va funksiya foydalanuvchilarga yetib borishini uzoq vaqt kutishingiz kerak.

Ushbu yo'lning bir qismi Docker tasvirini yaratishdir. Ba'zan yig'ilish daqiqalar, ba'zan o'nlab daqiqalar davom etadi, buni oddiy deb atash qiyin. Ushbu maqolada biz oddiy dasturni olamiz, uni tasvirga joylashtiramiz, qurishni tezlashtirish uchun bir nechta usullarni qo'llaymiz va bu usullar qanday ishlashining nuanslarini ko'rib chiqamiz.

Biz media veb-saytlarini yaratish va qo'llab-quvvatlash bo'yicha yaxshi tajribaga egamiz: TASS, Siyoh, "Yangi gazeta", respublika… Yaqinda biz mahsulot veb-saytini chiqarish orqali portfelimizni kengaytirdik Eslatma. Va yangi xususiyatlar tezda qo'shilgan va eski xatolar tuzatilgan bo'lsa-da, sekin o'rnatish katta muammoga aylandi.

Biz GitLab-ga joylashtiramiz. Biz rasmlarni yig'amiz, ularni GitLab registriga suramiz va ishlab chiqarishga chiqaramiz. Ushbu ro'yxatdagi eng uzun narsa tasvirlarni yig'ishdir. Masalan: optimallashtirishsiz har bir backend qurish 14 daqiqa davom etdi.

Oxir-oqibat, biz endi bunday yashay olmasligimiz ma'lum bo'ldi va biz tasvirlarni yig'ish nega uzoq davom etayotganini aniqlash uchun o'tirdik. Natijada biz yig'ish vaqtini 30 soniyagacha qisqartirishga muvaffaq bo'ldik!

Ushbu maqola uchun Reminder muhitiga bog'lanib qolmaslik uchun bo'sh Angular ilovasini yig'ish misolini ko'rib chiqamiz. Shunday qilib, keling, dasturimizni yaratamiz:

ng n app

Unga PWA qo'shing (biz progressivmiz):

ng add @angular/pwa --project app

Bir million npm paketlar yuklab olinayotganda, keling, docker tasviri qanday ishlashini aniqlaylik. Docker ilovalarni paketlash va ularni konteyner deb ataladigan izolyatsiya qilingan muhitda ishga tushirish imkoniyatini beradi. Izolyatsiya tufayli bir serverda bir vaqtning o'zida bir nechta konteynerlarni ishga tushirishingiz mumkin. Konteynerlar virtual mashinalarga qaraganda ancha engilroq, chunki ular to'g'ridan-to'g'ri tizim yadrosida ishlaydi. Ilovamiz bilan konteynerni ishga tushirish uchun avvalo rasm yaratishimiz kerak, unda ilovamiz ishlashi uchun zarur bo'lgan hamma narsani to'playmiz. Aslida, rasm fayl tizimining nusxasi. Masalan, Docker faylini oling:

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

Dockerfile - bu ko'rsatmalar to'plami; Ularning har birini bajarib, Docker fayl tizimidagi o'zgarishlarni saqlaydi va ularni avvalgilariga qo'yadi. Har bir jamoa o'z qatlamini yaratadi. Va tayyor tasvir bir-biriga birlashtirilgan qatlamlardir.

Nimani bilish muhim: har bir Docker qatlami keshlashi mumkin. Agar oxirgi tuzilishdan beri hech narsa o'zgarmagan bo'lsa, u holda buyruqni bajarish o'rniga docker tayyor qatlamni oladi. Qurilish tezligining asosiy o'sishi keshdan foydalanish bilan bog'liq bo'lganligi sababli, qurish tezligini o'lchashda biz tayyor kesh bilan tasvirni yaratishga alohida e'tibor beramiz. Shunday qilib, bosqichma-bosqich:

1. Oldingi ishlar sinovga ta'sir qilmasligi uchun biz rasmlarni mahalliy sifatida o'chirib tashlaymiz.
   docker rmi $(docker images -q)
2. Qurilishni birinchi marta boshlaymiz.
   time docker build -t app .
3. Biz src/index.html faylini o'zgartiramiz - biz dasturchining ishiga taqlid qilamiz.
4. Qurilishni ikkinchi marta bajaramiz.
   time docker build -t app .

Agar tasvirlarni yaratish muhiti to'g'ri sozlangan bo'lsa (quyida bu haqda batafsilroq), keyin qurish boshlanganda, Docker bortida allaqachon bir nechta keshlarga ega bo'ladi. Bizning vazifamiz, qurish imkon qadar tezroq ketishi uchun keshdan qanday foydalanishni o'rganishdir. Qurilishni keshsiz ishga tushirish faqat bir marta - birinchi marta sodir bo'ladi deb taxmin qilganimiz sababli, birinchi marta qanchalik sekin bo'lganiga e'tibor bermasligimiz mumkin. Sinovlarda, qurilishning ikkinchi bosqichi biz uchun muhim bo'lib, keshlar allaqachon qizdirilganda va biz kekimizni pishirishga tayyormiz. Biroq, ba'zi maslahatlar birinchi qurilishga ham ta'sir qiladi.

Keling, yuqorida tavsiflangan Dockerfaylni loyiha papkasiga joylashtiramiz va qurishni boshlaymiz. O'qish qulayligi uchun barcha ro'yxatlar qisqartirilgan.

$ 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

Biz src/index.html tarkibini o'zgartiramiz va uni ikkinchi marta ishga tushiramiz.

$ 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

Bizda rasm bor yoki yo'qligini bilish uchun buyruqni bajaring docker images:

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

Qurilishdan oldin docker joriy kontekstdagi barcha fayllarni oladi va ularni o'z demoniga yuboradi Sending build context to Docker daemon 409MB. Qurilish konteksti qurish buyrug'ining oxirgi argumenti sifatida ko'rsatilgan. Bizning holatda, bu joriy katalog - ".", - va Docker ushbu papkada mavjud bo'lgan barcha narsalarni sudrab olib boradi. 409 MB juda ko'p: keling, uni qanday tuzatish haqida o'ylab ko'raylik.

Kontekstni qisqartirish

Kontekstni kamaytirish uchun ikkita variant mavjud. Yoki yig'ish uchun zarur bo'lgan barcha fayllarni alohida papkaga joylashtiring va docker kontekstini ushbu jildga yo'naltiring. Bu har doim ham qulay bo'lmasligi mumkin, shuning uchun istisnolarni ko'rsatish mumkin: kontekstga nima tortilmasligi kerak. Buning uchun .dockerignore faylini loyihaga qo'ying va qurilish uchun nima kerak emasligini ko'rsating:

.git
/node_modules

va qurilishni qayta ishga tushiring:

$ 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 dan ancha yaxshi. Shuningdek, biz tasvir hajmini 1.74 dan 1.38 GB gacha qisqartirdik:

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

Keling, rasm hajmini yanada kamaytirishga harakat qilaylik.

Biz Alp tog'laridan foydalanamiz

Tasvir hajmini saqlashning yana bir usuli kichik ota-ona tasviridan foydalanishdir. Ota-ona qiyofasi - bu bizning tasvirimiz tayyorlangan tasvirdir. Pastki qatlam buyruq bilan belgilanadi FROM Docker faylida. Bizning holatda, biz allaqachon nodejs o'rnatilgan Ubuntu-ga asoslangan tasvirdan foydalanmoqdamiz. Va og'irligi ...

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

... deyarli bir gigabayt. Alpine Linux asosidagi tasvirdan foydalanib, ovoz balandligini sezilarli darajada kamaytirishingiz mumkin. Alp - juda kichik Linux. Alp tog'lariga asoslangan nodejs uchun docker tasvirining og'irligi bor-yo'g'i 88.5 MB. Shunday qilib, keling, uylardagi jonli tasvirimizni almashtiraylik:

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

Ilovani yaratish uchun zarur bo'lgan ba'zi narsalarni o'rnatishimiz kerak edi. Ha, Angular Python ¯(°_o)/¯siz yaratilmaydi

Ammo tasvir hajmi 150 MB ga tushdi:

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

Keling, yanada uzoqroqqa boraylik.

Ko'p bosqichli yig'ish

Tasvirdagi hamma narsa ishlab chiqarishda bizga kerak bo'lgan narsa emas.

$ 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

Yordamida docker run app ls -lah tasvirimiz asosida konteynerni ishga tushirdik app va undagi buyruqni bajardi ls -lah, shundan so'ng konteyner o'z ishini yakunladi.

Ishlab chiqarishda bizga faqat papka kerak dist. Bunday holda, fayllar qandaydir tarzda tashqarida berilishi kerak. Siz nodejs-da ba'zi HTTP serverlarini ishga tushirishingiz mumkin. Ammo biz buni osonlashtiramiz. To'rtta "y" harfidan iborat ruscha so'zni taxmin qiling. To'g'ri! Ynzhynyksy. Keling, nginx bilan rasmga tushamiz, unga papka qo'yamiz dist va kichik konfiguratsiya:

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

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

Ko'p bosqichli qurilish bularning barchasini bajarishga yordam beradi. Keling, Docker faylimizni o'zgartiraylik:

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 .

Endi bizda ikkita ko'rsatma bor FROM Dockerfile da ularning har biri boshqa qurish bosqichini bajaradi. Birinchisiga qo'ng'iroq qildik builder, lekin oxirgi FROM dan boshlab, bizning yakuniy rasmimiz tayyorlanadi. Oxirgi qadam - oldingi bosqichdagi yig'ilishimizning artefaktini nginx yordamida yakuniy rasmga nusxalash. Rasm hajmi sezilarli darajada kamaydi:

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

Keling, konteynerni rasmimiz bilan ishga tushiramiz va hamma narsa ishlayotganiga ishonch hosil qilamiz:

docker run -p8080:80 app

-p8080:80 opsiyasidan foydalanib, biz asosiy kompyuterimizdagi 8080-portni nginx ishlaydigan konteyner ichidagi 80-portga uzatdik. Brauzerda oching http://localhost:8080/ va biz arizamizni ko'ramiz. Hammasi ishlayapti!

Tasvir hajmini 1.74 GB dan 36 MB gacha qisqartirish ilovangizni ishlab chiqarishga yetkazish vaqtini sezilarli darajada qisqartiradi. Ammo yig'ilish vaqtiga qaytaylik.

$ 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

Qatlamlar tartibini o'zgartirish

Bizning dastlabki uchta qadamimiz keshlangan (maslahat Using cache). To'rtinchi bosqichda barcha loyiha fayllari nusxalanadi va beshinchi bosqichda bog'liqliklar o'rnatiladi RUN npm ci - 47.338 soniyagacha. Agar ular juda kam o'zgarsa, nega har safar bog'liqliklarni qayta o'rnating? Keling, nima uchun ular keshlanmaganligini aniqlaylik. Gap shundaki, Docker buyruq va u bilan bog'liq fayllar o'zgarganligini bilish uchun qatlam-qatlam tekshiradi. To'rtinchi bosqichda biz loyihamizning barcha fayllarini nusxalaymiz va ular orasida, albatta, o'zgarishlar mavjud, shuning uchun Docker nafaqat bu qatlamni keshdan, balki undan keyingi barcha qatlamlarni ham oladi! Keling, Dockerfile-ga kichik o'zgarishlar kiritaylik.

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 .

Birinchidan, package.json va package-lock.json nusxalanadi, keyin bog'liqliklar o'rnatiladi va shundan keyingina butun loyiha nusxalanadi. Natijada:

$ 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 daqiqa o'rniga 3 soniya - ancha yaxshi! Qatlamlarning to'g'ri tartibi muhim: birinchi navbatda biz o'zgarmasligini, keyin kamdan-kam o'zgarganini va nihoyat, tez-tez o'zgarganini nusxalaymiz.

Keyinchalik, CI/CD tizimlarida tasvirlarni yig'ish haqida bir necha so'z.

Kesh uchun oldingi rasmlardan foydalanish

Agar biz qurish uchun qandaydir SaaS yechimidan foydalansak, mahalliy Docker keshi toza va yangi bo'lishi mumkin. Dockerga pishirilgan qatlamlarni olish uchun joy berish uchun unga oldingi qurilgan tasvirni bering.

Keling, GitHub Actions-da ilovamizni yaratishga misol keltiraylik. Biz ushbu konfiguratsiyadan foydalanamiz

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

Tasvir yig'iladi va GitHub paketlariga ikki daqiqa 20 soniyada yuboriladi:

Keling, oldingi qurilgan tasvirlar asosida kesh ishlatilishi uchun qurilishni o'zgartiramiz:

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

Avval ikkita buyruq nima uchun ishga tushirilganligini aytib berishimiz kerak build. Gap shundaki, ko'p bosqichli yig'ilishda natijada olingan tasvir oxirgi bosqichdagi qatlamlar to'plami bo'ladi. Bunday holda, oldingi qatlamlardagi qatlamlar rasmga kiritilmaydi. Shuning uchun, oldingi tuzilishdagi yakuniy tasvirdan foydalanganda, Docker nodejs (quruvchi bosqichi) yordamida tasvirni yaratish uchun tayyor qatlamlarni topa olmaydi. Ushbu muammoni hal qilish uchun oraliq tasvir yaratiladi $IMAGE_NAME-builder-stage va keyingi tuzilishda kesh manbai sifatida foydalanish uchun GitHub paketlariga suriladi.

Umumiy yig'ish vaqti bir yarim daqiqaga qisqartirildi. Oldingi rasmlarni tortib olishga yarim daqiqa sarflanadi.

Oldindan tasvirlash

Toza Docker keshi muammosini hal qilishning yana bir yo'li - ba'zi qatlamlarni boshqa Dockerfaylga ko'chirish, uni alohida qurish, Konteynerlar registriga surish va undan ota-ona sifatida foydalanish.

Angular ilovasini yaratish uchun o'z nodejs tasvirimizni yaratamiz. Loyihada Dockerfile.node yarating

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

Biz Docker Hub-da umumiy tasvirni yig'amiz va suramiz:

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

Endi bizning asosiy Docker faylida biz tayyor rasmdan foydalanamiz:

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

Bizning misolimizda, qurish vaqti kamaymadi, lekin agar sizda ko'plab loyihalaringiz bo'lsa va ularning har birida bir xil bog'liqliklarni o'rnatishingiz kerak bo'lsa, oldindan yaratilgan tasvirlar foydali bo'lishi mumkin.

Biz docker tasvirlarini yaratishni tezlashtirishning bir necha usullarini ko'rib chiqdik. Agar siz tarqatish tezda bajarilishini istasangiz, buni loyihangizda ishlatib ko'ring:

• kontekstni qisqartirish;
• kichik ota-ona tasvirlaridan foydalanish;
• ko'p bosqichli yig'ish;
• keshdan samarali foydalanish uchun Dockerfiledagi ko'rsatmalar tartibini o'zgartirish;
• CI/CD tizimlarida keshni o'rnatish;
• tasvirlarni oldindan yaratish.

Umid qilamanki, misol Docker qanday ishlashini aniqroq qiladi va siz joylashtirishni optimal tarzda sozlashingiz mumkin. Maqoladagi misollar bilan o'ynash uchun ombor yaratildi https://github.com/devopsprodigy/test-docker-build.

Manba: www.habr.com