←back to thread

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

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

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

Show context
remram ◴[19 Jun 25 00:43 UTC] No.44314464[source]▶
Does it start a unregistry container on the remote/receiving end or the local/sending end? I think that runs remotely. I wonder if you could go the other way instead?
replies(2): >>44314647 #>>44316429 #
1. selcuka ◴[19 Jun 25 01:26 UTC] No.44314647[source]▶
You mean ssh'ing into the remote server, then pulling image from local? That would require your local host to be accessible from the remote host, or setting up some kind of ssh tunneling.
replies(2): >>44314962 #>>44319492 #
2. mdaniel ◴[19 Jun 25 02:40 UTC] No.44314962[source]▶
`ssh -R` and `ssh -L` are amazing, and I just learned that -L and -R both support unix sockets on either end and also unix socket to tcp socket https://manpages.ubuntu.com/manpages/noble/man1/ssh.1.html#:...

I would presume it's something akin to $(ssh -L /var/run/docker.sock:/tmp/d.sock sh -c 'docker -H unix:///tmp/d.sock save | docker load') type deal

3. matt_kantor ◴[19 Jun 25 15:19 UTC] No.44319492[source]▶
This is what docker-pushmi-pullyu[1] does, using `ssh -R` as suggested by a sibling comment.

[1]: https://github.com/mkantor/docker-pushmi-pullyu

replies(2): >>44323802 #>>44324834 #
4. remram ◴[20 Jun 25 00:37 UTC] No.44323802[source]▶
That's also what the submitted tool does, I want to do the same thing just in the reverse direction. I just don't want to start extra containers on the prod machine.
replies(1): >>44323921 #
5. selcuka ◴[20 Jun 25 01:10 UTC] No.44323921{3}[source]▶
No, the second one (docker-pushmi-pullyu) runs the registry on the build host.
replies(1): >>44324488 #
6. remram ◴[20 Jun 25 03:33 UTC] No.44324488{4}[source]▶
I meant to reply to you, whoops.

docker-pushmi-pullyu does an extra copy from build host to a registry, so it is just the standard workflow.

I think Spegel does what I want (= serve images from the local cache as a registry), I might be able to build from that. It is meant to be integrated with Kubernetes though, making a simple transfer tool probably requires some adaptation.

7. psviderski ◴[20 Jun 25 04:51 UTC] No.44324834[source]▶
The problem with running a registry locally is that Docker doesn't provide an API to get individual image layers to be able to build a registry API on top. You have to hook into the containerd Docker uses under the hood. You can't do this locally in many cases, for example, on macOS the VM running Docker Desktop doesn't expose the containerd socket. I guess the workaround you implemented in docker-pushmi-pullyu is an extra copy to the registry which is a bummer.
replies(1): >>44328355 #
8. matt_kantor ◴[20 Jun 25 15:00 UTC] No.44328355{3}[source]▶
Yeah, a few years ago I remember looking into whether I could expose image layers from the engine as a volume to mount directly into the registry, but at least at the time it seemed complex, and when I write tools like this simplicity is a primary goal.

As a mitigation docker-pushmi-pullyu caches pushed layers between runs[1]. More often than not I'm only changing upper layers of previously-pushed images, so this helps a lot. Also, since everything happens locally the push phase is typically quite fast even with cache misses (especially on an SSD), especially compared to the pull phase which is usually going over the internet (or another network).

[1]: https://github.com/mkantor/docker-pushmi-pullyu/pull/19/file...