←back to thread

Show HN: Unregistry – “docker push” directly to servers without a registry

(github.com)
726 points psviderski | 4 comments | 18 Jun 25 23:17 UTC | HN request time: 1.048s | source

I got tired of the push-to-registry/pull-from-registry dance every time I needed to deploy a Docker image.

In certain cases, using a full-fledged external (or even local) registry is annoying overhead. And if you think about it, there's already a form of registry present on any of your Docker-enabled hosts — the Docker's own image storage.

So I built Unregistry [1] that exposes Docker's (containerd) image storage through a standard registry API. It adds a `docker pussh` command that pushes images directly to remote Docker daemons over SSH. It transfers only the missing layers, making it fast and efficient.

  docker pussh myapp:latest user@server
Under the hood, it starts a temporary unregistry container on the remote host, pushes to it through an SSH tunnel, and cleans up when done.

I've built it as a byproduct while working on Uncloud [2], a tool for deploying containers across a network of Docker hosts, and figured it'd be useful as a standalone project.

Would love to hear your thoughts and use cases!

[1]: https://github.com/psviderski/unregistry

[2]: https://github.com/psviderski/uncloud

1. armx40 ◴[19 Jun 25 00:06 UTC] No.44314321[source]▶
How about using docker context. I use that a lot and works nicely.
replies(1): >>44314359 #
2. Snawoot ◴[19 Jun 25 00:14 UTC] No.44314359[source]▶
How do docker contexts help with the transfer of image between hosts?
replies(1): >>44317071 #
3. dobremeno ◴[19 Jun 25 10:00 UTC] No.44317071[source]▶
I assume OP meant something like this, building the image on the remote host directly using a docker context (which is different from a build context)

  docker context create my-awesome-remote-context --docker "host=ssh://user@remote-host"

  docker --context my-awesome-remote-context build . -t my-image:latest
This way you end up with `my-image:latest` on the remote host too. It has the advantage of not transferring the entire image but only transferring the build context. It builds the actual image on the remote host.
replies(1): >>44319556 #
4. revicon ◴[19 Jun 25 15:24 UTC] No.44319556{3}[source]▶
This is exactly what I do, make a context pointing to the remote host, use docker compose build / up to launch it on the remote system.