Unregistry – envoyer directement un `docker push` vers un serveur sans registre

 (github.com/psviderski)
4 points par GN⁺ 2025-06-19 | 1 commentaires | Partager sur WhatsApp
  • Unregistry est un outil open source qui permet d’envoyer des images Docker directement vers un serveur distant sans registre externe
  • Avec la commande docker pussh, il transfère les images vers un serveur distant via SSH de manière efficace, en ignorant les couches déjà présentes
  • Il élimine la complexité et l’inefficacité des approches traditionnelles comme Docker Hub, un registre auto-hébergé ou la méthode save/load
  • C’est un avantage majeur pour le déploiement en production, les environnements CI/CD et les réseaux isolés, où des transferts d’images rapides et sûrs sont essentiels
  • L’installation, l’utilisation et les prérequis sont très simples, sans service supplémentaire à exploiter ni port à exposer

Présentation d’Unregistry et principaux avantages

  • Unregistry est un registre d’images léger qui stocke et sert les images directement depuis le stockage du démon Docker
  • Avec la commande docker pussh, il est possible de transférer une image directement vers un serveur Docker distant via SSH, sans passer par un registre externe
  • Lors du transfert, les couches déjà présentes sur le serveur sont exclues, ce qui permet un envoi rapide uniquement des éléments nécessaires

Les problèmes du déploiement classique d’images Docker

  • Après avoir construit une image en local, les options pour la transférer vers un serveur sont les suivantes
    • Docker Hub / GitHub Container Registry : le code peut devenir public à l’extérieur, ou l’usage de dépôts privés entraîne des coûts
    • Registre auto-hébergé : cela ajoute la charge d’exploitation d’un service séparé, ainsi que des contraintes de sécurité et de gestion du stockage
    • Save/Load : l’image complète est toujours transférée, ce qui est inefficace
    • Rebuild direct sur le serveur : cela gaspille du temps et des ressources serveur, et complique le débogage

La solution Unregistry

  • Une seule commande docker pussh myapp:latest user@server permet un transfert direct sans stockage intermédiaire

  • Aucun réglage de registre supplémentaire, aucune exposition de port, aucun stockage à préparer, aucun abonnement requis

  • Processus de transfert

    • ouverture d’un tunnel SSH vers le serveur distant
    • lancement temporaire d’un conteneur unregistry
    • liaison entre un port local aléatoire et le port d’unregistry
    • envoi via docker push uniquement des couches absentes (utilisables immédiatement)
    • arrêt du conteneur unregistry et fermeture du tunnel SSH

  • L’approche est simple et efficace, à la manière de rsync

  • Ce projet a été développé dans le cadre de Uncloud afin de simplifier la complexité du déploiement de conteneurs sur plusieurs hôtes Docker

Exemples d’utilisation

Envoi direct d’images vers l’environnement de déploiement

  • Après une construction en local, push direct vers le serveur de production
    • docker build --platform linux/amd64 -t myapp:1.2.3 .
    • docker pussh myapp:1.2.3 deploy@prod-server
    • ssh deploy@prod-server docker run -d myapp:1.2.3

Pipeline CI/CD

  • Prend en charge la construction et le déploiement sans la complexité d’un registre
    • Utilisable directement dans un workflow GitHub Actions YAML

Homelab et environnements isolés sans accès à Internet

  • Permet de transférer des images en toute sécurité vers un réseau isolé sans les exposer sur Internet

Mode d’emploi

  • Le compte utilisateur SSH doit pouvoir exécuter des commandes Docker à distance
  • Des options supplémentaires sont prises en charge, comme une clé privée SSH ou un port SSH personnalisé
  • Le transfert d’images multi-plateformes est également pris en charge (dans un environnement basé sur containerd)

Prérequis

Environnement local

  • Docker CLI (avec prise en charge des plugins, 19.03+)
  • Client OpenSSH

