131–140 of 178 posts
Earlier quoted context omitted.
Indeed so! Because it's art, not engineering. The engineering approach would require a recognizably distinct command, eliminating the possibility of such a pun.
I used to have an alias em=mg, because mg(1) is a small Emacs, so "em" seemed like a fun name for a command. Until one day I made that typo.
Earlier quoted context omitted.
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 i…
Earlier quoted context omitted.
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.
Nice. And the `pussh` command definitely deserves the distinction of one of the most elegant puns: easy to remember, self-explanatory, and just one letter away from its sister standard command.
It's fine, but it wouldn't hurt to have a more formal alias like `docker push-over-ssh`. EDIT: why I think it's important because on automations that are developed collaboratively, "pussh" could be seen as a typo by someone unfamiliar with the feature and cause unnecessary confusion, whereas "push-over-ssh" is clearly deliberate. Think of them maybe as short-hand/full flags.
Nice. And the `pussh` command definitely deserves the distinction of one of the most elegant puns: easy to remember, self-explanatory, and just one letter away from its sister standard command.
> The extra 's' is for 'sssh' > What's that extra 's' for? > That's a typo
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…
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
/? difference between docker content trust dct and cosign: https://www.google.com/search?q=difference+between+docker+co...
Earlier quoted context omitted.
I used to have an alias em=mg, because mg(1) is a small Emacs, so "em" seemed like a fun name for a command. Until one day I made that typo.
I'm a fan of installing sl(1), the terminal steam locomotive. I mistype it every couple months and it always gives me a laugh. https://github.com/mtoyoda/sl
THANK you. Can you do the same for kubernetes somehow?
Also have a look at https://spegel.dev/, it's basically a daemonset running in your k8s cluster that implements a (mirror) registry using locally cached images and peer-to-peer communication.
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…
But if we're talking about hosts that run production-like workloads, using them to perform potentially cpu-/io-intensive build processes might be undesirable. A dedicated build host and context can help mitigate this, but then you again face the challenge of transferring the built images to the production machine, that's where the unregistry approach should help.