Français
Menu

Bases du cloud et des conteneurs

FROM alpine
COPY data.tar.gz /tmp/
RUN tar -xzf /tmp/data.tar.gz -C /opt && rm /tmp/data.tar.gz

Pour décompresser une archive de 500 MB, data.tar.gz, une image a été construite avec le Dockerfile ci-dessus. Bien que l'archive ait été supprimée dans le même RUN après la décompression, l'image est restée plus grosse de la taille de l'archive. Quelle association entre la cause et le remède est la plus appropriée ?

  1. ALe rm placé après && n'est pas exécuté pendant la construction. Il faut écrire le rm dans une instruction RUN séparée
  2. BLes fichiers supprimés restent dans l'image sous forme de cache de construction. Il faut reconstruire en ajoutant --no-cache à docker build
  3. CL'archive reste dans la couche créée par l'instruction COPY. Il faut utiliser une construction multi-étapes et ne copier dans l'image finale que les fichiers décompressés
Afficher la réponse et l'explication

Réponse : C. L'archive reste dans la couche créée par l'instruction COPY. Il faut utiliser une construction multi-étapes et ne copier dans l'image finale que les fichiers décompressés

Chaque instruction d'un Dockerfile qui modifie le système de fichiers (comme COPY ou RUN) devient une couche, et une image est l'empilement de ces couches. Supprimer un fichier dans une couche ultérieure ne fait qu'enregistrer une marque de suppression dans la couche supérieure : l'archive de 500 MB entrée dans la couche de COPY reste donc dans l'image. Avec une construction multi-étapes qui décompresse dans une autre étape et n'apporte que les fichiers décompressés dans la dernière étape avec COPY --from, l'archive ne figure pas dans l'image finale. Télécharger, décompresser et supprimer dans un seul RUN est une autre approche, mais elle ne s'applique pas à un fichier apporté par COPY.

S'entraîner sur ce thème Retour au thème

Autres questions sur Bases du cloud et des conteneurs

  1. Cinq images empilent chacune leur propre couche de 30 MB sur la même image de base (120 MB). On néglige la compression des couches et la taille des métadonnées. Quel est l'espace disque utilisé par les images quand les cinq sont récupérées (pull) sur un même serveur ?
  2. Pour le Dockerfile ci-dessus, quelle association entre la commande exécutée lors de la construction de l'image avec docker build et la commande exécutée lors du démarrage d'un conteneur avec docker run est correcte ?
  3. Une image nommée pinger, construite à partir du Dockerfile ci-dessus, est démarrée par docker run pinger example.com. Quelle est la commande exécutée dans le conteneur ?
  4. Un conteneur est démarré par la commande ci-dessus à partir de l'image nginx, un serveur web qui écoute sur le port 80. L'adresse IP de l'hôte est 192.0.2.10, et il n'y a aucune restriction comme un pare-feu. Quelle est l'URL correcte pour joindre ce serveur web depuis un navigateur sur un autre PC du même réseau ?
  5. Le Dockerfile (B) ci-dessus a été obtenu à partir du Dockerfile (A), qui plaçait RUN npm ci après COPY . ., en changeant l'ordre pour ne copier d'abord que les fichiers de dépendances. npm ci prend 120 secondes, npm run build 30 secondes et COPY . . 2 secondes, et la durée des autres instructions est négligeable. L'image est reconstruite 20 fois par jour après une modification du seul code source sous src (package.json et package-lock.json ne changent pas). Si le cache de la construction précédente peut être utilisé, de combien la durée totale de construction par jour est-elle plus courte avec B qu'avec A ?