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

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

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

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

Деплой правим на GitLab. Изграждаме образи, пускаме в GitLab Registry и разпределяме на продукцията. В този процес най-дългото е изграждането на образи. Например: без оптимизация всяко изграждане на бекенда отнемаше 14 минути.

В крайна сметка стана ясно, че така не може да продължава, и се заехме да разберем защо образите се изграждат толкова дълго. В крайна сметка успяхме да съкратим времето за изграждане до 30 секунди!

За тази статия, за да не се привързваме към средата на Reminder, ще разгледаме пример за изграждане на празно приложение на Angular. И така, създаваме нашето приложение:

ng n app

Добавяме в него PWA (в крайна сметка, ние сме прогресивни):

ng add @angular/pwa --project app

Докато се изтеглят милион npm пакета, нека разберем как е организиран docker-образът. 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 .
Изпращане на контекста на билд до Docker демон 409MB
Стъпка 1/5 : FROM node:12.16.2
Статус: Изтеглена по-нова версия на образа за node:12.16.2
Стъпка 2/5 : WORKDIR /app
Стъпка 3/5 : COPY . .
Стъпка 4/5 : RUN npm ci
добавени 1357 пакета за 22.47s
Стъпка 5/5 : RUN npm run build --prod
Дата: 2020-04-16T19:20:09.664Z - Хаш: fffa0fddaa3425c55dd3 - Време: 37581ms
Успешно построен c8c279335f46
Успешно етикетирано app:latest

реално 5m4.541s
потребител 0m0.000s
система 0m0.000s

Променяме съдържанието на src/index.html и стартираме за втори път.

$ time docker build -t app .
Изпращане на контекста на билд до Docker демон 409MB
Стъпка 1/5 : FROM node:12.16.2
Стъпка 2/5 : WORKDIR /app
 ---> Използване на кеш
Стъпка 3/5 : COPY . .
Стъпка 4/5 : RUN npm ci
добавени 1357 пакета за 22.47s
Стъпка 5/5 : RUN npm run build --prod
Дата: 2020-04-16T19:26:26.587Z - Хаш: fffa0fddaa3425c55dd3 - Време: 37902ms
Успешно построен 79f335df92d3
Успешно етикетирано app:latest

реално 3m33.262s
потребител 0m0.000s
система 0m0.000s

За да видим дали образът ни е успешен, изпълняваме командата docker images:

REPOSITORY   TAG      IMAGE ID       CREATED              SIZE
app          latest   79f335df92d3   Преди около минута   1.74GB

Преди изграждането Docker взима всички файлове от текущия контекст и ги изпраща на своя демон. Изпращане на контекста за изграждане на Docker демона 409MB. Контекстът за изграждане се посочва като последен аргумент на командата build. В нашия случай това е текущата директория — «.», и Docker изтегля всичко, което имаме в тази папка. 409 MB е много; нека помислим как можем да го намалим.

Намаляване на контекста

За да намалим контекста, имаме два варианта. Или да сложим всички файлове, необходими за изграждане, в отделна папка и да посочим контекста на Docker именно към този каталог. Това не винаги може да е удобно, затова имаме възможност да посочим изключения: какво не трябва да се включва в контекста. За това ще добавим файл .dockerignore в проекта и ще посочим, какво не е нужно за изграждане:

.git
/node_modules

и ще стартираме изграждането отново:

$ time docker build -t app .
Изпращане на контекста за изграждане на Docker демона 607.2kB
Стъпка 1/5 : FROM node:12.16.2
Стъпка 2/5 : WORKDIR /app
 ---> Използване на кеша
Стъпка 3/5 : COPY . .
Стъпка 4/5 : RUN npm ci
добавени 1357 пакета за 22.47s
Стъпка 5/5 : RUN npm run build --prod
Дата: 2020-04-16T19:33:54.338Z - Хеш: fffa0fddaa3425c55dd3 - Време: 37313ms
Успешно построен 4942f010792a
Успешно тагнат app:latest

реално 1m47.763s
потребител 0m0.000s
система 0m0.000s

607.2 Кбайта — значително по-добре от 409 MB. Освен това сме намалили размера на образа от 1.74 до 1.38 Гбайта:

