Proxy Docker : Guide complet pour utiliser les conteneurs derrière les pare-feu d'entreprise

La plupart des réseaux d'entreprise utilisent des serveurs proxy pour surveiller et filtrer le trafic Internet. Cela crée des obstacles lorsque Docker tente d'extraire des images des registres. Vous rencontrerez des délais d'expiration de connexion, des erreurs d'authentification et des échecs de compilation qui fonctionnent pourtant sur votre réseau domestique. Ces problèmes liés aux proxys peuvent perturber le travail des équipes de développement qui ne peuvent pas accéder aux images de base dont elles ont besoin.

La configuration du proxy Docker résout ces problèmes de connectivité tout en améliorant les performances grâce à la mise en cache et en répondant aux exigences de sécurité de l'entreprise. Une fois configurés, vos conteneurs extrairont les images indépendamment des restrictions réseau.

Dans ce tutoriel, je vais vous guider à travers la configuration des paramètres du proxy du démon Docker, la configuration des variables d'environnement du conteneur et la gestion de la configuration du proxy dans Docker Compose.

Vous débutez avec Docker et vous vous sentez dépassé par tous les concepts liés au réseau ? Commencez par les principes fondamentaux de Docker et renforcez votre confiance étape par étape.

Comprendre l'architecture du proxy Docker

Différentes parties de l'écosystème Docker nécessitent une configuration de proxy à différents niveaux.

Les proxys agissent comme intermédiaires entre vos composants Docker et les réseaux externes. Lorsque Docker doit extraire des images, que les conteneurs ont besoin d'un accès à Internet ou que les builds nécessitent des ressources externes, les serveurs proxy contrôlent et surveillent ces connexions. Ils se trouvent entre vos applications conteneurisées et le monde extérieur, filtrant les demandes et les réponses.

Les organisations utilisent des proxys avec Docker pour améliorer les performances, la sécurité et la conformité.

Les performances proviennent de la mise en cache des ressources fréquemment utilisées, telles que les images de base, ce qui réduit les temps de téléchargement pour l'ensemble de votre équipe. Les avantages en matière de sécurité comprennent le filtrage du trafic, la recherche de logiciels malveillants et le blocage de l'accès aux sites non autorisés. Les exigences de conformité stipulent que tout le trafic réseau doit transiter par des canaux surveillés, dotés de contrôles d'accès appropriés et de pistes d'audit.

La configuration du proxy Docker s'effectue à quatre niveaux :

• Proxy client : affecte les commandes CLI Docker telles que docker pull docker push

• Proxy démon : contrôle la manière dont le démon Docker accède aux registres externes.

• Proxy d'exécution de conteneur : définit les variables proxy pour les applications à l'intérieur des conteneurs.

• Proxy de compilation : gère les paramètres de proxy pendant les opérations d'docker build lorsque les fichiers Dockerfile ont besoin d'accéder à Internet.

Chaque couche a une fonction spécifique et nécessite sa propre approche de configuration.

Pour comprendre le fonctionnement du réseau Docker, il est nécessaire de saisir comment les conteneurs communiquent entre eux. 

Configurer Docker pour utiliser un proxy

Pour que Docker fonctionne avec le proxy de votre entreprise, vous devez configurer à la fois le démon Docker et le client.

Pourquoi ? Parce qu'ils gèrent différents types de requêtes réseau. 

Le démon gère les extractions et les transferts d'images, ainsi que l'authentification du registre, tandis que le client gère les opérations CLI et les appels API. Si l'une ou l'autre de ces configurations est manquante, des lacunes peuvent apparaître et entraîner des échecs des opérations Docker avec des erreurs de connexion.

Comment configurer le démon Docker

Le démon Docker lit les paramètres de proxy à partir de /etc/docker/daemon.json. Veuillez créer ce fichier s'il n'existe pas :

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.company.com:8080",
      "httpsProxy": "http://proxy.company.com:8080",
      "noProxy": "localhost,127.0.0.1,.company.com"
    }
  }
}

Le champ « noProxy » répertorie les adresses qui doivent contourner le proxy. Veuillez inclure ici vos domaines de registre interne et vos adresses localhost.

Configuration des remplacements de services systemd

Sur les systèmes Linux basés sur systemd, il est également nécessaire de configurer le service Docker lui-même pour qu'il utilise le proxy. Veuillez créer le répertoire de remplacement et le fichier de configuration :

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

Ensuite, veuillez ajouter ces variables d'environnement au fichier http-proxy.conf:

[Service]
Environment="HTTP_PROXY=http://proxy.company.com:8080"
Environment="HTTPS_PROXY=http://proxy.company.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,.company.com"

Cela garantit que le processus du démon Docker lui-même peut accéder aux services externes via votre proxy.

Docker ne prendra pas en charge les modifications du proxy tant que vous n'aurez pas redémarré le démon. Veuillez exécuter ces commandes pour recharger systemd et redémarrer Docker :

sudo systemctl daemon-reload
sudo systemctl restart docker

La commande daemon reload indique à systemd de lire la nouvelle configuration du service, tandis que la commande Docker restart applique les modifications apportées à l'daemon.json.

