Unregistry – „docker push“ direkt auf einen Server ohne Registry übertragen

 (github.com/psviderski)
4 Punkte von GN⁺ 2025-06-19 | 1 Kommentare | Auf WhatsApp teilen
  • Unregistry ist ein Open-Source-Tool, mit dem sich Docker-Images direkt auf entfernte Server übertragen lassen – ganz ohne externe Registry
  • Mit dem Befehl docker pussh werden Images per SSH effizient an einen Remote-Server gesendet; bereits vorhandene Layer werden dabei übersprungen
  • Es beseitigt die Komplexität und Ineffizienz klassischer Wege wie Docker Hub, selbst betriebene Registries oder save/load
  • Gerade bei Deployments in Produktionsumgebungen, CI/CD und isolierten Netzwerken ist die schnelle und sichere Image-Übertragung ein großer Vorteil
  • Installation, Nutzung und Anforderungen sind sehr einfach, zusätzliche Services oder offene Ports sind nicht nötig

Einführung in Unregistry und die wichtigsten Vorteile

  • Unregistry ist eine leichtgewichtige Image-Registry, die Images direkt aus dem Storage des Docker-Daemons speichert und bereitstellt
  • Mit dem Befehl docker pussh lassen sich Images per SSH ohne externe Registry direkt auf einen entfernten Docker-Server übertragen
  • Bei der Übertragung werden bereits auf dem Server vorhandene Layer ausgeschlossen, sodass nur die benötigten Teile schnell übertragen werden

Probleme bei der herkömmlichen Verteilung von Docker-Images

  • Wenn ein Image lokal gebaut und anschließend auf einen Server übertragen werden soll, gibt es typischerweise folgende Optionen
    • Docker Hub/GitHub Container Registry: Code wird extern offengelegt oder bei privaten Repositories fallen Kosten an
    • Eigene Registry: Zusätzlicher Betriebsaufwand für Service, Sicherheit und Storage-Management
    • Save/Load: Immer das komplette Image wird übertragen, was ineffizient ist
    • Direktes Rebuild auf dem Server: Verschwendet Zeit und Server-Ressourcen und erschwert das Debugging

Die Unregistry-Lösung

  • Mit nur einem Befehl docker pussh myapp:latest user@server ist eine direkte Übertragung ohne Zwischenspeicher möglich

  • Keine zusätzliche Registry-Konfiguration, keine offenen Ports, keine vorbereitete Storage-Infrastruktur und kein Abonnement erforderlich

  • Ablauf der Übertragung

    • Aufbau eines SSH-Tunnels zum Remote-Server
    • Temporäres Starten eines Unregistry-Containers
    • Verbindung eines zufälligen lokalen Ports mit dem Unregistry-Port
    • Übertragung per docker push nur der noch nicht vorhandenen Layer (sofort nutzbar)
    • Beenden des Unregistry-Containers und des SSH-Tunnels

  • Das Verfahren ist einfach und effizient, ähnlich wie rsync

  • Das Projekt wurde im Rahmen von Uncloud entwickelt, um die Komplexität der Container-Bereitstellung auf mehreren Docker-Hosts zu vereinfachen

Anwendungsbeispiele

Images direkt in eine Deployment-Umgebung übertragen

  • Nach dem lokalen Build direkt auf den Produktionsserver pushen
    • 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

CI/CD-Pipelines

  • Unterstützt Build und Deployment ohne die Komplexität einer Registry
    • Direkte Übertragung kann z. B. in GitHub-Action-YAML verwendet werden

Homelab- und isolierte Offline-Umgebungen

  • Sichere Übertragung in isolierte Netzwerke, ohne Images im Internet veröffentlichen zu müssen

Verwendung

  • Das SSH-Benutzerkonto muss auf dem Remote-System Docker-Befehle ausführen dürfen
  • Zusätzliche Optionen wie SSH-Private-Key oder benutzerdefinierte SSH-Ports werden unterstützt
  • Auch die Übertragung von Multi-Platform-Images wird unterstützt (bei containerd-basierter Umgebung)

Anforderungen

Lokale Umgebung

  • Docker CLI (mit Plugin-Unterstützung, 19.03+)
  • OpenSSH-Client

