ingénierie
Architecture Docker pour les ingénieurs CI
Démon, conteneur, BuildKit et snapshotter : ce que chacun fait et lequel ralentit votre construction.
{auteur} · {rôle} · 2026-04-21 · 10 min de lecture
La plupart des conseils de performances Docker sont une liste d'astuces Dockerfile. Cela fonctionne mieux si vous savez à quel composant chaque astuce s'adresse réellement.
Les pièces
Lequel est lent
- Ralentir avant l'exécution d'une étape → démarrage du démon et extraction de l'image ; corriger avec un coureur chaud et un cache pull-through
- Ralentir pendant COPY et RUN avec une attente d'E/S élevée → le snapshotter sur le disque connecté au réseau ; réparer avec NVMe local
- Reconstruire les couches qui n'ont pas changé → Cache BuildKit ; correction de l'ordre des instructions et du backend du cache
- arm64 catastrophiquement lent → QEMU, pas Docker ; réparer avec les coureurs natifs
Votre prochain build pourrait être deux fois plus rapide, pour moitié prix
Commencez gratuitement. Repartir tient à la même ligne, et nous publions ce diff aussi.
À lire aussi
CI quand vos coéquipiers sont des agentsLes agents de codage de l’IA poussent beaucoup plus souvent que les humains. Voici comment cela change la conception des pipelines et le contrôle des coûts.Pourquoi nous publions des instructions pour partirChaque page de migration de ce site inclut la différence pour migrer vers nous. Voici le raisonnement.Ce que nous avons appris en gérant un million d'emplois CITemps d'attente, comportement du cache, dimensionnement correct et modes de défaillance qui n'apparaissent qu'à grande échelle.Arrêtez de réessayer des tests instablesLes tentatives automatiques convertissent un bug réel en un bug intermittent et entraînent votre équipe à se méfier de chaque échec.