Considérations spécifiques à la plateforme

Docker Desktop gère la configuration du proxy différemment des installations sur serveur. Sous Windows et macOS, veuillez utiliser l'interface graphique Docker Desktop pour configurer les paramètres de proxy dans la section Ressources - Proxies. Ces paramètres configurent automatiquement le démon et le client.

Les hôtes Linux utilisant Docker Engine nécessitent la configuration manuelle décrite ci-dessus. Certaines distributions packagent Docker différemment, veuillez donc vérifier si votre système utilise directement dockerd ou via un gestionnaire de services différent.

Vérification de votre configuration

Vérifiez que Docker peut accéder aux registres externes à l'aide d'une simple commande pull :

docker pull hello-world

Vous pouvez également vérifier la configuration effective du démon :

docker system info | grep -i proxy

Cela indique si Docker a détecté et appliqué vos paramètres de proxy.

Si les extractions échouent toujours, veuillez vérifier les journaux de votre serveur proxy pour confirmer que Docker achemine correctement les requêtes.

Des problèmes de réseau vous bloquent ? Exposez correctement les ports Docker afin d'éviter tout problème de connectivité.

Configuration des variables d'environnement proxy

Les commandes CLI Docker nécessitent leur propre configuration de proxy, distincte des paramètres du démon. Les variables d'environnement vous permettent de contrôler de manière flexible la manière dont les clients Docker se connectent via les proxys d'entreprise.

Les proxys client contrôlent les opérations de l'interface CLI Docker telles que « docker pull », « docker push » et « docker login ». Lorsque vous exécutez ces commandes, le client Docker envoie des requêtes HTTP aux registres et doit savoir quel serveur proxy utiliser. Sans paramètres de proxy client, ces opérations échouent même lorsque le démon est correctement configuré.

Méthode de configuration JSON

L'approche la plus propre consiste à utiliser le fichier de configuration de Docker disponible à l'adresse ~/.docker/config.json:

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.company.com:8080",
      "httpsProxy": "http://proxy.company.com:8080",
      "noProxy": "localhost,127.0.0.1,.company.com"
    }
  }
}

Cette méthode conserve les paramètres de proxy dans la configuration de Docker et n'affecte pas les autres applications de votre système.

Variable d'environnement alternative

Vous pouvez également définir des variables d'environnement proxy standard que Docker détectera automatiquement à l'aide des commandes suivantes :

export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
export NO_PROXY=localhost,127.0.0.1,.company.com

Ces variables fonctionnent pour toute application respectant les normes proxy, pas uniquement Docker.

Configuration globale ou par utilisateur

Pour une configuration à l'échelle du système, veuillez ajouter les variables d'environnement à /etc/environment ou créer un script dans /etc/profile.d/:

# /etc/profile.d/proxy.sh
export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
export NO_PROXY=localhost,127.0.0.1,.company.com

Pour une configuration par utilisateur, veuillez les ajouter à votre profil shell (~/.bashrc, ~/.zshrc) ou utiliser la méthode de configuration JSON. Les paramètres par utilisateur offrent aux développeurs la flexibilité nécessaire pour utiliser différents proxys ou les contourner entièrement à des fins de test.

Considérations relatives à la sécurité

Il est fortement déconseillé de coder en dur les noms d'utilisateur et les mots de passe dans les fichiers de configuration ou les variables d'environnement. 

Les informations d'identification proxy en texte clair présentent des risques pour la sécurité, en particulier dans les environnements partagés ou les systèmes de contrôle de version.

Veuillez plutôt utiliser les approches suivantes :

• Veuillez configurer votre serveur proxy pour l'authentification par adresse IP lorsque cela est possible.
• Veuillez utiliser des assistants d'authentification ou des systèmes de stockage sécurisés pour l'authentification.
• Configurez des comptes de service avec des autorisations minimales pour les opérations Docker.

Si vous devez inclure des informations d'identification, veuillez utiliser le format http://username:password@proxy.company.com:8080, mais conservez-les dans des fichiers protégés avec des autorisations restreintes.

Configuration du proxy lors de la compilation

Les builds Docker nécessitent que les paramètres de proxy soient explicitement transmis via les arguments de build :

docker build \
  --build-arg HTTP_PROXY=http://proxy.company.com:8080 \
  --build-arg HTTPS_PROXY=http://proxy.company.com:8080 \
  --build-arg NO_PROXY=localhost,127.0.0.1 \
  -t myapp .

Les arguments de compilation deviennent des variables d'environnement dans le contexte de compilation.

Cela permet aux instructions d'RUN de télécharger les paquets et les dépendances via votre proxy. Sans ces arguments, les compilations échouent lorsque les fichiers Dockerfile tentent d'installer des logiciels ou de récupérer des ressources sur Internet.

Les paramètres de proxy définis lors de la compilation ne sont pas conservés dans l'image finale, sauf si vous les définissez explicitement à l'aide des instructions ENV dans votre fichier Dockerfile.

Les variables d'environnement vous offrent la flexibilité nécessaire pour gérer les paramètres de proxy au niveau approprié pour votre flux de travail.