Serveur distant

  • Docker doit être installé et en cours d’exécution
  • L’utilisateur SSH doit disposer des droits Docker et, si nécessaire, pouvoir exécuter sudo docker sans mot de passe
  • L’utilisation du containerd image store améliore les performances
    • ajouter la configuration suivante à /etc/docker/daemon.json puis redémarrer Docker 
      {
  "features": {
    "containerd-snapshotter": true
  }
}

Utilisation avancée

Utilisation comme registre local autonome

  • Il est possible d’exploiter facilement unregistry comme registre local sans composant supplémentaire
  • Le déploiement et le push peuvent se faire via des commandes Docker

Utilisation d’options SSH personnalisées

  • Le fichier de configuration SSH permet d’ajouter des réglages précis adaptés aux besoins, comme l’authentification supplémentaire ou des ports spécifiques

Contribution et communauté

  • En cas de bug, vous pouvez ouvrir une issue sur GitHub
  • La communauté Discord de Uncloud permet d’échanger sur les fonctionnalités, la feuille de route et les détails d’implémentation

Inspiration et projets open source de référence

  • Spegel : source d’inspiration pour l’implémentation d’un registre d’images conteneur P2P basé sur containerd
  • Docker Distribution : utilisé comme base pour l’implémentation du registre réel

Résumé

  • Unregistry est un outil qui permet de transférer facilement et rapidement des images Docker directement vers un serveur distant, sans avoir à mettre en place ni gérer un registre
  • Il offre de solides avantages dans différents scénarios, notamment le déploiement en production, le CI/CD et les réseaux isolés
  • Il convient particulièrement bien lorsque serveurs et administrateurs veulent simplement déplacer des images sans procédure complexe

À lire aussi

