Mettre en miroir la bibliothèque Docker Hub

Cas d'usage

Si vous avez plusieurs instances de Docker fonctionnant dans votre environnement, comme plusieurs machines physiques ou virtuelles toutes exécutant Docker, chaque daemon va sur internet et récupère une image qu'il n'a pas localement, depuis le dépôt Docker. Vous pouvez exécuter un miroir de registre local et pointer tous vos daemons là-bas, pour éviter ce trafic internet supplémentaire.

Note

Les Images Officielles Docker sont une propriété intellectuelle de Docker.

Alternatives

Alternativement, si l'ensemble d'images que vous utilisez est bien délimité, vous pouvez simplement les télécharger manuellement et les pousser vers un simple registre local privé.

De plus, si vos images sont toutes construites en interne, ne pas utiliser le Hub du tout et compter entièrement sur votre registre local est le scénario le plus simple.

Piège

Il n'est actuellement pas possible de mettre en miroir un autre registre privé. Seul le Hub central peut être mis en miroir.

Note

Les miroirs de Docker Hub sont toujours soumis à la politique d'usage équitable de Docker.

Solution

Le Registre peut être configuré comme un cache de téléchargement transparent. Dans ce mode un Registre répond à toutes les requêtes docker pull normales mais stocke tout le contenu localement.

Utilisation de la Gestion d'Accès au Registre (RAM) avec un miroir de registre

Si l'accès à Docker Hub est restreint via votre configuration de Gestion d'Accès au Registre (RAM), vous ne pourrez pas télécharger les images provenant de Docker Hub même si les images sont disponibles dans votre miroir de registre.

Vous rencontrerez l'erreur suivante :

Error response from daemon: Access to docker.io has been restricted by your administrators.

Si vous ne pouvez pas autoriser l'accès à Docker Hub, vous pouvez télécharger manuellement depuis votre miroir de registre et optionnellement, ré-étiqueter l'image. Par exemple :

docker pull <your-registry-mirror>[:<port>]/library/busybox
docker tag <your-registry-mirror>[:<port>]/library/busybox:latest busybox:latest

Comment ça fonctionne ?

La première fois que vous demandez une image depuis votre miroir de registre local, il télécharge l'image depuis le registre Docker public et la stocke localement avant de vous la retourner. Lors des requêtes subséquentes, le miroir de registre local est capable de servir l'image depuis son propre stockage.

Que se passe-t-il si le contenu change sur le Hub ?

Quand un téléchargement est tenté avec une étiquette, le Registre vérifie le distant pour s'assurer qu'il a la dernière version du contenu demandé. Sinon, il récupère et met en cache le dernier contenu.

Et mon disque ?

Dans les environnements avec des taux de rotation élevés, des données obsolètes peuvent s'accumuler dans le cache. Lors de l'exécution comme un cache de téléchargement transparent, le Registre supprime périodiquement l'ancien contenu pour économiser de l'espace disque. Les requêtes subséquentes pour le contenu supprimé causent un récupération distante et une remise en cache locale.

Pour assurer les meilleures performances et garantir la justesse, le cache du Registre devrait être configuré pour utiliser le driver filesystem pour le stockage.

Exécuter un Registre comme un cache de téléchargement transparent

La façon la plus facile d'exécuter un registre comme un cache de téléchargement transparent est d'exécuter l'image officielle Registre. Au minimum, vous devez spécifier proxy.remoteurl dans /etc/docker/registry/config.yml comme décrit dans la sous-section suivante.

Plusieurs caches de registre peuvent être déployés sur le même backend. Un seul cache de registre assure que les requêtes concurrentes ne téléchargent pas de données dupliquées, mais cette propriété ne reste pas vraie pour un cluster de cache de registre.

Configurer le cache

Pour configurer un Registre pour fonctionner comme un cache de téléchargement transparent, l'ajout d'une section proxy est requis dans le fichier de configuration.

Pour accéder aux images privées sur Docker Hub, un nom d'utilisateur et mot de passe peuvent être fournis.

proxy:
  remoteurl: https://registry-1.docker.io
  username: [username]
  password: [password]

Warning

Si vous spécifiez un nom d'utilisateur et mot de passe, il est très important de comprendre que les ressources privées auxquelles cet utilisateur a accès sur Docker Hub sont rendues disponibles sur votre miroir. Vous devez sécuriser votre miroir en implémentant l'authentification si vous vous attendez à ce que ces ressources restent privées !

Warning

Pour que le planificateur nettoie les anciennes entrées, delete doit être activé dans la configuration du registre.

Configurer le daemon Docker

Passez soit l'option --registry-mirror quand vous démarrez dockerd manuellement, ou éditez /etc/docker/daemon.json et ajoutez la clé et valeur registry-mirrors, pour rendre le changement persistant.

{
  "registry-mirrors": ["https://<my-docker-mirror-host>"]
}

Sauvegardez le fichier et rechargez Docker pour que le changement prenne effet.

Note

Certains messages de log qui semblent être des erreurs sont en fait des messages informationnels.

Vérifiez le champ level pour déterminer si le message vous avertit d'une erreur ou vous donne des informations. Par exemple, ce message de log est informationnel :

time="2017-06-02T15:47:37Z" level=info msg="error statting local store, serving from upstream: unknown blob" go.version=go1.7.4

Il vous dit que le fichier n'existe pas encore dans le cache local et est en cours de téléchargement depuis l'amont.