Trouvez-vous les arguments de construction confus ? Maîtrisez les arguments de compilation Docker à l'aide d'exemples concrets qui fonctionnent réellement.

Conteneur et injection de proxy au moment de la compilation

La configuration du client Docker ne constitue qu'une étape intermédiaire : vos conteneurs et vos builds nécessitent leurs propres paramètres de proxy. Dans cette section, je vais vous montrer comment injecter la configuration du proxy lors de l'exécution et de la compilation.

Variables d'environnement d'exécution

Les conteneurs n'héritent pas des paramètres proxy de votre hôte.

Vous devez transmettre explicitement les variables proxy lors du démarrage des conteneurs. Docker vous offre plusieurs méthodes pour ce faire, selon que vous souhaitiez configurer tous les conteneurs ou seulement certains d'entre eux.

La configuration JSON est l'approche la plus claire pour obtenir des paramètres de proxy cohérents, comme indiqué précédemment. Pour résumer, veuillez ajouter ceci à votre fichier ~/.docker/config.json:

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.company.com:8080",
      "httpsProxy": "http://proxy.company.com:8080",
      "noProxy": "localhost,127.0.0.1,.company.com"
    }
  }
}

Docker injecte automatiquement ces variables dans chaque conteneur que vous démarrez. Aucun indicateur supplémentaire n'est nécessaire.

Les indicateurs CLI vous offrent davantage de contrôle sur chaque conteneur :

docker run \
  --env HTTP_PROXY=http://proxy.company.com:8080 \
  --env HTTPS_PROXY=http://proxy.company.com:8080 \
  --env NO_PROXY=localhost,127.0.0.1 \
  nginx

Vous pouvez également transmettre un fichier d'environnement complet :

# proxy.env
HTTP_PROXY=http://proxy.company.com:8080
HTTPS_PROXY=http://proxy.company.com:8080
NO_PROXY=localhost,127.0.0.1

docker run --env-file proxy.env nginx

Les conteneurs existants peuvent recevoir des variables proxy après leur démarrage à l'aide de l'docker exec:

docker exec -e HTTP_PROXY=http://proxy.company.com:8080 container_name curl google.com

Cette approche fonctionne pour les commandes ponctuelles, mais ne persiste pas après le redémarrage du conteneur.

Configuration du proxy lors de la compilation

La création d'images échoue dans les environnements proxy à moins que vous ne transmettiez explicitement les paramètres proxy.

Les arguments de compilation constituent la méthode standard pour injecter des variables proxy pendant les compilations :

docker build \
  --build-arg HTTP_PROXY=http://proxy.company.com:8080 \
  --build-arg HTTPS_PROXY=http://proxy.company.com:8080 \
  --build-arg NO_PROXY=localhost,127.0.0.1 \
  --tag myapp .

Votre fichier Dockerfile doit déclarer ces arguments pour pouvoir les utiliser :

ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY

# Use proxy for package installation
RUN apt-get update && apt-get install -y curl

# Don't persist proxy in final image

Les déclarations Dockerfile vous permettent de définir des valeurs proxy par défaut :

ARG HTTP_PROXY=http://proxy.company.com:8080
ARG HTTPS_PROXY=http://proxy.company.com:8080

ENV HTTP_PROXY=$HTTP_PROXY
ENV HTTPS_PROXY=$HTTPS_PROXY

RUN pip install requests

L'instruction « ENV » rend les variables proxy disponibles pour toutes les commandes « RUN » suivantes dans votre build.

Veuillez noter que les limitations de BuildKit peuvent entraîner des problèmes de proxy avec les versions récentes de Docker. BuildKit met en cache de manière intensive les contextes de compilation, ce qui peut parfois entraîner l'ignorance des modifications apportées au proxy.

Vous pouvez forcer BuildKit à reconnaître les mises à jour du proxy :

DOCKER_BUILDKIT=1 docker build \
  --no-cache \
  --build-arg HTTP_PROXY=$HTTP_PROXY \
  --tag myapp .

Ou bien, vous pouvez désactiver complètement BuildKit pour les compilations sensibles au proxy :

DOCKER_BUILDKIT=0 docker build --build-arg HTTP_PROXY=$HTTP_PROXY --tag myapp .

En ce qui concerne les compilations en plusieurs étapes, une configuration proxy cohérente est nécessaire à toutes les étapes :

ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY

# Build stage
FROM python:3.13 AS builder
ENV HTTP_PROXY=$HTTP_PROXY
ENV HTTPS_PROXY=$HTTPS_PROXY
ENV NO_PROXY=$NO_PROXY

COPY requirements.txt .
RUN pip install -r requirements.txt

# Runtime stage
FROM python:3.13-slim AS runtime
ENV HTTP_PROXY=$HTTP_PROXY
ENV HTTPS_PROXY=$HTTPS_PROXY
ENV NO_PROXY=$NO_PROXY

COPY --from=builder /usr/local/lib/python*/site-packages /usr/local/lib/python*/site-packages
RUN apt-get update && apt-get install -y curl

