Clienții Docker sau Podman care rulează pe MacOS/Windows pot folosi un server la distanță pentru a construi/a rula containere?

Cu MacOS și Windows ca clienți și aș dori să am o adresă în rețeaua mea (locală sau publică) să gestionez pașii de construire a containerului și să rulez containerul.

Deci, când rulez ceva de genul următor, se execută pe mașina mea de la distanță, dar pare să ruleze local

docker build .
docker run -v .:/app -p 9000:9000 foo:latest

Speranța mea este că pot folosi un laptop asemănător unui client subțire pentru a-mi scrie codul în timp ce codul se compilează și se execută pe telecomandă - permițându-mi să profit de un spațiu de stocare mai mare pentru imaginile stocate în cache, calcul mai rapid, partajarea puterii de procesare, astfel încât îmi pot centraliza costurile hardware pentru un efect maxim.

De asemenea, când mă întorc inevitabil la birou, pot descărca munca pe desktop stând acasă în timp ce folosesc un laptop ușor/portabil la birou.

Nu-mi pasă de interfața grafică pentru desktop și nu mă deranjează dacă este Podman sau Docker.

Este posibilă o astfel de configurare sau este mai bine să folosesc ssh, tunelare porturi și folosirea unei implementări fusible ssh-fs?

Straight from the command line, you can do the following with Docker:

DOCKER_HOST=ssh://user@host docker build -t image:tag .

And to save a bit of typing, you can set a context to save the remote host:

docker context create remote --docker "host=ssh://user@host"

and then use that remote context with:

docker -c remote build -t image:tag .

and if you want to run all of the commands with that context, then:

# switch to the remote context for all future commands
docker context use remote
# and to revert back to the default local context
docker context use default

This works well with a build, because the build context is sent to that remote server, and so there are no local filesystem mounts.

However, once you go to run the container, things get more complicated. All of the listening ports will be on the remote host, and volume mounts will be on the remote host filesystem. If you need these capabilities, then tunneling ports and ssh-fs may be the better option. The other option that comes to mind is remote plugins in the IDE that make all code changes on the remote host over ssh so development feels like it's local even when it isn't.