docker build vs BuildKit: builds de imagem mais rápidos no CI
BuildKit é o backend de build moderno para Docker - ele paraleliza stages, suporta cache mounts e build secrets, e agora é o padrão.
O docker build legado executa um Dockerfile sequencialmente com cache de layer grosseiro. BuildKit (exposto via docker buildx e agora o builder padrão) paraleliza stages independentes, adiciona cache mounts, build secrets e export/import de cache mais rico - um grande ganho de velocidade no CI com o mesmo Dockerfile.
| docker build (legado) | BuildKit | |
|---|---|---|
| Paralelismo de stages | Sequencial | Paralelo |
| Cache mounts | Não | Sim (--mount=type=cache) |
| Build secrets | Contornos | Nativo (--secret) |
| Export/import de cache | Limitado | Rico (registry, gha, local) |
| Status | Legado | Builder padrão |
No CI
BuildKit é a escolha clara em pipelines modernos: stages paralelos cortam o tempo de relógio, cache mounts mantêm os downloads de pacotes quentes entre builds, e os backends de cache gha ou registry deixam um job reutilizar as layers de outro job. O docker build legado ainda existe para configurações antigas, mas deixa velocidade na mesa. Habilite o BuildKit (ele está ligado por padrão em versões recentes do Docker) ou use docker buildx.
Acelere
Exporte o cache do BuildKit para um registry ou para o cache do GitHub Actions e importe-o na próxima execução para layers quentes. Builds ainda rodam em runners de CI; runners gerenciados mais rápidos encurtam o build real da layer.
O veredito
Use BuildKit (buildx) - ele é o padrão, constrói em paralelo e adiciona cache mounts e secrets. Há pouca razão para ficar no docker build legado exceto para ambientes muito antigos e congelados.