# Clear proxy variables for final image
ENV HTTP_PROXY=
ENV HTTPS_PROXY=
ENV NO_PROXY=

Chaque étape hérite des arguments de compilation, mais pas des variables d'environnement des étapes précédentes. Définissez explicitement les variables proxy à chaque étape où elles sont nécessaires.

En résumé : configurez une seule fois, injectez partout.

Vous ne comprenez pas bien la différence entre ENTRYPOINT et CMD dans vos conteneurs compatibles avec un proxy ? Obtenez le détail complet avec des exemples pratiques.

Configuration des gestionnaires de paquets pour utiliser un proxy dans des conteneurs

Les paramètres de proxy de Docker ne sont pas automatiquement répercutés vers les gestionnaires de paquets à l'intérieur de vos conteneurs. Il est nécessaire de configurer chaque gestionnaire de paquets séparément afin de télécharger les paquets via le proxy de votre entreprise.

Les gestionnaires de paquets tels que apt-get, yum et apk établissent des connexions HTTP directes avec les référentiels de paquets. Dans les environnements réseau restreints, ces connexions échouent à moins que le gestionnaire de paquets ne connaisse votre serveur proxy.

Les variables d'environnement standard ne sont pas suffisantes. La plupart des gestionnaires de paquets disposent de leurs propres fichiers de configuration qui remplacent les paramètres proxy du système.

Ubuntu/Debian : configuration d'apt-get

Veuillez créer un fichier de configuration proxy que apt-get lira lors de l'installation du paquet.

Veuillez ajouter ceci à votre fichier Dockerfile :

FROM python:3.13

# Configure apt proxy
RUN echo 'Acquire::http::Proxy "http://proxy.company.com:8080";' > /etc/apt/apt.conf.d/proxy.conf && \
    echo 'Acquire::https::Proxy "http://proxy.company.com:8080";' >> /etc/apt/apt.conf.d/proxy.conf

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

Le fichier /etc/apt/apt.conf.d/proxy.conf indique à apt-get de diriger tous les téléchargements de paquets via votre proxy. Le fichier persiste à travers les commandes d'RUN s dans votre build.

Vous pouvez également définir des exclusions de proxy pour les référentiels internes :

RUN echo 'Acquire::http::Proxy::internal.company.com "DIRECT";' >> /etc/apt/apt.conf.d/proxy.conf

Alpine Linux : configuration apk

Alpine utilise le gestionnaire de paquets apk, qui lit les paramètres proxy à partir de /etc/apk/repositories et des variables d'environnement.

FROM python:3.13-alpine

# Configure apk proxy
ENV HTTP_PROXY=http://proxy.company.com:8080
ENV HTTPS_PROXY=http://proxy.company.com:8080

RUN apk add --no-cache curl wget

apk d'Alpine respecte les variables d'environnement standard du proxy HTTP, vous n'avez donc pas besoin de fichiers de configuration séparés. Cependant, vous pouvez en créer un pour plus de contrôle :

RUN echo 'http_proxy=http://proxy.company.com:8080' > /etc/environment && \
    echo 'https_proxy=http://proxy.company.com:8080' >> /etc/environment

CentOS/RHEL : configuration de yum

Les systèmes CentOS et RHEL utilisent yum ou dnf, qui lisent les paramètres proxy à partir de /etc/yum.conf.

FROM centos:8

# Configure yum proxy
RUN echo 'proxy=http://proxy.company.com:8080' >> /etc/yum.conf

RUN yum update -y && yum install -y curl wget

Pour les versions plus récentes de CentOS utilisant l'dnf, veuillez utiliser la commande suivante :

FROM centos:stream9

# Configure dnf proxy
RUN echo 'proxy=http://proxy.company.com:8080' >> /etc/dnf/dnf.conf

RUN dnf update -y && dnf install -y curl wget

Vous pouvez également exclure des domaines spécifiques du routage proxy en ajoutant cette commande :

RUN echo 'proxy_exclude=internal.company.com,localhost' >> /etc/yum.conf

Vérification de la fonctionnalité du proxy

Tout d'abord, veuillez vérifier que votre gestionnaire de paquets peut accéder aux référentiels via le proxy.

Ajoutez des commandes de test à votre fichier Dockerfile :

FROM python:3.13

# Configure proxy
RUN echo 'Acquire::http::Proxy "http://proxy.company.com:8080";' > /etc/apt/apt.conf.d/proxy.conf

# Test package manager connectivity
RUN apt-get update && \
    apt-get install -y --dry-run curl && \
    echo "Package manager proxy test passed"

# Install actual packages
RUN apt-get install -y curl python3-pip

Le drapeau --dry-run teste la résolution des paquets sans rien installer. Si cela fonctionne, votre configuration de proxy est correcte.

Vous pouvez également effectuer un test avec une sortie détaillée pour dépanner les problèmes de connexion :

RUN apt-get -o Debug::Acquire::http=true update

Cela indique précisément les URL auxquelles apt-get tente d'accéder et si les connexions proxy aboutissent.

Pour les essais en montagne, veuillez utiliser les éléments suivants :

RUN apk update --verbose && \
    apk add --simulate curl && \
    echo "Alpine proxy test passed"

