Live data from Hacker News

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

github.com

151–160 of 178 posts

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

#151

Earlier quoted context omitted.

Seems like it makes more sense to build on the build machine, and then just copy images out to PROD servers. Having source code on PROD servers is generally considered bad practice.

The source code does not get to the filesystem on the prod server. It is sent to the Docker daemon when it builds the image. After the build ends, there's only the image on the prod server. I am now convinced that this is a hidden docker feature that too many people aren't aware of and do not understand.

Yeah, I definitely didn't understand that! Thanks for explaining. I've bookmarked this thread, because there's several commands that look more powerful and clean than what I'm currently doing which is to "docker save" to TAR, copy the TAR up to prod and then "docker load".

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

#152
post #33

Earlier quoted context omitted.

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.

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

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.

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

#153
post #152

Earlier quoted context omitted.

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

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.

No, the second one (docker-pushmi-pullyu) runs the registry on the build host.

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

#154

It's very silly that Docker didn't work this way to start with. Thank you, it looks cool!

You can already achieve the same thing by making your image into an archive, pushing it to your server, and then running it from the archive on your server. Saving as archive looks like this: `docker save -o may-app.tar my-app:latest` And loading it looks like this: `docker load -i /path/to/my-app.tar` Using a tool like ansible, you can achieve easily what "Unregistry" is doing automatically. According to the github…

If you read the README, you'll see that replacing the "save | upload | load" workflow is the whole point of this, to drastically reduce the amount of data to upload by only sending new layers instead of everything, and you can use this inside your ansible setup to speed it up.

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

#155

I always just use "docker save" to generate a TAR file, then copy the TAR file to the server, and then run "docker load" (on the server) to install the TAR file on the target machine.

See the README, this results in only changed layers being sent instead of _everything_ which can save a lot of time.

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

#156

I always just use "docker save" to generate a TAR file, then copy the TAR file to the server, and then run "docker load" (on the server) to install the TAR file on the target machine.

See the README, this results in only changed layers being sent instead of _everything_ which can save a lot of time.

I'll do that. Thank you.

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

#157
post #129

Earlier quoted context omitted.

This is probably an anti-feature in most contexts.

The ability to push a verified artifact is an anti-feature in most contexts? How so?

It is fine if you are just working by yourself on non-prod things and you’re happy with that.

But if you are working with others on things that matter, then you’ll find you want your images to have been published from a central, documented location, where it is verified what tests they passed, the version of the CI pipeline, the environment itself, and what revision they were built on. And the image will be tagged with this information, and your coworkers and you will know exactly where to look to get this info when needed.

This is incompatible with pushing an image from your local dev environment.

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

#158
post #152

Earlier quoted context omitted.

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.

No, the second one (docker-pushmi-pullyu) runs the registry on the build host.

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.

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

#159
post #150

Docker creator here. I love this. In my opinion the ideal design would have been: 1. No distinction between docker engine and docker registry. Just a single server that can store, transfer and run containers as needed. It would have been a much more robust building block, and would have avoided the regrettable drift between how the engine & registry store images. 2. push-to-cluster deployment. Every production cluste…

Hey Solomon, thank you for sharing your thoughts, love your work!

1. Yeah agreed, it's a bit of a mess that we have at least three different file system layouts for images and two image stores in the engine. I believe it's still not too late for Docker to achieve what you described without breaking the current model. Not sure if they care though, they're having hard times

2. Hm, push-to-cluster deployment sounds clever. I'm definitely thinking about a distributed image store, e.g. embedding unregistry in every node so that they can pull and share images between each other. But triggering a deployment on push is something I need to think through. Thanks for the idea!

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

#160

I naively sent the Docker developers a PR[1] to add this functionality into mainline Docker back in 2015. I was rapidly redirected into helping out in other areas - not having to use a registry undermined their business model too much I guess. [1]: https://github.com/richardcrichardc/docker2docker

You're the OG! Hats off, mate.

It's a bummer docker still doesn't have an API to explore image layers. I guess their plans to eventually transition to containerd image store as the default. Once we have containerd image store both locally and remotely we will finally be able to do what you've done without the registry wrapper.

Post reply on HN