Configuração de proxy no Docker

A configuração de proxy no Docker consiste em configurar contêineres individuais, serviços do docker-compose ou o próprio daemon do Docker para rotear o tráfego de rede de saída através de um servidor proxy intermediário, em tarefas como baixar imagens, fazer builds ou acessar recursos externos de dentro das aplicações.

Por que usar um proxy com o Docker?

Integrar um proxy a ambientes Docker atende a várias necessidades comuns:

• Controle de acesso à internet: Em redes corporativas ou restritas, o acesso direto à internet a partir de servidores de build ou contêineres pode ser proibido. O proxy funciona como um gateway controlado.
• Varredura e filtragem de segurança: Proxies podem interceptar e analisar o tráfego de saída dos contêineres em busca de conteúdo malicioso ou aplicar políticas de conteúdo.
• Cache: Proxies podem armazenar em cache recursos externos acessados com frequência (por exemplo, repositórios de gerenciadores de pacotes, imagens base), reduzindo o consumo de banda e acelerando builds/downloads.
• Anonimato/desbloqueio geográfico: Embora menos comum em ambientes corporativos, proxies podem mascarar o IP de origem ou contornar restrições geográficas.

Tipos de configuração de proxy

Existem dois contextos principais de uso de proxy no Docker:

1. Proxy do daemon do Docker: Configura o próprio daemon do Docker para usar um proxy em operações como baixar imagens base, acessar registries remotos ou durante o processo de build (para comandos como RUN apt-get update).
2. Proxy de contêiner/serviço: Configura contêineres individuais ou serviços dentro do docker-compose para usar um proxy no tráfego de saída da própria aplicação em tempo de execução.

Essas configurações são independentes e, muitas vezes, ambas são necessárias para uma configuração completa.

Configuração de proxy do daemon do Docker

Esse método garante que as operações do daemon do Docker, incluindo download de imagens e algumas etapas de build, passem pelo proxy especificado.

Para hosts Linux baseados em systemd

A maioria das distribuições Linux modernas usa systemd. Crie um diretório drop-in para o serviço do Docker:

sudo mkdir -p /etc/systemd/system/docker.service.d

Crie um arquivo de configuração (por exemplo, http-proxy.conf) dentro desse diretório:

sudo nano /etc/systemd/system/docker.service.d/http-proxy.conf

Adicione o conteúdo a seguir, substituindo YOUR_PROXY_HOST e YOUR_PROXY_PORT pelos dados do seu proxy:

[Service]
Environment="HTTP_PROXY=http://YOUR_PROXY_HOST:YOUR_PROXY_PORT"
Environment="HTTPS_PROXY=http://YOUR_PROXY_HOST:YOUR_PROXY_PORT"
Environment="NO_PROXY=localhost,127.0.0.1,::1,YOUR_DOCKER_NETWORK_CIDR,YOUR_INTERNAL_DOMAINS"

Observação:
* HTTP_PROXY e HTTPS_PROXY normalmente devem usar o esquema http://, mesmo para tráfego HTTPS, já que o servidor proxy cuida da negociação TLS.
* NO_PROXY é essencial. Ele impede que o tráfego para hosts ou redes especificados passe pelo proxy. Inclua localhost, 127.0.0.1, ::1 e quaisquer redes internas do Docker (por exemplo, 172.17.0.0/16 para a rede bridge padrão, ou CIDRs de redes personalizadas) para garantir que os contêineres consigam se comunicar entre si e com o host sem problemas. Inclua também qualquer nome de domínio interno que deva contornar o proxy.

Recarregue o systemd e reinicie o daemon do Docker para que as mudanças tenham efeito:

sudo systemctl daemon-reload
sudo systemctl restart docker

Verifique baixando uma imagem:

docker pull alpine

Se o proxy estiver configurado corretamente, essa operação de download passará pelo proxy.

Para a Docker CLI (configuração do lado do cliente)

Essa configuração afeta o cliente Docker ao interagir com registries. É menos comum para proxy em nível de daemon, mas útil para operações específicas via CLI.

Crie ou edite ~/.docker/config.json:

{
  "proxies": {
    "default": {
      "httpProxy": "http://YOUR_PROXY_HOST:YOUR_PROXY_PORT",
      "httpsProxy": "http://YOUR_PROXY_HOST:YOUR_PROXY_PORT",
      "noProxy": "localhost,127.0.0.1,::1,YOUR_DOCKER_NETWORK_CIDR,YOUR_INTERNAL_DOMAINS"
    }
  }
}

Essa configuração vale para o usuário que executa a Docker CLI.

Configuração de proxy de contêiner/serviço

Esse método configura contêineres específicos ou serviços do docker-compose para usar um proxy no tráfego de saída em tempo de execução. É diferente do proxy do daemon e costuma ser necessário para que aplicações rodando dentro dos contêineres acessem recursos externos através de um proxy.

Usando o Dockerfile

Você pode definir as variáveis de ambiente de proxy diretamente no seu Dockerfile. Isso embute as configurações de proxy na imagem.

FROM ubuntu:latest

# Define o proxy para operações em tempo de build (por exemplo, apt-get update)
ENV HTTP_PROXY="http://YOUR_PROXY_HOST:YOUR_PROXY_PORT" \
    HTTPS_PROXY="http://YOUR_PROXY_HOST:YOUR_PROXY_PORT" \
    NO_PROXY="localhost,127.0.0.1,::1,YOUR_DOCKER_NETWORK_CIDR,YOUR_INTERNAL_DOMAINS"

RUN apt-get update && apt-get install -y curl