En résumé, configurez chaque gestionnaire de paquets individuellement et vos compilations fonctionneront derrière n'importe quel proxy.

Vous avez besoin de nettoyer les artefacts de compilation liés au proxy ? Les commandes Docker prune libèrent de l'espace et permettent de maintenir votre système propre.

Implémentations avancées de proxy

Les proxys HTTP de base constituent un bon point de départ, mais les environnements de production nécessitent un contrôle accru sur l'accès au registre et la mise en cache des images. Voici comment configurer des proxys de mise en cache et des miroirs de registre pour améliorer les performances et la fiabilité.

Registres de proxy de mise en cache

Le fait de récupérer les mêmes images de base à plusieurs reprises gaspille de la bande passante et ralentit les compilations.

Les proxys de mise en cache se trouvent entre vos clients Docker et les registres externes tels que Docker Hub. Ils stockent localement les images fréquemment consultées, de sorte que les téléchargements ultérieurs proviennent de votre réseau interne plutôt que d'Internet.

Harbor est le choix le plus populaire pour les environnements d'entreprise :

# docker-compose.yml for Harbor
version: '3.8'
services:
  harbor-core:
    image: goharbor/harbor-core:v2.8.0
    environment:
      - CORE_SECRET=your-secret-key
      - JOBSERVICE_SECRET=your-job-secret
    ports:
      - "80:8080"
    volumes:
      - ./harbor.yml:/etc/core/app.conf

Vous pouvez configurer Harbor en tant que cache proxy en modifiant le fichier harbor.yml:

# harbor.yml
hostname: harbor.company.com
http:
  port: 80

database:
  password: harbor-db-password

data_volume: /data

proxy_cache:
  - endpoint: https://registry-1.docker.io
    username: your-dockerhub-username
    password: your-dockerhub-token

Si vous avez besoin d'une alternative plus simple pour la mise en cache de base, veuillez utiliser Docker Registry Proxy. Voici comment procéder :

docker run -d \
  --name registry-proxy \
  -p 5000:5000 \
  -e REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io \
  -v registry-cache:/var/lib/registry \
  registry:2

Ensuite, redirigez vos clients Docker vers le proxy de mise en cache :

{
  "registry-mirrors": ["http://harbor.company.com"]
}

Voici tous les avantages dont vous bénéficiez avec les proxys de mise en cache :

• Téléchargement plus rapide des images après le premier téléchargement
• Réduction de l'utilisation de la bande passante Internet
• Améliorez la fiabilité des builds lorsque les registres externes rencontrent des problèmes.
• Contrôle d'accès centralisé et numérisation d'images

Miroirs du registre et BuildKit

Les miroirs de registre vous permettent de rediriger les extraits d'images vers des registres internes ou géographiquement plus proches.

La configuration à miroir unique achemine toutes les requêtes Docker Hub via un seul miroir :

{
  "registry-mirrors": ["https://mirror.company.com"],
  "insecure-registries": ["harbor.company.com:5000"]
}

Veuillez ajouter ceci à /etc/docker/daemon.json et redémarrer Docker. Toutes les commandes d'docker pull tenteront d'abord le miroir, puis se rabattront sur Docker Hub si le miroir n'est pas disponible.

Plusieurs miroirs assurent la redondance :

{
  "registry-mirrors": [
    "https://mirror1.company.com",
    "https://mirror2.company.com",
    "https://registry-1.docker.io"
  ]
}

Docker tentera les miroirs dans l'ordre jusqu'à ce que l'un d'entre eux fonctionne.

La configuration du miroir BuildKit nécessite une configuration distincte, car BuildKit contourne certains paramètres du démon :

# buildkitd.toml
debug = true

[registry."docker.io"]
  mirrors = ["mirror.company.com"]

[registry."mirror.company.com"]
  http = true
  insecure = true

Vous pouvez démarrer BuildKit avec la configuration personnalisée :

buildkitd --config=/etc/buildkit/buildkitd.toml

Ou utilisez la configuration de miroir en ligne de BuildKit :

docker buildx create \
  --name mybuilder \
  --config /etc/buildkit/buildkitd.toml \
  --use

Enfin, veuillez tester la configuration de votre miroir en créant une image à partir de Docker Hub :

FROM python:3.13-slim
RUN pip install requests

docker build --progress=plain .

Le drapeau d'--progress=plain e indique le registre auquel BuildKit accède réellement. Vous devriez voir les URL de vos miroirs dans le résultat de la compilation.

C'est tout !

Vous gérez des configurations de proxy multi-conteneurs complexes ? Docker Compose simplifie la mise en réseau et la découverte des services.

Renforcement de la sécurité

Les configurations de proxy ouvrent de nouvelles possibilités d'attaques qui nécessitent une attention particulière. Voici comment verrouiller l'accès au socket Docker et protéger les informations d'identification du proxy contre toute exposition.

Proxy de socket Docker

L'exposition directe du socket Docker représente un risque de sécurité important.

