რამდენიმე რჩევა, თუ როგორ უნდა დააჩქაროთ Docker სურათების შექმნა. მაგალითად, 30 წამამდე

სანამ ფუნქცია შევა წარმოებაში, რთული ორკესტრანტებისა და CI/CD-ის დღეებში, დიდი გზაა გასავლელი ვალდებულებიდან ტესტებამდე და მიწოდებამდე. ადრე, თქვენ შეგეძლოთ ახალი ფაილების ატვირთვა FTP-ის საშუალებით (ამას აღარავინ აკეთებს, არა?) და "განლაგების" პროცესს წამები დასჭირდა. ახლა თქვენ უნდა შექმნათ შერწყმის მოთხოვნა და დიდხანს დაელოდოთ ფუნქციის მომხმარებლამდე მისვლას.

ამ გზის ნაწილია Docker გამოსახულების აგება. შეკრება ხან წუთებს გრძელდება, ხან ათეულ წუთს, რასაც ძნელად შეიძლება ვუწოდოთ ნორმალური. ამ სტატიაში ჩვენ ავიღებთ მარტივ აპლიკაციას, რომელსაც შევფუთავთ სურათში, გამოვიყენებთ რამდენიმე მეთოდს მშენებლობის დასაჩქარებლად და გადავხედავთ ამ მეთოდების მუშაობის ნიუანსებს.

ჩვენ გვაქვს კარგი გამოცდილება მედია ვებსაიტების შექმნისა და მხარდაჭერის საქმეში: TASS, Bell, "ახალი გაზეთი", რესპუბლიკა… ცოტა ხნის წინ ჩვენ გავაფართოვეთ ჩვენი პორტფელი პროდუქტის ვებსაიტის გამოქვეყნებით შეხსენება. და სანამ ახალი ფუნქციები სწრაფად დაემატა და ძველი შეცდომები გამოსწორდა, ნელი დანერგვა დიდ პრობლემად იქცა.

ჩვენ განვათავსებთ GitLab-ში. ჩვენ ვაგროვებთ სურათებს, ვაყენებთ მათ GitLab Registry-ში და ვამუშავებთ მათ წარმოებაში. ამ სიაში ყველაზე გრძელი რამ არის სურათების აწყობა. მაგალითად: ოპტიმიზაციის გარეშე, თითოეული backend-ის აშენებას 14 წუთი დასჭირდა.

ბოლოს გაირკვა, რომ ასე ცხოვრება აღარ შეგვეძლო და დავსხედით იმის გასარკვევად, თუ რატომ სჭირდებოდა ამდენი სურათების შეგროვება. შედეგად, ჩვენ შევძელით შეკრების დროის შემცირება 30 წამამდე!

ამ სტატიისთვის, იმისათვის, რომ არ იყოს მიბმული Reminder-ის გარემოსთან, მოდით შევხედოთ ცარიელი Angular აპლიკაციის აწყობის მაგალითს. ასე რომ, მოდით შევქმნათ ჩვენი აპლიკაცია:

ng n app

დაამატეთ მას PWA (ჩვენ პროგრესულები ვართ):

ng add @angular/pwa --project app

სანამ ხდება მილიონი npm პაკეტის ჩამოტვირთვა, მოდით გაერკვნენ, თუ როგორ მუშაობს დოკერის სურათი. Docker უზრუნველყოფს აპლიკაციების შეფუთვის და მათი გაშვების შესაძლებლობას იზოლირებულ გარემოში, რომელსაც ეწოდება კონტეინერი. იზოლაციის წყალობით, შეგიძლიათ ერთდროულად გაუშვათ მრავალი კონტეინერი ერთ სერვერზე. კონტეინერები ვირტუალურ მანქანებზე ბევრად მსუბუქია, რადგან ისინი უშუალოდ სისტემის ბირთვზე მუშაობენ. ჩვენი აპლიკაციით კონტეინერის გასაშვებად, ჯერ უნდა შევქმნათ სურათი, რომელშიც შევფუთავთ ყველაფერს, რაც აუცილებელია ჩვენი აპლიკაციის გასაშვებად. არსებითად, სურათი არის ფაილური სისტემის ასლი. მაგალითად, აიღეთ Dockerfile:

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

Dockerfile არის ინსტრუქციების ნაკრები; თითოეული მათგანის გაკეთებით, Docker შეინახავს ცვლილებებს ფაილურ სისტემაში და გადაფარავს მათ წინაზე. თითოეული გუნდი ქმნის საკუთარ ფენას. და დასრულებული სურათი არის ფენები ერთად გაერთიანებული.

