Guide Docker · 2 min de lecture

Docker derrière un proxy : démon, construction et composition

Docker a besoin d'un proxy à trois endroits différents : le démon qui récupère les images, la construction qui exécute des commandes et les conteneurs que vous exécutez. Si vous en définissez un incorrect, les récupérations échoueront toujours. Voici chacun, correctement défini.

Commencez

Trois couches, trois configurations

La raison pour laquelle "j'ai défini http_proxy mais docker pull échoue toujours" est si courante, c'est que Docker a trois contextes réseau indépendants, et les variables d'environnement de votre shell n'en touchent qu'un seul. Tout d'abord, le daemon (dockerd) est celui qui tire réellement les images d'un registre — il fonctionne en tant que service système et lit son proxy à partir de sa propre configuration, pas de votre shell. Deuxièmement, le build exécute chaque étape RUN à l'intérieur d'un conteneur temporaire qui a besoin de son propre proxy pour accéder au réseau. Troisièmement, le conteneur en cours d'exécution a besoin d'un proxy si l'application à l'intérieur effectue des appels sortants.

Les trois utilisent le s4m point de terminaison HTTP sur le port 3128 avec une authentification USER:PASS. La manière moderne de configurer le daemon et le build est le fichier de configuration du client Docker ~/.docker/config.json, qui injecte les paramètres de proxy dans les builds et docker run automatiquement ; le daemon lui-même est configuré via un drop-in systemd ou les paramètres de Docker Desktop. Consultez la page proxy ; cela s'associe naturellement avec les guides npm/yarn et pip/conda pour ce qui s'exécute à l'intérieur de vos images.

Configurez les trois couches

Démon via systemd drop-in, construit et exécuté via docker config.json, et un fallback compose. Remplacez 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

Obtenez docker pull et build fonctionnels

Fixez les couches dans l'ordre dans lequel les échecs apparaissent généralement.

Réparez d'abord le démon

Si docker pull échoue, le démon ne peut pas atteindre le registre. Ajoutez le drop-in systemd avec HTTP_PROXY/HTTPS_PROXY, puis daemon-reload et redémarrez docker. Sur Docker Desktop, définissez le proxy dans les paramètres à la place.

Configurez le client pour les builds

Ajoutez le bloc de proxies à ~/.docker/config.json afin que docker build et docker run injectent le proxy dans chaque étape et conteneur automatiquement — aucune modification du Dockerfile n'est requise.

Ajouter NO_PROXY partout

Inclure localhost, 127.0.0.1 et tout hôte de registre ou de service interne dans NO_PROXY à chaque niveau, afin que le trafic interne ne soit pas inutilement acheminé par le proxy.

Vérifiez chaque couche

Testez avec docker pull hello-world (daemon), une build qui exécute apt-get ou pip (build), et un conteneur qui curl un point de terminaison d'écho IP (runtime).

Définition des objectifs, secrets et honnêteté

Deux avertissements. Premièrement, gardez les identifiants de proxy hors des couches d'image. Définir des variables d'environnement de proxy à l'intérieur d'un Dockerfile avec ENV les intègre dans l'image ; utilisez plutôt des arguments de construction ou l'injection du client config.json, afin que les identifiants restent sur l'hôte de construction. Deuxièmement, soyez précis avec NO_PROXY — une entrée manquante pour un registre interne signifie que Docker essaie d'y accéder via le proxy externe et échoue de manière déroutante.

Le proxy HTTP de s4m est un point de terminaison de centre de données authentifié, facturé à l'utilisation — bien adapté aux constructeurs CI et aux hôtes DevOps qui doivent récupérer des images et des paquets derrière une sortie contrôlée. Ce n'est pas résidentiel, et c'est un proxy direct, pas un miroir de registre ou un cache ; pour la mise en cache par tirage, exécutez un miroir de registre à côté. Lorsque votre flotte de construction a besoin d'une adresse IP de sortie autorisée, ajoutez une adresse IP personnelle dédiée. Un 407 n'importe où signifie de mauvais identifiants de proxy — consultez le guide 407. Validez le point de terminaison avec les outils.

FAQ

Questions, réponses

Pourquoi docker pull échoue-t-il même si j'ai défini http_proxy dans mon shell ?

Parce que les récupérations d'images sont effectuées par le démon, pas par votre shell. Configurez le proxy de dockerd via un drop-in systemd (ou les paramètres de Docker Desktop) avec HTTP_PROXY/HTTPS_PROXY, puis daemon-reload et redémarrez docker.

Comment faire un proxy pour docker build et docker run sans modifier le Dockerfile ?

Ajoutez un bloc de proxies à ~/.docker/config.json. Le client Docker injecte httpProxy/httpsProxy dans chaque étape de construction et conteneur automatiquement, donc aucun changement de Dockerfile n'est nécessaire.

Comment garder les identifiants de proxy hors de mon image ?

Ne les définissez pas avec ENV dans le Dockerfile — cela les intègre dans les couches. Utilisez des arguments de construction ou l'injection de config.json du client afin que les identifiants restent sur l'hôte de construction, pas dans l'image expédiée.

s4m fournit-il un miroir de registre ou un cache ?

Non. s4m est un proxy de centre de données en avant pour le trafic sortant, pas un cache de registre à tirage. Pour mettre en cache des images, exécutez un miroir de registre et faites-le passer par le proxy si nécessaire.

Continuez à lire

Tirer et construire derrière un proxy

Dirigez le démon Docker, les builds et les conteneurs via le point de terminaison HTTP authentifié sur proxy.s4m.online:3128. Paiement à l'utilisation, IP dédiée pour les listes blanches CI.

Voir les prix des proxies Voir les prix

Les gens ont trouvé cette page en recherchant

Docker derrière un proxy
comment utiliser des proxies avec Scrapy
Docker derrière un proxy tutoriel
Réglages Docker derrière un proxy
comment vérifier si un proxy est valide (avec un script prêt à l'emploi)
comment proxy socks5 fonctionne
comment wireguard fonctionne
est authentification de proxy sûr
adresse IP
combien de temps les proxies gratuits vivent-ils
authentification de proxy

Vraies phrases de recherche auxquelles cette page répond — les liens ouvrent la page qui les couvre en profondeur.