РЕПОЗИТОРИЙ   ТАГ      ID НА ОБРАЗА       СЪЗДАДЕН         РАЗМЕР
app          latest   4942f010792a   преди 3 минути   1.38GB

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

Използване на Alpine

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

$ docker images -a | grep node
node 12.16.2 406aa3abbc6c преди 17 минути 916MB

… почти гигабайт. Значително може да се намали обемът, използвайки образ, основан на Alpine Linux. Alpine е изключително малък Linux. Docker-образ за 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:

РЕПОЗИТОРИЙ   ТАГ      ID НА ОБРАЗА       СЪЗДАДЕН          РАЗМЕР
app          latest   aa031edc315a   преди 22 минути   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. Но ще направим нещата по-просто. Познайте руската дума, в която има четири букви „ы“. Правилно! Ынжыныксы. Вземаме образ с nginx, слагаме в него папката dist и малък конфигурационен файл:

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

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

Това всичко ще ни помогне да направим multi-stage build. Ще променим нашия 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 .

Сега имаме две инструкции OT в 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 Гбайт на 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.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 .
Изпращане на контекста на строежа на Docker даемона 608.8kB
Стъпка 1/12 : FROM node:12.16.2-alpine3.11 as builder
Стъпка 2/12 : RUN apk --no-cache --update --virtual build-dependencies add python make g++
 ---> Използване на кеша
Стъпка 3/12 : WORKDIR /app
 ---> Използване на кеша
Стъпка 4/12 : COPY package*.json ./
 ---> Използване на кеша
Стъпка 5/12 : RUN npm ci
 ---> Използване на кеша
Стъпка 6/12 : COPY . .
Стъпка 7/12 : RUN npm run build --prod
Дата: 2020-04-16T21:29:44.770Z - Хеш: fffa0fddaa3425c55dd3 - Време: 38287ms
 ---> 1b9448c73558
Стъпка 8/12 : FROM nginx:stable-alpine
Стъпка 9/12 : WORKDIR /app
 ---> Използване на кеша
Стъпка 10/12 : RUN rm /etc/nginx/conf.d/default.conf
 ---> Използване на кеша
Стъпка 11/12 : COPY nginx/static.conf /etc/nginx/conf.d
 ---> Използване на кеша
Стъпка 12/12 : COPY --from=builder /app/dist/app .
Успешно построен a44dd7c217c3
Успешно означен app:latest

реално 0m46.497s
потребител 0m0.000s
система 0m0.000s

46 секунди вместо 3 минути — значително по-добре! Важен е правилния ред на слоевете: първо копираме онова, което не се променя, след това онова, което рядко се променя, а накрая — онова, което се променя често.

Следва малко информация за изграждането на образи в CI/CD системи.

Използване на предишни образи за кеш

Ако използваме SaaS решение за изграждане, локалният кеш на Docker може да бъде чист и неопетнен. За да има откъде 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 (етап builder). За да решим този проблем, се създава междинен образ $IMAGE_NAME-builder-stage и се изпраща в GitHub Packages, за да може да се използва в следващото изграждане като източник на кеш.

Общото време за изграждане е намалено на 1,5 минути. Половин минута се изразходва за изтегляне на предишните образи.

Предварително изграждане на образи

Друг начин за разрешаване на проблема с чистия кеш на Docker е да изнесем част от слоевете в друг Dockerfile, да го изградим отделно, да го качим в Container Registry и да го използваме като родителски.

Създаваме свой образ на 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
...

В нашия пример времето за сглобяване не намаля, но предварително създадените образи могат да бъдат полезни, ако имате много проекти и във всеки от тях е необходимо да инсталирате същите зависимости.

Разгледахме няколко метода за ускоряване на изграждането на docker образи. Ако искате да деплойвате бързо, опитайте да приложите в проекта си:

• намаляване на контекста;
• използване на малки родителски образи;
• мултистейдж сглобяване;
• смяна на реда на инструкциите в Dockerfile, за да се използва кеша ефективно;
• настройка на кеша в CI/CD системите;
• предварително създаване на образи.

Надявам се, че с примера ще стане по-ясно как работи Docker и ще можете оптимално да настроите своя деплой. За да експериментирате с примерите от статията, е създаден репозиторий. https://github.com/devopsprodigy/test-docker-build.

Източник: habr.com