O Que É Docker Layer Caching? Por Que o Segundo Build É Rápido
Docker layer caching reaproveita o resultado de uma instrução quando suas entradas não mudaram, então apenas os passos após uma mudança real re-executam.
Na primeira vez que você constrói uma imagem, cada layer é criada do zero. Na segunda vez, o Docker verifica cada instrução contra seu cache e reaproveita qualquer layer cujas entradas sejam idênticas. Entender o que invalida o cache é a maior alavanca isolada para builds Docker rápidos.
Como o cache funciona
O Docker percorre o Dockerfile de cima para baixo. Para cada instrução ele computa uma chave de cache a partir da instrução e suas entradas (para COPY, o conteúdo do arquivo). Se a chave corresponde a uma layer cacheada, ele a reaproveita. O primeiro miss invalida aquela layer e tudo depois dela.
A regra da cascata
A invalidação de cache cascateia. Se a linha 5 muda, as linhas 5 até o fim reconstroem mesmo que as linhas 6+ estejam intocadas. É por isso que a ordem das instruções importa tanto.
Ordene para cache hits
Coloque os passos que raramente mudam primeiro e os que mudam com frequência por último. Copie seu lockfile e instale dependências antes de copiar o source, para que uma edição de código não invalide a layer de dependências.
Cache em CI efêmero
Runners de CI novos começam com um cache local vazio, então setups ingênuos reconstroem tudo toda vez. Soluções incluem cache baseado em registry (--cache-from), exports de cache do BuildKit, ou runners que persistem o cache entre jobs.
Caching em runners gerenciados
Os runners gerenciados Latchkey mantêm os caches de layers Docker aquecidos entre jobs, então as layers de dependência e de base são reaproveitadas em vez de reconstruídas - transformando builds frios de vários minutos em segundos.
Principais conclusões
- Uma layer é reaproveitada quando sua instrução e entradas estão inalteradas.
- A invalidação cascateia - uma linha alterada reconstrói tudo depois dela.
- CI efêmero precisa de um cache externo ou persistente para se beneficiar.