# Replicar la biblioteca de Docker Hub ## Caso de uso Si tienes múltiples instancias de Docker ejecutándose en tu entorno, como varias máquinas físicas o virtuales que ejecutan Docker, cada demonio se conecta a internet y descarga del repositorio de Docker una imagen que no tiene localmente. Puedes ejecutar una réplica local del registro y apuntar todos tus demonios allí para evitar este tráfico de internet adicional. > [!NOTE] > > Las Docker Official Images son propiedad intelectual de Docker. ### Alternativas Alternativamente, si el conjunto de imágenes que utilizas está bien delimitado, puedes descargarlas manualmente y subirlas a un registro privado local simple. Además, si tus imágenes se compilan internamente, no usar el Hub en absoluto y depender por completo de tu registro local es el escenario más sencillo. ### Limitación Actualmente no es posible replicar otro registro privado. Solo se puede replicar el Hub central. > [!NOTE] > > Las réplicas de Docker Hub siguen estando sujetas a la [política de uso justo](/docker-hub/usage/#fair-use) de Docker. ### Solución El registro se puede configurar como un caché de descarga directa (pull-through cache). En este modo, un registro responde a todas las solicitudes normales de `docker pull` pero almacena todo el contenido localmente. ### Usar la Gestión de Acceso al Registro (RAM) con una réplica de registro Si el acceso a Docker Hub está restringido a través de tu configuración de Gestión de Acceso al Registro (Registry Access Management - RAM), no podrás descargar imágenes originarias de Docker Hub incluso si las imágenes están disponibles en la réplica de tu registro. Te encontrarás con el siguiente error: ```console Error response from daemon: Access to docker.io has been restricted by your administrators. ``` Si no puedes permitir el acceso a Docker Hub, puedes descargar manualmente desde la réplica de tu registro y, opcionalmente, volver a etiquetar la imagen. Por ejemplo: ```console docker pull [:]/library/busybox docker tag [:]/library/busybox:latest busybox:latest ``` ## ¿Cómo funciona? La primera vez que solicitas una imagen a la réplica de tu registro local, esta descarga la imagen desde el registro público de Docker y la almacena localmente antes de entregártela. En las solicitudes posteriores, la réplica del registro local puede servir la imagen desde su propio almacenamiento. ### ¿Qué pasa si el contenido cambia en el Hub? Cuando se intenta una descarga con una etiqueta, el registro comprueba el control remoto para asegurarse de si tiene la versión más reciente del contenido solicitado. De lo contrario, descarga y almacena en caché el contenido más reciente. ### ¿Qué pasa con el disco? En entornos con altas tasas de rotación, los datos obsoletos pueden acumularse en el caché. Cuando funciona como un caché de descarga directa, el registro elimina periódicamente el contenido antiguo para ahorrar espacio en disco. Las solicitudes posteriores de contenido eliminado provocan una descarga remota y un nuevo almacenamiento en caché local. Para garantizar el mejor rendimiento y la corrección, el caché del registro debe configurarse para utilizar el controlador `filesystem` para el almacenamiento. ## Ejecutar un registro como caché de descarga directa La forma más sencilla de ejecutar un registro como caché de descarga directa es ejecutar la imagen oficial de [Registry](https://hub.docker.com/_/registry). Como mínimo, debes especificar `proxy.remoteurl` dentro de `/etc/docker/registry/config.yml` como se describe en la siguiente subsección. Se pueden desplegar múltiples cachés de registro sobre el mismo backend. Un único caché de registro garantiza que las solicitudes concurrentes no descarguen datos duplicados, pero esta propiedad no se cumple para un clúster de caché de registro. ### Configurar el caché Para configurar un registro para que funcione como caché de descarga directa, se requiere añadir una sección `proxy` al archivo de configuración. Para acceder a imágenes privadas en Docker Hub, se puede suministrar un nombre de usuario y una contraseña. ```yaml proxy: remoteurl: https://registry-1.docker.io username: [username] password: [password] ``` > [!WARNING] > > Si especificas un nombre de usuario y una contraseña, ten en cuenta que los recursos privados a los que este usuario tiene acceso en Docker Hub se pondrán a disposición en tu réplica. ¡Debes proteger tu réplica implementando autenticación si esperas que estos recursos sigan siendo privados! > [!WARNING] > > Para que el programador limpie las entradas antiguas, se debe habilitar `delete` en la configuración del registro. ### Configurar el demonio de Docker Pasa la opción `--registry-mirror` al iniciar `dockerd` manualmente, o edita [`/etc/docker/daemon.json`](/reference/cli/dockerd/#daemon-configuration-file) y añade la clave y el valor de `registry-mirrors` para que el cambio sea permanente. ```json { "registry-mirrors": ["https://"] } ``` Guarda el archivo y recarga Docker para que el cambio surta efecto. > [!NOTE] > > Algunos mensajes de registro que parecen ser errores son en realidad mensajes informativos. > > Comprueba el campo `level` para determinar si el mensaje te advierte de un error o te está dando información. Por ejemplo, este mensaje de registro es informativo: > > ```text > time="2017-06-02T15:47:37Z" level=info msg="error statting local store, serving from upstream: unknown blob" go.version=go1.7.4 > ``` > > Te está indicando que el archivo aún no existe en el caché local y que se está descargando desde el origen (upstream).