{"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 per accelerare la creazione di immagini Docker. Ad esempio, fino a 30 secondi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Prima che una funzione arrivi in produzione, al giorno d'oggi, tra orchestratori complessi e CI\/CD, \u00e8 necessario affrontare un lungo percorso, dal commit ai test e alla consegna. Un tempo era possibile caricare nuovi file via FTP (ma non si fa pi\u00f9 cos\u00ec, giusto?), e il processo di \"deploy\" richiedeva solo pochi secondi. Ora invece \u00e8 necessario creare una richiesta di merge e aspettare un bel po' di tempo affinch\u00e9 la funzione arrivi agli utenti.<\/p>\n

<\/p>\n

Una parte di questo percorso \u00e8 la costruzione dell'immagine Docker. A volte la costruzione dura minuti, altre volte decine di minuti, il che \u00e8 difficile da definire normale. In questo articolo prenderemo un'applicazione semplice da impacchettare in un'immagine, applicheremo alcuni metodi per velocizzare la costruzione e esamineremo le peculiarit\u00e0 di questi metodi.<\/p>\n

<\/p>\n

\"Alcuni<\/p>\n

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

Abbiamo una buona esperienza nella creazione e manutenzione di siti per i media: \u0422\u0410\u0421\u0421<\/a><\/noindex>, The Bell<\/a><\/noindex>, \"Nuova Gazetta\"<\/a><\/noindex>, Republic<\/a><\/noindex>\u2026 Non molto tempo fa abbiamo ampliato il nostro portafoglio, lanciando in produzione il sito Reminder<\/a><\/noindex>. E mentre affinavamo rapidamente nuove funzionalit\u00e0 e sistemavamo bug preesistenti, il lento deploy \u00e8 diventato un grande problema.<\/p>\n

<\/p>\n

Effettuiamo il deploy su GitLab. Creiamo immagini, le pubblichiamo nel GitLab Registry e le distribuiamo in produzione. In questo elenco, la cosa pi\u00f9 lunga \u00e8 la costruzione delle immagini. Per esempio: senza ottimizzazione, ogni costruzione del backend richiedeva 14 minuti.<\/p>\n

<\/p>\n

\"Alcuni<\/p>\n

<\/p>\n

Alla fine \u00e8 diventato chiaro che non si poteva continuare cos\u00ec, e ci siamo messi a capire perch\u00e9 le immagini venivano costruite in cos\u00ec tanto tempo. 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 in Angular. Quindi, creiamo la nostra applicazione:<\/p>\n

<\/p>\n

ng n app<\/code><\/pre>\n
<\/p>\n
Aggiungiamo il 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, vediamo come \u00e8 strutturata un'immagine docker. Docker consente di impacchettare applicazioni e di eseguirle in un ambiente isolato, chiamato contenitore. Grazie all'isolamento, \u00e8 possibile eseguire pi\u00f9 contenitori contemporaneamente su un server. I contenitori sono significativamente pi\u00f9 leggeri delle macchine virtuali, poich\u00e9 vengono eseguiti direttamente sul kernel del sistema. Per avviare un contenitore con la nostra applicazione, prima dobbiamo creare un'immagine, in cui impacchettiamo tutto ci\u00f2 che \u00e8 necessario per far funzionare la nostra applicazione. In sostanza, l'immagine \u00e8 un'istantanea del file system. Ad esempio, consideriamo questo 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 nella file system e le sovrapporr\u00e0 a quelle precedenti. Ogni comando crea il proprio layer. Un'immagine finale \u00e8 quindi un'unione di questi layer.<\/p>\n
<\/p>\n
\u00c8 importante sapere che Docker pu\u00f2 memorizzare in cache ciascun layer. Se nulla \u00e8 cambiato rispetto alla costruzione precedente, Docker utilizzer\u00e0 il layer gi\u00e0 pronto invece di eseguire di nuovo il comando. Poich\u00e9 il principale incremento nella velocit\u00e0 di costruzione si basa sull'uso della cache, durante le misurazioni della velocit\u00e0 di costruzione ci concentreremo sulla costruzione dell'immagine con la cache gi\u00e0 pronta. Procediamo passo dopo passo:<\/p>\n
<\/p>\n
    \n
  1. Eliminiamo le immagini localmente, affinch\u00e9 i precedenti avvii non influenzino il test.
    \ndocker rmi $(docker images -q)<\/code><\/li>\n
  2. Eseguiamo il 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 il build per la seconda volta.
    \ntime docker build -t app .<\/code><\/li>\n<\/ol>\n
    <\/p>\n
    Se l'ambiente per la costruzione delle immagini \u00e8 configurato correttamente (di questo parler\u00f2 tra poco), Docker avr\u00e0 gi\u00e0 una serie di cache pronte al momento di avviare la costruzione. Il nostro obiettivo \u00e8 imparare a utilizzare la cache in modo tale che la costruzione avvenga il pi\u00f9 rapidamente possibile. Poich\u00e9 si presume che l'avvio della costruzione senza cache avvenga solo una volta - la prima volta, possiamo ignorare quanto sia stato lento quel primo avvio. Nei test, \u00e8 importante per noi il secondo avvio della costruzione, quando le cache sono gi\u00e0 attive e siamo pronti a sfornare la nostra torta. Tuttavia, alcuni consigli influenzeranno anche la prima costruzione.<\/p>\n
    <\/p>\n
    Posizioniamo il Dockerfile, descritto sopra, nella cartella del progetto e avviamo la costruzione. Tutti i listati sopra sono stati abbreviati per facilitare la lettura.<\/p>\n
    <\/p>\n
    $ time docker build -t app .\nSending build context to Docker daemon 409MB\nStep 1\/5 : FROM node:12.16.2\nStatus: Downloaded newer image for node:12.16.2\nStep 2\/5 : WORKDIR \/app\nStep 3\/5 : COPY . .\nStep 4\/5 : RUN npm ci\nadded 1357 packages in 22.47s\nStep 5\/5 : RUN npm run build --prod\nDate: 2020-04-16T19:20:09.664Z - Hash: fffa0fddaa3425c55dd3 - Time: 37581ms\nSuccessfully built c8c279335f46\nSuccessfully tagged app:latest\n\nreal 5m4.541s\nuser 0m0.000s\nsys 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 .\nSending build context to Docker daemon 409MB\nStep 1\/5 : FROM node:12.16.2\nStep 2\/5 : WORKDIR \/app\n ---> Using cache\nStep 3\/5 : COPY . .\nStep 4\/5 : RUN npm ci\nadded 1357 packages in 22.47s\nStep 5\/5 : RUN npm run build --prod\nDate: 2020-04-16T19:26:26.587Z - Hash: fffa0fddaa3425c55dd3 - Time: 37902ms\nSuccessfully built 79f335df92d3\nSuccessfully tagged app:latest\n\nreal 3m33.262s\nuser 0m0.000s\nsys 0m0.000s<\/code><\/pre>\n
    <\/p>\n
    Per controllare se abbiamo ottenuto l'immagine, eseguiamo il comando docker images<\/code>:<\/p>\n
    <\/p>\n
    REPOSITORY   TAG      IMAGE ID       CREATED              SIZE\napp          latest   79f335df92d3   About a minute ago   1.74GB<\/code><\/pre>\n
    <\/p>\n
    Prima della costruzione, Docker prende tutti i file nel contesto attuale e li invia al suo demone Sending build context to Docker daemon 409MB<\/code>. Il contesto per la build viene specificato come ultimo argomento del comando build. Nel nostro caso, si tratta della directory corrente \u2014 \u00ab.\u00bb, \u2014 e Docker trascina tutto ci\u00f2 che abbiamo in questa cartella. 409 MB sono molti: pensiamo insieme a come correggere questo.<\/p>\n
    <\/p>\n
    Riduciamo il contesto<\/h2>\n
    <\/p>\n
    Per ridurre il contesto, ci sono due opzioni. Possiamo mettere tutti i file necessari per la build in una cartella separata e indicare a Docker di usare proprio quella per il contesto. Questo potrebbe non essere sempre comodo, quindi abbiamo la possibilit\u00e0 di indicare delle eccezioni: cosa non deve essere inclusa nel contesto. A questo scopo, creiamo un file .dockerignore nel progetto e indichiamo ci\u00f2 che non serve per la build:<\/p>\n
    <\/p>\n
    .git\n\/node_modules<\/code><\/pre>\n
    <\/p>\n
    e rilanciamo la build ancora una volta:<\/p>\n
    <\/p>\n
    $ time docker build -t app .\nInvio del contesto di build al demone Docker 607.2kB\nPassaggio 1\/5 : FROM node:12.16.2\nPassaggio 2\/5 : WORKDIR \/app\n ---> Utilizzando la cache\nPassaggio 3\/5 : COPY . .\nPassaggio 4\/5 : RUN npm ci\naggiunti 1357 pacchetti in 22.47s\nPassaggio 5\/5 : RUN npm run build --prod\nData: 2020-04-16T19:33:54.338Z - Hash: fffa0fddaa3425c55dd3 - Tempo: 37313ms\nBuild riuscito 4942f010792a\nTagging riuscito app:latest\n\nreale 1m47.763s\nutente 0m0.000s\nsys 0m0.000s<\/code><\/pre>\n
    <\/p>\n
    607.2 KB \u2014 molto meglio di 409 MB. Inoltre, abbiamo ridotto le dimensioni dell'immagine da 1.74 a 1.38 GB:<\/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 le dimensioni dell'immagine.<\/p>\n
    <\/p>\n
    Utilizziamo Alpine<\/h2>\n
    <\/p>\n
    Un altro modo per risparmiare sulle dimensioni dell'immagine \u00e8 utilizzare un'immagine base pi\u00f9 piccola. L'immagine base \u00e8 l'immagine sulla quale viene costruita la nostra immagine. Lo strato inferiore \u00e8 specificato con il comando DA<\/code> nel Dockerfile. Nel nostro caso, stiamo usando un'immagine basata su Ubuntu, in cui \u00e8 gi\u00e0 presente nodejs. E pesa \u2026<\/p>\n
    <\/p>\n
    $ docker images -a | grep node\nnode 12.16.2 406aa3abbc6c 17 minuti fa 916MB<\/code><\/pre>\n
    <\/p>\n
    \u2026 quasi un gigabyte. Possiamo ridurre notevolmente il peso utilizzando un'immagine basata su Alpine Linux. Alpine \u00e8 un Linux molto leggero. L'immagine Docker per nodejs basata su alpine pesa solo 88.5 MB. Quindi, sostituiamo la nostra immagine pesante:<\/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 la build dell'applicazione. S\u00ec, Angular non si compila senza Python \u00af(\u00b0_o)\/\u00af<\/p>\n
    <\/p>\n
    Ma, ancora, le dimensioni dell'immagine sono diminuite 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 ancora oltre.<\/p>\n
    <\/p>\n
    Build multi-stadio<\/h2>\n
    <\/p>\n
    Non tutto ci\u00f2 che \u00e8 presente 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
    Con docker run app ls -lah<\/code> \u00e8 stato eseguito un contenitore basato sulla nostra immagine app<\/code> e abbiamo eseguito al suo interno il comando ls -lah<\/code>, dopo di che il contenitore ha terminato la sua esecuzione.<\/p>\n
    <\/p>\n
    In produzione ci serve solo la cartella dist<\/code>. A questo punto, dobbiamo fornire i file all'esterno. Possiamo avviare un qualche server HTTP su nodejs. Ma lo faremo in modo pi\u00f9 semplice. Indovina una parola russa che ha quattro lettere \u00ab\u044b\u00bb. Esatto! \u042b\u043d\u0436\u044b\u043d\u044b\u043a\u0441\u044b. Prendiamo un'immagine con nginx, mettiamo dentro la cartella dist<\/code> e un piccolo file di 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
    Per eseguire tutto questo ci aiuter\u00e0 la build multi-stadio. 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 la propria fase di build. La prima l'abbiamo chiamata builder<\/code>, e da quel momento in poi l'ultimo FROM verr\u00e0 utilizzato per preparare la nostra immagine finale. Nell'ultimo passaggio, copiamo l'artefatto della nostra build dalla fase precedente nell'immagine finale con nginx. Le dimensioni dell'immagine sono diminuite notevolmente:<\/p>\n
    <\/p>\n
    REPOSITORY   TAG      IMAGE ID       CREATED          SIZE\napp          latest   2c6c5da07802   29 minuti fa   36MB<\/code><\/pre>\n
    <\/p>\n
    Eseguiamo un contenitore 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 esportato la porta 8080 sulla nostra macchina host alla porta 80 all'interno del contenitore, 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 le dimensioni dell'immagine da 1.74 GB a 36 MB accorcia significativamente il tempo necessario per portare la tua applicazione in produzione. Ma torniamo al tempo di build.<\/p>\n
    <\/p>\n
    $ time docker build -t app .\nInvio del contesto di build al demone Docker 608.8kB\nPassaggio 1\/11 : FROM node:12.16.2-alpine3.11 as builder\nPassaggio 2\/11 : RUN apk --no-cache --update --virtual build-dependencies add python make g++\n ---> Utilizzando la cache\nPassaggio 3\/11 : WORKDIR \/app\n ---> Utilizzando la cache\nPassaggio 4\/11 : COPY . .\nPassaggio 5\/11 : RUN npm ci\naggiunti 1357 pacchetti in 47.338s\nPassaggio 6\/11 : RUN npm run build --prod\nData: 2020-04-16T21:16:03.899Z - Hash: fffa0fddaa3425c55dd3 - Tempo: 39948ms\n ---> 27f1479221e4\nPassaggio 7\/11 : FROM nginx:stable-alpine\nPassaggio 8\/11 : WORKDIR \/app\n ---> Utilizzando la cache\nPassaggio 9\/11 : RUN rm \/etc\/nginx\/conf.d\/default.conf\n ---> Utilizzando la cache\nPassaggio 10\/11 : COPY nginx\/static.conf \/etc\/nginx\/conf.d\n ---> Utilizzando la cache\nPassaggio 11\/11 : COPY --from=builder \/app\/dist\/app .\nBuild riuscito d201471c91ad\nTagging riuscito app:latest\n\nreale 2m17.700s\nutente 0m0.000s\nsys 0m0.000s<\/code><\/pre>\n
    <\/p>\n
    Cambiamo l'ordine dei layer<\/h2>\n
    <\/p>\n
    I primi tre passaggi sono stati memorizzati nella cache (indicazione Utilizzando la cache<\/code>). Nel quarto passaggio vengono copiati tutti i file del progetto e nel quinto vengono installate le dipendenze RUN npm ci<\/code> \u2014 un intero 47.338s. Perch\u00e9 reinstallare ogni volta le dipendenze, se cambiano molto raramente? Analizziamo perch\u00e9 non sono state memorizzate nella cache. Il fatto \u00e8 che Docker controlla layer per layer, se il comando e i file associati a esso sono cambiati. Nel quarto passaggio copiamo tutti i file del nostro progetto e tra questi, naturalmente, ci sono cambiamenti, quindi Docker non solo non utilizza dalla cache questo layer, ma neppure 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
    Inizialmente vengono copiati package.json e package-lock.json, quindi vengono installate le dipendenze e solo dopo viene copiato l'intero progetto. 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 invece di 3 minuti \u2014 notevolmente meglio! \u00c8 importante seguire l'ordine corretto dei layer: prima copiamo ci\u00f2 che non cambia, poi ci\u00f2 che cambia raramente e infine ci\u00f2 che cambia spesso.<\/p>\n
    <\/p>\n
    Parliamo ora brevemente della creazione di immagini nei sistemi CI\/CD.<\/p>\n
    <\/p>\n
    Utilizzo delle immagini precedenti per la cache<\/h2>\n
    <\/p>\n
    Se stiamo utilizzando una soluzione SaaS per la creazione, la cache locale di Docker pu\u00f2 risultare pulita e aggiornata. Per consentire a Docker di avere da dove recuperare i layer gi\u00e0 creati, fornitegli un'immagine precedente costruita.<\/p>\n
    <\/p>\n
    Prendiamo ad esempio la build della nostra app 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 inviata a GitHub Packages in due minuti e 20 secondi:<\/p>\n
    <\/p>\n
    \"Alcuni<\/p>\n
    <\/p>\n
    Ora modifichiamo la build in modo che utilizzi la cache basata su 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>. Il fatto \u00e8 che in una build multi-stadio, l'immagine risultante sar\u00e0 un insieme di layer dell'ultimo stadio. In questo modo, i layer degli stadi precedenti non verranno inclusi nell'immagine. Pertanto, quando si utilizza l'immagine finale dalla precedente build, Docker non sar\u00e0 in grado di trovare i layer gi\u00e0 pronti per costruire l'immagine con nodejs (stadio builder). Per risolvere questo problema, si crea un'immagine intermedia $IMAGE_NAME-builder-stage<\/code> e viene inviata a GitHub Packages, in modo che possa essere utilizzata nella build successiva come fonte di cache.<\/p>\n
    <\/p>\n
    \"Alcuni<\/p>\n
    <\/p>\n
    Il tempo totale di costruzione \u00e8 stato ridotto a un minuto e mezzo. Trenta secondi vengono spesi per caricare le immagini precedenti.<\/p>\n
    <\/p>\n
    Creazione preliminare delle immagini<\/h2>\n
    <\/p>\n
    Un altro modo per risolvere il problema della cache pulita di Docker \u00e8 spostare alcuni layer in un altro Dockerfile, costruirlo separatamente, inviarlo al Container Registry e utilizzarlo come base.<\/p>\n
    <\/p>\n
    Creiamo la nostra immagine nodejs per costruire applicazioni Angular. Creiamo un Dockerfile.node nel progetto<\/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 pubblichiamo l'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 build non \u00e8 diminuito, ma le immagini pre-create possono essere utili se hai molti progetti e in ciascuno di essi devi installare le stesse dipendenze.<\/p>\n
    <\/p>\n
    \"Alcuni<\/p>\n
    <\/p>\n
    Abbiamo esaminato diversi metodi per accelerare la build delle immagini Docker. Se desideri che il deploy avvenga rapidamente, prova ad applicare nel tuo progetto:<\/p>\n
    <\/p>\n