Le socket Docker (/var/run/docker.sock) vous accorde un accès root à l'ensemble de votre système hôte. Tout processus capable d'écrire sur ce socket peut créer des conteneurs avec accès au système de fichiers hôte, élever ses privilèges ou échapper complètement à l'isolation du conteneur.

Le montage direct sur prise est dangereux :

# DON'T DO THIS
docker run -v /var/run/docker.sock:/var/run/docker.sock myapp

Ce modèle apparaît dans les configurations Docker-in-Docker et les pipelines CI/CD, mais il représente un défi en matière de sécurité. Un conteneur compromis peut contrôler l'ensemble du démon Docker.

Les services de proxy socket créent une couche intermédiaire plus sécurisée. Ils filtrent les appels API Docker et limitent les actions que les conteneurs peuvent réellement effectuer.

Veuillez utiliser le proxy docker-socket de Tecnativa :

# docker-compose.yml
version: '3.8'
services:
  docker-proxy:
    image: tecnativa/docker-socket-proxy
    environment:
      - CONTAINERS=1
      - IMAGES=1
      - NETWORKS=1
      - VOLUMES=1
      - BUILD=0
      - COMMIT=0
      - CONFIGS=0
      - SECRETS=0
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - "2375:2375"

Le proxy expose uniquement des points de terminaison API Docker spécifiques. Définissez les variables d'environnement sur 1 pour les opérations autorisées et sur 0 pour les opérations bloquées.

Vos applications se connectent au proxy au lieu de la socket brute :

docker run --env DOCKER_HOST=tcp://docker-proxy:2375 myapp

Voici quelques stratégies supplémentaires pour renforcer la sécurité des sockets :

• Veuillez exécuter le proxy socket sur un segment de réseau distinct.
• Utiliser l'authentification TLS entre les clients et le proxy
• Surveillez les journaux proxy de la prise pour détecter les appels API suspects.
• Veuillez renouveler régulièrement les informations d'identification d'accès proxy.

Gestion des informations d'identification

Les informations d'identification proxy en texte clair apparaissent partout : journaux, listes de processus, vidages d'environnement.

N'intégrez jamais d'informations d'identification dans les URL proxy :

# SECURITY RISK - credentials visible in process list
export HTTP_PROXY=http://admin:password123@proxy.company.com:8080

Toute personne ayant accès à ps aux ou aux vidages de variables d'environnement peut voir votre mot de passe proxy. Cela inclut les journaux d'application, l'inspection des conteneurs et les outils de surveillance du système.

Veuillez utiliser des fichiers d'authentification à la place :

# Create credentials file with restricted permissions
echo "admin:password123" > ~/.proxy-creds
chmod 600 ~/.proxy-creds

# Configure proxy without embedded credentials
export HTTP_PROXY=http://proxy.company.com:8080

Veuillez configurer votre serveur proxy pour qu'il lise les informations d'identification à partir du fichier ou utilisez des systèmes d'authentification externes.

Les proxys TLS chiffrent tout le trafic proxy, y compris les échanges d'authentification :

# HTTPS proxy encrypts credentials in transit
export HTTPS_PROXY=https://proxy.company.com:8443

Configurez votre serveur proxy avec les certificats TLS appropriés, qu'ils proviennent d'une autorité de certification ou qu'il s'agisse de certificats auto-signés distribués aux machines clientes.

L'authentification par certificat élimine complètement les mots de passe :

# Client certificate authentication
export HTTPS_PROXY=https://proxy.company.com:8443
curl --cert client.crt --key client.key --cacert proxy-ca.crt https://example.com

Le proxy valide les certificats client au lieu des combinaisons nom d'utilisateur/mot de passe. Les certificats peuvent être révoqués individuellement s'ils sont compromis.

La gestion des secrets Kubernetes empêche les informations d'identification du proxy d'apparaître dans les images de conteneurs :

apiVersion: v1
kind: Secret
metadata:
  name: proxy-credentials
type: Opaque
data:
  username: YWRtaW4=  # base64 encoded
  password: cGFzc3dvcmQxMjM=  # base64 encoded

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: myapp
        env:
        - name: PROXY_USER
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: username
        - name: PROXY_PASS
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: password

Les secrets restent chiffrés au repos et sont injectés lors de l'exécution sans apparaître dans les couches d'image.

Verrouillez l'accès aux sockets et cryptez vos informations d'identification : vous vous en féliciterez plus tard.

Vous envisagez des alternatives à Docker pour la configuration de votre proxy ? Veuillez comparer Docker et Podman afin de sélectionner l'outil de conteneurisation le mieux adapté à vos besoins.

Résolution des problèmes courants

Les problèmes de proxy se manifestent par des délais d'attente, des échecs de connexion et des erreurs de compilation mystérieuses qui ne se produisent pas en dehors de votre réseau. Voici une approche systématique pour diagnostiquer et résoudre les problèmes de proxy Docker les plus courants.

Approche diagnostique structurée

Commencez par les bases et progressez progressivement.

Étape 1 : Vérifiez la connectivité du proxy depuis l'hôte.

Vérifiez si votre serveur proxy est accessible :

curl -x http://proxy.company.com:8080 https://registry-1.docker.io/v2/

