containerd vs Docker: runtime vs motor completo
O containerd é o runtime de baixo nível que de fato roda os containers; o Docker é o motor completo e a experiência de desenvolvedor construída sobre ele.
O Docker é a plataforma de container completa - CLI, build, rede e ergonomia para o desenvolvedor - e usa o containerd por baixo. O containerd é o runtime focado e graduado pela CNCF que baixa imagens e roda containers; ferramentas como o nerdctl lhe dão uma CLI parecida com a do Docker. Eles operam em camadas diferentes.
| containerd | Docker | |
|---|---|---|
| Camada | Runtime central | Motor completo (usa containerd) |
| CLI | ctr / nerdctl | docker |
| Build de imagens | Via BuildKit/nerdctl | Embutido |
| Melhor para | Plataformas, nós Kubernetes | Fluxos de desenvolvedor + CI |
| Ergonomia | Mais baixo nível | Alta |
No CI
Para a maioria dos pipelines, o Docker é o nível certo de abstração - uma CLI para build, run e push. O containerd importa quando você opera a própria plataforma (nós Kubernetes o usam como runtime) ou quer um runtime mínimo com nerdctl para uma experiência parecida com a do Docker. Compará-los é na verdade comparar camadas: o Docker é o motor do desenvolvedor, o containerd é o que roda os containers.
Acelere
Faça cache dos layers de imagem independentemente do runtime. Ambos rodam em runners de CI; managed runners mais rápidos encurtam pulls e builds.
O veredito
Quer um motor completo e ergonômico para CI e dev: Docker. Operando uma plataforma ou querendo um runtime mínimo (muitas vezes com nerdctl): containerd. Para a maioria dos times, são camadas complementares, não um ou outro estrito.