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…
Show HN: Unregistry – “docker push” directly to servers without a registry
171–178 of 178 posts
Re: Show HN: Unregistry – “docker push” directly to servers without a registry
#172Functionality-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.
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
#173Earlier 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.
Re: Show HN: Unregistry – “docker push” directly to servers without a registry
#174Takes 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.
Re: Show HN: Unregistry – “docker push” directly to servers without a registry
#175Earlier 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…
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
#176Earlier 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…
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
#177Earlier 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?
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-badRe: Show HN: Unregistry – “docker push” directly to servers without a registry
#178I 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!