Utilisation de proxies de registry / pull-through caches

Le problème : dépendance et latence des registries distants

Lorsque vous exécutez `docker pull une_image_publique`, votre démon Docker contacte directement le registry source, le plus souvent Docker Hub. Dans les environnements avec de nombreux hôtes Docker ou des pipelines CI/CD intensifs, cela peut entraîner plusieurs problèmes. Chaque hôte télécharge sa propre copie de l'image, consommant potentiellement beaucoup de bande passante internet. De plus, la vitesse de téléchargement dépend de la latence réseau entre vos hôtes et le registry distant.

Une dépendance directe sur un registry externe comme Docker Hub peut aussi poser des problèmes de résilience. Si Docker Hub rencontre des difficultés ou si votre connexion internet est instable, les téléchargements d'images peuvent échouer, bloquant vos déploiements ou vos processus de développement.

C'est pour pallier ces inconvénients qu'intervient le concept de proxy de registry, également appelé miroir ou cache pull-through (pull-through cache).

Qu'est-ce qu'un proxy de registry (pull-through cache) ?

Un proxy de registry agit comme un intermédiaire entre vos démons Docker et un registry distant (comme Docker Hub ou un autre registry privé). Lorsqu'un client Docker demande une image via le proxy, celui-ci vérifie d'abord s'il possède déjà cette image (et la bonne version/couche) dans son cache local.

Si l'image est présente dans le cache, le proxy la sert directement au client, ce qui est généralement beaucoup plus rapide et ne consomme pas de bande passante externe. Si l'image n'est pas dans le cache (ou si une version plus récente est demandée), le proxy la télécharge depuis le registry distant, la stocke dans son cache local, puis la transmet au client.

Les requêtes suivantes pour la même image seront alors servies depuis le cache local. Essentiellement, il s'agit d'un cache local intelligent pour vos images Docker provenant de registries externes.

Principaux avantages d'un proxy de registry

La mise en place d'un proxy de registry offre plusieurs avantages significatifs :

Mise en place avec l'image 'registry:2'

L'image Docker officielle `registry:2` peut être configurée pour fonctionner comme un proxy pull-through. Cela se fait généralement via un fichier de configuration YAML (`config.yml`) plutôt que par des variables d'environnement.

Voici un exemple de fichier `config.yml` pour configurer un registry comme proxy pour Docker Hub :

version: 0.1
log:
  fields:
    service: registry
storage:
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /var/lib/registry # Important pour la persistance
delete:
    enabled: true # Nécessaire pour le nettoyage futur
http:
  addr: :5000
  headers:
    X-Content-Type-Options: [nosniff]
health:
  storagedriver:
    enabled: true
    interval: 10s
    threshold: 3
# Configuration spécifique au proxy
proxy:
  remoteurl: https://registry-1.docker.io # URL du registry distant (Docker Hub ici)
  # username: [votre_username_dockerhub] # Optionnel : si le remote nécessite une authentification
  # password: [votre_password_dockerhub] # Optionnel

Vous montez ensuite ce fichier `config.yml` dans le conteneur registry, ainsi qu'un volume pour persister le cache :

docker run -d -p 5000:5000 \
  --restart=always \
  --name mon-registry-proxy \
  -v "$(pwd)"/registry-proxy-data:/var/lib/registry \
  -v "$(pwd)"/config.yml:/etc/docker/registry/config.yml \
  registry:2

Comme pour un registry privé, il est fortement recommandé de sécuriser ce proxy avec TLS et potentiellement une authentification si nécessaire, surtout s'il est accessible depuis l'extérieur de votre réseau local.

Configuration des clients Docker (démon)

Pour que vos machines utilisent ce proxy, vous devez configurer le démon Docker sur chaque machine cliente. Cela se fait en modifiant le fichier de configuration du démon, généralement situé à `/etc/docker/daemon.json` sur Linux.

Vous utilisez la clé `registry-mirrors`. C'est un tableau de chaînes de caractères, où chaque chaîne est l'URL de votre proxy (incluant le protocole `http` ou `https` et le port).

{
  "registry-mirrors": ["https://mon-proxy.domaine.local:5000"]
}

Si votre proxy utilise un certificat TLS auto-signé ou non reconnu par le système, vous devrez également configurer le démon Docker pour faire confiance à ce certificat, ou (moins recommandé pour la production) ajouter l'URL du proxy à `insecure-registries` si vous n'utilisez pas TLS.

Après avoir modifié `daemon.json`, vous devez recharger la configuration et redémarrer le démon Docker :

sudo systemctl daemon-reload
sudo systemctl restart docker

Désormais, lorsque ce démon Docker exécutera `docker pull ubuntu`, il essaiera d'abord de contacter `https://mon-proxy.domaine.local:5000`. Si le proxy répond et a l'image, elle sera servie depuis le proxy. Si le proxy ne répond pas ou n'a pas l'image, le démon Docker tentera alors de contacter directement Docker Hub (comportement par défaut).

Points clés et considérations

Les proxies de registry (pull-through caches) sont une solution efficace pour accélérer les téléchargements d'images, réduire la consommation de bande passante externe et améliorer la résilience face aux indisponibilités des registries distants.

L'image officielle `registry:2` peut être configurée en mode proxy via un fichier `config.yml`, en spécifiant l'URL du `remoteurl` (par exemple, Docker Hub). N'oubliez pas la persistance des données du cache via un volume et la sécurisation (TLS).

La configuration côté client est cruciale : modifiez le fichier `daemon.json` sur chaque hôte Docker pour ajouter l'URL de votre proxy dans le tableau `registry-mirrors`.

Un proxy complète souvent un registry privé : le registry privé héberge vos images internes, tandis que le proxy met en cache les images publiques externes fréquemment utilisées. Des solutions de gestion d'artefacts plus complètes (Nexus, Artifactory, Harbor) intègrent souvent ces deux fonctionnalités (hébergement privé + proxy).