Няколко съвета как да ускорите изграждането на 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.38GB:

REPOSITORY   TAG      IMAGE ID       CREATED         SIZE
app          latest   4942f010792a   преди 3 минути   1.38GB

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

Използваме Alpine

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

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

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

REPOSITORY   TAG      IMAGE ID       CREATED          SIZE
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;
    }
}

Това ще стане благодарение на многоетапната сборка. Ще променим нашия 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 ГБ до 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. Защо всеки път да инсталираме отново зависимостите, когато те рядко се променят? Нека да разберем защо те не бяха кеширани. Фактът е, че Докер проверява слой по слой, дали командата и свързаните с нея файлове са се променили. На четвърта стъпка копираме всички файлове на нашия проект и сред тях, разбира се, има промени, така че Докер не само че не взема от кеша този слой, но и всички последващи! Нека да внесем незначителни изменения в 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 решение, локалният кеш на Докер може да бъде чист и свеж. За да може Докер да се сдобие с готови слоеве, дайте му предишно събрания образ.

Нека разгледаме за пример изграждането на нашето приложение в 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, за да може да се използва в последващото изграждане като източник на кеш.

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

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

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