Docker Buildx: Como criar imagens de contêineres multiplataforma

Casos de uso avançados

Até agora, mostrei a você comandos básicos do Buildx e casos de uso. Há muito mais que o Buildx pode fazer, sendo que alguns dos recursos são impossíveis de implementar com o construtor clássico.

Vamos explorar algumas técnicas avançadas para levar o seu fluxo de trabalho de conteinerização para o próximo nível.

Otimização de compilação em vários estágios

As compilações em vários estágios são um dos recursos mais avançados do Docker para criar imagens eficientes, e o Buildx as torna ainda melhores.

Para demonstrar, vamos criar um aplicativo Python otimizado com vários estágios:

# Dockerfile.optimized
FROM python:3.13-slim AS base
WORKDIR /app
COPY requirements.txt .

FROM base AS builder
RUN pip install --no-cache-dir --target=/install -r requirements.txt

FROM base AS linter
COPY --from=builder /install /usr/local/lib/python3.13/site-packages
COPY app.py .
RUN pip install pylint && pylint app.py || exit 0

FROM base AS tester
COPY --from=builder /install /usr/local/lib/python3.9/site-packages
COPY app.py .
RUN pip install pytest && python -m pytest app.py -v || exit 0

FROM python:3.13-alpine AS final
WORKDIR /app
COPY --from=builder /install /usr/local/lib/python3.13/site-packages
COPY app.py .
EXPOSE 5000
CMD ["python", "app.py"]

Com o Buildx, você pode criar isso com mais eficiência:

docker buildx build --file Dockerfile.optimized -t myapp:optimized --load .

Imagem 9 - Construções em vários estágios

Então, o que torna isso especial? O Buildx processa estágios independentes em paralelo. Enquanto o construtor legado executaria cada estágio sequencialmente, o Buildx identifica que os estágios linter e tester não dependem um do outro e os constrói simultaneamente.

Outro benefício adicional dessa otimização de compilação é a redução no tamanho do arquivo. Você pode verificar o tamanho da imagem executando o seguinte:

docker images myapp

Você verá algo parecido com isto:

Imagem 10 - Tamanhos de imagem do Docker

A imagem final baseada em alpinos é muito menor.

Integração do pipeline de CI/CD

Enquanto estiver trabalhando localmente, você ainda poderá definir as configurações do Buildx que espelham seu ambiente de CI/CD.

Para começar, crie um arquivo .dockerignore para manter as compilações limpas:

.git
__pycache__
*.pyc
*.pyo
*.pyd
.Python
env
venv
*.so
.coverage
htmlcov

Em seguida, crie um script de compilação que imite o que o pipeline de CI pode fazer:

#!/bin/bash
# build.sh - Local CI/CD simulation

echo "Starting CI/CD build process..."

# Setup builder with emulation support
echo "Setting up builder..."
docker buildx create --name cibuilder --use || true
docker buildx inspect --bootstrap

# Run linting
echo "Running lint stage..."
docker buildx build --file Dockerfile.optimized --target linter .

# Run tests
echo "Running test stage..."
docker buildx build --file Dockerfile.optimized --target tester .

# Build for multiple platforms
echo "Building multi-platform image..."
docker buildx build --file Dockerfile.optimized \
  --platform linux/amd64,linux/arm64 \
  --tag myapp:$(date +%Y%m%d) \
  --tag myapp:latest \
  --load \
  --progress=plain \
  .

echo "Build process complete!"

Em linguagem simples, esse script faz o seguinte:

• Cria um construtor dedicado para CI/CD.
• Executa o estágio de linting.
• Executa o estágio de teste.
• Cria a imagem final multiplataforma com tags com controle de versão.

Agora a parte divertida: torne o script executável e o execute:

chmod +x build.sh
./build.sh

Edição local

Um ponto problemático comum ao trabalhar com o Docker é que, toda vez que você altera o arquivo de origem, precisa reconstruir a imagem e executar o contêiner. Isso leva muito tempo.

Aqui está a boa notícia: para o desenvolvimento local com iterações mais rápidas, você pode criar uma versão de desenvolvimento:

# Dockerfile.dev
FROM python:3.13-slim
WORKDIR /app

RUN pip install flask psutil python-dotenv

# Install development tools
RUN pip install pytest pylint watchdog

# Mount app code at runtime instead of copying
CMD ["python", "app.py"]

Execute-o com uma montagem de volume para recarregar o código em tempo real:

docker buildx build -f Dockerfile.dev -t myapp:dev --load .
docker run -it --rm -p 5000:5000 -v $(pwd):/app myapp:dev

Agora você pode editar o arquivo app.py localmente, e as alterações serão refletidas imediatamente no contêiner em execução!

A seguir, vamos discutir o desempenho.

Considerações sobre o desempenho

Ninguém gosta de um fluxo de trabalho de desenvolvimento lento, e o poder da paralelização com o Docker Buildx pode ajudar.

Vamos explorar como otimizar suas compilações e aproveitar os recursos de desempenho do Buildx para criar imagens mais rapidamente.

Criar técnicas de paralelização

Uma das maiores vantagens do Buildx é sua capacidade de criar estágios em paralelo. O construtor tradicional do Docker executa cada etapa sequencialmente, mas o Buildx analisa seu Dockerfile e identifica quais etapas podem ser executadas ao mesmo tempo.

Para demonstrar, usarei dois arquivos: Dockerfile.standard e Dockerfile.parallel. Aqui estão os conteúdos de ambos:

Dockerfile.standard

FROM python:3.13-slim
WORKDIR /app

# System dependencies
RUN apt-get update && apt-get install -y --no-install-recommends \
    gcc \
    g++ \
    && rm -rf /var/lib/apt/lists/*

# Python dependencies
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Application code
COPY app.py .

# Linting
RUN pip install pylint && pylint app.py || true

EXPOSE 5000
CMD ["python", "app.py"]

Dockerfile.parallel

FROM python:3.13-slim AS python-base
WORKDIR /app

# Independent stage for installing system dependencies
FROM python-base AS system-deps
RUN apt-get update && apt-get install -y --no-install-recommends \
    gcc \
    g++ \
    && rm -rf /var/lib/apt/lists/*

# Independent stage for installing Python dependencies
FROM python-base AS python-deps
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Independent stage for static code analysis
FROM python-deps AS linting
COPY app.py .
RUN pip install pylint && pylint app.py || true

# Final stage that combines dependencies
FROM python-base AS final
# Copy from system deps stage
COPY --from=system-deps /usr/bin/gcc /usr/bin/gcc
# Copy from Python deps stage
COPY --from=python-deps /usr/local/lib/python3.13/site-packages /usr/local/lib/python3.13/site-packages
COPY app.py .
EXPOSE 5000
CMD ["python", "app.py"]

Vamos avaliar como essa estrutura paralela melhora os tempos de construção:

# Time the standard sequential build
time docker build -t myapp:standard -f Dockerfile.standard .

# Time the parallel-optimized build with Buildx
time docker buildx build --load -t myapp:parallel -f Dockerfile.parallel .

Para referência, a compilação padrão levou 18,48 segundos, enquanto a compilação paralela levou apenas 1,17 segundos!

Para obter um desempenho ainda melhor, você pode tentar usar os sinalizadores --cache-from e --cache-to para aproveitar o cache de disco local:

# First build - create cache
docker buildx build --load -t myapp:latest --cache-to type=local,dest=./buildcache .

# Subsequent builds - use cache
docker buildx build --load -t myapp:latest --cache-from type=local,src=./buildcache .

Você também pode limitar o tamanho do contexto com arquivos .dockerignore cuidadosos:

# Create a comprehensive .dockerignore
cat > .dockerignore << 'EOF'
.git
.github
.dockerignore
.pytest_cache
__pycache__
*.pyc
*.pyo
*.pyd
.Python
venv
env
node_modules
.coverage
htmlcov
.DS_Store
EOF

Resumindo, ao estruturar seus Dockerfiles com a paralelização em mente e aproveitar o cache avançado do Buildx, você passará menos tempo esperando por compilações e mais tempo desenvolvendo recursos.

Integração do ecossistema

O Docker Buildx não existe isoladamente. Ele foi criado para se integrar perfeitamente a outras ferramentas em seu ambiente de desenvolvimento.

Vamos explorar como o Buildx funciona com as ferramentas locais do desenvolvedor e torna o fluxo de trabalho do contêiner mais eficiente.

Criar clusters do Kubernetes

O Kubernetes oferece recursos avançados para executar operações distribuídas do Docker Buildx em um cluster. Ao integrar o Buildx com o Kubernetes, você pode obter compilações mais rápidas e resilientes que se adaptam às necessidades do seu projeto.

> Você é novo no Kubernetes? O Kubernetes vs Docker: Diferenças que todo desenvolvedor deve conhecer post é sua próxima parada.

Usar o Kubernetes para sua infraestrutura de compilação oferece algumas vantagens:

1. Dimensionamento automático: O Kubernetes pode aumentar ou diminuir a escala dos nós do construtor com base na demanda, alocando recursos de forma eficiente em todo o cluster. Você pode até mesmo configurar regras de dimensionamento automático com base na utilização da CPU.
2. Otimização de recursos: O agendamento do Kubernetes garante que suas compilações obtenham os recursos necessários sem sobrecarregar os nós individuais. Você pode definir limites de recursos e solicitações para garantir um desempenho consistente.
3. Alta disponibilidade: Ao distribuir as instâncias do BuildKit em vários nós, sua infraestrutura de compilação permanece disponível mesmo que os nós individuais falhem.
4. Ambientes consistentes: Todos os membros da equipe se conectam à mesma infraestrutura de compilação, eliminando problemas de "funciona no meu computador".
5. Execução paralela: Construções complexas com muitos estágios podem ser executadas em paralelo em vários nós, reduzindo significativamente os tempos de construção. Um projeto que pode levar 15 minutos para ser desenvolvido localmente pode ser concluído em 3 a 4 minutos quando distribuído.

Considere esta uma seção mais "teórica", pois aprofundar-se no Kubernetes é um tópico avançado por si só.

Para começar, crie um arquivo chamado buildkit-deployment.yaml com o seguinte conteúdo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: buildkit
  namespace: buildkit
spec:
  replicas: 3
  selector:
    matchLabels:
      app: buildkit
  template:
    metadata:
      labels:
        app: buildkit
    spec:
      containers:
      - name: buildkit
        image: moby/buildkit:latest
        args:
        - --addr
        - tcp://0.0.0.0:1234
        ports:
        - containerPort: 1234
        securityContext:
          privileged: true
---
apiVersion: v1
kind: Service
metadata:
  name: buildkit
  namespace: buildkit
spec:
  type: ClusterIP
  ports:
  - port: 1234
    targetPort: 1234
  selector:
    app: buildkit

A próxima etapa é aplicar esse arquivo ao seu cluster do Kubernetes:

kubectl create namespace buildkit
kubectl apply -f buildkit-deployment.yaml

Por fim, conecte-se a essa implementação a partir de seu computador local:

docker buildx create --name k8s-builder \
  --driver remote \
  --driver-opt endpoint=tcp://<cluster-ip>:1234 \
  --use

E é isso, você está pronto para começar!

Suporte ao plug-in do IDE

IDEs como o Visual Studio Code oferecem excelente integração com o Docker Buildx por meio de sua extensão Docker. Essa integração facilita o gerenciamento dos fluxos de trabalho do Buildx diretamente do seu ambiente de desenvolvimento.

Para começar a usar o Docker Buildx no VS Code, instale a extensão "Docker" do marketplace do VS Code.

Depois de instalado, você obterá vários recursos específicos do Buildx:

• Clique com o botão direito do mouse em qualquer Dockerfile para ver um menu de contexto com a opção "Build Image..." que oferece suporte ao Buildx.
• Acesso a argumentos de compilação, metas de plataforma e opções de saída por meio da interface do usuário.
• Capacidade de gerenciar e alternar entre diferentes instâncias do construtor.
• Integração com o terminal VS Code para executar comandos complexos do Buildx.

Imagem 11 - Extensão do Docker para VSCode

Aqui está um exemplo de personalização das tarefas do VS Code para usar o Buildx, criando um arquivo .vscode/tasks.json:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Docker: Buildx Build",
      "type": "shell",
      "command": "docker buildx build --load -t ${input:imageName} .",
      "group": {
        "kind": "build",
        "isDefault": true
      }
    },
    {
      "label": "Docker: Buildx Multi-Platform",
      "type": "shell",
      "command": "docker buildx build --platform linux/amd64,linux/arm64 -t ${input:imageName} ."
    }
  ],
  "inputs": [
    {
      "id": "imageName",
      "description": "Image name (with tag):",
      "default": "myapp:latest",
      "type": "promptString"
    }
  ]
}

Com essa configuração, você pode acessar rapidamente comandos comuns do Buildx no menu Tarefas do VS Code(Terminal > Executar tarefa). A extensão também fornece realce de sintaxe útil para Dockerfiles e preenchimento automático para comandos comuns do Docker, o que torna o fluxo de trabalho do Buildx mais produtivo.

Solução de problemas e depuração

Toda ferramenta de desenvolvimento às vezes (com muita frequência) precisará de solução de problemas, e o Docker Buildx não é exceção. Nesta seção, apresentarei alguns problemas comuns para que você mesmo possa diagnosticá-los rapidamente e voltar ao programa.

Problemas e resoluções comuns

Ao trabalhar com o Buildx, você pode encontrar alguns desafios comuns. Aqui estão os problemas mais frequentes e suas soluções:

• A criação do construtor falha. Se você encontrar erros ao criar um construtor com docker buildx create, verifique sua versão do Docker:

docker version

O Buildx requer o Docker 19.03 ou mais recente. Se você estiver usando uma versão mais antiga, atualize o Docker para acessar os recursos do Buildx.

Para erros do tipo "no such plugin", verifique se o Buildx está instalado corretamente executando:

docker buildx version

• Falhas de compilação em várias plataformas. Ao compilar para várias plataformas com erros como "erro de formato de execução" ou "nenhum manifesto correspondente", verifique se o QEMU está instalado:

docker buildx inspect --bootstrap

Se necessário, instale emuladores de plataforma:

docker run --privileged --rm tonistiigi/binfmt --install all

• Problemas relacionados ao cache. Se você tiver problemas com o cache, tente limpar o cache de compilação local:

# Remove specific builder's cache
docker buildx prune -b mybuilder

# Remove all build cache
docker buildx prune --all

> O que exatamente é o comando Docker prune? Aprenda com vários exemplos práticos.

• Problemas de conexão do daemon do BuildKit. Se você vir a mensagem "failed to solve" ou erros de conexão, reinicie o construtor:

docker buildx rm mybuilder
docker buildx create --name mybuilder --use
docker buildx inspect --bootstrap

• Problemas relacionados ao desempenho. Para compilações lentas, experimente a saída de depuração para identificar gargalos:

docker buildx build --progress=plain --no-cache .

Essa saída detalhada ajuda a identificar quais estágios de compilação estão levando mais tempo, permitindo que você otimize seu Dockerfile de acordo.

• Falhas no comando "Load". Se você encontrar a mensagem "error: docker exporter does not currently support exporting manifest lists" ao usar o site --load com compilações multiplataforma, lembre-se de que não há suporte para o carregamento simultâneo de várias plataformas no daemon do Docker. Instead:

# Build for your current platform and load it
docker buildx build --platform linux/amd64 --load -t myapp:latest .

• Práticas de depuração. Para problemas mais complexos, essas abordagens de depuração ajudarão você:

# Enable BuildKit debug logs
BUILDKIT_DEBUG=1 docker buildx build .

# Inspect the builder's internal state
docker buildx inspect

# Check system requirements
docker info

# For specific stage failures, build only up to that stage
docker buildx build --target problem-stage .

# Verify your Docker context
docker context ls

Ao trabalhar sistematicamente com essas etapas de solução de problemas, você pode resolver a maioria dos problemas do Buildx e manter um fluxo de trabalho eficiente de criação de contêineres.

Resumindo o guia Docker Buildx

Cobrimos muitas coisas neste artigo do Docker Buildx! Você já viu como essa poderosa ferramenta pode tornar as compilações de contêineres mais rápidas e flexíveis.

Lembre-se dos principais benefícios: Você pode criar imagens para várias plataformas com um único comando, acelerar suas criações com cache avançado e manter suas imagens seguras com o gerenciamento adequado de segredos. As melhorias de desempenho são reais, especialmente quando você estrutura seus Dockerfiles para aproveitar a criação paralela.

Eu o utilizo o tempo todo em meu Macbook com chip M, pois nem todas as imagens estão disponíveis para ARM.

Não importa se você é um desenvolvedor individual ou faz parte de uma grande equipe, o Buildx oferece ferramentas que se adaptam ao seu fluxo de trabalho. Você pode executar compilações localmente, distribuí-las entre contêineres ou até mesmo escalar para clusters do Kubernetes à medida que suas necessidades aumentam.

Para saber mais sobre o Docker e o Docker Buildx, recomendo que você se inscreva nos seguintes cursos da DataCamp:

• Conceitos de virtualização e de contêineres
• Introdução ao Docker
• Docker intermediário
• Containerização e virtualização com Docker e Kubernetes
• CI/CD para machine learning