O que é o contexto de build e por que usar um arquivo .dockerignore?

Question

Accepted Answer

Quando você executa `docker build`, o Docker envia o **contexto de build** (os arquivos no diretório de build) para o daemon. Um arquivo **.dockerignore** exclui arquivos desnecessários deste contexto — acelerando builds, reduzindo o tamanho da imagem e evitando vazamento de arquivos sensíveis.

## O contexto de build

```bash
docker build -t myapp .     # the "." is the build context — the directory sent to the daemon
# → Docker tarballs the ENTIRE context directory and sends it to the daemon BEFORE building
# → a big context (node_modules, .git, large files) = slow builds, more data transferred
```

O **contexto de build** é o conjunto de arquivos que o Docker envia para o daemon para construir a imagem. Tudo no diretório de build é incluído, a menos que seja excluído — portanto, um contexto inchado desacelera cada build.

## .dockerignore — excluir arquivos desnecessários

```text
# .dockerignore (like .gitignore, for the build context)
node_modules        # don't send local deps (they're installed in the image anyway)
.git                # don't send version history
*.log
.env                # ⚠️ don't send SECRETS into the build context/image
Dockerfile
dist
.vscode
```

`.dockerignore` funciona como `.gitignore`, excluindo arquivos do contexto de build.

## Por que isso importa (três benefícios)

```text
✓ FASTER builds — a smaller context transfers faster; fewer files to process
  (also helps caching: COPY . . won't be invalidated by irrelevant file changes)
✓ SMALLER images — excluded files (node_modules, .git) don't get COPYed into the image
✓ SECURITY — keep SECRETS (.env, keys, credentials) out of the context AND the image
  (a COPY . . could otherwise copy a .env file into the image — a real leak risk)
```

## Por que isso importa

Entender o contexto de build e `.dockerignore` é valioso para **builds Docker eficientes e seguros**, portanto é conhecimento praticamente útil.

Muitos desenvolvedores não percebem que `docker build .` envia o **diretório de contexto de build inteiro para o daemon** antes de construir — então um contexto inchado (contendo `node_modules`, `.git`, artefatos de build, arquivos grandes) torna **cada build mais lento** (mais dados para transferir e processar) e risca copiar arquivos indesejados para a imagem.

O arquivo **`.dockerignore`** (funcionando como `.gitignore`) resolve isso com três benefícios concretos: **builds mais rápidos** (um contexto menor é transferido e processado mais rápido, e também melhora o cache de camadas já que `COPY . .` não será invalidado por alterações em arquivos irrelevantes), **imagens menores** (arquivos excluídos não são copiados — por exemplo, não empacotando `node_modules` locais que são reinstalados de qualquer forma), e crucialmente **segurança** (mantendo **segredos como arquivos `.env`, chaves e credenciais fora do contexto de build e da imagem** — já que um `COPY . .` copiaria um `.env` para a imagem, um risco real e comum de vazamento de credenciais).

Este benefício de segurança é particularmente importante, pois incorporar acidentalmente segredos ou arquivos sensíveis em imagens via uma cópia muito ampla é um erro genuíno que `.dockerignore` ajuda a prevenir.

Como builds acontecem constantemente e eficiência de build, tamanho da imagem e evitar vazamento de segredos são importantes, e como entender o contexto de build e usar `.dockerignore` melhora diretamente todos os três, entender o contexto de build e `.dockerignore` é conhecimento Docker valioso e praticamente relevante — uma prática simples mas importante para builds rápidos, enxutos e seguros que é fácil de ignorar mas significativamente impactante, especialmente para prevenir a inclusão acidental de segredos em imagens.