I used a lot ansible_connection=chroot to configure a chroot on some of my hosts and I think this would be a nice feature if we were capable of launching an ansible playbook to configure a docker, but from the host machine and without ssh (ansible_connection=docker ?).
Not a comment about the proposed functionality itself -- I'll leave
that to the experienced developers.
I do, however, feel that the assertion "docker ssh considered evil"
should be challenged.
It's interesting how many opinions there are about Docker best
practices -- and how comparatively few of them come directly from the
nice folks at Docker.
Here's a direct quote from Solomon Hykes, founder of Docker:
"Different people use Docker for different purposes, that is normal
and a fundamental goal of Docker. I do have criticism for your
communication around that base image, starting with the link-bait blog
post 'you're using Docker wrong'. Your message is that anybody not
using Docker your way (full-blown init process, sshd, embedded syslog)
is doing it wrong. That is not only incorrect, it contradicts Docker's
philosophy of allowing and supporting more than one usage pattern."
There is also a connection=jail, so I think a docker or lxc connection plugin make sense.
As for ssh on docker being evil, it is only if you are using docker as a ‘run single immutable app’ container, for those using docker like a openvz/bsd jails lightweight VM it makes sense to run ssh.
One caveat is of course we have historically not implemented a “manage a Docker connection with SSH” kind of multi-hop connection type.
For the same reason, we don’t support management of remote jails, and the jail connection type remains only usable locally - and for that reason, we don’t really promote it.
Generally I think Docker images are best used immutably, and most use cases will use ansible to build the image and then deploy it, but yes, there are valid reasons to want to SSH inside one.
I’d venture though that almost no one sets this up, as then you have to do the supervisor thing to run SSH because of the single-entrypoint problem.