Configuración de Proxy Docker

La configuración de proxy de Docker implica configurar contenedores individuales, servicios de docker-compose o el propio demonio de Docker para enrutar el tráfico de red saliente a través de un servidor proxy intermediario para tareas como la descarga de imágenes, la construcción o el acceso a recursos externos desde dentro de las aplicaciones.

¿Por qué usar un proxy con Docker?

La integración de un proxy con entornos Docker aborda varios requisitos comunes:

• Control de Acceso a Internet: En entornos de red corporativos o restringidos, el acceso directo a Internet desde servidores de compilación o contenedores puede estar prohibido. Un proxy actúa como una puerta de enlace controlada.
• Escaneo y Filtrado de Seguridad: Los proxies pueden interceptar y escanear el tráfico saliente de los contenedores en busca de contenido malicioso o aplicar políticas de contenido.
• Almacenamiento en caché: Los proxies pueden almacenar en caché recursos externos a los que se accede con frecuencia (por ejemplo, repositorios de gestores de paquetes, imágenes base), lo que reduce el uso de ancho de banda y acelera las compilaciones/descargas.
• Anonimato/Desbloqueo geográfico: Aunque menos común en configuraciones empresariales, los proxies pueden enmascarar la IP de origen o eludir las restricciones geográficas.

Tipos de Configuraciones de Proxy

Existen dos contextos principales para el proxying en Docker:

1. Proxy del Demonio de Docker: Configura el propio demonio de Docker para usar un proxy para operaciones como la descarga de imágenes base, el acceso a registros remotos o durante el proceso de compilación (para comandos como RUN apt-get update).
2. Proxy de Contenedor/Servicio: Configura contenedores o servicios individuales dentro de docker-compose para usar un proxy para su propio tráfico de aplicación saliente en tiempo de ejecución.

Estas configuraciones son independientes y a menudo ambas son necesarias para una configuración completa.

Configuración del Proxy del Demonio de Docker

Este método garantiza que las operaciones del demonio de Docker, incluidas las descargas de imágenes y algunos pasos de compilación, pasen a través del proxy especificado.

Para Hosts Linux basados en systemd

La mayoría de las distribuciones modernas de Linux usan systemd. Cree un directorio de configuración adicional para el servicio Docker:

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

Cree un archivo de configuración (por ejemplo, http-proxy.conf) dentro de este directorio:

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

Agregue el siguiente contenido, reemplazando YOUR_PROXY_HOST y YOUR_PROXY_PORT con los detalles de su 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"

Nota:
* HTTP_PROXY y HTTPS_PROXY deben usar típicamente el esquema http://, incluso para el tráfico HTTPS, ya que el servidor proxy maneja la negociación TLS.
* NO_PROXY es crucial. Evita que el tráfico a hosts o redes específicos pase por el proxy. Incluya localhost, 127.0.0.0.1, ::1 y cualquier red interna de Docker (por ejemplo, 172.17.0.0/16 para la red puente predeterminada, o CIDRs de red personalizados) para garantizar que los contenedores puedan comunicarse entre sí y con el host sin problemas. Además, agregue cualquier nombre de dominio interno que deba omitir el proxy.

Recargue systemd y reinicie el demonio de Docker para que los cambios surtan efecto:

sudo systemctl daemon-reload
sudo systemctl restart docker

Verifique descargando una imagen:

docker pull alpine

Si el proxy está configurado correctamente, esta operación de descarga se realizará a través del proxy.

Para Docker CLI (Configuración del lado del cliente)

Esta configuración afecta al cliente de Docker al interactuar con los registros. Es menos común para el proxying a nivel de demonio, pero útil para operaciones específicas de la CLI.

Cree o 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"
    }
  }
}

Esta configuración se aplica al usuario que ejecuta la CLI de Docker.

Configuración del Proxy de Contenedor/Servicio

Este método configura contenedores específicos o servicios de docker-compose para usar un proxy para su tráfico saliente en tiempo de ejecución. Esto es distinto del proxy del demonio y a menudo es necesario para que las aplicaciones que se ejecutan dentro de los contenedores accedan a recursos externos a través de un proxy.

Usando Dockerfile

Puede establecer variables de entorno del proxy directamente en su Dockerfile. Esto integra la configuración del proxy en la imagen.

FROM ubuntu:latest