რა მნიშვნელოვანია იცოდეთ: Docker-ის თითოეულ ფენას შეუძლია ქეშირება. თუ არაფერი შეცვლილა ბოლო აშენების შემდეგ, მაშინ ბრძანების შესრულების ნაცვლად, დოკერი მიიღებს მზა ფენას. ვინაიდან აშენების სიჩქარის ძირითადი ზრდა განპირობებული იქნება ქეშის გამოყენებით, აშენების სიჩქარის გაზომვისას ყურადღებას მივაქცევთ კონკრეტულად მზა ქეშით გამოსახულების აგებას. ასე რომ, ეტაპობრივად:

1. ჩვენ ვშლით სურათებს ლოკალურად, რათა წინა გაშვებებმა არ იმოქმედოს ტესტზე.
   docker rmi $(docker images -q)
2. ჩვენ პირველად ვიწყებთ მშენებლობას.
   time docker build -t app .
3. ვცვლით src/index.html ფაილს - ვაბაძავთ პროგრამისტის მუშაობას.
4. მშენებლობას მეორედ ვაწარმოებთ.
   time docker build -t app .

თუ სურათების შესაქმნელად გარემო სწორად არის კონფიგურირებული (დაწვრილებით ამის შესახებ ქვემოთ), მაშინ როდესაც build დაიწყება, Docker-ს უკვე ექნება ქეშის თაიგული ბორტზე. ჩვენი ამოცანაა ვისწავლოთ როგორ გამოვიყენოთ ქეში ისე, რომ მშენებლობა რაც შეიძლება სწრაფად მოხდეს. მას შემდეგ, რაც ჩვენ ვივარაუდებთ, რომ ქეშის გარეშე build-ის გაშვება მხოლოდ ერთხელ ხდება - პირველივე ჯერზე, ამიტომ შეგვიძლია უგულებელვყოთ რამდენად ნელი იყო ეს პირველი შემთხვევა. ტესტებში ჩვენთვის მნიშვნელოვანია კონსტრუქციის მეორე გაშვება, როდესაც ქეშები უკვე გახურებულია და მზად ვართ გამოვაცხოთ ჩვენი ნამცხვარი. თუმცა, ზოგიერთი რჩევა ასევე იმოქმედებს პირველ მშენებლობაზე.

მოდით ჩავდოთ ზემოთ აღწერილი Dockerfile პროექტის საქაღალდეში და დავიწყოთ build. ყველა ჩამონათვალი შეკუმშულია კითხვის სიმარტივისთვის.

$ 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. build კონტექსტი მითითებულია, როგორც build ბრძანების ბოლო არგუმენტი. ჩვენს შემთხვევაში, ეს არის მიმდინარე დირექტორია - “.”, - და Docker გადაათრევს ყველაფერს, რაც გვაქვს ამ საქაღალდეში. 409 MB ბევრია: მოდი ვიფიქროთ როგორ გამოვასწოროთ.

კონტექსტის შემცირება

კონტექსტის შესამცირებლად, არსებობს ორი ვარიანტი. ან მოათავსეთ ასამბლეისთვის საჭირო ყველა ფაილი ცალკე საქაღალდეში და მიუთითეთ დოკერის კონტექსტი ამ საქაღალდეზე. ეს შეიძლება ყოველთვის არ იყოს მოსახერხებელი, ამიტომ შესაძლებელია გამონაკლისების დაზუსტება: რა არ უნდა იყოს ჩათრეული კონტექსტში. ამისათვის ჩადეთ .dockerignore ფაილი პროექტში და მიუთითეთ რა არ არის საჭირო build-ისთვის:

.git
/node_modules

და კვლავ გაუშვით build:

$ 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 გბ-მდე:

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

შევეცადოთ კიდევ უფრო შევამციროთ სურათის ზომა.

ჩვენ ვიყენებთ ალპურს

სურათის ზომის დაზოგვის კიდევ ერთი გზა არის პატარა მშობლის სურათის გამოყენება. მშობლის სურათი არის სურათი, რომლის საფუძველზეც მზადდება ჩვენი სურათი. ქვედა ფენა მითითებულია ბრძანებით FROM Dockerfile-ში. ჩვენს შემთხვევაში, ჩვენ ვიყენებთ Ubuntu-ზე დაფუძნებულ სურათს, რომელსაც უკვე აქვს დაინსტალირებული nodejs. და იწონის...

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

... თითქმის გიგაბაიტი. თქვენ შეგიძლიათ მნიშვნელოვნად შეამციროთ მოცულობა Alpine Linux-ზე დაფუძნებული სურათის გამოყენებით. Alpine არის ძალიან პატარა Linux. დოკერის გამოსახულება nodej-ებისთვის, რომელიც დაფუძნებულია ალპურზე, იწონის მხოლოდ 88.5 მბ. მოდით შევცვალოთ ჩვენი ცოცხალი სურათი სახლებში:

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 მბ-მდე:

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. ამ შემთხვევაში, ფაილები რატომღაც უნდა მიეცეს გარეთ. შეგიძლიათ გაუშვათ ზოგიერთი 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-ში თითოეული მათგანი აწარმოებს განსხვავებულ build-ის საფეხურს. პირველს დავურეკეთ 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 გბ-დან 36 მბ-მდე მნიშვნელოვნად ამცირებს თქვენი განაცხადის წარმოებამდე მიტანის დროს. მაგრამ მოდით დავუბრუნდეთ შეკრების დროს.

