EnglishCommencer

Docker avancé : des images légères

Construire en plusieurs étapes, choisir une image de base minimale, ordonner les couches pour profiter du cache, exclure ce qui n'a rien à faire dans l'image, tirer par empreinte et pousser sur un registre privé.

  • 28 cartes
  • 4 thèmes
  • Gratuit
Réviser ce deck

Le programme, thème par thème

Le poids de chaque thème suit celui que lui donne l'examen.

  1. Notions
  2. Questions
  3. Ranger et relier
  4. Mises en situation

Quelques cartes du deck

  • Construction en plusieurs étapes : de quoi s'agit-il ?

    Voir la réponse

    Dockerfile à plusieurs instructions FROM : une étape compile avec tous ses outils, l'étape finale ne reprend que le résultat par COPY --from.

    Seule la dernière étape devient l'image livrée. Le compilateur, les sources et les caches des étapes précédentes n'y figurent pas : pour un binaire Go, l'image passe de plusieurs centaines de Mo à quelques Mo.

  • Ce Dockerfile est construit une première fois. Tu modifies ensuite uniquement server.js et tu relances docker build. Quelles instructions sont refaites ?

    ```dockerfile
    FROM node:20-alpine
    WORKDIR /app
    COPY package.json package-lock.json ./
    RUN npm ci
    COPY . .
    CMD ["node", "server.js"]
    `

    • COPY . . seulement : npm ci reste en cache
    • Toutes, de FROM à CMD, comme à la première construction
    • RUN npm ci et COPY . ., car l'installation lit aussi server.js
    • Aucune : server.js n'est pas listé dans une instruction COPY
    Voir la réponse

    COPY . . seulement : npm ci reste en cache

    Le cache s'invalide à partir de la première instruction dont les entrées changent. La copie des seuls fichiers de dépendances précède l'installation : tant qu'ils sont intacts, npm ci est réutilisé. COPY . . voit server.js changer, et c'est la dernière couche refaite (CMD n'est qu'une métadonnée).

  • Dans un Dockerfile en plusieurs étapes, on nomme l'étape de compilation avec … et on en récupère un fichier dans l'étape finale avec ….

    Voir la réponse

    Dans un Dockerfile en plusieurs étapes, on nomme l'étape de compilation avec FROM golang:1.22 AS build et on en récupère un fichier dans l'étape finale avec COPY --from=build.

    AS build donne un nom à l'étape ; --from=build copie depuis le système de fichiers de cette étape plutôt que depuis le contexte de construction.

  • Image de base : de quoi s'agit-il ?

    Voir la réponse

    Image désignée par FROM, sur laquelle toutes les couches d'un Dockerfile s'empilent ; elle fixe le système, les outils et une grande partie du poids.

    Plus elle contient d'outils (shell, gestionnaire de paquets), plus l'image est lourde et plus il y a de choses à mettre à jour ou à exploiter. Variantes courantes : complète, slim, alpine, distroless, scratch.

  • Une API Node de 40 Mo de code sort en image de 1,1 Go, construite sur node:20 avec ses outils de compilation. Quelle amélioration réduit le plus la taille sans changer l'application ?

    • Enchaîner tous les RUN en un seul pour réduire le nombre de couches
    • Compresser l'image avec gzip avant de la pousser
    • Passer à la base latest, qui est plus récente donc plus petite
    • Une construction en plusieurs étapes dont l'étape finale part d'une base alpine ou slim
    Voir la réponse

    Une construction en plusieurs étapes dont l'étape finale part d'une base alpine ou slim

    Le poids vient surtout de la base et des outils de construction : l'étape finale ne garde que le code et ses dépendances d'exécution, sur une base minimale. Fusionner des RUN n'enlève pas les outils, et les images sont déjà compressées à l'envoi.

Réviser ce deck