Docker vs Kaniko: construindo imagens sem um daemon
Docker constrói imagens via um daemon privilegiado; Kaniko as constrói a partir de um Dockerfile dentro de um container sem daemon e sem root, ideal para Kubernetes.
Docker é o construtor de imagens padrão, mas precisa de um daemon e tipicamente de acesso privilegiado. Kaniko (Google) constrói imagens a partir de um Dockerfile inteiramente em userspace dentro de um container - sem daemon, sem socket Docker - e é por isso que é popular para construir imagens em CI baseado em Kubernetes sem privilégios.
| Docker | Kaniko | |
|---|---|---|
| Daemon necessário | Sim | Não |
| Privilégio | Frequentemente privilegiado | Sem privilégios |
| Melhor ambiente | VMs, runners padrão | Kubernetes, runners restritos |
| Paridade com dev local | Alta | Apenas build |
| Cache | Cache de layer + BuildKit | Cache de layer para registry |
No CI
Em runners VM padrão com um daemon Docker, Docker (com BuildKit) é o mais simples e rápido. Kaniko conquista seu lugar quando você constrói dentro de Kubernetes ou em runners que proíbem um socket Docker ou modo privilegiado - ele constrói e faz push a partir de um Dockerfile sem qualquer daemon. O cache do Kaniko funciona via um cache de registry em vez de um cache de daemon local.
Acelere
Faça push e reutilize um cache de layer no seu registry para que rebuilds pulem stages inalterados. Ambos rodam em runners de CI; runners gerenciados mais rápidos encurtam o build da imagem em si.
O veredito
Runners padrão com um daemon: Docker com BuildKit. Builds sem daemon, sem privilégios, ou dentro de Kubernetes: Kaniko. Escolha pelas restrições de segurança e isolamento do seu runner.