Неколку совети за тоа како да го забрзате создавањето на Docker слики. На пример, до 30 секунди

Пред некоја функција да влезе во продукција, во овие денови на сложени оркестратори и CI/CD, има долг пат да се помине од обврзување до тестови и испорака. Претходно, можевте да испраќате нови датотеки преку FTP (никој повеќе не го прави тоа, нели?), а процесот на „распоредување“ траеше неколку секунди. Сега треба да креирате барање за спојување и да чекате долго време функцијата да стигне до корисниците.

Дел од оваа патека е изградба на слика на Докер. Некогаш склопувањето трае неколку минути, некогаш десетици минути, што тешко може да се нарече нормално. Во оваа статија, ќе земеме едноставна апликација која ќе ја спакуваме во слика, ќе примениме неколку методи за да го забрзаме градењето и ќе ги разгледаме нијансите за тоа како функционираат овие методи.

Имаме добро искуство во креирање и поддршка на медиумски веб-страници: ТАСС, Бел, „Нов весник“, Република… Не одамна го проширивме нашето портфолио со објавување на веб-локација за производи Потсетник. И додека новите функции беа брзо додадени и старите грешки беа поправени, бавното распоредување стана голем проблем.

Се распоредуваме во GitLab. Ние собираме слики, ги туркаме во GitLab Registry и ги пренесуваме во производство. Најдолгата работа на оваа листа е составувањето слики. На пример: без оптимизација, секоја изработка на задниот дел траеше 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 .

Ако околината за градење слики е правилно конфигурирана (повеќе за тоа подолу), тогаш кога ќе започне изградбата, Docker веќе ќе има куп кешови на одборот. Наша задача е да научиме како да го користиме кешот, така што изградбата ќе оди што е можно побрзо. Бидејќи претпоставуваме дека извршувањето на изградбата без кеш се случува само еднаш - првиот пат - затоа можеме да игнорираме колку бавно беше тој прв пат. Во тестовите, второто возење на изградбата ни е важно, кога кешовите се веќе загреани и ние сме подготвени да ја испечеме нашата торта. Сепак, некои совети ќе влијаат и на првата изработка.

Ајде да ја ставиме 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

Пред изградбата, docker ги зема сите датотеки во тековниот контекст и ги испраќа до својот демон 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 во Dockerfile. Во нашиот случај, ние користиме слика базирана на Ubuntu која веќе има инсталирано nodejs. И тежи...

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

... речиси гигабајт. Можете значително да ја намалите јачината на звукот со користење на слика базирана на Alpine Linux. Alpine е многу мал Linux. Сликата на докер за nodej базирана на алпски тежи само 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. Во овој случај, датотеките некако треба да се дадат надвор. Можете да извршите некој 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, но почнувајќи од последниот ОД, ќе се подготви нашата конечна слика. Последниот чекор е да го копирате артефактот на нашето собрание во претходниот чекор во конечната слика со 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 с. Зошто повторно да ги инсталирате зависностите секој пат ако тие се менуваат многу ретко? Ајде да откриеме зошто тие не беа кеширани. Поентата е дека 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. Факт е дека во повеќестепеното склопување, добиената слика ќе биде збир на слоеви од последната фаза. Во овој случај, слоевите од претходните слоеви нема да бидат вклучени во сликата. Затоа, кога се користи конечната слика од претходната верзија, Docker нема да може да најде подготвени слоеви за да ја изгради сликата со nodejs (градител фаза). За да се реши овој проблем, се креира средна слика $IMAGE_NAME-builder-stage и се турка до GitHub Packages за да може да се користи во последователна верзија како извор на кеш.

Вкупното време на склопување беше намалено на една и пол минута. Потрошена е половина минута за повлекување на претходните слики.

Преслики

Друг начин да се реши проблемот со чистата кеш на 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