L’IMAGE OBÈSE
L’image payments-api:latest embarque un cache de compilation inutile. Inspecte ses vraies couches, puis construis la cible runtime du Dockerfile multi-stage déjà préparé.
Chaque livraison transfère une couche de cache inutile et ralentit le déploiement de payments-api.
Exemples disponibles dans le briefing.
ENVIRONNEMENT
- Docker 29 imbriqué dans gVisor
- Images payments-api:latest et base Alpine locales
- Aucun accès réseau extérieur
PRÉREQUIS & COMPÉTENCES
- Comprendre les couches Docker
- Connaître les builds multi-stage
- Analyse de taille
- Build ciblé
- Comparaison d’images
CONTRAINTES
- Conserver le comportement de l’application
- Produire le tag payments-api:slim
- Ne pas utiliser le socket Docker hôte
Syntaxe et options des commandes Docker utilisées dans le terminal.
OUVRIR ↗DockerDocker BuildImages, Dockerfile, cache, BuildKit et chaîne de construction.
OUVRIR ↗DockerBuilds multi-stageRéduire la taille et la surface d’attaque d’une image finale.
OUVRIR ↗docs dans le terminal pour rappeler ces liens.OBJECTIFS
- Inspecter les couches
- Construire la cible optimisée
- Vérifier le poids final
Inspecte l’historique de payments-api:latest pour repérer la couche qui transporte le cache legacy.
ValidationUne commande d’historique ou d’inspection de l’image doit réussir et afficher ses couches.
EXEMPLES ACCEPTÉS
docker history payments-api:latest
docker image history --no-trunc payments-api:latestTab compléter · ↑/↓ historique · hint indices · why explication · docs références · solution après effort · restart recommencer
OpsArena gVisor · Docker 29 isolé
Image cible réelle : payments-api:latest