$ 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 წმ. რატომ ხელახლა დააინსტალიროთ დამოკიდებულებები ყოველ ჯერზე, თუ ისინი ძალიან იშვიათად იცვლება? მოდი გავარკვიოთ, რატომ არ იქნა შენახული ისინი. საქმე იმაშია, რომ Docker ფენა-ფენად შეამოწმებს, შეიცვალა თუ არა ბრძანება და მასთან დაკავშირებული ფაილები. მეოთხე ეტაპზე ჩვენ ვაკოპირებთ ჩვენი პროექტის ყველა ფაილს და მათ შორის, რა თქმა უნდა, არის ცვლილებები, ასე რომ, Docker არა მხოლოდ არ იღებს ამ ფენას ქეშიდან, არამედ ყველა შემდგომში! მოდით შევიტანოთ მცირე ცვლილებები 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 ქეში შეიძლება იყოს სუფთა და ახალი. დოკერს რომ მივცეთ ადგილი გამომცხვარი ფენების მისაღებად, მიეცით მას წინა აშენებული სურათი.

ავიღოთ GitHub Actions-ში ჩვენი აპლიკაციის აგების მაგალითი. ჩვენ ვიყენებთ ამ კონფიგურაციას

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

სურათი იკრიბება და გადადის GitHub Packages-ში ორ წუთსა და 20 წამში:

ახლა მოდით შევცვალოთ კონსტრუქცია ისე, რომ ქეში გამოყენებული იყოს წინა აშენებულ სურათებზე დაყრდნობით:

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. ფაქტია, რომ მრავალსაფეხურიანი ასამბლეის შედეგად მიღებული სურათი იქნება ფენების ნაკრები ბოლო ეტაპიდან. ამ შემთხვევაში, წინა ფენების ფენები არ იქნება ჩართული სურათში. ამიტომ, წინა build-ის საბოლოო სურათის გამოყენებისას, Docker ვერ იპოვის მზა ფენებს გამოსახულების ასაგებად nodejs-ით (მშენებლის ეტაპი). ამ პრობლემის გადასაჭრელად იქმნება შუალედური სურათი $IMAGE_NAME-builder-stage და გადადის GitHub Packages-ზე, რათა მისი გამოყენება შემდგომ build-ში ქეშის წყაროდ შეიძლება.

მთლიანი შეკრების დრო შემცირდა წუთნახევარამდე. ნახევარი წუთი იხარჯება წინა სურათების ასაღებად.

წინასწარი ვიზუალიზაცია

Docker-ის სუფთა ქეშის პრობლემის გადაჭრის კიდევ ერთი გზაა ზოგიერთი ფენის სხვა Dockerfile-ში გადატანა, ცალკე აშენება, კონტეინერების რეესტრში ჩასმა და მისი მშობლის გამოყენება.

ჩვენ ვქმნით საკუთარ nodejs სურათს 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

ახლა ჩვენს მთავარ Dockerfile-ში ვიყენებთ დასრულებულ სურათს:

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

ჩვენს მაგალითში, აშენების დრო არ შემცირდა, მაგრამ წინასწარ აშენებული სურათები შეიძლება სასარგებლო იყოს, თუ ბევრი პროექტი გაქვთ და თითოეულ მათგანში უნდა დააინსტალიროთ იგივე დამოკიდებულებები.

ჩვენ გადავხედეთ რამდენიმე მეთოდს დოკერის სურათების აგების დაჩქარების მიზნით. თუ გსურთ, რომ განლაგება სწრაფად მოხდეს, სცადეთ გამოიყენოთ ეს თქვენს პროექტში:

• კონტექსტის შემცირება;
• მცირე ზომის მშობლის სურათების გამოყენება;
• მრავალსაფეხურიანი შეკრება;
• Dockerfile-ში ინსტრუქციების თანმიმდევრობის შეცვლა ქეშის ეფექტურად გამოყენების მიზნით;
• ქეშის დაყენება CI/CD სისტემებში;
• სურათების წინასწარი შექმნა.

იმედი მაქვს, მაგალითი უფრო ნათელს გახდის როგორ მუშაობს Docker და თქვენ შეძლებთ თქვენი განლაგების ოპტიმალურად კონფიგურაციას. სტატიიდან მაგალითებთან თამაშის მიზნით, შეიქმნა საცავი https://github.com/devopsprodigy/test-docker-build.

წყარო: www.habr.com