Guía de Docker · 2 min de lectura

Docker detrás de un proxy: demonio, construcción y composición

Docker necesita un proxy en tres lugares separados: el daemon que descarga imágenes, la construcción que ejecuta comandos y los contenedores que ejecutas. Si configuras el incorrecto, las descargas seguirán fallando. Aquí está cada uno, correctamente definido.

Tres capas, tres configuraciones

La razón por la que "configuré http_proxy pero docker pull aún falla" es tan común es que Docker tiene tres contextos de red independientes, y las variables de entorno de tu shell solo tocan uno de ellos. Primero, el daemon (dockerd) es el que realmente descarga imágenes de un registro — se ejecuta como un servicio del sistema y lee su proxy de su propia configuración, no de tu shell. En segundo lugar, el build ejecuta cada paso RUN dentro de un contenedor temporal que necesita su propio proxy para acceder a la red. Por último, el contenedor en ejecución necesita un proxy si la aplicación dentro de él realiza llamadas salientes.

Los tres utilizan el s4m punto final HTTP en el puerto 3128 con autenticación USER:PASS. La forma moderna de configurar el daemon y el build es el archivo de configuración del cliente de Docker ~/.docker/config.json, que inyecta configuraciones de proxy en los builds y en docker run automáticamente; el daemon en sí se configura a través de un drop-in de systemd o configuraciones de Docker Desktop. Consulta la página de proxy; esto se empareja naturalmente con las guías de npm/yarn y pip/conda para lo que se ejecuta dentro de tus imágenes.

Configura las tres capas

Daemon a través de systemd drop-in, construye y ejecuta a través de docker config.json, y un fallback de compose. Reemplaza USER:PASS.

bash
# --- 1) DAEMON (image pulls): systemd drop-in on Linux ---
sudo mkdir -p /etc/systemd/system/docker.service.d
sudo tee /etc/systemd/system/docker.service.d/http-proxy.conf >/dev/null <<'CONF'
[Service]
Environment="HTTP_PROXY=http://USER:PASS@proxy.s4m.online:3128"
Environment="HTTPS_PROXY=http://USER:PASS@proxy.s4m.online:3128"
Environment="NO_PROXY=localhost,127.0.0.1,.internal"
CONF
sudo systemctl daemon-reload && sudo systemctl restart docker

# --- 2) BUILDS + RUNS: ~/.docker/config.json (injected automatically) ---
cat > ~/.docker/config.json <<'JSON'
{
  "proxies": {
    "default": {
      "httpProxy":  "http://USER:PASS@proxy.s4m.online:3128",
      "httpsProxy": "http://USER:PASS@proxy.s4m.online:3128",
      "noProxy":    "localhost,127.0.0.1,.internal"
    }
  }
}
JSON

# --- 3) docker-compose fallback (per-service build args) ---
# services:
#   app:
#     build:
#       context: .
#       args:
#         HTTP_PROXY:  http://USER:PASS@proxy.s4m.online:3128
#         HTTPS_PROXY: http://USER:PASS@proxy.s4m.online:3128

Obtener docker pull y build funcionando

Arregla las capas en el orden en que suelen aparecer los fallos.

Arregla el daemon primero

Si docker pull falla, el daemon no puede alcanzar el registro. Agregue el drop-in de systemd con HTTP_PROXY/HTTPS_PROXY, luego daemon-reload y reinicie docker. En Docker Desktop, configure el proxy en Configuración en su lugar.

Configurar el cliente para compilaciones

Agrega el bloque de proxies a ~/.docker/config.json para que docker build y docker run inyecten el proxy en cada paso y contenedor automáticamente — no se requieren ediciones en el Dockerfile.

Agregar NO_PROXY en todas partes

Incluya localhost, 127.0.0.1 y cualquier registro interno o host de servicio en NO_PROXY en cada capa, para que el tráfico interno no se enrute innecesariamente a través del proxy.

Verifica cada capa

Prueba con docker pull hello-world (demonio), una construcción que ejecuta apt-get o pip (construcción), y un contenedor que hace curl a un endpoint de eco de IP (tiempo de ejecución).

Alcance, secretos y honestidad

Dos advertencias. Primero, mantén las credenciales del proxy fuera de las capas de la imagen. Configurar variables de entorno del proxy dentro de un Dockerfile con ENV las incorpora en la imagen; usa argumentos de construcción o la inyección del cliente config.json en su lugar, para que las credenciales permanezcan en el host de construcción. Segundo, sé preciso con NO_PROXY — una entrada faltante para un registro interno significa que Docker intenta acceder a él a través del proxy externo y falla de manera confusa.

El proxy HTTP de s4m es un punto final autenticado de centro de datos, con pago por uso medido — bien adaptado para constructores de CI y hosts de DevOps que deben obtener imágenes y paquetes desde detrás de una salida controlada. No es residencial, y es un proxy directo, no un espejo de registro o caché; para caché de tirón, ejecuta un espejo de registro junto a él. Cuando tu flota de construcción necesita una IP de salida permitida, añade una IP personal dedicada. Un 407 en cualquier lugar significa credenciales de proxy incorrectas — consulta la guía 407. Valida el punto final con las herramientas.

FAQ

Preguntas, respondidas

¿Por qué falla docker pull aunque configuré http_proxy en mi shell?

Porque las extracciones de imágenes son realizadas por el demonio, no por tu shell. Configura el proxy de dockerd a través de un drop-in de systemd (o configuraciones de Docker Desktop) con HTTP_PROXY/HTTPS_PROXY, luego recarga el demonio y reinicia docker.

¿Cómo hago proxy de docker build y docker run sin editar el Dockerfile?

Agrega un bloque de proxies a ~/.docker/config.json. El cliente de Docker inyecta httpProxy/httpsProxy en cada paso de construcción y contenedor automáticamente, por lo que no se necesitan cambios en el Dockerfile.

¿Cómo mantengo las credenciales del proxy fuera de mi imagen?

No los configures con ENV en el Dockerfile; eso los integra en las capas. Usa argumentos de construcción o la inyección de config.json del cliente para que las credenciales permanezcan en el host de construcción, no en la imagen enviada.

¿s4m proporciona un espejo de registro o caché?

No. s4m es un proxy de centro de datos hacia adelante para tráfico saliente, no un caché de registro de extracción. Para almacenar en caché imágenes, ejecuta un espejo de registro y enrútalo a través del proxy si es necesario.

Extraer y construir detrás de un proxy

Dirige el daemon de Docker, construcciones y contenedores a través del punto final HTTP autenticado en proxy.s4m.online:3128. IP dedicada de pago por uso, para listas de permitidos de CI.

Las personas encontraron esta página buscando

Frases de búsqueda reales que esta página responde — los enlaces abren la página que las cubre en profundidad.