Remote-Server

  • Docker muss installiert sein und laufen
  • Der SSH-Benutzer muss Docker-Berechtigungen besitzen und bei Bedarf sudo docker ohne Passwort ausführen können
  • Mit dem containerd image store verbessert sich die Performance
    • Dazu folgende Einstellung in /etc/docker/daemon.json ergänzen und Docker neu starten 
      {
  "features": {
    "containerd-snapshotter": true
  }
}

Fortgeschrittene Nutzung

Als lokale Standalone-Registry verwenden

  • Unregistry lässt sich ohne zusätzliche Komponenten einfach als lokale Registry betreiben
  • Deployment und Push sind über Docker-Befehle möglich

Benutzerdefinierte SSH-Optionen nutzen

  • Über die SSH-Config-Datei lassen sich zusätzliche Authentifizierungs-, Port- und andere Detailoptionen passend zur Umgebung festlegen

Beiträge und Community

  • Bei Bugs können GitHub-Issues erstellt werden
  • In der Uncloud-Discord-Community können Features, Roadmap und Implementierungsdetails diskutiert werden

Inspiration und referenzierte Open-Source-Projekte

  • Spegel: Inspiration durch die Implementierung einer containerd-basierten P2P-Container-Image-Registry
  • Docker Distribution: Dient als Basis für die eigentliche Registry-Implementierung

Zusammenfassung

  • Unregistry ist ein Tool, mit dem sich Docker-Images einfach und schnell direkt auf entfernte Server übertragen lassen und das den Aufwand für Aufbau und Betrieb einer Registry eliminiert
  • Es bietet starke Vorteile in Szenarien wie Produktionsdeployments, CI/CD und isolierten Netzwerken
  • Besonders geeignet, wenn Server und Administratoren Images unkompliziert und ohne zusätzliche Prozesse verschieben möchten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-19
