{"id":81600,"date":"2020-05-15T01:42:41","date_gmt":"2020-05-14T23:42:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/neskolko-sovetov-o-tom-kak-uskorit-sborku-docker-obrazov-naprimer-do-30-sekund"},"modified":"2020-05-15T01:42:41","modified_gmt":"2020-05-14T23:42:41","slug":"neskolko-sovetov-o-tom-kak-uskorit-sborku-docker-obrazov-naprimer-do-30-sekund","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/neskolko-sovetov-o-tom-kak-uskorit-sborku-docker-obrazov-naprimer-do-30-sekund","title":{"rendered":"Alcuni consigli su come velocizzare la costruzione delle immagini Docker. Ad esempio, fino a 30 secondi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Prima che una funzionalit\u00e0 arrivi in produzione, al giorno d'oggi, con orchestratori complessi e CI\/CD, c'\u00e8 un lungo percorso da affrontare, dal commit ai test e alla consegna. In passato era possibile trasferire nuovi file via FTP (ma nessuno lo fa pi\u00f9, giusto?), e il processo di \"deploy\" richiedeva secondi. Ora, invece, bisogna creare una merge request e attendere un bel po' di tempo prima che la funzionalit\u00e0 raggiunga gli utenti.<\/p>\n

<\/p>\n

Parte di questo percorso \u00e8 la costruzione dell'immagine Docker. A volte la costruzione richiede minuti, altre volte decine di minuti, il che \u00e8 difficile da considerare normale. In questo articolo prenderemo come esempio un'applicazione semplice, la confezioneremo in un'immagine, applicheremo diversi metodi per accelerare la costruzione e esamineremo le sfide legate a questi metodi.<\/p>\n

<\/p>\n

\"Alcuni<\/p>\n

<\/a><\/noindex><\/p>\n

Abbiamo una buona esperienza nella creazione e nel supporto di siti per i media: TASS<\/a><\/noindex>, The Bell<\/a><\/noindex>, "Nuova Gazeta"<\/a><\/noindex>, Republic<\/a><\/noindex>\u2026 Non molto tempo fa abbiamo ampliato il nostro portafoglio, lanciando un sito in produzione Reminder<\/a><\/noindex>. E mentre ci affrettavamo a completare nuove funzionalit\u00e0 e risolvere bug vecchi, il deploy lento \u00e8 diventato un grosso problema.<\/p>\n

<\/p>\n

Effettuiamo il deploy su GitLab. Creiamo immagini, le carichiamo nel GitLab Registry e le distribuiamo in produzione. La parte pi\u00f9 lunga di questo processo \u00e8 la costruzione delle immagini. Ad esempio: senza ottimizzazione, ogni costruzione del backend richiedeva 14 minuti.<\/p>\n

<\/p>\n

\"Alcuni<\/p>\n

<\/p>\n

Alla fine ci siamo resi conto che non era possibile continuare in questo modo, e ci siamo messi a capire perch\u00e9 le immagini impiegassero cos\u00ec tanto tempo a essere costruite. Alla fine, siamo riusciti a ridurre il tempo di costruzione a 30 secondi!<\/p>\n

<\/p>\n

\"Alcuni<\/p>\n

<\/p>\n

Per questo articolo, per non legarci all'ambiente di Reminder, consideriamo un esempio di creazione di un'applicazione vuota su Angular. Quindi, creiamo la nostra applicazione:<\/p>\n

<\/p>\n

ng n app<\/code><\/pre>\n
<\/p>\n
Aggiungiamoci PWA (siamo pur sempre progressivi):<\/p>\n
<\/p>\n
ng add @angular\/pwa --project app<\/code><\/pre>\n
<\/p>\n
Mentre si scaricano milioni di pacchetti npm, diamo un'occhiata a come \u00e8 strutturata l'immagine Docker. Docker offre la possibilit\u00e0 di confezionare applicazioni e farle girare in un ambiente isolato, chiamato contenitore. Grazie all'isolamento, \u00e8 possibile eseguire molti contenitori contemporaneamente su un singolo server. I contenitori sono significativamente pi\u00f9 leggeri delle macchine virtuali, in quanto vengono eseguiti direttamente sul kernel del sistema. Per eseguire un contenitore con la nostra applicazione, dobbiamo prima creare un'immagine in cui confezioniamo tutto il necessario per il funzionamento della nostra applicazione. In sostanza, l'immagine \u00e8 un'istantanea del file system. Ad esempio, consideriamo il Dockerfile:<\/p>\n
<\/p>\n
FROM node:12.16.2\nWORKDIR \/app\nCOPY . .\nRUN npm ci\nRUN npm run build --prod<\/code><\/pre>\n
<\/p>\n
Il Dockerfile \u00e8 un insieme di istruzioni; eseguendo ciascuna di esse, Docker salver\u00e0 le modifiche nel file system e le sovrapporr\u00e0 a quelle precedenti. Ogni comando crea il proprio strato. L'immagine finale \u00e8 l'insieme degli strati uniti.<\/p>\n
<\/p>\n
Cosa \u00e8 importante sapere: ogni strato pu\u00f2 essere memorizzato nella cache da Docker. Se nulla \u00e8 cambiato dall'ultima build, Docker utilizzer\u00e0 lo strato gi\u00e0 pronto invece di eseguire il comando. Poich\u00e9 il principale guadagno in velocit\u00e0 di build deriverebbe dall'uso della cache, nelle misurazioni della velocit\u00e0 di build ci concentreremo sulla costruzione dell'immagine con la cache pronta. Quindi, per passi:<\/p>\n
<\/p>\n
    \n
  1. Rimuoviamo le immagini localmente, in modo che le esecuzioni precedenti non influenzino il test.
    \ndocker rmi $(docker images -q)<\/code><\/li>\n
  2. Eseguiamo la build per la prima volta.
    \ntime docker build -t app .<\/code><\/li>\n
  3. Modifichiamo il file src\/index.html per simulare il lavoro di uno sviluppatore.<\/li>\n
  4. Eseguiamo la build per la seconda volta.
    \ntime docker build -t app .<\/code><\/li>\n<\/ol>\n
    <\/p>\n
    Se l'ambiente per la creazione delle immagini \u00e8 impostato correttamente (di cui parleremo brevemente dopo), Docker avr\u00e0 gi\u00e0 a bordo vari strati di cache quando avviamo la build. Il nostro obiettivo \u00e8 imparare a utilizzare la cache in modo che la build si svolga nel modo pi\u00f9 rapido possibile. Poich\u00e9 presumiamo che l'avvio della build senza cache avvenga solo una volta \u2014 la prima \u2014 possiamo ignorare la lentezza di questa prima esecuzione. \u00c8 il secondo avvio della build che ci interessa nei test, quando le cache sono gi\u00e0 attive e siamo pronti a infornare il nostro dolce. Tuttavia, alcuni suggerimenti influenzeranno anche la prima build.<\/p>\n
    <\/p>\n
    Posizioniamo il Dockerfile descritto sopra nella cartella del progetto e avviamo la build. Tutti gli elenchi forniti sono abbreviati per facilitare la lettura.<\/p>\n
    <\/p>\n
    $ time docker build -t app .\nInvio del contesto di build al demone Docker 409MB\nPasso 1\/5 : FROM node:12.16.2\nStato: Immagine pi\u00f9 recente scaricata per node:12.16.2\nPasso 2\/5 : WORKDIR \/app\nPasso 3\/5 : COPY . .\nPasso 4\/5 : RUN npm ci\naggiunti 1357 pacchetti in 22.47s\nPasso 5\/5 : RUN npm run build --prod\nData: 2020-04-16T19:20:09.664Z - Hash: fffa0fddaa3425c55dd3 - Tempo: 37581ms\nCostruzione avvenuta con successo c8c279335f46\nTagging avvenuto con successo app:latest\n\nreale 5m4.541s\nutente 0m0.000s\nsistema 0m0.000s<\/code><\/pre>\n
    <\/p>\n
    Modifichiamo il contenuto di src\/index.html e avviamo per la seconda volta.<\/p>\n
    <\/p>\n
    $ time docker build -t app .\nInvio del contesto di build al demone Docker 409MB\nPasso 1\/5 : FROM node:12.16.2\nPasso 2\/5 : WORKDIR \/app\n ---> Utilizzo della cache\nPasso 3\/5 : COPY . .\nPasso 4\/5 : RUN npm ci\naggiunti 1357 pacchetti in 22.47s\nPasso 5\/5 : RUN npm run build --prod\nData: 2020-04-16T19:26:26.587Z - Hash: fffa0fddaa3425c55dd3 - Tempo: 37902ms\nCostruzione avvenuta con successo 79f335df92d3\nTagging avvenuto con successo app:latest\n\nreale 3m33.262s\nutente 0m0.000s\nsistema 0m0.000s<\/code><\/pre>\n
    <\/p>\n
    Per vedere se siamo riusciti a creare l'immagine, eseguiamo il comando docker images<\/code>:<\/p>\n
    <\/p>\n
    REPOSITORY   TAG      IMAGE ID       CREATED              SIZE\napp          latest   79f335df92d3   Circa un minuto fa   1.74GB<\/code><\/pre>\n
    <\/p>\n
    Prima di costruire, Docker prende tutti i file nel contesto corrente e li invia al suo demone Invio del contesto di build al demone Docker 409MB<\/code>. Il contesto per la build viene specificato come ultimo argomento del comando build. Nel nostro caso, si tratta della directory corrente - \u00ab.\u00bb, - e Docker porta tutto ci\u00f2 che abbiamo in questa cartella. 409 MB sono molti: pensiamo a come risolvere questo problema.<\/p>\n
    <\/p>\n
    Riduciamo il contesto<\/h2>\n
    <\/p>\n
    Per ridurre il contesto, ci sono due opzioni. O mettiamo tutti i file necessari per la costruzione in una cartella separata e indichiamo a Docker di utilizzare proprio quella cartella come contesto. Questo potrebbe non essere sempre comodo, quindi c'\u00e8 la possibilit\u00e0 di specificare delle eccezioni: cosa non deve essere portato nel contesto. Per farlo, mettiamo nel progetto un file .dockerignore e indichiamo cosa non serve per la build:<\/p>\n
    <\/p>\n
    .git\n\/node_modules<\/code><\/pre>\n
    <\/p>\n
    e avviamo nuovamente la costruzione:<\/p>\n
    <\/p>\n
    $ time docker build -t app .\nInvio del contesto di build al demone Docker 607.2kB\nStep 1\/5 : FROM node:12.16.2\nStep 2\/5 : WORKDIR \/app\n ---> Utilizzando la cache\nStep 3\/5 : COPY . .\nStep 4\/5 : RUN npm ci\naggiunti 1357 pacchetti in 22.47s\nStep 5\/5 : RUN npm run build --prod\nData: 2020-04-16T19:33:54.338Z - Hash: fffa0fddaa3425c55dd3 - Tempo: 37313ms\nCostruito con successo 4942f010792a\nContrassegnato con successo app:latest\n\nreale 1m47.763s\nutente 0m0.000s\nsys 0m0.000s<\/code><\/pre>\n
    <\/p>\n
    607.2 Kbyte - molto meglio rispetto a 409 MB. Inoltre, abbiamo ridotto la dimensione dell'immagine da 1.74 a 1.38GB:<\/p>\n
    <\/p>\n
    REPOSITORY   TAG      IMAGE ID       CREATED         SIZE\napp          latest   4942f010792a   3 minuti fa   1.38GB<\/code><\/pre>\n
    <\/p>\n
    Proviamo a ridurre ulteriormente la dimensione dell'immagine.<\/p>\n
    <\/p>\n
    Utilizziamo Alpine<\/h2>\n
    <\/p>\n
    Un altro modo per risparmiare sulla dimensione dell'immagine \u00e8 utilizzare una piccola immagine madre. L'immagine madre \u00e8 l'immagine sulla quale viene costruita la nostra immagine. Lo strato inferiore \u00e8 specificato nel comando DA<\/code> nel Dockerfile. Nel nostro caso, utilizziamo un'immagine basata su Ubuntu, gi\u00e0 dotata di nodejs. E pesa ...<\/p>\n
    <\/p>\n
    $ docker images -a | grep node\nnode 12.16.2 406aa3abbc6c 17 minuti fa 916MB<\/code><\/pre>\n
    <\/p>\n
    ... quasi un gigabyte. Possiamo ridurre notevolmente il volume utilizzando un'immagine basata su Alpine Linux. Alpine \u00e8 un sistema operativo Linux molto leggero. L'immagine Docker per nodejs basata su alpine pesa solo 88.5 MB. Quindi, sostituiamo la nostra immagine grossa con:<\/p>\n
    <\/p>\n
    FROM node:12.16.2-alpine3.11\nRUN apk --no-cache --update --virtual build-dependencies add \n    python \n    make \n    g++\nWORKDIR \/app\nCOPY . .\nRUN npm ci\nRUN npm run build --prod<\/code><\/pre>\n
    <\/p>\n
    Abbiamo dovuto installare alcune cose necessarie per costruire l'applicazione. S\u00ec, Angular non si costruisce senza Python \u00af(\u00b0_o)\\\/\u00af<\/p>\n
    <\/p>\n
    Ma la dimensione dell'immagine \u00e8 scesa di 150 MB:<\/p>\n
    <\/p>\n
    REPOSITORY   TAG      IMAGE ID       CREATED          SIZE\napp          latest   aa031edc315a   22 minuti fa   761MB<\/code><\/pre>\n
    <\/p>\n
    Andiamo oltre.<\/p>\n
    <\/p>\n
    Build multi-stage<\/h2>\n
    <\/p>\n
    Non tutto ci\u00f2 che c'\u00e8 nell'immagine ci serve in produzione.<\/p>\n
    <\/p>\n
    $ docker run app ls -lah\ntotal 576K\ndrwxr-xr-x 1 root root 4.0K Apr 16 19:54 .\ndrwxr-xr-x 1 root root 4.0K Apr 16 20:00 ..\n-rwxr-xr-x 1 root root 19 Apr 17 2020 .dockerignore\n-rwxr-xr-x 1 root root 246 Apr 17 2020 .editorconfig\n-rwxr-xr-x 1 root root 631 Apr 17 2020 .gitignore\n-rwxr-xr-x 1 root root 181 Apr 17 2020 Dockerfile\n-rwxr-xr-x 1 root root 1020 Apr 17 2020 README.md\n-rwxr-xr-x 1 root root 3.6K Apr 17 2020 angular.json\n-rwxr-xr-x 1 root root 429 Apr 17 2020 browserslist\ndrwxr-xr-x 3 root root 4.0K Apr 16 19:54 dist\ndrwxr-xr-x 3 root root 4.0K Apr 17 2020 e2e\n-rwxr-xr-x 1 root root 1015 Apr 17 2020 karma.conf.js\n-rwxr-xr-x 1 root root 620 Apr 17 2020 ngsw-config.json\ndrwxr-xr-x 1 root root 4.0K Apr 16 19:54 node_modules\n-rwxr-xr-x 1 root root 494.9K Apr 17 2020 package-lock.json\n-rwxr-xr-x 1 root root 1.3K Apr 17 2020 package.json\ndrwxr-xr-x 5 root root 4.0K Apr 17 2020 src\n-rwxr-xr-x 1 root root 210 Apr 17 2020 tsconfig.app.json\n-rwxr-xr-x 1 root root 489 Apr 17 2020 tsconfig.json\n-rwxr-xr-x 1 root root 270 Apr 17 2020 tsconfig.spec.json\n-rwxr-xr-x 1 root root 1.9K Apr 17 2020 tslint.json<\/code><\/pre>\n
    <\/p>\n
    Utilizzando docker run app ls -lah<\/code> abbiamo avviato un container basato sulla nostra immagine app<\/code> e abbiamo eseguito al suo interno il comando ls -lah<\/code>, dopo di che il container ha terminato il suo lavoro.<\/p>\n
    <\/p>\n
    In produzione abbiamo bisogno solo della cartella dist<\/code>. Dobbiamo comunque trasferire i file all'esterno. Possiamo avviare un server HTTP su nodejs. Ma faremo qualcosa di pi\u00f9 semplice. Indovinate la parola russa che ha quattro lettere \u00ab\u044b\u00bb. Giusto! \u042b\u043d\u0436\u044b\u043d\u044b\u043a\u0441\u044b. Prendiamo l'immagine con nginx, ci mettiamo dentro la cartella dist<\/code> e una piccola configurazione:<\/p>\n
    <\/p>\n
    server {\n    listen 80 default_server;\n    server_name localhost;\n    charset utf-8;\n    root \/app\/dist;\n\n    location \/ {\n        try_files $uri $uri\/ \/index.html;\n    }\n}<\/code><\/pre>\n
    <\/p>\n
    Tutto questo ci aiuter\u00e0 a fare un multi-stage build. Modifichiamo il nostro Dockerfile:<\/p>\n
    <\/p>\n
    FROM node:12.16.2-alpine3.11 as builder\nRUN apk --no-cache --update --virtual build-dependencies add \n    python \n    make \n    g++\nWORKDIR \/app\nCOPY . .\nRUN npm ci\nRUN npm run build --prod\n\nFROM nginx:1.17.10-alpine\nRUN rm \/etc\/nginx\/conf.d\/default.conf\nCOPY nginx\/static.conf \/etc\/nginx\/conf.d\nCOPY --from=builder \/app\/dist\/app .<\/code><\/pre>\n
    <\/p>\n
    Ora abbiamo due istruzioni DA<\/code> nel Dockerfile, ognuna delle quali avvia il proprio stadio di costruzione. Il primo lo abbiamo chiamato builder<\/code>, mentre a partire dall'ultimo FROM verr\u00e0 preparata la nostra immagine finale. L'ultimo passo \u00e8 copiare l'artefatto della nostra build nella fase precedente nell'immagine finale con nginx. La dimensione dell'immagine \u00e8 diminuita significativamente:<\/p>\n
    <\/p>\n
    REPOSITORY   TAG      IMAGE ID       CREATED          SIZE\napp          latest   2c6c5da07802   29 minuti fa   36MB<\/code><\/pre>\n
    <\/p>\n
    Facciamo partire il container con la nostra immagine e assicuriamoci che tutto funzioni:<\/p>\n
    <\/p>\n
    docker run -p8080:80 app<\/code><\/pre>\n
    <\/p>\n
    Con l'opzione -p8080:80 abbiamo mappato la porta 8080 sulla nostra macchina host alla porta 80 all'interno del container, dove gira nginx. Apriamo nel browser http:\/\/localhost:8080\/<\/a><\/noindex> e vediamo la nostra applicazione. Funziona tutto!<\/p>\n
    <\/p>\n
    \"Alcuni<\/p>\n
    <\/p>\n
    Ridurre la dimensione dell'immagine da 1.74 GB a 36 MB abbrevia significativamente il tempo di consegna della tua applicazione in produzione. Ma torniamo al tempo di costruzione.<\/p>\n
    <\/p>\n
    $ time docker build -t app .\nSending build context to Docker daemon 608.8kB\nStep 1\/11 : FROM node:12.16.2-alpine3.11 as builder\nStep 2\/11 : RUN apk --no-cache --update --virtual build-dependencies add python make g++\n ---> Using cache\nStep 3\/11 : WORKDIR \/app\n ---> Using cache\nStep 4\/11 : COPY . .\nStep 5\/11 : RUN npm ci\nadded 1357 packages in 47.338s\nStep 6\/11 : RUN npm run build --prod\nDate: 2020-04-16T21:16:03.899Z - Hash: fffa0fddaa3425c55dd3 - Time: 39948ms\n ---> 27f1479221e4\nStep 7\/11 : FROM nginx:stable-alpine\nStep 8\/11 : WORKDIR \/app\n ---> Using cache\nStep 9\/11 : RUN rm \/etc\/nginx\/conf.d\/default.conf\n ---> Using cache\nStep 10\/11 : COPY nginx\/static.conf \/etc\/nginx\/conf.d\n ---> Using cache\nStep 11\/11 : COPY --from=builder \/app\/dist\/app .\nSuccessfully built d201471c91ad\nSuccessfully tagged app:latest\n\nreal 2m17.700s\nuser 0m0.000s\nsys 0m0.000s<\/code><\/pre>\n
    <\/p>\n
    Cambiando l'ordine dei layer<\/h2>\n
    <\/p>\n
    I primi tre passaggi sono stati memorizzati nella cache (suggerimento Using cache<\/code>). Nel quarto passaggio vengono copiati tutti i file del progetto e nel quinto passaggio vengono installate le dipendenze RUN npm ci<\/code> \u2014 un totale di 47.338 secondi. Perch\u00e9 ricominciare ogni volta a installare le dipendenze, se cambiano molto raramente? Vediamo perch\u00e9 non sono state memorizzate nella cache. Il fatto \u00e8 che Docker controlla strato per strato se il comando e i file ad esso correlati sono cambiati. Nel quarto passaggio copiamo tutti i file del nostro progetto e tra di essi ci sono naturalmente delle modifiche, quindi Docker non solo non prende dalla cache questo strato, ma nemmeno tutti i successivi! Apportiamo alcune piccole modifiche al Dockerfile.<\/p>\n
    <\/p>\n
    FROM node:12.16.2-alpine3.11 as builder\nRUN apk --no-cache --update --virtual build-dependencies add \n    python \n    make \n    g++\nWORKDIR \/app\nCOPY package*.json .\/\nRUN npm ci\nCOPY . .\nRUN npm run build --prod\n\nFROM nginx:1.17.10-alpine\nRUN rm \/etc\/nginx\/conf.d\/default.conf\nCOPY nginx\/static.conf \/etc\/nginx\/conf.d\nCOPY --from=builder \/app\/dist\/app .<\/code><\/pre>\n
    <\/p>\n
    Prima si copiano package.json e package-lock.json, poi si installano le dipendenze e solo dopo si copia l'intero progetto. Come risultato:<\/p>\n
    <\/p>\n
    $ time docker build -t app .\nSending build context to Docker daemon 608.8kB\nStep 1\/12 : FROM node:12.16.2-alpine3.11 as builder\nStep 2\/12 : RUN apk --no-cache --update --virtual build-dependencies add python make g++\n ---> Using cache\nStep 3\/12 : WORKDIR \/app\n ---> Using cache\nStep 4\/12 : COPY package*.json .\/\n ---> Using cache\nStep 5\/12 : RUN npm ci\n ---> Using cache\nStep 6\/12 : COPY . .\nStep 7\/12 : RUN npm run build --prod\nDate: 2020-04-16T21:29:44.770Z - Hash: fffa0fddaa3425c55dd3 - Time: 38287ms\n ---> 1b9448c73558\nStep 8\/12 : FROM nginx:stable-alpine\nStep 9\/12 : WORKDIR \/app\n ---> Using cache\nStep 10\/12 : RUN rm \/etc\/nginx\/conf.d\/default.conf\n ---> Using cache\nStep 11\/12 : COPY nginx\/static.conf \/etc\/nginx\/conf.d\n ---> Using cache\nStep 12\/12 : COPY --from=builder \/app\/dist\/app .\nSuccessfully built a44dd7c217c3\nSuccessfully tagged app:latest\n\nreal 0m46.497s\nuser 0m0.000s\nsys 0m0.000s<\/code><\/pre>\n
    <\/p>\n
    46 secondi anzich\u00e9 3 minuti \u2014 decisamente meglio! \u00c8 importante il giusto ordine degli strati: prima copiamo quello che non cambia, poi quello che cambia raramente e infine quello che cambia spesso.<\/p>\n
    <\/p>\n
    Passiamo ora a dire qualcosa sulla creazione di immagini nei sistemi CI\/CD.<\/p>\n
    <\/p>\n
    Utilizzo di immagini precedenti per la cache<\/h2>\n
    <\/p>\n
    Se utilizziamo per la costruzione una soluzione SaaS, allora la cache locale di Docker potrebbe essere pulita e fresca. Per consentire a Docker di recuperare gli strati costruiti, fornitegli l'immagine precedentemente creata.<\/p>\n
    <\/p>\n
    Prendiamo ad esempio la costruzione della nostra applicazione in GitHub Actions. Utilizziamo questa configurazione<\/p>\n
    <\/p>\n
    on:\n  push:\n    branches:\n      - master\n\nname: Test docker build\n\njobs:\n  deploy:\n    name: Build\n    runs-on: ubuntu-latest\n    env:\n      IMAGE_NAME: docker.pkg.github.com\/${{ github.repository }}\/app\n      IMAGE_TAG: ${{ github.sha }}\n\n    steps:\n    - name: Checkout\n      uses: actions\/checkout@v2\n\n    - name: Login to GitHub Packages\n      env:\n        TOKEN: ${{ secrets.GITHUB_TOKEN }}\n      run: |\n        docker login docker.pkg.github.com -u $GITHUB_ACTOR -p $TOKEN\n\n    - name: Build\n      run: |\n        docker build \n          -t $IMAGE_NAME:$IMAGE_TAG \n          -t $IMAGE_NAME:latest \n          .\n\n    - name: Push image to GitHub Packages\n      run: |\n        docker push $IMAGE_NAME:latest\n        docker push $IMAGE_NAME:$IMAGE_TAG\n\n    - name: Logout\n      run: |\n        docker logout docker.pkg.github.com<\/code><\/pre>\n
    <\/p>\n
    L'immagine viene costruita e caricata in GitHub Packages in due minuti e 20 secondi:<\/p>\n
    <\/p>\n
    \"Alcuni<\/p>\n
    <\/p>\n
    Ora modifichiamo la build per utilizzare la cache basata sulle immagini precedentemente costruite:<\/p>\n
    <\/p>\n
    on:\n  push:\n    branches:\n      - master\n\nname: Test docker build\n\njobs:\n  deploy:\n    name: Build\n    runs-on: ubuntu-latest\n    env:\n      IMAGE_NAME: docker.pkg.github.com\/${{ github.repository }}\/app\n      IMAGE_TAG: ${{ github.sha }}\n\n    steps:\n    - name: Checkout\n      uses: actions\/checkout@v2\n\n    - name: Login to GitHub Packages\n      env:\n        TOKEN: ${{ secrets.GITHUB_TOKEN }}\n      run: |\n        docker login docker.pkg.github.com -u $GITHUB_ACTOR -p $TOKEN\n\n    - name: Pull latest images\n      run: |\n        docker pull $IMAGE_NAME:latest || true\n        docker pull $IMAGE_NAME-builder-stage:latest || true\n\n    - name: Images list\n      run: |\n        docker images\n\n    - name: Build\n      run: |\n        docker build \n          --target builder \n          --cache-from $IMAGE_NAME-builder-stage:latest \n          -t $IMAGE_NAME-builder-stage \n          .\n        docker build \n          --cache-from $IMAGE_NAME-builder-stage:latest \n          --cache-from $IMAGE_NAME:latest \n          -t $IMAGE_NAME:$IMAGE_TAG \n          -t $IMAGE_NAME:latest \n          .\n\n    - name: Push image to GitHub Packages\n      run: |\n        docker push $IMAGE_NAME-builder-stage:latest\n        docker push $IMAGE_NAME:latest\n        docker push $IMAGE_NAME:$IMAGE_TAG\n\n    - name: Logout\n      run: |\n        docker logout docker.pkg.github.com<\/code><\/pre>\n
    <\/p>\n
    Per iniziare, \u00e8 necessario spiegare perch\u00e9 vengono eseguite due comandi. build<\/code>La questione \u00e8 che in una build multi-stadio, l'immagine risultante sar\u00e0 un insieme di livelli dell'ultimo stadio. In questo modo, i livelli degli stadi precedenti non verranno inclusi nell'immagine. Pertanto, utilizzando l'immagine finale proveniente da una build precedente, Docker non sar\u00e0 in grado di trovare i livelli gi\u00e0 pronti per costruire l'immagine con nodejs (stadio builder). Per risolvere questo problema, viene creato un'immagine intermedia. $IMAGE_NAME-builder-stage<\/code> e viene caricata in GitHub Packages, affinch\u00e9 possa essere utilizzata in una build successiva come sorgente della cache.<\/p>\n
    <\/p>\n
    \"Alcuni<\/p>\n
    <\/p>\n
    Il tempo totale di build \u00e8 stato ridotto a un minuto e mezzo. Mezzo minuto viene speso per recuperare le immagini precedenti.<\/p>\n
    <\/p>\n
    Creazione preventiva delle immagini<\/h2>\n
    <\/p>\n
    Un altro modo per risolvere il problema della cache pulita di Docker \u00e8 spostare parte degli strati in un altro Dockerfile, compilarlo separatamente, caricarlo nel Container Registry e usarlo come genitore.<\/p>\n
    <\/p>\n
    Creiamo la nostra immagine Node.js per la compilazione dell'applicazione Angular. Creiamo nel progetto Dockerfile.node<\/p>\n
    <\/p>\n
    FROM node:12.16.2-alpine3.11\nRUN apk --no-cache --update --virtual build-dependencies add \n    python \n    make \n    g++<\/code><\/pre>\n
    <\/p>\n
    Costruiamo e carichiamo un'immagine pubblica su Docker Hub:<\/p>\n
    <\/p>\n
    docker build -t exsmund\/node-for-angular -f Dockerfile.node .\ndocker push exsmund\/node-for-angular:latest<\/code><\/pre>\n
    <\/p>\n
    Ora nel nostro Dockerfile principale utilizziamo l'immagine pronta:<\/p>\n
    <\/p>\n
    FROM exsmund\/node-for-angular:latest as builder\n...<\/code><\/pre>\n
    <\/p>\n
    Nel nostro esempio, il tempo di costruzione non \u00e8 diminuito, ma le immagini create in precedenza possono essere utili se hai molti progetti e in ognuno di essi devi installare le stesse dipendenze.<\/p>\n
    <\/p>\n
    \"Alcuni<\/p>\n
    <\/p>\n
    Abbiamo esaminato diversi metodi per accelerare la costruzione delle immagini Docker. Se desideri che il deploy avvenga rapidamente, prova a applicare nel tuo progetto:<\/p>\n
    <\/p>\n