# Essas variáveis ENV também estarão presentes em tempo de execução, a menos que sejam sobrescritas
CMD ["curl", "http://example.com"]

Pontos de atenção:
* Credenciais de proxy em Dockerfiles são um risco de segurança. Considere usar argumentos de build (ARG) ou variáveis de ambiente em tempo de execução (-e ou environment no docker-compose.yml).
* Se o proxy só for necessário durante o build, remova as variáveis ao final do estágio de build em um build multiestágio ou use RUN --mount=type=secret,id=proxy,target=/run/secrets/proxy-creds para um tratamento mais seguro.

Usando docker run

Para contêineres individuais, passe as configurações de proxy com a flag -e:

docker run -e HTTP_PROXY="http://YOUR_PROXY_HOST:YOUR_PROXY_PORT" \
           -e HTTPS_PROXY="http://YOUR_PROXY_HOST:YOUR_PROXY_PORT" \
           -e NO_PROXY="localhost,127.0.0.1,::1,172.17.0.0/16,my-app-service" \
           my-image:latest curl http://example.com

Usando docker-compose.yml

Para aplicações com vários serviços, o docker-compose é o padrão. Defina as variáveis de ambiente de proxy na seção environment de cada serviço que precisa de acesso via proxy:

version: '3.8'
services:
  webapp:
    image: my-webapp:latest
    environment:
      - HTTP_PROXY=http://YOUR_PROXY_HOST:YOUR_PROXY_PORT
      - HTTPS_PROXY=http://YOUR_PROXY_HOST:YOUR_PROXY_PORT
      - NO_PROXY=localhost,127.0.0.1,::1,your-db-service,your-cache-service,172.18.0.0/16 # Adicione nomes de serviços internos e CIDRs de rede
    # ... outras configurações do serviço

  database:
    image: postgres:13
    # Normalmente este serviço não precisa de configurações de proxy se só se comunica internamente ou não faz tráfego de saída
    # ... outras configurações do serviço

Observação sobre NO_PROXY no docker-compose:
* Inclua localhost, 127.0.0.1, ::1.
* Inclua os nomes dos outros serviços da mesma rede do docker-compose (por exemplo, your-db-service).
* Inclua a faixa CIDR da rede Docker criada pelo docker-compose (por exemplo, 172.18.0.0/16, se a sua rede do docker-compose estiver nessa faixa). Você pode inspecionar a rede com docker network inspect <network_name> para descobrir o CIDR.

Arquivo externo proxy.env

Para gerenciar melhor configurações de proxy sensíveis ou que mudam com frequência, você pode defini-las em um arquivo .env externo e referenciá-lo no docker-compose.yml:

proxy.env:

HTTP_PROXY=http://YOUR_PROXY_HOST:YOUR_PROXY_PORT
HTTPS_PROXY=http://YOUR_PROXY_HOST:YOUR_PROXY_PORT
NO_PROXY=localhost,127.0.0.1,::1,your-db-service,your-cache-service,172.18.0.0/16

docker-compose.yml:

version: '3.8'
services:
  webapp:
    image: my-webapp:latest
    env_file:
      - ./proxy.env
    # ... outras configurações do serviço

Essa abordagem é mais limpa e permite atualizações fáceis sem alterar diretamente o docker-compose.yml.

Configuração de proxy SOCKS

Embora os proxies HTTP/HTTPS sejam os mais comuns, alguns ambientes usam proxies SOCKS. O Docker não suporta nativamente variáveis de ambiente de proxy SOCKS (SOCKS_PROXY, ALL_PROXY) da mesma forma abrangente que HTTP/HTTPS.

• Nível de aplicação: A maioria das aplicações precisa de suporte explícito a SOCKS. Se a sua aplicação dentro do contêiner suportar SOCKS, você pode passar ALL_PROXY ou variáveis semelhantes.
• Proxychains-NG: Para aplicações que não suportam SOCKS nativamente, ferramentas como o proxychains-ng podem ser instaladas dentro do contêiner para forçar o tráfego através de um proxy SOCKS. Isso adiciona complexidade e sobrecarga.

Em implantações Docker típicas, o proxy HTTP/HTTPS é preferido por ter suporte mais amplo.

Comparação dos métodos de configuração de proxy

Solução de problemas comuns de proxy

• Verifique as variáveis de ambiente: Dentro de um contêiner em execução, use docker exec -it <container_id> env para conferir se HTTP_PROXY, HTTPS_PROXY e NO_PROXY estão definidos corretamente.
• Teste a conectividade a partir do contêiner:
  bash docker exec -it <container_id> curl -v --proxy <YOUR_PROXY_HOST:YOUR_PROXY_PORT> http://example.com
  Isso força explicitamente o curl a usar o proxy, ignorando as variáveis de ambiente do contêiner, para um teste direto.
• Verifique os logs do servidor proxy: Inspecione os logs de acesso do seu servidor proxy para ver se o tráfego do host Docker ou dos contêineres está chegando e sendo processado.
• Conectividade de rede: Garanta que o host Docker consiga alcançar o servidor proxy na porta especificada. Use curl ou telnet a partir do host Docker.
• Regras de firewall: Verifique se nenhum firewall (do host, da rede ou do servidor proxy) está bloqueando o tráfego entre o host/contêineres Docker e o servidor proxy.
• Resolução DNS: Garanta que a resolução DNS funcione corretamente dentro dos contêineres, especialmente para o próprio host do proxy e para os domínios de destino.
• Configuração de NO_PROXY: Configurações incorretas ou incompletas de NO_PROXY costumam causar falhas de comunicação interna. Certifique-se de listar todas as redes internas, redes bridge do Docker e nomes de serviços.