unregistry

Unregistry es un registro ligero de imágenes de contenedores que almacena y sirve imágenes directamente desde el almacenamiento del daemon de Docker (almacén de imágenes containerd). Está diseñado para eliminar la necesidad de un registro externo al mover imágenes entre máquinas. El proyecto incluye un comando plugin de la CLI de Docker, `docker pussh` (la 's' extra significa SSH), que envía imágenes directamente a un servidor Docker remoto a través de SSH. Solo se transfieren las capas que faltan en el lado remoto, lo que el README describe como una operación rápida y eficiente. Cómo funciona, según el README: el comando establece un túnel SSH al servidor remoto, inicia un contenedor temporal de unregistry allí, reenvía un puerto localhost aleatorio al puerto de unregistry a través del túnel, ejecuta `docker push` hacia unregistry mediante ese puerto reenviado (transfiriendo solo capas no presentes remotamente), luego detiene el contenedor de unregistry y cierra el túnel. La imagen transferida queda disponible en el daemon Docker remoto. El README compara este enfoque con rsync para imágenes Docker. Motivación: el README enumera alternativas comunes y sus inconvenientes: registros públicos (exposición de código o repositorios privados de pago), registros autoalojados (servicio extra que mantener y asegurar), `docker save | ssh ... docker load` (transfiere toda la imagen incluso cuando la mayoría de capas ya existen remotamente) y reconstrucciones remotas (tiempo y recursos desperdiciados). Unregistry fue creado originalmente para Uncloud, una herramienta para desplegar contenedores en múltiples hosts Docker. Requisitos: localmente, una CLI de Docker con soporte de plugins (Docker 19.03+) y un cliente OpenSSH. En el servidor remoto, Docker debe estar instalado y en ejecución, el usuario SSH debe poder ejecutar comandos docker (root o un usuario en el grupo docker), y se necesita `sudo docker` sin contraseña si se requiere sudo. El servidor necesita acceso a internet a ghcr.io para descargar la imagen de unregistry en el primer uso, a menos que la imagen se precargue manualmente para entornos aislados o restringidos. El contenedor de unregistry necesita acceso al socket containerd en /run/containerd/containerd.sock y se ejecuta como root. Opciones de instalación documentadas: Homebrew (`brew install psviderski/tap/docker-pussh`, más un enlace simbólico en ~/.docker/cli-plugins), descarga directa del script docker-pussh en el directorio de plugins, y paquetes Debian no oficiales mantenidos en un repositorio separado. Windows no está soportado actualmente, aunque se sugiere WSL 2 con las instrucciones de Linux. La instalación se puede verificar con `docker pussh --help`. Un tema de configuración notable es el almacén de imágenes containerd. Unregistry almacena imágenes en el almacén de imágenes de containerd, pero por defecto Docker mantiene su propia capa de almacenamiento separada. Con el almacén de imágenes containerd habilitado en Docker, las imágenes enviadas están inmediatamente disponibles para Docker sin duplicación y con operaciones pussh más rápidas. Sin él, pussh ejecuta un `docker pull` adicional en el host remoto, las imágenes se almacenan dos veces y pueden acumularse imágenes containerd no gestionadas; el README muestra `ctr -n moby images ls` y `ctr -n moby images rm` para limpieza manual. Habilitar el almacén de imágenes containerd está documentado como causa de pérdida temporal de imágenes y contenedores creados con el controlador de almacenamiento clásico. Ejemplos de uso incluyen enviar a un host remoto, autenticación con clave SSH con `-i`, un puerto SSH personalizado, un archivo de configuración SSH personalizado con `-F`, seleccionar una plataforma para imágenes multi-plataforma (requiriendo el almacén de imágenes containerd localmente) y sobrescribir la versión de la imagen de unregistry mediante la variable de entorno UNREGISTRY_IMAGE. Casos de uso documentados son despliegues a servidores de producción, pipelines CI/CD y entornos homelab o aislados. Unregistry también puede ejecutarse de forma independiente como registro local en el puerto 5000 montando el socket containerd. El README enlaza proyectos de terceros: una GitHub Action para enviar imágenes con docker-pussh, una GitHub Action para instalar el plugin y una herramienta Python para limpiar imágenes en registros autoalojados. Da crédito a Spegel como inspiración por usar el almacén de imágenes containerd como backend de registro y a Docker Distribution como la implementación de registro en la que se basa unregistry.