Några tips om hur man kan snabba upp byggandet av Docker-bilder. Till exempel, upp till 30 sekunder.

Innan en funktion går live, måste den i vår tid av komplexa orkestratorer och CI/CD genomgå en lång väg från commit till tester och leverans. Tidigare kunde man bara ladda upp nya filer via FTP (det är inte så någon gör längre, eller hur?), och processen för "deployment" tog sekunder. Nu måste man skapa en merge request och vänta en betydande tid på att funktionen ska nå användarna.

En del av denna väg är att bygga Docker-bilder. Ibland tar byggandet minuter, ibland – tiotals minuter, vilket är svårt att kalla normalt. I den här artikeln kommer vi att ta ett enkelt program, packa det i en bild, tillämpa några metoder för att snabba upp byggnaden och gå igenom detaljerna för dessa metoder.

Vi har en ganska bra erfarenhet av att skapa och underhålla nyhetssajter: TASS, The Bell, "Ny Tid", Republic… För inte så länge sedan utökade vi vår portfölj genom att lansera sajten Reminder. Och medan vi snabbt finjusterade nya funktioner och fixade gamla buggar blev den långsamma deploymenten ett stort problem.

Vi gör deployment på GitLab. Vi bygger bilder, pushar till GitLab Registry och distribuerar till produktion. Det som tar längst tid i den här listan är byggandet av bilder. Som exempel: utan optimering tog varje backend-bygge 14 minuter.

Till slut blev det uppenbart att vi inte kunde fortsätta så här, och vi satte oss ned för att förstå varför bilderna tog så lång tid att bygga. Vi lyckades i slutändan minska byggtiden till 30 sekunder!

För den här artikeln, för att inte knyta oss till Reminder-miljön, kommer vi att titta på ett exempel på hur man bygger en tom applikation på Angular. Så, låt oss skapa vår applikation:

ng n app

Vi lägger till PWA (vi är ju progressiva):

ng add @angular/pwa --project app

Medan en miljon npm-paket laddas ner, låt oss ta en titt på hur en docker-bild är uppbyggd. Docker ger möjlighet att paketera applikationer och köra dem i en isolerad miljö som kallas container. Tack vare isoleringen kan många containrar köras samtidigt på en och samma server. Containrar är betydligt lättare än virtuella maskiner eftersom de körs direkt på systemets kärna. För att köra en container med vår applikation behöver vi först skapa en bild där vi packar allt som behövs för att vår applikation ska fungera. I princip är en bild en avbildning av filsystemet. Låt oss ta ett exempel på Dockerfile:

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

Dockerfile är en uppsättning instruktioner; när varje instruktion utförs kommer Docker att spara ändringarna i filsystemet och applicera dem på föregående lager. Varje kommando skapar sitt eget lager. Den färdiga bilden är en sammanställning av dessa lager.

Det är viktigt att veta: varje lager kan cachas av Docker. Om ingenting har ändrats sedan den senaste byggprocessen, kommer Docker att ta det redan existerande lagret istället för att utföra kommandot. Eftersom den största hastighetsvinsten i byggprocessen kommer att ske genom användning av cache, kommer vi att fokusera på byggtiden för att mäta detta med caching. Så, steg för steg:

1. Vi tar bort bilder lokalt så att tidigare körningar inte påverkar testet.
   docker rmi $(docker images -q)
2. Vi kör bygget första gången.
   time docker build -t app .
3. Vi ändrar filen src/index.html — simulerar programmerarens arbete.
4. Vi kör bygget en andra gång.
   time docker build -t app .

Om miljön för byggandet av bilder är korrekt inställd (vilket beskrivs lite längre ner), kommer Docker vid byggstart att ha en mängd cachelagrade objekt. Vårt mål är att lära oss att använda cachen så att byggprocessen går så snabbt som möjligt. Eftersom vi antar att byggprocessen utan cache bara körs en gång — den allra första — kan vi bortse från hur långsam den första körningen var. I testerna är den andra körningen den mest relevanta, när cacherna redan är uppvärmda och vi är redo att baka vår kaka. Trots detta kommer vissa tips också påverka den första byggprocessen.

Vi lägger Dockerfile som beskrivs ovan i projektmappen och kör bygget. Alla angivna listingar är förkortade för att underlätta läsningen.

$ 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

Vi ändrar innehållet i src/index.html och kör det en andra gång.

$ 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

För att se om vi har fått en bild, kör vi följande kommando docker images:

REPOSITORY   TAG      IMAGE ID       CREATED              SIZE
app          latest   79f335df92d3   För ungefär en minut sedan   1.74GB

Innan bygget tar Docker alla filer i den aktuella kontexten och skickar dem till sin daemon. Skickar byggets kontext till Docker-demonen 409MB.. Kontexten för bygget anges som det sista argumentet i build-kommandot. I vårt fall är det den aktuella katalogen – «.», – och Docker tar med allt vi har i den här mappen. 409 megabyte är mycket: låt oss tänka på hur vi kan åtgärda detta.

Minska kontexten.

För att minska kontexten finns det två alternativ. Antingen lägger vi alla filer som behövs för bygget i en separat mapp och anger för Docker att kontexten är just den mappen. Detta kanske inte alltid är bekvämt, så det finns möjlighet att ange undantag: vad som inte ska tas med i kontexten. För detta lägger vi till en .dockerignore-fil i projektet och anger vad som inte behövs för bygget:

.git
/node_modules

och kör bygget igen:

$ time docker build -t app .
Skickar byggets kontext till Docker-demonen 607.2kB
Steg 1/5 : FRÅN node:12.16.2
Steg 2/5 : WORKDIR /app
 ---> Använder cache
Steg 3/5 : COPY . .
Steg 4/5 : RUN npm ci
lade till 1357 paket på 22.47s
Steg 5/5 : RUN npm run build --prod
Datum: 2020-04-16T19:33:54.338Z - Hash: fffa0fddaa3425c55dd3 - Tid: 37313ms
Byggd framgångsrikt 4942f010792a
Märkt app:latest

reell 1m47.763s
användare 0m0.000s
system 0m0.000s

607.2 kB – mycket bättre än 409 MB. Och dessutom har vi minskat bildens storlek från 1.74 till 1.38 GB:

REPOSITORY   TAG      IMAGE ID       CREATED         SIZE
app          latest   4942f010792a   3 minuter sedan   1.38GB

Låt oss försöka minska bildens storlek ännu mer.

Använd Alpine.

Ännu ett sätt att spara på bildens storlek är att använda en liten föräldrabild. Föräldrabilden är bilden som vår bild byggs på. Det undre lagret anges med kommandot FRÅN i Dockerfile. I vårt fall använder vi en bild baserad på Ubuntu, som redan har nodejs installerat. Och den väger …

$ docker images -a | grep node
node 12.16.2 406aa3abbc6c 17 minuter sedan 916MB

… nästan en gigabyte. Vi kan kraftigt minska storleken genom att använda en bild baserad på Alpine Linux. Alpine är en mycket liten Linux. Docker-bilden för nodejs baserat på Alpine väger endast 88.5 MB. Så låt oss ersätta vår feta föräldrabild:

FRÅN 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

Vi var tvungna att installera några verktyg som behövs för att bygga applikationen. Ja, Angular byggs inte utan Python ¯(°_o)/¯

Men storleken på bilden minskade med 150 MB:

REPOSITORY   TAG      IMAGE ID       CREATED          SIZE
app          latest   aa031edc315a   22 minuter sedan   761MB

Låt oss gå ännu längre.

Multi-stage build.

Inte allt som finns i bilden behöver vi i produktionen.

$ 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

Med hjälp av docker run app ls -lah Vi har startat en container baserad på vår bild app och körde ett kommando i den ls -lah, efter vilket containern avslutade sin drift.

I produktion behöver vi bara mappen dist. Samtidigt måste vi på något sätt ge ut filerna. Vi kan starta en HTTP-server med nodejs. Men vi gör det enklare. Gissa ett ryskt ord som innehåller fyra bokstäver „ы“. Rätt! Ынжыныксы. Vi tar en bild med nginx, lägger in mappen dist och en liten konfiguration:

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

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

Detta kommer att hjälpa oss att genomföra en multi-stage build. Vi ändrar vår 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 .

Nu har vi två instruktioner FRÅN i Dockerfile, var och en av dem kör sin egen byggfas. Den första har vi kallat För Raspberry Pi 3 med un-def-kärnor, lts, mp, måste en av ljudkortarna (hörlurar eller HDMI) stängas av när pulseaudio används, annars upplevs långsam avstängning av datorn och ljud kan försvinna på grund av fryst pulseaudio., men från den sista FROM kommer vårt slutgiltiga bild att förberedas. Som sista steg kopierar vi artefakten från vår tidigare byggfas till den slutgiltiga bilden med nginx. Storleken på bilden har minskat betydligt:

REPOSITORY   TAG      IMAGE ID       CREATED          SIZE
app          latest   2c6c5da07802   29 minuter sedan   36MB

Låt oss köra en container med vår bild och se till att allt fungerar:

docker run -p8080:80 app

Med alternativet -p8080:80 har vi vidarebefordrat port 8080 på vår värdmaskin till port 80 inuti containern, där nginx körs. Öppna i webbläsaren http://localhost:8080/ och se vår applikation. Allt fungerar!

Att minska bildens storlek från 1,74 GB till 36 MB minskar avsevärt tiden för att leverera din applikation till produktion. Men låt oss återvända till byggtiden.

$ 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

Vi ändrar ordningen på lagren

De första tre stegen har cache-lagts (tips Using cache). I det fjärde steget kopieras alla projektfiler och i det femte steget installeras beroenden RUN npm ci — hela 47.338s. Varför installera beroenden varje gång, om de ändras så sällan? Låt oss gå igenom varför de inte cachades. Saken är den att Docker kontrollerar lager för lager, om kommandot och filer kopplade till det har ändrats. I det fjärde steget kopierar vi alla filer från vårt projekt, och bland dem finns det givetvis ändringar, därför att Docker inte bara inte tar det här lagret från cachen, utan även alla efterföljande! Låt oss göra några små ändringar i 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 .

Först kopieras package.json och package-lock.json, sedan installeras beroenden, och först efter det kopieras hela projektet. Resultatet:

$ 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 sekunder istället för 3 minuter — mycket bättre! Viktigt är den korrekta ordningen på lagren: först kopierar vi det som inte ändras, sedan det som sällan ändras, och till sist — det som ofta ändras.

Sedan några ord om att bygga bilder i CI/CD-system.

Användning av tidigare bilder för caching

Om vi använder en SaaS-lösning för att bygga, kan den lokala cachén av Docker vara ren och fräsch. För att Docker ska ha någonstans att hämta bakade lager från, ge den den tidigare byggda bilden.

Låt oss ta exemplet med att bygga vår applikation i GitHub Actions. Vi använder en sådan konfiguration

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

Avbilden samlas och pushas till GitHub Packages på två minuter och 20 sekunder:

Nu förändrar vi bygget så att vi använder cache baserat på tidigare byggda bilder:

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

Först måste vi förklara varför två kommandon körs build. Det handlar om att i en multi-stage-build kommer den resulterande bilden att vara en uppsättning lager från det senaste steget. Lager från tidigare steg kommer inte att ingå i bilden. Därför, när man använder den slutgiltiga bilden från tidigare byggning, kommer Docker inte att kunna hitta de färdiga lagren för att bygga bilden med nodejs (builder-steget). För att lösa detta problem skapas en mellanliggande bild $IMAGE_NAME-builder-stage och skickas till GitHub Packages så att den kan användas i den efterföljande byggningen som en cachekälla.

Den totala byggetiden har minskat till en och en halv minut. En halv minut går åt till att hämta tidigare bilder.

Förhandsbygge av bilder

Ett annat sätt att lösa problemet med ren Docker-cache är att extrahera delar av lagren till en annan Dockerfile, bygga den separat, pusha den till Container Registry och använda den som förälder.

Vi skapar vår egen Node.js-bild för att bygga Angular-applikationen. Skapa Dockerfile.node i projektet.

FROM node:12.16.2-alpine3.11
RUN apk --no-cache --update --virtual build-dependencies add 
    python 
    make 
    g++

Bygg och pusha den offentliga bilden till Docker Hub:

docker build -t exsmund/node-for-angular -f Dockerfile.node .
docker push exsmund/node-for-angular:latest

Nu använder vi den färdiga bilden i vår huvud-Dockerfile:

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

I vårt exempel har byggtiden inte minskat, men förhandsbyggda bilder kan vara användbara om du har många projekt som kräver samma beroenden.

Vi har gått igenom flera metoder för att påskynda byggandet av Docker-bilder. Om du vill att distributionen ska gå snabbt, prova att implementera följande i ditt projekt:

• reducera kontexten;
• använda små förälderbilder;
• multistage-build;
• ändra ordningen på instruktionerna i Dockerfile för att effektivt använda cache;
• konfigurera cache i CI/CD-system;
• förhandsbygga bilder.

Jag hoppas att exemplet gör det tydligare hur Docker fungerar, och att du kan optimera din distribution. För att experimentera med exemplen i artikeln har ett repo skapats. https://github.com/devopsprodigy/test-docker-build.

Källa: habr.com