Si cela ne fonctionne pas, cela signifie que votre configuration proxy ou votre routage réseau présente des problèmes. Veuillez contacter votre équipe réseau avant de procéder au dépannage de Docker.

Étape 2 : Veuillez vérifier les paramètres du proxy du démon Docker.

Vérifiez que le démon lit bien votre configuration proxy :

docker info | grep -i proxy

Vos URL de proxy devraient apparaître dans la liste. S'ils sont manquants, veuillez consulter /etc/docker/daemon.json et redémarrer le service Docker.

Étape 3 : Tester les opérations du client Docker

Veuillez essayer de télécharger une image simple :

docker pull hello-world

La réussite signifie que les paramètres de votre client proxy fonctionnent correctement. L'échec indique des problèmes de proxy au niveau du démon.

Étape 4 : Vérifier la connectivité au niveau du conteneur

Exécutez un conteneur et testez les connexions sortantes :

docker run --rm \
  -e HTTP_PROXY=http://proxy.company.com:8080 \
  -e HTTPS_PROXY=http://proxy.company.com:8080 \
  python:3.13-slim \
  python -c "import urllib.request; print(urllib.request.urlopen('https://pypi.org').getcode())"

Cela permet d'isoler le problème et de déterminer s'il provient des opérations Docker ou de la mise en réseau des conteneurs.

Problèmes courants et solutions

Problème : le délai d'expiration de la requête « docker pull » est dépassé.

Cette erreur s'affiche lorsque Docker ne parvient pas à accéder aux registres externes :

Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io: no such host

Commencez par tester la connectivité de base afin d'isoler l'origine du problème :

# Check if DNS resolution works through proxy
nslookup registry-1.docker.io

# Test direct registry access
curl -I https://registry-1.docker.io/v2/

# Verify daemon proxy configuration
sudo journalctl -u docker.service | grep -i proxy

Veuillez résoudre ce problème en vérifiant la configuration DNS et proxy.

• Ajouter des serveurs DNS à /etc/docker/daemon.json

• Configurer NO_PROXY pour les serveurs DNS internes

• Vérifiez si le proxy prend en charge la méthode HTTPS CONNECT.

Problème : L'installation du package échoue pendant la compilation.

Les gestionnaires de paquets à l'intérieur des conteneurs ne peuvent pas accéder aux référentiels et affichent des erreurs telles que celle-ci :

E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jammy/Release

Vérifiez la connectivité du gestionnaire de paquets directement dans un conteneur temporaire :

# Test package manager connectivity in a running container
docker run -it --rm python:3.13 bash
apt-get update -o Debug::Acquire::http=true

La sortie détaillée indique précisément où la connexion échoue.

Pour résoudre ce problème, veuillez configurer les gestionnaires de paquets afin qu'ils utilisent votre proxy :

• Configurer les paramètres du proxy du gestionnaire de paquets dans Dockerfile
• Transmettre les arguments de compilation proxy à la compilation Docker
• Vérifiez si le proxy bloque les domaines du référentiel de paquets.

Problème : BuildKit ignore les paramètres de proxy.

BuildKit utilise une gestion des proxys différente de celle du générateur hérité, ce qui entraîne des erreurs telles que celle-ci :

failed to solve: failed to fetch remote https://github.com/user/repo.git

Vérifiez si le problème est spécifique à BuildKit en vérifiant la configuration de votre générateur :

# Check BuildKit configuration
docker buildx inspect

# Build with legacy builder
DOCKER_BUILDKIT=0 docker build .

Si le générateur d'héritage fonctionne, vous rencontrez un problème de configuration du proxy BuildKit.

Veuillez résoudre les problèmes de proxy BuildKit à l'aide des approches suivantes :

• Configurez les paramètres de proxy spécifiques à BuildKit dans buildkitd.toml
• Utilisez --build-arg pour transmettre explicitement les variables proxy.
• Désactiver BuildKit pour les compilations sensibles au proxy

Problème : Le conteneur ne peut pas accéder aux services externes.

Votre application à l'intérieur du conteneur ne parvient pas à se connecter aux API externes :

requests.exceptions.ConnectionError: HTTPSConnectionPool(host='api.example.com', port=443)

Veuillez déboguer en testant la connectivité depuis l'intérieur du conteneur :

# Test from inside the container
docker exec container_name curl -v https://api.example.com

# Check container environment variables
docker exec container_name env | grep -i proxy

Ceci indique si les variables proxy sont présentes et si la tentative de connexion a réussi.

Veuillez résoudre les problèmes de connectivité du conteneur en vous assurant que la configuration du proxy est correcte :

• Transmettre les variables d'environnement proxy lors de l'exécution
• Configurer les paramètres de proxy spécifiques à l'application
• Ajouter la destination à la liste NO_PROXY

Analyse des journaux et tests de connectivité

Les journaux du démon Docker fournissent des informations détaillées sur les négociations et les échecs de proxy.

Sur les systèmes basés sur systemd, veuillez utiliser journalctl pour suivre les journaux du service Docker en temps réel :

# SystemD systems
sudo journalctl -u docker.service -f