1 commentaires

 
GN⁺ 2025-06-19
Commentaires sur Hacker News

  • Je ne recommanderais pas d’utiliser Homebrew sur Linux du point de vue des caractéristiques du serveur, des frontières de sécurité et du durcissement ; même si l’installation pour Linux existe, elle donne l’impression d’avoir été ajoutée après coup, et cela se comporte moins comme un gestionnaire de paquets que comme un pigeon sur un échiquier

  • Je trouve que c’est une idée élégante qui conviendrait bien aux environnements utilisant déjà des outils de déploiement push comme Ansible, et cela semble aussi adapté comme technique de déploiement de correctifs urgents pour les entreprises où un registre Docker n’est pas disponible 24h/24 ; je me demande si cela s’intègre proprement avec l’outillage OCI (buildah, etc.) ou s’il faut une installation Docker complète des deux côtés ; je n’ai pas encore creusé sérieusement, mais je compte m’y pencher, et j’avais eu l’impression que skopeo manquait d’un moyen de bootstrapper son propre registre sur le serveur distant pour fonctionner dans ce type d’environnement

    • Le serveur distant a besoin de containerd (Docker et Kubernetes utilisent aussi containerd), et côté client, n’importe quoi capable de comprendre l’API du registre convient (spécification OCI Distribution : https://github.com/opencontainers/distribution-spec) ; Unregistry réutilise le code officiel du registre Docker pour la couche API, ce qui lui donne une sensation proche du registre de Docker Hub ; on peut utiliser skopeo, crane, regclient, BuildKit et d’autres outils compatibles avec un registre OCI, mais cela nécessite d’exécuter directement unregistry sur l’hôte distant ; la commande docker pussh sert à automatiser tout ce flux en s’appuyant sur Docker en local ; c’est un script bash, donc je recommande d’y jeter un œil : https://github.com/psviderski/unregistry/blob/main/docker-pussh, et il est facile à modifier à sa guise

    • Il faut un daemon Docker des deux côtés ; cette méthode utilise une approche astucieuse consistant à partager les layers entre les deux daemons via ssh

  • Je trouve que la commande pussh est facile à retenir, explicite, et constitue un joli jeu de mots à une lettre près du nom de la commande standard existante

    • "pussh" n’est pas mal, mais pour l’automatisation, un alias plus explicite comme "docker push-over-ssh" serait sans doute préférable ; quelqu’un qui voit "pussh" pour la première fois pourrait croire à une faute de frappe, ce qui créerait une confusion inutile ; ce serait bien de proposer à la fois une version courte et une version longue avec drapeau complet

    • Il y a une explication en plaisantant selon laquelle le s supplémentaire représenterait sssh, tandis que d’autres disent que c’est simplement une faute de frappe

    • Le nom "pussh" risque d’entrer en conflit avec d’autres commandes

  • Une telle fonctionnalité aurait dû exister depuis longtemps, et je trouve ça très cool ; les registres Docker ont leur utilité, mais dans l’ensemble c’est devenu trop complexe et éloigné de l’esprit hacker

    • Docker étant une entreprise financée par du capital-risque, il fallait bien qu’elle trouve un moyen de générer des revenus

  • Le projet et l’approche sont impressionnants ; j’en ai eu assez des registres coûteux au point d’auto-héberger quelque chose comme Zot(https://zotregistry.dev), mais cette méthode semble bien plus simple dans certains cas d’usage ; j’aimerais voir se généraliser davantage de services de registre privé faciles, peu coûteux et facturés à l’usage

    • Quelqu’un signale que le certificat SSL de zothub.io a expiré

  • J’ai l’impression que Docker aurait dû fonctionner comme ça dès le départ ; je trouve l’idée excellente

    • On peut obtenir un résultat similaire en sauvegardant l’image dans une archive, en la transférant vers le serveur, puis en la chargeant ; par exemple, la sauvegarder avec docker save -o my-app.tar my-app:latest, puis la charger avec docker load -i /path/to/my-app.tar ; combiné avec un outil d’automatisation comme ansible, on peut faire soi-même ce qu’Unregistry automatise ; cela dit, l’approche save/load a l’inconvénient de devoir transférer l’image entière à chaque fois, et la gestion des images est aussi plus pratique que celle de simples fichiers d’archive, comme l’indique le dépôt GitHub

  • Je me réjouis de ce retour vers l’auto-hébergement en s’appuyant sur ce genre d’outils et sur l’outillage SSH, et cela me semble être une réalisation bien conçue ; je compte l’essayer moi-même

  • Grâce à cet outil, j’ai découvert pour la première fois le projet uncloud, et cela ressemble à une solution de déploiement serveur dans l’esprit de dokku mais plus puissante, ce que je trouve intéressant

    • Je partage cet avis selon lequel uncloud leur convient bien ; si vous avez des questions, n’hésitez pas à venir sur Discord

    • Il est aussi recommandé de jeter un œil à https://skateco.github.io/, qui propose une approche similaire

    • Recommandation de Portainer : utilisation réussie de Portainer Community Edition et de Portainer Agent sur deux instances AWS EC2 ; la fonctionnalité de stacks (basée sur docker compose) est particulièrement appréciée, et sur l’une des instances EC2, portainer agent fait tourner Caddy dans un conteneur pour assurer les fonctions d’équilibreur de charge et de proxy inverse

  • L’idée est originale, mais ce type d’approche est fortement couplé au déploiement du service, ce qui nécessite une logique supplémentaire prenant en compte le moment du « push » pour le déploiement et la montée en charge, par exemple dans le cas d’un déploiement blue/green ; en y réfléchissant, je me rends compte que c’est justement ce rôle qu’implémente l’architecture d’uncloud ; mais au final, c’est une question de compromis, et si l’on privilégie la simplicité sur une unique VM Hetzner, le simple fait de construire l’image en local peut déjà être un choix très satisfaisant

    • Comme toujours, tout est affaire de compromis, et le mieux reste de pouvoir choisir l’outil optimal selon le contexte