Why local-to-remote push instead of remote-to-local pull?

[taylor-sb]

Unregistry looks really useful and we're evaluating it for peer-to-peer image pushing.

I'm trying to understand a Chesterton's Fence in unregistry's design.

Why does docker pussh start a registry server on the remote and then push to it? Why not start the registry server locally then have the remote pull from the registry? Then the remote wouldn't need to have the unregistry container. 

We often push to devices over a LAN, with no internet, and getting the unregistry image on each remote host is an inconvenience.

Here is a rough example of how a remote-to-local pull would work:
(assumes Docker is configured with containerd image store)

# RUN LOCALLY

# Run unregistry
docker run -p 127.0.0.1:5000:5000 \
  -v /run/containerd/containerd.sock:/run/containerd/containerd.sock \
  --userns=host --user root:root \
  ghcr.io/psviderski/unregistry:latest

# Pull some random image as a test
docker pull ubuntu:latest
docker tag ubuntu:latest myimage:latest

# Open reverse tunnel
ssh -R 5000:localhost:5000 vm-localhost  # vm-localhost is an SSH config for a VM on my machine in a NAT


# RUN ON REMOTE

# Pull the image
docker pull localhost:5000/myimage:latest

EDIT: removed the intermediate step of pushing into the local registry first

[taylor-sb]

docker-pushmi-pullyu took this approach, but without the convenience of centralizing around one image store like unregistry does.

[psviderski]

We discussed this briefly in the comments on HN with the author of docker-pushmi-pullyu: https://news.ycombinator.com/item?id=44324834

In a nutshell, there is too much variability on the local system (macOS Docker/Rancher Desktop, Colima, Orbstack, Linux) compared to the remote one (typically Docker Engine on Linux) to be able to create a generic solution. If you know your use case and you don't need to cater for any other, there is nothing wrong about developing your own solution. It will likely be a much shorter script (you've already written 80% of it above) than our current docker-pussh one trying to handle all the possible edge cases.

The other reason is I was keeping the uncloud use case in my mind while I was developing it. I'm planning to run unregistry as part of uncloudd daemon on every machine in the cluster to be able to easily distribute images in the cluster. You will be able to push an image from the local machine to any machine in the cluster and other machines will be able to pull it from that machine over the cluster private network. Perhaps I was already biased toward that model which influenced the design of docker-pussh.

Note there is at least one more approach which I'd consider going with if I were redoing everything from scratch now. Still use the push model but instead of running unregistry container on the remote machine, you can run it locally and forward the containerd.sock from the remote machine to your local machine and bind mount to the unregistry container. But I suspect there will be permission issues we could workaround with the current approach. Namely, the ssh user could have access to the docker socket but not the containerd socket. Also, I'm not sure if local socket binding works consistently in Docker Desktop/Colima/Orbstack on macOS.

[taylor-sb]

Ah, I see. I didn't consider the variability in the local system. It would indeed be difficult to hook in to every OS's implementation of the image store.