Hacker-News-Kommentare

  • Aufgrund der Eigenschaften von Servern, ihrer Sicherheitsgrenzen und im Hinblick auf Hardening würde ich nicht empfehlen, Homebrew unter Linux zu verwenden; selbst wenn die Linux-Installation eher wie ein nachträglicher Zusatz angeboten wird, wirkt es weniger wie ein Paketmanager und mehr wie eine Taube auf einem Schachbrett.

  • Ich halte das für eine coole Idee, die gut zu Umgebungen passt, in denen man bereits Push-Deployment-Tooling wie Ansible auf Systemen nutzt; außerdem scheint es sich für Unternehmen, in denen eine Docker-Registry nicht rund um die Uhr unterstützt wird, auch als Hotfix-Deployment-Technik zu eignen. Ich frage mich, ob es auch sauber mit OCI-Tooling (buildah usw.) zusammenspielt oder ob auf beiden Seiten eine vollständige Docker-Installation nötig ist. Ich habe mich noch nicht tief eingearbeitet, plane aber, in dem Bereich zu arbeiten, und hatte bei skopeo das Gefühl, dass ihm in solchen Umgebungen die Fähigkeit fehlt, auf dem Remote-Server eine eigene Registry zu bootstrappen.

    • Auf dem Remote-Server wird containerd benötigt (Docker und Kubernetes nutzen ebenfalls containerd), und auf der Client-Seite reicht alles, was die Registry-API versteht (OCI Distribution Spec: https://github.com/opencontainers/distribution-spec). Unregistry verwendet den offiziellen Docker-Registry-Code für die API-Schicht wieder, sodass es sich ähnlich anfühlt wie die Registry von Docker Hub. Man kann skopeo, crane, regclient, BuildKit usw. mit OCI-Registries verwenden; dafür muss auf dem Remote-Host unregistry direkt laufen. Der Befehl docker pussh automatisiert all diese Abläufe mithilfe des lokalen Docker. Es ist ein Bash-Skript, also lohnt sich ein Blick darauf: https://github.com/psviderski/unregistry/blob/main/docker-pussh. Man kann es auch leicht nach Belieben anpassen.

    • Auf beiden Seiten wird ein Docker-Daemon benötigt; diese Methode verwendet auf clevere Weise SSH, um Layer zwischen den beiden Daemons zu teilen.

  • Ich finde, der Befehl pussh ist leicht zu merken und selbsterklärend und zeigt ein nettes Wortspiel, da er sich nur durch einen Buchstaben vom bestehenden Standardbefehl unterscheidet.

    • „pussh“ ist auch okay, aber für Automatisierung wäre ein klarerer Alias wie „docker push-over-ssh“ vielleicht besser. Jemand, der „pussh“ zum ersten Mal sieht, könnte es für einen Tippfehler halten, und es könnte unnötige Verwirrung entstehen. Ich fände es gut, wenn sowohl eine kurze Version als auch eine Version mit vollständigem Flag unterstützt würden.

    • Es gibt eine scherzhafte Erklärung, dass das zusätzliche „s“ für „sssh“ stehen solle; andere sagen, es sei einfach nur ein Tippfehler.

    • Der Name pussh könnte mit anderen Befehlen kollidieren.

  • So eine Funktion hätte es eigentlich schon lange geben sollen, und ich finde sie sehr cool. Eine Docker-Registry hat zwar ihren eigenen Wert, aber insgesamt ist das alles zu komplex geworden und weit vom Hacker-Mindset entfernt.

    • Da Docker ein VC-finanziertes Unternehmen war, musste es irgendwie Geld verdienen.

  • Das Projekt und der Ansatz sind beeindruckend. Ich war teure Registries leid und habe schon Dinge wie Zot(https://zotregistry.dev) selbst gehostet, aber diese Methode wirkt für einige Anwendungsfälle deutlich einfacher. Ich wünschte, einfache, günstige und nutzungsbasierte private Registry-Services wären weiter verbreitet.

    • Ein Kommentar weist darauf hin, dass das SSL-Zertifikat von zothub.io abgelaufen ist.

  • Ich finde, Docker hätte von Anfang an so funktionieren sollen; eine coole Idee.

    • Ein ähnliches Ergebnis lässt sich auch erreichen, indem man ein Image als Archivdatei speichert, auf den Server überträgt und dort lädt. Zum Beispiel mit docker save -o my-app.tar my-app:latest speichern und mit docker load -i /path/to/my-app.tar laden. In Kombination mit Automatisierungstools wie Ansible kann man damit das, was Unregistry automatisiert, auch selbst umsetzen. Im GitHub-Repo wird allerdings erwähnt, dass beim Save/Load-Ansatz immer das gesamte Image übertragen werden muss und dass die Image-Verwaltung komfortabler ist als die Arbeit mit Archivdateien.

  • Ich freue mich über diese Rückkehr zu Self-Hosting mit solchen Tools und SSH-Tooling und finde das Ergebnis gut gemacht. Ich habe vor, es selbst auszuprobieren.

  • Durch dieses Tool habe ich zum ersten Mal vom Projekt uncloud erfahren, und es wirkt auf mich wie eine Dokku-ähnliche, aber leistungsfähigere Server-Deployment-Lösung, die ich schon lange wollte.

    • Zustimmung zu dem Feedback, dass uncloud gut passt; bei Fragen ist man auf Discord willkommen.

    • Es wird auch https://skateco.github.io/ als Dienst mit einem ähnlichen Ansatz empfohlen.

    • Empfehlung für Portainer: Mit der Portainer Community Edition und dem Portainer-Agenten läuft es auf zwei AWS-EC2-Instanzen gut. Besonders stark ist die Stack-Funktion auf Basis von Docker Compose; auf einer EC2 betreibt der Portainer-Agent Caddy als Container und übernimmt Load-Balancing- und Reverse-Proxy-Funktionen.

  • Eine originelle Idee, allerdings ist dieser Ansatz stark an Service-Deployment gekoppelt, sodass für Deployment und Skalierung, etwa bei Blue-Green-Deployments, zusätzliche Logik nötig ist, die den „Push“ erkennt. Beim Nachdenken darüber wird klar, dass genau diese Rolle in der Architektur von uncloud umgesetzt ist. Letztlich ist es aber ein Trade-off, und wenn man auf einer einzelnen Hetzner-VM Wert auf Einfachheit legt, kann es vollkommen ausreichen, Images lokal zu bauen.

    • Wie immer gibt es überall Trade-offs, und das Beste ist, dass man je nach Situation das passende Werkzeug wählen kann.