111–120 of 178 posts
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.…
Considering the nature of servers, security boundaries and hardening, > Linux via Homebrew Please don't encourage this on Linux. It happens to offer a Linux setup as an afterthought but behaves like a pigeon on a chessboard rather than a package manager.
I simply use "docker save : | ssh docker load"
This is a cool idea that seems like it would integrate well with systems already using push deploy tooling like Ansible. It also seems like it would work as a good hotfix deployment mechanism at companies where the Docker registry doesn't have 24/7 support. Does it integrate cleanly with OCI tooling like buildah etc, or if you need to have a full-blown Docker install on both ends? I haven't dug deeply into this yet b…
Being able to run a registry server over the local containerd image store is great.
The details of how some other machine's containerd gets images from that registry to me is a separate concern. docker pull will work just fine provided it is given a suitable registry url and credentials. There are many ways to provide the necessary network connectivity and credentials sharing and so I don't want that aspect to be baked in.
Very slick though.
Earlier quoted context omitted.
Downside: it's Nix. I tried it, but I have not been able to easily replicate our Homebrew env. We have a private repo with pre-compiled binaries, and a simple Homebrew formula that downloads the utilities and installs them. Compiling the binaries requires quite a few tools (C++, sigh). I got stuck at the point where I needed to use a private repo in Nix.
> We have a private repo with pre-compiled binaries, and a simple Homebrew formula that downloads the utilities and installs them. Perfectly doable with Nix. Ignore the purists and do the hackiest way that works. It's too bad that tutorials get lost on concepts (which are useful to know but a real turn down) instead of focusing on some hands-on practical how-to. This should about do it and is really not that differen…
> Instantly sounds like a whole reason to use nix and capture those tools as part of the dependency set.
It's tempting, and I tried that, but ran away crying. We're using Docker images instead for now.
We are also using direnv that transparently execs commands inside Docker containers, this works surprisingly well.
@psviderski I'm curious why you implemented your own registry for this, was it just to keep the image as small as possible?
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.
Until one day I made that typo.
Does it start a unregistry container on the remote/receiving end or the local/sending end? I think that runs remotely. I wonder if you could go the other way instead?
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.
As a long ago fan of chef-solo, this is really cool. Currently, I need to use a docker registry for my Kamal deployments. Are you familiar with it and if this removes the 3rd party dependency?
Yep, I'm familiar with Kamal and it actually inspired me to build Uncloud using similar principles but with more cluster-like capabilities. I built Unregistry for Uncloud but I belive Kamal could also benefit from using it.