You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If podman is it be considered a drop-in replacement for docker cli, we also need to provide a way to run commands remotely.
Docker cli and also its python library (used by Ansible) is using DOCKER_HOST=tcp://host:port or even DOCKER_HOST=ssh://host starting with version 18.09 which is quite handy for doing operations remotely, especially from laptops where you may not want to run heavy tasks on your own host (or where your localhost platform has some other limitations).
If we make this work we may be able to mitigate challenges like #1840 . When remoting all/most commands could be send to the remote machine so the local client could be very thin.
I would personally would not mind even if the only supported protocol would be ssh as this would be very easy and safe to use.
If implemented I expect the two commands to have the same result:
This is quite important because it would allow use to implement fallback logics like below were we use whatever tool is available (useful for testing code locally, tox,...)
TOOL=`which podman docker | head -1`
$TOOL pull centos:7
....
The text was updated successfully, but these errors were encountered:
We're working on this at present (@baude and @jwhonce are working on porting Podman's CLI to allow it to be used with the Varlink API as well, allowing calls to remote systems)
If podman is it be considered a drop-in replacement for docker cli, we also need to provide a way to run commands remotely.
Docker cli and also its python library (used by Ansible) is using
DOCKER_HOST=tcp://host:port
or evenDOCKER_HOST=ssh://host
starting with version 18.09 which is quite handy for doing operations remotely, especially from laptops where you may not want to run heavy tasks on your own host (or where your localhost platform has some other limitations).If we make this work we may be able to mitigate challenges like #1840 . When remoting all/most commands could be send to the remote machine so the local client could be very thin.
I would personally would not mind even if the only supported protocol would be ssh as this would be very easy and safe to use.
If implemented I expect the two commands to have the same result:
This is quite important because it would allow use to implement fallback logics like below were we use whatever tool is available (useful for testing code locally, tox,...)
The text was updated successfully, but these errors were encountered: