{"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\/fr\/blog\/administrirovanie\/neskolko-sovetov-o-tom-kak-uskorit-sborku-docker-obrazov-naprimer-do-30-sekund","title":{"rendered":"Quelques conseils pour acc\u00e9l\u00e9rer la construction des images Docker. Par exemple, jusqu'\u00e0 30 secondes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Avant qu'une fonctionnalit\u00e9 n'atteigne la production, dans notre \u00e9poque d'orchestrateurs complexes et de CI\/CD, elle doit passer par un long chemin depuis le commit jusqu'aux tests et \u00e0 la livraison. Auparavant, il \u00e9tait possible de transf\u00e9rer de nouveaux fichiers par FTP (ce qui n'est plus la norme, n'est-ce pas ?), et le processus de \"d\u00e9ploiement\" ne prenait que quelques secondes. Maintenant, il faut cr\u00e9er une demande de fusion et attendre un certain temps avant que la fonctionnalit\u00e9 ne parvienne aux utilisateurs.<\/p>\n

<\/p>\n

Une partie de ce parcours consiste \u00e0 construire une image Docker. Parfois, la construction dure des minutes, parfois des dizaines de minutes, ce qui est difficilement acceptable. Dans cet article, nous prendrons une application simple que nous emballerons dans une image, appliquerons plusieurs m\u00e9thodes pour acc\u00e9l\u00e9rer la construction et examinerons les nuances de ces m\u00e9thodes.<\/p>\n

<\/p>\n

\"Quelques<\/p>\n

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

Nous avons une bonne exp\u00e9rience de cr\u00e9ation et de maintenance de sites d'information : TASS<\/a><\/noindex>, The Bell<\/a><\/noindex>, "Nouvelle Gazette"<\/a><\/noindex>, Republic<\/a><\/noindex>\u2026 R\u00e9cemment, nous avons compl\u00e9t\u00e9 notre portefeuille en lan\u00e7ant en production le site Reminder<\/a><\/noindex>. Et pendant que nous peaufinions rapidement de nouvelles fonctionnalit\u00e9s et corrigions d'anciens bugs, le d\u00e9ploiement lent est devenu un gros probl\u00e8me.<\/p>\n

<\/p>\n

Nous effectuons le d\u00e9ploiement sur GitLab. Nous construisons des images, les poussons dans le GitLab Registry et les d\u00e9ployons en production. Dans cette liste, le plus long est la construction des images. \u00c0 titre d'exemple : sans optimisation, chaque construction du backend prenait 14 minutes.<\/p>\n

<\/p>\n

\"Quelques<\/p>\n

<\/p>\n

Finalement, il est devenu clair qu'il \u00e9tait impossible de continuer ainsi, nous avons donc d\u00e9cid\u00e9 d'explorer pourquoi les images prenaient autant de temps \u00e0 se construire. Au final, nous avons r\u00e9ussi \u00e0 r\u00e9duire le temps de construction \u00e0 30 secondes !<\/p>\n

<\/p>\n

\"Quelques<\/p>\n

<\/p>\n

Pour cet article, afin de ne pas se rattacher \u00e0 l'environnement de Reminder, consid\u00e9rons un exemple de construction d'une application vide sur Angular. Ainsi, cr\u00e9ons notre application :<\/p>\n

<\/p>\n

ng n app<\/code><\/pre>\n
<\/p>\n
Ajoutons-lui PWA (nous sommes progressistes) :<\/p>\n
<\/p>\n
ng add @angular\/pwa --project app<\/code><\/pre>\n
<\/p>\n
Pendant que des millions de paquets npm sont t\u00e9l\u00e9charg\u00e9s, examinons comment fonctionne une image docker. Docker permet d'emballer des applications et de les ex\u00e9cuter dans un environnement isol\u00e9, appel\u00e9 conteneur. Gr\u00e2ce \u00e0 l'isolation, il est possible d'ex\u00e9cuter plusieurs conteneurs en m\u00eame temps sur un m\u00eame serveur. Les conteneurs sont beaucoup plus l\u00e9gers que les machines virtuelles, car ils s'ex\u00e9cutent directement sur le noyau du syst\u00e8me. Pour ex\u00e9cuter un conteneur avec notre application, nous devons d'abord cr\u00e9er une image dans laquelle nous emballons tout ce qui est n\u00e9cessaire au fonctionnement de notre application. En gros, une image est une copie de la structure du syst\u00e8me de fichiers. Par exemple, prenons un 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
Un Dockerfile est un ensemble d'instructions ; en ex\u00e9cutant chacune d'elles, Docker sauvegardera les modifications dans le syst\u00e8me de fichiers et les appliquera aux pr\u00e9c\u00e9dentes. Chaque commande cr\u00e9e sa propre couche. L'image finale est la combinaison de toutes ces couches.<\/p>\n
<\/p>\n
Ce qu'il est important de savoir : chaque couche peut \u00eatre mise en cache par Docker. Si rien n'a chang\u00e9 depuis la derni\u00e8re construction, Docker utilisera la couche d\u00e9j\u00e0 pr\u00e9par\u00e9e au lieu d'ex\u00e9cuter la commande. Comme le principal gain de vitesse de construction proviendra de l'utilisation du cache, nous nous concentrerons sur la construction de l'image avec le cache d\u00e9j\u00e0 pr\u00eat. Ainsi, de mani\u00e8re chronologique :<\/p>\n
<\/p>\n
    \n
  1. Nous supprimons les images localement pour que les ex\u00e9cutions pr\u00e9c\u00e9dentes n'affectent pas le test.
    \ndocker rmi $(docker images -q)<\/code><\/li>\n
  2. Nous lan\u00e7ons la construction pour la premi\u00e8re fois.
    \ntime docker build -t app .<\/code><\/li>\n
  3. Nous modifions le fichier src\/index.html \u2014 nous simulons le travail d'un programmeur.<\/li>\n
  4. Nous lan\u00e7ons la construction une deuxi\u00e8me fois.
    \ntime docker build -t app .<\/code><\/li>\n<\/ol>\n
    <\/p>\n
    Si l'environnement de construction des images est correctement configur\u00e9 (nous en parlerons un peu plus bas), Docker aura d\u00e9j\u00e0 un tas de caches disponibles lors du lancement de la construction. Notre objectif est d'apprendre \u00e0 utiliser le cache afin que la construction se fasse le plus rapidement possible. Comme nous supposons que le lancement de la construction sans cache n'a lieu qu'une seule fois \u2014 la toute premi\u00e8re \u2014 nous pouvons ignorer la lenteur de ce premier lancement. Dans nos tests, ce qui compte, c'est la seconde ex\u00e9cution de la construction, lorsque les caches sont d\u00e9j\u00e0 radi\u00e9s et que nous sommes pr\u00eats \u00e0 cuire notre g\u00e2teau. Cependant, quelques conseils auront \u00e9galement un impact sur la premi\u00e8re construction.<\/p>\n
    <\/p>\n
    Mettons le Dockerfile d\u00e9crit ci-dessus dans le dossier du projet et lan\u00e7ons la construction. Tous les listings fournis ont \u00e9t\u00e9 abr\u00e9g\u00e9s pour faciliter la lecture.<\/p>\n
    <\/p>\n
    $ time docker build -t app .\nEnvoi du contexte de construction au d\u00e9mon Docker 409 Mo\n\u00c9tape 1\/5 : FROM node:12.16.2\nStatut : Image plus r\u00e9cente t\u00e9l\u00e9charg\u00e9e pour node:12.16.2\n\u00c9tape 2\/5 : WORKDIR \/app\n\u00c9tape 3\/5 : COPY . .\n\u00c9tape 4\/5 : RUN npm ci\n1357 paquets ajout\u00e9s en 22,47 s\n\u00c9tape 5\/5 : RUN npm run build --prod\nDate : 2020-04-16T19:20:09.664Z - Hash : fffa0fddaa3425c55dd3 - Temps : 37581ms\nConstruit avec succ\u00e8s c8c279335f46\n\u00c9tiquet\u00e9 avec succ\u00e8s app:latest\n\nr\u00e9el 5m4.541s\nutilisateur 0m0.000s\nsyst\u00e8me 0m0.000s<\/code><\/pre>\n
    <\/p>\n
    Nous modifions le contenu de src\/index.html et lan\u00e7ons une deuxi\u00e8me fois.<\/p>\n
    <\/p>\n
    $ time docker build -t app .\nEnvoi du contexte de construction au d\u00e9mon Docker 409 Mo\n\u00c9tape 1\/5 : FROM node:12.16.2\n\u00c9tape 2\/5 : WORKDIR \/app\n ---> Utilisation du cache\n\u00c9tape 3\/5 : COPY . .\n\u00c9tape 4\/5 : RUN npm ci\n1357 paquets ajout\u00e9s en 22,47 s\n\u00c9tape 5\/5 : RUN npm run build --prod\nDate : 2020-04-16T19:26:26.587Z - Hash : fffa0fddaa3425c55dd3 - Temps : 37902ms\nConstruit avec succ\u00e8s 79f335df92d3\n\u00c9tiquet\u00e9 avec succ\u00e8s app:latest\n\nr\u00e9el 3m33.262s\nutilisateur 0m0.000s\nsyst\u00e8me 0m0.000s<\/code><\/pre>\n
    <\/p>\n
    Pour v\u00e9rifier si notre image a \u00e9t\u00e9 cr\u00e9\u00e9e avec succ\u00e8s, ex\u00e9cutons la commande docker images<\/code>:<\/p>\n
    <\/p>\n
    R\u00c9PERTOIRE   TAG      ID DE L'IMAGE       CR\u00c9\u00c9              TAILLE\napp          latest   79f335df92d3   Il y a environ une minute   1.74 Go<\/code><\/pre>\n
    <\/p>\n
    Avant de construire, Docker prend tous les fichiers dans le contexte actuel et les envoie \u00e0 son d\u00e9mon. Envoi du contexte de construction au d\u00e9mon Docker 409 Mo<\/code>. Le contexte de construction est sp\u00e9cifi\u00e9 comme le dernier argument de la commande build. Dans notre cas, il s'agit du r\u00e9pertoire courant \u2014 \u00ab. \u00bb \u2014 et Docker tire tout ce que nous avons dans ce dossier. 409 Mo, c'est beaucoup : r\u00e9fl\u00e9chissons \u00e0 comment optimiser cela.<\/p>\n
    <\/p>\n
    R\u00e9duisons le contexte<\/h2>\n
    <\/p>\n
    Pour r\u00e9duire le contexte, il y a deux options. Soit nous pla\u00e7ons tous les fichiers n\u00e9cessaires \u00e0 la construction dans un dossier s\u00e9par\u00e9 et nous indiquons le contexte de Docker sur ce dossier. Cela peut ne pas toujours \u00eatre pratique, donc il est possible de sp\u00e9cifier des exceptions : ce qui ne doit pas \u00eatre inclus dans le contexte. Pour cela, nous allons cr\u00e9er un fichier .dockerignore et indiquer ce qui n'est pas n\u00e9cessaire pour la construction :<\/p>\n
    <\/p>\n
    .git\n\/node_modules<\/code><\/pre>\n
    <\/p>\n
    et nous allons relancer la construction :<\/p>\n
    <\/p>\n
    $ time docker build -t app .\nEnvoi du contexte de construction au d\u00e9mon Docker 607.2 Ko\n\u00c9tape 1\/5 : FROM node:12.16.2\n\u00c9tape 2\/5 : WORKDIR \/app\n ---> Utilisation du cache\n\u00c9tape 3\/5 : COPY . .\n\u00c9tape 4\/5 : RUN npm ci\nAjout de 1357 paquets en 22.47s\n\u00c9tape 5\/5 : RUN npm run build --prod\nDate : 2020-04-16T19:33:54.338Z - Hash : fffa0fddaa3425c55dd3 - Temps : 37313ms\nConstruit avec succ\u00e8s 4942f010792a\nTagu\u00e9 avec succ\u00e8s app:latest\n\nr\u00e9el 1m47.763s\nutilisateur 0m0.000s\nsyst\u00e8me 0m0.000s<\/code><\/pre>\n
    <\/p>\n
    607.2 Ko \u2014 bien mieux que 409 Mo. De plus, nous avons r\u00e9duit la taille de l'image de 1.74 \u00e0 1.38 Go :<\/p>\n
    <\/p>\n
    D\u00c9P\u00d4T   TAG      ID D'IMAGE       CR\u00c9\u00c9         TAILLE\napp          latest   4942f010792a   il y a 3 minutes   1.38GB<\/code><\/pre>\n
    <\/p>\n
    Essayons encore de r\u00e9duire la taille de l'image.<\/p>\n
    <\/p>\n
    Utilisons Alpine<\/h2>\n
    <\/p>\n
    Une autre fa\u00e7on d'\u00e9conomiser sur la taille de l'image est d'utiliser une petite image parent. L'image parent est l'image sur laquelle notre image est construite. Le niveau inf\u00e9rieur est sp\u00e9cifi\u00e9 par la commande DE<\/code> dans le Dockerfile. Dans notre cas, nous utilisons une image bas\u00e9e sur Ubuntu, qui a d\u00e9j\u00e0 Node.js install\u00e9. Et elle p\u00e8se ...<\/p>\n
    <\/p>\n
    $ docker images -a | grep node\nnode 12.16.2 406aa3abbc6c 17 minutes ago 916MB<\/code><\/pre>\n
    <\/p>\n
    ... presque un gigaoctet. On peut r\u00e9duire consid\u00e9rablement l'espace en utilisant une image bas\u00e9e sur Alpine Linux. Alpine est un Linux tr\u00e8s l\u00e9ger. L'image Docker pour Node.js bas\u00e9e sur Alpine ne p\u00e8se que 88.5 Mo. Alors, rempla\u00e7ons notre lourde image par :<\/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
    Nous avons d\u00fb installer certaines choses n\u00e9cessaires \u00e0 la construction de l'application. Oui, Angular ne se construit pas sans Python \u00af(\u00b0_o)\\\/\u00af<\/p>\n
    <\/p>\n
    Mais au moins, la taille de l'image a diminu\u00e9 de 150 Mo :<\/p>\n
    <\/p>\n
    D\u00c9P\u00d4T   TAG      ID D'IMAGE       CR\u00c9\u00c9          TAILLE\napp          latest   aa031edc315a   il y a 22 minutes   761MB<\/code><\/pre>\n
    <\/p>\n
    Allons plus loin.<\/p>\n
    <\/p>\n
    Construction multi-\u00e9tapes<\/h2>\n
    <\/p>\n
    Tout ce qui se trouve dans l'image n'est pas n\u00e9cessaire en production.<\/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
    Avec docker run app ls -lah<\/code> Nous avons lanc\u00e9 un conteneur bas\u00e9 sur notre image app<\/code> et avons ex\u00e9cut\u00e9 la commande ls -lah<\/code>, apr\u00e8s quoi le conteneur a termin\u00e9 son travail.<\/p>\n
    <\/p>\n
    En production, nous avons seulement besoin du dossier dist<\/code>. Cependant, les fichiers doivent \u00eatre accessibles \u00e0 l'ext\u00e9rieur. Nous pouvons d\u00e9marrer un serveur HTTP sur Node.js. Mais nous allons simplifier les choses. Devinez le mot russe qui contient quatre lettres \u00ab\u044b\u00bb. Correct ! \u042b\u043d\u0436\u044b\u043d\u044b\u043a\u0441\u044b. Prenons une image avec Nginx, mettons-y le dossier dist<\/code> et une petite configuration :<\/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
    Tout cela sera facilit\u00e9 par un multi-stage build. Modifions notre 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
    Maintenant, nous avons deux instructions DE<\/code> dans le Dockerfile, chacune d'elles lance sa propre \u00e9tape de construction. La premi\u00e8re s'appelle builder<\/code>, et \u00e0 partir du dernier FROM, notre image finale sera pr\u00e9par\u00e9e. En derni\u00e8re \u00e9tape, nous copions l'art\u00e9fact de notre construction de l'\u00e9tape pr\u00e9c\u00e9dente dans l'image finale avec Nginx. La taille de l'image a \u00e9t\u00e9 consid\u00e9rablement r\u00e9duite :<\/p>\n
    <\/p>\n
    REPOSITORY   TAG      IMAGE ID       CREATED          SIZE\napp          latest   2c6c5da07802   29 minutes ago   36MB<\/code><\/pre>\n
    <\/p>\n
    Lan\u00e7ons un conteneur avec notre image et v\u00e9rifions que tout fonctionne :<\/p>\n
    <\/p>\n
    docker run -p8080:80 app<\/code><\/pre>\n
    <\/p>\n
    Avec l'option -p8080:80, nous avons redirig\u00e9 le port 8080 de notre machine h\u00f4te vers le port 80 \u00e0 l'int\u00e9rieur du conteneur, o\u00f9 Nginx fonctionne. Ouvrons dans le navigateur http:\/\/localhost:8080\/<\/a><\/noindex> et voyons notre application. Tout fonctionne !<\/p>\n
    <\/p>\n
    \"Quelques<\/p>\n
    <\/p>\n
    R\u00e9duire la taille de l'image de 1,74 Go \u00e0 36 Mo diminue consid\u00e9rablement le temps de livraison de votre application en production. Mais revenons au temps de construction.<\/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
    Changeons l'ordre des couches<\/h2>\n
    <\/p>\n
    Les trois premi\u00e8res \u00e9tapes ont \u00e9t\u00e9 mises en cache (indice Using cache<\/code>). \u00c0 la quatri\u00e8me \u00e9tape, tous les fichiers du projet sont copi\u00e9s et \u00e0 la cinqui\u00e8me, les d\u00e9pendances sont install\u00e9es RUN npm ci<\/code> \u2014 un total de 47,338 s. Pourquoi installer les d\u00e9pendances \u00e0 chaque fois alors qu'elles changent tr\u00e8s rarement ? Voyons pourquoi elles n'ont pas \u00e9t\u00e9 mises en cache. En fait, Docker v\u00e9rifie couche par couche si la commande et les fichiers associ\u00e9s ont chang\u00e9. \u00c0 la quatri\u00e8me \u00e9tape, nous copions tous les fichiers de notre projet et, bien s\u00fbr, il y a des modifications, donc Docker ne prend pas seulement pas cette couche dans le cache, mais toutes les suivantes ! Faisons quelques petites modifications dans le 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
    D'abord, package.json et package-lock.json sont copi\u00e9s, puis les d\u00e9pendances sont install\u00e9es, et seulement apr\u00e8s cela, l'ensemble du projet est copi\u00e9. En cons\u00e9quence :<\/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 secondes au lieu de 3 minutes \u2014 c'est bien mieux ! L'ordre des couches est crucial : nous copions d'abord ce qui ne change pas, puis ce qui change rarement, et enfin ce qui change souvent.<\/p>\n
    <\/p>\n
    Ensuite, quelques mots sur la construction des images dans les syst\u00e8mes CI\/CD.<\/p>\n
    <\/p>\n
    Utilisation des images pr\u00e9c\u00e9dentes pour le cache<\/h2>\n
    <\/p>\n
    Si nous utilisons une solution SaaS pour la construction, le cache Docker local peut \u00eatre propre et frais. Pour que Docker puisse r\u00e9cup\u00e9rer des couches d\u00e9j\u00e0 cuites, donnez-lui l'image pr\u00e9c\u00e9dente construite.<\/p>\n
    <\/p>\n
    Prenons l'exemple de la construction de notre application dans GitHub Actions. Utilisons cette configuration.<\/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'image se construit et se pousse dans GitHub Packages en deux minutes et 20 secondes :<\/p>\n
    <\/p>\n
    \"Quelques<\/p>\n
    <\/p>\n
    Nous allons maintenant modifier la construction pour utiliser le cache bas\u00e9 sur les images pr\u00e9c\u00e9demment construites :<\/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
    Pour commencer, il faut expliquer pourquoi deux commandes sont lanc\u00e9es. build<\/code>En effet, dans une construction multi-\u00e9tapes, le r\u00e9sultat sera un ensemble de couches du dernier stade. Les couches des stades pr\u00e9c\u00e9dents ne seront pas incluses dans l'image. Ainsi, lorsque l'image finale de la construction pr\u00e9c\u00e9dente est utilis\u00e9e, Docker ne peut pas trouver les couches pr\u00eates pour construire l'image avec nodejs (stade builder). Pour r\u00e9soudre ce probl\u00e8me, une image interm\u00e9diaire est cr\u00e9\u00e9e. $IMAGE_NAME-builder-stage<\/code> et est envoy\u00e9e dans GitHub Packages afin de pouvoir \u00eatre utilis\u00e9e dans la construction suivante comme source de cache.<\/p>\n
    <\/p>\n
    \"Quelques<\/p>\n
    <\/p>\n
    Le temps total de construction a \u00e9t\u00e9 r\u00e9duit \u00e0 une minute et demie. Une demi-minute est consacr\u00e9e \u00e0 r\u00e9cup\u00e9rer les images pr\u00e9c\u00e9dentes.<\/p>\n
    <\/p>\n
    Cr\u00e9ation d'images pr\u00e9liminaires<\/h2>\n
    <\/p>\n
    Une autre fa\u00e7on de r\u00e9soudre le probl\u00e8me de cache Docker propre est de d\u00e9placer une partie des couches dans un autre Dockerfile, de le construire s\u00e9par\u00e9ment, de le pousser dans le Container Registry et de l'utiliser comme parent.<\/p>\n
    <\/p>\n
    Cr\u00e9ons notre propre image nodejs pour construire une application Angular. Cr\u00e9ez un Dockerfile.node dans le projet.<\/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
    Construisons et poussons l'image publique sur 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
    Maintenant, dans notre Dockerfile principal, utilisons l'image pr\u00eate \u00e0 l'emploi :<\/p>\n
    <\/p>\n
    FROM exsmund\/node-for-angular:latest as builder\n...<\/code><\/pre>\n
    <\/p>\n
    Dans notre exemple, le temps de construction n'a pas diminu\u00e9, mais les images pr\u00e9-cr\u00e9\u00e9es peuvent \u00eatre utiles si vous avez de nombreux projets et que chacun d'eux n\u00e9cessite les m\u00eames d\u00e9pendances.<\/p>\n
    <\/p>\n
    \"Quelques<\/p>\n
    <\/p>\n
    Nous avons examin\u00e9 plusieurs m\u00e9thodes pour acc\u00e9l\u00e9rer la construction des images Docker. Si vous souhaitez que le d\u00e9ploiement se fasse rapidement, essayez d'appliquer dans votre projet :<\/p>\n
    <\/p>\n