Pour les systèmes utilisant des fichiers journaux traditionnels, veuillez vérifier directement le journal Docker :

# Direct log file
sudo tail -f /var/log/docker.log

Recherchez des modèles spécifiques liés aux proxys dans les journaux. Les erreurs de connexion refusée indiquent que le serveur proxy n'est pas accessible. Les échecs d'authentification s'affichent sous la forme de messages « 407 Proxy Authentication Required » (Authentification proxy requise). Les erreurs de délai d'expiration indiquent des problèmes de routage réseau ou une surcharge du serveur proxy.

Les tests au niveau du conteneur avec curl et wget vous fournissent des informations détaillées sur le comportement du proxy.

Vérifiez les connexions HTTP via votre proxy pour observer précisément ce qui se passe pendant la négociation :

# Test HTTP proxy
docker run --rm \
  -e HTTP_PROXY=http://proxy.company.com:8080 \
  python:3.13-slim \
  curl -v http://httpbin.org/ip

La sortie détaillée affiche la résolution DNS, l'établissement de la connexion proxy et le flux réel de la requête HTTP. Si le tunnel proxy fonctionne correctement, vous verrez apparaître des lignes telles que « Connecté à proxy.company.com », suivies de « CONNECT httpbin.org:80 ».

Les connexions HTTPS nécessitent que le proxy prenne en charge la méthode CONNECT :

# Test HTTPS proxy
docker run --rm \
  -e HTTPS_PROXY=http://proxy.company.com:8080 \
  python:3.13-slim \
  curl -v https://httpbin.org/ip

Recherchez « CONNECT httpbin.org:443 HTTP/1.1 » dans la sortie. Si vous voyez « Méthode non autorisée » ou une erreur similaire, cela signifie que votre proxy ne prend pas en charge le tunneling HTTPS.

Vérifiez l'authentification en intégrant les informations d'identification dans l'URL du proxy :

# Test with authentication
docker run --rm \
  -e HTTPS_PROXY=http://user:pass@proxy.company.com:8080 \
  python:3.13-slim \
  wget -O- https://httpbin.org/ip

Les échecs d'authentification s'affichent sous la forme de réponses « 407 Proxy Authentication Required » (Authentification proxy requise). Une authentification réussie aboutit directement à la requête cible.

Le débogage au niveau du réseau avec tcpdump permet de capturer les paquets réels entre Docker et votre serveur proxy.

Exécutez tcpdump pour visualiser tout le trafic vers votre proxy :

# Capture proxy traffic
sudo tcpdump -i any host proxy.company.com and port 8080

Cette capture brute de paquets montre les tentatives de connexion, le transfert de données et la fin de la connexion. Recherchez l'établissement d'une connexion TCP (paquets SYN/ACK) suivi du trafic HTTP. Les délais d'expiration de connexion apparaissent sous forme de paquets SYN répétés sans réponse.

Le test de résolution DNS élimine une source courante de confusion liée aux proxys.

De nombreux problèmes de proxy sont en réalité des problèmes DNS déguisés. Vérifier la résolution DNS à l'intérieur des conteneurs :

# Test DNS inside containers  
docker run --rm python:3.13-slim nslookup registry-1.docker.io

Si cela échoue, le conteneur ne peut pas résoudre les noms de domaine. Veuillez essayer d'utiliser un serveur DNS public pour isoler le problème :

# Test with custom DNS
docker run --dns 8.8.8.8 --rm python:3.13-slim nslookup registry-1.docker.io

Les environnements d'entreprise disposent souvent de serveurs DNS qui ne fonctionnent qu'à l'intérieur du réseau. Votre proxy peut être amené à gérer les requêtes DNS ainsi que le trafic HTTP, ou vous devrez peut-être configurer des conteneurs avec des serveurs DNS spécifiques qui fonctionnent via votre proxy.

Examinez chaque couche de manière systématique et vous trouverez la cause profonde.

Vous recherchez des options qui pourraient gérer les proxys différemment? Nous mettons à votre disposition un guide sur les alternatives à Docker afin que vous puissiez découvrir l'ensemble des outils de conteneurisation disponibles en 2025.

Conclusion

La configuration du proxy Docker ne se limite pas au téléchargement d'images. Elle permet également de créer des applications conteneurisées fiables et sécurisées dans des environnements d'entreprise.

Je vous ai montré comment configurer les paramètres proxy à quatre niveaux différents : opérations client, processus démon, exécution du conteneur et opérations de compilation. Chaque couche remplit une fonction spécifique et nécessite sa propre approche de configuration, de l'à partir de fichiers JSON et de variables d'environnement aux paramètres du gestionnaire de paquets et aux configurations BuildKit. Une stratégie de proxy multicouche vous protège contre les points de défaillance uniques.

Souhaitez-vous approfondir vos connaissances sur Docker, la conteneurisation et la sécurité ? Veuillez consulter notre liste de cours sélectionnés :

• Présentation de Docker
• Docker intermédiaire
• Concepts de conteneurisation et de virtualisation
• Conteneurisation et virtualisation avec Docker et Kubernetes
• Concepts DevOps
• Présentation de Kubernetes