# Set proxy for build time operations (e.g., 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

# These ENV variables will also be present at runtime unless overridden
CMD ["curl", "http://example.com"]

Consideraciones:
* Las credenciales del proxy en los Dockerfiles son un riesgo de seguridad. Considere usar argumentos de construcción (ARG) o variables de entorno en tiempo de ejecución (-e o environment en docker-compose.yml) en su lugar.
* Si el proxy solo se necesita durante la construcción, desestablezca las variables al final de la etapa de construcción en una construcción multi-etapa o use RUN --mount=type=secret,id=proxy,target=/run/secrets/proxy-creds para un manejo más seguro.

Usando docker run

Para contenedores individuales, pase la configuración del proxy usando la bandera -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 aplicaciones multiservicio, docker-compose es el estándar. Defina las variables de entorno del proxy dentro de la sección environment de cada servicio que requiera acceso al 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 # Add internal service names and network CIDRs
    # ... other service configurations

  database:
    image: postgres:13
    # This service typically does not need proxy settings if it only communicates internally or is not outbound
    # ... other service configurations

Nota sobre NO_PROXY en docker-compose:
* Incluya localhost, 127.0.0.1, ::1.
* Incluya los nombres de otros servicios dentro de la misma red de docker-compose (por ejemplo, your-db-service).
* Incluya el rango CIDR de la red Docker creada por docker-compose (por ejemplo, 172.18.0.0/16 si su red de docker-compose está en ese rango). Puede inspeccionar la red con docker network inspect <network_name> para encontrar su CIDR.

Archivo .env externo para proxy

Para una mejor gestión de la configuración del proxy sensible o que cambia con frecuencia, puede definirlas en un archivo .env externo y referenciarlo en 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
    # ... other service configurations

Este enfoque es más limpio y permite actualizaciones fáciles sin modificar directamente el docker-compose.yml.

Configuración de Proxy SOCKS

Aunque los proxies HTTP/HTTPS son los más comunes, algunos entornos usan proxies SOCKS. Docker no soporta de forma nativa las variables de entorno de proxy SOCKS (SOCKS_PROXY, ALL_PROXY) de la misma manera ubicua que HTTP/HTTPS.

• A nivel de aplicación: La mayoría de las aplicaciones necesitan soporte SOCKS explícito. Si su aplicación dentro del contenedor soporta SOCKS, puede pasar ALL_PROXY o variables similares.
• Proxychains-NG: Para aplicaciones que no soportan SOCKS de forma nativa, herramientas como proxychains-ng pueden instalarse dentro del contenedor para forzar el tráfico a través de un proxy SOCKS. Esto añade complejidad y sobrecarga.

Para implementaciones típicas de Docker, se prefiere el proxying HTTP/HTTPS debido a su mayor soporte.

Comparación de Métodos de Configuración de Proxy

Solución de Problemas Comunes de Proxy

• Verificar Variables de Entorno: Dentro de un contenedor en ejecución, use docker exec -it <container_id> env para verificar si HTTP_PROXY, HTTPS_PROXY y NO_PROXY están configuradas correctamente.
• Probar Conectividad desde el Contenedor:
  bash docker exec -it <container_id> curl -v --proxy <YOUR_PROXY_HOST:YOUR_PROXY_PORT> http://example.com
  Esto fuerza explícitamente a curl a usar el proxy, ignorando las variables de entorno del contenedor, para una prueba directa.
• Verificar Registros del Servidor Proxy: Inspeccione los registros de acceso de su servidor proxy para ver si el tráfico del host Docker o de los contenedores lo está alcanzando y siendo procesado.
• Conectividad de Red: Asegúrese de que el host Docker pueda alcanzar el servidor proxy en el puerto especificado. Use curl o telnet desde el host Docker.
• Reglas de Firewall: Verifique que ningún firewall (del host, de la red o del servidor proxy) esté bloqueando el tráfico entre el host/contenedores Docker y el servidor proxy.
• Resolución DNS: Asegúrese de que la resolución DNS funcione correctamente dentro de los contenedores, especialmente para el propio host proxy y los dominios de destino.
• Configuración de NO_PROXY: Las configuraciones de NO_PROXY incorrectas o incompletas a menudo conducen a fallos de comunicación interna. Asegúrese de que todas las redes internas, las redes puente de Docker y los nombres de servicio estén listados.