Live data from Hacker News

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

github.com

171–178 of 178 posts

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

#171

I've prepared a quick one using reverse port forwarding and a local temp registry. In case anyone finds it useful: #!/bin/bash set -euo pipefail IMAGE_NAME="my-app" IMAGE_TAG="latest" # A temporary Docker registry that runs on your local machine during deployment. LOCAL_REGISTRY="localhost:5000" REMOTE_IMAGE_NAME="${LOCAL_REGISTRY}/${IMAGE_NAME}:${IMAGE_TAG}" REGISTRY_CONTAINER_NAME="temp-deploy-registry" # SSH conne…

Your script is the same idea as https://github.com/mkantor/docker-pushmi-pullyu (which is in the public domain, so feel free to steal).

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

#172

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…

> I'm curious why you implemented your own registry for this Answering my own question: I think it's because you want to avoid the `docker pull` side of the equation (when possible) by having the registry's backing storage be the same as the engine's on the remote host.

Exactly, although my main motivation was to reduce the distinction between docker engine and docker registry. To make it possible for a user to push/pull to the docker daemon as if it was a registry, hence a registry wrapper.

This is a prerequisite for what I want to build for uncloud, a clustering solution I’m developing. I want to make it possible to push an image to a cluster (store it right in the docker on one or multiple machines) and then run it on any machine in the cluster (pull from a machine that has the image if missing locally) eliminating a registry middleman.

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

#173
post #157

Earlier quoted context omitted.

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 wi…

With that sort of setup you'd run `docker pussh` from your build server, not your local machine (really though you'd probably want a non-ephemeral registry, so wouldn't use unregistry at all). Other than "it's convenient and my use case is low-stakes enough for me to not care", I can't think of any reason why one would want to build images on their production servers.

Agreed.

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

#174
post #85

Takes a look at pipeline that builds image in gitlab, pushes to artifactory, triggers deployment that pulls from artifactory and pushes to AWS ECR, then updates deployment template in EKS which pulls from ECR to node and boots pod container. I need this in my life.

Out of curiosity why do you use both Artifactory and ECR? We're currently considering a switch from Artifactory to ECR for cost savings reasons.

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

#175

Earlier quoted context omitted.

> I'm curious why you implemented your own registry for this Answering my own question: I think it's because you want to avoid the `docker pull` side of the equation (when possible) by having the registry's backing storage be the same as the engine's on the remote host.

Exactly, although my main motivation was to reduce the distinction between docker engine and docker registry. To make it possible for a user to push/pull to the docker daemon as if it was a registry, hence a registry wrapper. This is a prerequisite for what I want to build for uncloud, a clustering solution I’m developing. I want to make it possible to push an image to a cluster (store it right in the docker on one o…

Very cool. As others have said: "push/pull to the docker daemon as if it was a registry" is how docker should always have worked.

This is next level but I can imagine distributing resource usage across the cluster by pulling different layers from different peers concurrently.

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

#176

Earlier quoted context omitted.

Do docker-pussh or docker-pushmi-pullyu verify container image signatures and attestations? From "About Docker Content Trust (DCT)" https://docs.docker.com/engine/security/trust/ : > Image consumers can enable DCT to ensure that images they use were signed. If a consumer enables DCT, they can only pull, run, or build with trusted images. export DOCKER_CONTENT_TRUST=1 cosign > verifying containers > verify attestation…

docker-pushmi-pullyu does a vanilla `docker pull`[1] on the remote side, so you should be able to set `DOCKER_CONTENT_TRUST` in the remote environment to get whatever behavior you want (though admittedly I have not tested this). If there's desire for an option to specify `--disable-content-trust` during push and/or pull I'll happily add it. Please file an issue if this is something you want. [1]: https://github.com/m…

Should it be set in both the local and remote envs?

What does it do if there's no signature?

Do images built and signed with podman and cosign work with docker; are the artifact signatures portable across container CLIs docker, nerdctl, and podman?

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

#177

Earlier quoted context omitted.

docker-pushmi-pullyu does a vanilla `docker pull`[1] on the remote side, so you should be able to set `DOCKER_CONTENT_TRUST` in the remote environment to get whatever behavior you want (though admittedly I have not tested this). If there's desire for an option to specify `--disable-content-trust` during push and/or pull I'll happily add it. Please file an issue if this is something you want. [1]: https://github.com/m…

Should it be set in both the local and remote envs? What does it do if there's no signature? Do images built and signed with podman and cosign work with docker; are the artifact signatures portable across container CLIs docker, nerdctl, and podman?

From nerdctl/docs/cosign.md "Container Image Sign and Verify with cosign tool" https://github.com/containerd/nerdctl/blob/main/docs/cosign.... ; handily answering my own question aloud:

Sign the container image while pushing, verify the signature on fetch/pull:

  # Sign the image with Keyless mode
  $ nerdctl push --sign=cosign devopps/hello-world
  
  # Sign the image and store the signature in the registry
  $ nerdctl push --sign=cosign --cosign-key cosign.key devopps/hello-world

  # Verify the image with Keyless mode
  $ nerdctl pull --verify=cosign --certificate-identity=name@example.com --certificate-oidc-issuer=https://accounts.example.com devopps/hello-world


  # You can not verify the image if it is not signed
  $ nerdctl pull --verify=cosign --cosign-key cosign.pub devopps/hello-world-bad

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

#178
Amazing. Our company has to push gigantic docker images to IoT style devices, and we’ve had to maintain an installer script that downloads and stands up a local dummy registry, pushes the image to that, then ssh’s to the remote and pulls from it. When the installer fails, this process is almost always the culprit. Your tool looks like it would be a huge improvement (- although the requirement that the host have the unregistry container is a _slight_ demerit). Nevertheless, I can’t wait to check this out.

I have spent an absolutely bewildering 7 years trying to understand why this huge gap in the docker ecosystem tooling exists. Even if I never use your tool, it’s such a relief to find someone else who sees the problem in clear terms. Even in this very thread you have people who cannot imagine “why you don’t just docker save | docker load”.

It’s also cathartic to see Solomon regretting how fucky the arbitrary distinction between registries and local engines is. I wish it had been easier to see that point discussed out in the open some time in the past 8 years.

It always felt to me as though the shape of the entire docker ecosystem was frozen incredibly fast. I was aware of docker becoming popular in 2017ish. By the time I actually stated to dive in, in 2018 or so, it felt like its design was already beyond question. If you were confused about holes in the story, you had to sift through cargo cult people incapable of conceiving that docker could work any differently than it already did. This created a pervasive gaslighty experience: Maybe I was just Holding It Wrong? Why is everyone else so unperturbed by these holes, I wondered. But it turns out, no, damnit - I was right!

Post reply on HN