Mõned nõuanded, kuidas kiirendada Docker-piltide koostamist. Näiteks kuni 30 sekundit

Enne kui funktsioon jõuab tootmisse, peab see praeguste keeruliste orkestratorite ja CI/CD süsteemide tõttu läbima pika tee koodiversioonist testimise ja kohaletoimetamiseni. Varem võis uusi faile lihtsalt FTP kaudu laadida (nii ei tee keegi enam, eks?), ja „deploidi” protsess kestis sekundeid. Nüüd tuleb luua merge-päring ja oodata märkimisväärselt kaua, kuni funktsioon kasutajateni jõuab.

Osana sellest teest toimub Docker-pildi kogumine. Mõnikord kestab kogumine minuteid, mõnikord aga kümneid minuteid, mida on raske normaalseks nimetada. Käesolevas artiklis võtame lihtsa rakenduse, pakime selle pildiks, rakendame mitmeid meetodeid kogumise kiirendamiseks ja vaatame nende meetodite toimimise nüansse.

Meil on hea kogemus meedia saitide loomisel ja hooldamisel: ТАСС, The Bell, "Новая газета", Republic…Äsja täiendasime oma portfelli, lastes tootmisse saidi Reminder. Ja samal ajal kui me kiiresti uusi funktsioone viimistlesime ja vanu vigu parandasime, sai aeglane deploiimisprotsess suureks probleemiks.

Teostame deploiimist GitLab-is. Kogume pilte, push'ime need GitLabi registrisse ja kaevame need tootmisse. Selle nimekirja kõige aeglasem osa on piltide kogumine. Näiteks: ilma optimeerimiseta kestis iga taustaprogrammi kogumine 14 minutit.

Lõpuks sai selgeks, et selliselt elada enam ei saa, ja me asusime arutama, miks pildid nii kaua kokku kogunevad. Lõpuks õnnestus kokkupanemisaega vähendada 30 sekundini!

Käesolevas artiklis, et mitte siduda end Reminder'i keskkonnaga, vaatame näidet tühja rakenduse koostamisest Angularis. Nii et loome oma rakenduse:

ng n app

Lisame sellele PWA (me ju oleme progressiivsed):

ng add @angular/pwa --project app

Kui alla laaditakse miljonit npm-paketti, vaatame, kuidas docker-pilt koosneb. Docker võimaldab rakendusi pakendada ja käivitada neid isoleeritud keskkonnas, mida nimetatakse konteineriks. Tänu isoleerimisele saab samaaegselt käivitada palju konteinerite ühel serveril. Konteinerid on oluliselt kergemad kui virtuaalsed masinad, kuna need töötavad otse süsteemi tuumal. Et käivitada konteinerit meie rakendusega, peame esmalt looma pildi, kuhu pakime kõik, mis meie rakenduse töötamiseks vajalik. Sisuliselt on pilt - see on failisüsteemi koopia. Näiteks võtame Dockerfile:

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

Dockerfile — see on juhiste kogum; iga juhise täitmisega salvestab Docker muudatused failisüsteemis ja rakendab neid eelnevatele. Iga käsk loob oma kihi. Valmis pilt on koositatud kihtidest.

Oluline teada: iga kiht on Dockeris vahemällu salvestatav. Kui viimase koostamisega ei ole midagi muutunud, siis võtab Docker käsku täitmata juba valmis kihi. Kuna peamine kiirusetõus koostamisel tuleb vahemälu kasutamisest, siis keskendume kiirusemõõtmiste ajal just pildi koostamisele valmis vahemäluga. Nii et järgime samme:

1. Kustutame kohalikud pildid, et eelnevad käivitamised ei mõjutaks testi.
   docker rmi $(docker images -q)
2. Käivitame ehituse esmakordselt.
   time docker build -t app .
3. Muudame faili src/index.html — simuleerime programmeerija tööd.
4. Käivitame ehituse teist korda.
   time docker build -t app .

Kui pildikogumise keskkond on õigesti seadistatud (millest räägime veidi allpool), siis Dockeril on pildikoostamise käivitamisel juba olemas hulk vahemälu. Meie eesmärk on õppida, kuidas vahemälu kasutada nii, et koostamine toimuks võimalikult kiiresti. Oletame, et koostamise käivitamine ilma vahemäluta toimub ainult üks kord — esmakordselt — seega saame ignoreerida, kui aeglane oli see esimene kord. Testides on meie jaoks oluliseks teiseks koostamiseks, kui vahemälud on juba soojendatud ja oleme valmis küpsetama oma kooki. Sellegipoolest mõningad näpunäited mõjutavad ka esimest koostamist.

Asetame ülaltoodud Dockerfile projekti kausta ja käivitame koostamise. Kõik esitatud loetelud on mugavuse huvides lühendatud.

$ time docker build -t app .
Saadan ehituskonteksti Docker daemonile 409MB
Samm 1/5 : FROM node:12.16.2
Olek: Laaditud uuem pilt node:12.16.2
Samm 2/5 : WORKDIR /app
Samm 3/5 : COPY . .
Samm 4/5 : RUN npm ci
lisa 1357 paketti 22.47s
Samm 5/5 : RUN npm run build --prod
Kuupäev: 2020-04-16T19:20:09.664Z - Hash: fffa0fddaa3425c55dd3 - Aeg: 37581ms
Edukas koostamine: c8c279335f46
Edukas märgistamine: app:latest

reaalne 5m4.541s
kasutaja 0m0.000s
süsteem 0m0.000s

Muudame sisu src/index.html ja käivitame teist korda.

$ 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

Vaadates, kas meie pilt on valmis, käivitame käsu docker images:

REPOSITORY   TAG      IMAGE ID       CREATED              SIZE
app          latest   79f335df92d3   About a minute ago   1.74GB

Enne koostamist kogub docker kõik failid praegusest kontekstist ja saadab need oma deemonile Sending build context to Docker daemon 409MB. Koostamiskontekst määratakse käskluse build viimaseks argumendiks. Meie puhul on see praegune kataloog — «.», — ja docker toob kõik, mis meil selles kaustas on. 409 MB on palju: mõelgem, kuidas seda parandada.

Konteksti vähendamine

Konteksti vähendamiseks on kaks võimalust. Kas panna kõik koostamiseks vajalikud failid eraldi kausta ja näidata dockerile konteksti just sellele kaustale. See ei pruugi alati mugav olla, seega on võimalik näidata erandeid: mida ei peaks konteksti tooma. Selleks paneme projekti faili .dockerignore ja näitame, mis ei ole koostamiseks vajalik:

.git
/node_modules

ja käivitame koostamise uuesti:

$ 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 — palju parem kui 409 MB. Samuti vähendasime pildi suurust 1.74 GB-lt 1.38 GB-le:

REPOSITORY   TAG      IMAGE ID       CREATED         SIZE
app          latest   4942f010792a   3 minutes ago   1.38GB

Katsume veel pildi suurust vähendada.

Kasutame Alpine'i

Veel üks viis pildi suuruse kokkuhoiuks on kasutada väikest vanemapilti. Vanemapilt on see pilt, mille põhjal meie pilt valmistatakse. Alumine kiht määratakse käsuga FROM Dockerfile'is. Meie puhul kasutame Ubuntu-põhist pilti, kus on juba nodejs. Ja selle kaal on …

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

… peaaegu gigabait. Mahtu saab tunduvalt vähendada, kasutades Alpine Linux-põhist pilti. Alpine on väga väike Linux. Nodejs-i Docker-pilt, mis põhineb Alpine'il, kaalub ainult 88.5 MB. Seetõttu asendame meie suure pildi:

MUUTU 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

Pidime paigaldama mõned asjad, mis on vajalikud rakenduse ehitamiseks. Jah, Angular ei ehita ilma Pythonita ¯(°_o)/¯

Aga pildi suurus vähenes 150 MB võrra:

REPOSITORY   TAG      IMAGE ID       CREATED          SIZE
app          latest   aa031edc315a   22 minutes ago   761MB

Liigume veel edasi.

Mitme etapi ehitus

Kõik, mis pildis on, pole meile tootmises vajalik.

$ 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

Käesoleva abil docker run app ls -lah me käivitasime konteineri meie pildilt app ja täitsime seal käsu ls -lah, pärast mida konteiner lõpetas oma tööd.

Tootmises vajame ainult kausta dist. Samal ajal on faile kuidagi vaja välja anda. Saame käivitada mingisuguse HTTP-serveri nodejs-is. Aga teeme lihtsamalt. Arva ära vene sõna, milles on neli tähte "ы". Õige! Ынжыныксы. Võtame nginx'i pildi, paneme sinna kausta dist ja väikese konfiguratsiooni:

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

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

Selle kõikide tegemiseks aitab meid multi-stage build. Muudame meie Dockerfile'i:

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 .

Nüüd on meil kaks käsklust FROM Dockerfile'is, millest igaüks käivitab oma ehitusetapi. Esimesele andsime nime builder, ja alates viimasest FROM-ist hakatakse meie lõplikku pilti ette valmistama. Viimase sammuna kopeerime meie eelneva etapi ehitusartefakti lõpp- tagasi nginx-i. Pildi suurus on oluliselt vähenenud:

REPOSITORY   TAG      IMAGE ID       CREATED          SIZE
app          latest   2c6c5da07802   29 minutes ago   36MB

Käivitame konteineri meie pildiga ja veendume, et kõik töötab:

docker run -p8080:80 app

Argument -p8080:80 suunab meie hostmasinas 8080 pordi 80 porti konteineris, kus töötab nginx. Avame brauseris http://localhost:8080/ ja näeme meie rakendust. Kõik töötab!

Pildi suuruse vähendamine 1.74 GB-st 36 MB-ni lühendab oluliselt teie rakenduse tootmisesse toimetamise aega. Kuid naaseme ehitusaega.

$ 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

Muudame kihtide järjekorda

Esimesed kolm sammu olid meil vahemälus (vihje Using cache). Neljandas etapis kopeeritakse kõik projekti failid ja viiendas etapis paigaldatakse sõltuvused RUN npm ci — kokku 47,338 s. Miks paigaldada sõltuvused iga kord uuesti, kui need muutuvad väga harva? Vaatame, miks nad ei ole vahemälusse salvestatud. Asi on selles, et Docker kontrollib kiht kihi haaval, kas käsk ja sellega seotud failid on muutunud. Neljandas sammus kopeerime kõik meie projekti failid ja nende seas on loomulikult muudatused, mistõttu Docker ei kasuta mitte ainult seda kihti vahemälust, vaid kõiki järgmisi! Teeme Dockerfile'is väiksed muudatused.

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 .

Esmalt kopeeritakse package.json ja package-lock.json, seejärel paigaldatakse sõltuvused ja alles pärast seda kopeeritakse kogu projekt. Tulemuseks:

$ 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 sekundit kolme minuti asemel — oluliselt parem! Oluline on kihtide õige järjekord: esmalt kopeerime selle, mis ei muutu, seejärel selle, mis harva muutub, ja lõpuks — selle, mis sageli.

Jätkame natuke juttu pildihaldusest CI/CD süsteemides.

Eelmiste piltide kasutamine vahehoiuna

Kui me kasutame mingit SaaS-lahendust ehitamiseks, siis võib kohalik Docker'i vahehoidla olla puhas ja värske. Et Docker'il oleks kust võtta küpsetatud kihte, andke talle eelnevalt kokku pandud pilt.

Vaatame näiteks meie rakenduse ehitamist GitHub Actionsis. Kasutame sellist konfi

kas:
  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

Pilt kogutakse ja saadetakse GitHub Packagesi kahe minuti ja 20 sekundi jooksul:

Nüüd muudame kogumise nii, et kasutame varasemate kogutud piltide põhjal vahemälu:

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

Esiteks on vaja rääkida, miks käivitatakse kaks käsku build. Probleem on selles, et mitmeetapise ehituse tulemusena on komplekt kihte viimasest etapist. Eelmiste kihtide kihid ei jõua pildile. Seega, kui kasutada viimast pilti eelmisest ehitusest, ei suuda Docker leida valmis kihte nodejs pildi (ehitusetapp builder) koostamiseks. Selle probleemi lahendamiseks luuakse vahepilt $IMAGE_NAME-builder-stage ja saadetakse GitHub Packages'i, et seda saaks kasutada järgmises ehituses vahekaustana.

Üldine ehitusaeg on lühenenud ühe ja poole minutini. Pool minutit kulub eelmiste piltide tõmbamiseks.

Piltide eelneva loomine

Veel üks viis Docker'i puhta vahecache probleemi lahendamiseks on osa kihtidest välja viia teise Dockerfile'i, ehitada see eraldi, pushida Container Registry'sse ja kasutada vanemana.

Loome oma nodejs pildi Angular rakenduse koostamiseks. Loome projektis Dockerfile.node

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

Kogume ja pushime avaliku pildi Docker Hubi:

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

Nüüd kasutame oma põhijuhendis valmis pilti:

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

Meie näites ei lühenenud ehitusaeg, kuid eelnevalt loodud pildid võivad olla kasulikud, kui teil on palju projekte, milles peate installima samu sõltuvusi.

Olemegi käsitlenud mitmeid meetodeid Docker-piltide ehitamise kiirendamiseks. Kui soovite kiirusest lugu pidada, proovige oma projektis rakendada:

• konteksti vähendamine;
• väikeste vanemapiltide kasutamine;
• multi-stage ehitus;
• Dockerfile'i käskude järjestuse muutmine koodi efektiivseks kasutamiseks;
• CI/CD süsteemides cache’i seadistamine;
• piltide eelnev loomine.

Loodan, et näidisest saab selgemaks, kuidas Docker töötab, ja et suudate oma seadistusi optimaalselt kohandada. Artikli näidistega mängimiseks on loodud hoidla. https://github.com/devopsprodigy/test-docker-build.

Allikas: habr.com