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

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

Част от този път е изграждането на Docker изображение. Понякога сглобяването продължава минути, понякога десетки минути, което трудно може да се нарече нормално. В тази статия ще вземем просто приложение, което ще опаковаме в изображение, ще приложим няколко метода за ускоряване на изграждането и ще разгледаме нюансите на това как работят тези методи.

Имаме добър опит в създаването и поддръжката на медийни уебсайтове: ТАСС, The Bell, "Нов вестник", Република… Неотдавна разширихме нашето портфолио, като пуснахме продуктов уебсайт Напомняне. И докато нови функции бяха добавени бързо и старите грешки бяха коригирани, бавното внедряване се превърна в голям проблем.

Разполагаме в GitLab. Ние събираме изображения, изпращаме ги в регистъра на GitLab и ги пускаме в производство. Най-дългото нещо в този списък е сглобяването на изображения. Например: без оптимизация всяка бекенд компилация отне 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

Нека се опитаме да намалим още повече размера на изображението.

Използваме Alpine

Друг начин да спестите от размера на изображението е да използвате малко родителско изображение. Родителският образ е образът, на базата на който се изготвя нашият образ. Долният слой се определя от командата FROM в Dockerfile. В нашия случай използваме базирано на Ubuntu изображение, което вече има инсталиран nodejs. И тежи...

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

... почти гигабайт. Можете значително да намалите силата на звука, като използвате изображение, базирано на Alpine Linux. Alpine е много малък Linux. Докер изображението за nodejs, базирано на alpine, тежи само 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". вярно! Инжиникси. Да вземем изображение с 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 вътре в контейнера, където работи 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.338s. Защо да преинсталирате зависимости всеки път, ако се променят много рядко? Нека да разберем защо не са били кеширани. Въпросът е, че 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