Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

121–130 of 178 posts

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

#121

Post by revicon »

dobremeno wrote: post #95
Snawoot wrote: post #14

Earlier quoted context omitted.

How do docker contexts help with the transfer of image between hosts?

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…

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.

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

#122

Post by matt_kantor »

matt_kantor wrote: post #117

Functionality-wise this is a lot like docker-pushmi-pullyu[1] (which I wrote), except docker-pushmi-pullyu is a single relatively-simple shell script, and uses the official registry image[2] rather than a custom server implementation. @psviderski I'm curious why you implemented your own registry for this, was it just to keep the image as small as possible? [1]: https://github.com/mkantor/docker-pushmi-pullyu [2]: htt…

After taking a closer look it seems the main conceptual difference between unregistry/docker-pussh and docker-pushmi-pullyu is that the former runs the temporary registry on the remote host, while the latter runs it locally. Although in both cases this is not something users should typically have to care about.

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

#123

Post by christiangenco »

rudasn wrote: post #22
dzonga wrote: post #8

this is nice, hopefully DHH and the folks working on Kamal adopt this. the whole reason I didn't end up using kamal was the 'need' a docker registry thing. when I can easily push a dockerfile / compose to my vps build an image there and restart to deploy via a make command

Build the image on the deployment server? Why not build somewhere else once and save time during deployments? I'm most familiar with on-prem deployments and quickly realised that it's much faster to build once, push to registry (eg github) and docker compose pull during deployments.

I think the idea with unregistry is that you're still building somewhere else once but then instead of pushing everything to a registry once you push your unique layers directly to each server you're deploying.

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

#124

Post by revicon »

Is this different from using a remote docker context?

My workflow in my homelab is to create a remote docker context like this...

(from my local development machine)

> docker context create mylinuxserver --docker "host=ssh://revicon@192.168.50.70"

Then I can do...

> docker context use mylinuxserver

> docker compose build

> docker compose up -d

And all the images contained in my docker-compose.yml file are built, deployed and running in my remote linux server.

No fuss, registry, no extra applications needed.

Way simpler than using docker swarm, Kubernetes or whatever. Maybe I'm missing something that @psviderski is doing that I don't get with my method.

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

#125

Post by matt_kantor »

revicon wrote: post #124

Is this different from using a remote docker context? My workflow in my homelab is to create a remote docker context like this... (from my local development machine) > docker context create mylinuxserver --docker "host=ssh://revicon@192.168.50.70" Then I can do... > docker context use mylinuxserver > docker compose build > docker compose up -d And all the images contained in my docker-compose.yml file are built, depl…

Assuming I understand your workflow, one difference is that unregistry works with already-built images. They aren't built on the remote host, just pushed there. This means you can be confident that the image on your server is exactly the same as the one you tested locally, and also will typically be much faster (assuming well-structured Dockerfiles with small layers, etc).

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

#126

Post by dreis_sw »

metadat wrote: post #27

This should have always been a thing! Brilliant. Docker registries have their place but are overall over-engineered and an antithesis to the hacker mentality.

I recommend using GitHub's registry, ghcr.io, with GitHub Actions.

I invested just 20 minutes to setup a .yaml workflow that builds and pushes an image to my private registry on ghcr.io, and 5 minutes to allow my server to pull images from it.

It's a very practical setup.

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

#127

Post by pinoy420 »

nine_k wrote: post #49
someothherguyy wrote: post #41

Earlier quoted context omitted.

and prone to collision!

Indeed so! Because it's art, not engineering. The engineering approach would require a recognizably distinct command, eliminating the possibility of such a pun.

[dead]

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

#128

Post by jdsleppy »

kosolam wrote: post #104
jdsleppy wrote: post #100

I've been very happy doing this: DOCKER_HOST=“ssh://user@remotehost” docker-compose up -d It works with plain docker, too. Another user is getting at the same idea when they mention docker contexts, which is just a different way to set the variable. Did you know about this approach? In the snippet above, the image will be built on the remote machine and then run. The context (files) are sent over the wire as needed.…

This approach is akin to the prod server pulling an image from a registry. The op method is push based.

No, in my example the docker-compose.yml would exist alongside your application's source code and you can use the `build` directive https://docs.docker.com/reference/compose-file/services/#bui... to instruct the remote host (Hetzner VPS, or whatever else) to build the image. That image does not go to an external registry, but is used internal to that remote host.

For 3rd party images like `postgres`, etc., then yes it will pull those from DockerHub or the registry you configure.

But in this method you push the source code, not a finished docker image, to the server.

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

#129

Post by pbh101 »

matt_kantor wrote: post #125
revicon wrote: post #124

Is this different from using a remote docker context? My workflow in my homelab is to create a remote docker context like this... (from my local development machine) > docker context create mylinuxserver --docker "host=ssh://revicon@192.168.50.70" Then I can do... > docker context use mylinuxserver > docker compose build > docker compose up -d And all the images contained in my docker-compose.yml file are built, depl…

Assuming I understand your workflow, one difference is that unregistry works with already-built images. They aren't built on the remote host, just pushed there. This means you can be confident that the image on your server is exactly the same as the one you tested locally, and also will typically be much faster (assuming well-structured Dockerfiles with small layers, etc).

This is probably an anti-feature in most contexts.

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

#130

Post by lxe »

nodesocket wrote: post #18
lxe wrote: post #15

Ooh this made me discover uncloud. Sounds like exactly what I was looking for. I wanted something like dokku but beefier for a sideproject server setup.

A recommendation for Portainer if you haven't used or considered it. I'm running two EC2 instances on AWS using portainer community edition and portainer agent and works really well. The stack feature (which is just docker compose) is also super nice. One EC2 instance; running Portainer agent runs Caddy in a container which acts as the load balancer and reverse proxy.

I'm actually running portainer for my homelab setup hosting things like octoprint and omada controller etc.
Post reply on HN