techniek
Docker-architectuur voor CI-ingenieurs
Daemon, containerd, BuildKit en de snapshotter - wat ze allemaal doen en welke je build traag maakt.
{auteur} · {rol} · {datum} · {minuten} min leestijd
Het meeste Docker-prestatieadvies bestaat uit een lijst met Dockerfile-trucs. Het werkt beter als je weet op welk onderdeel elke truc daadwerkelijk betrekking heeft.
De stukken
Welke is langzaam
- Langzaam voordat een stap wordt uitgevoerd → daemon starten en image pull; repareren met een warme hardloper en een doortrekcache
- Langzaam tijdens COPY en RUN met hoge I/O-wachttijd → de snapshotter op netwerkgekoppelde schijf; repareren met lokale NVMe
- Lagen opnieuw opbouwen die niet zijn veranderd → BuildKit-cache; repareer de instructievolgorde en cache-backend
- arm64 catastrofaal traag → QEMU, niet Docker; oplossen met inheemse hardlopers
Je volgende build kan twee keer zo snel zijn, voor de halve prijs
Begin gratis. Weggaan is dezelfde ene regel, en die diff publiceren we ook.
Gerelateerd
CI als je teamgenoten agenten zijnAI-codeermiddelen pushen veel vaker dan mensen. Hier leest u hoe dat het pijplijnontwerp en de kostenbeheersing verandert.Waarom we instructies voor vertrek publicerenElke migratiepagina op deze site bevat de diff om terug van ons te migreren. Hier is de redenering.Wat we hebben geleerd bij het runnen van een miljoen CI-banenWachtrijtijd, cachegedrag, juiste grootte en de faalmodi die alleen op schaal voorkomen.Stop met het opnieuw proberen van slechte testsAutomatische nieuwe pogingen veranderen een echte bug in een periodieke bug en trainen uw team om elke fout te wantrouwen.