4 ms·

Several weeks ago when baseimage-docker was released (from the article "Your Docker image might be broken without you knowing it", http://phusion.github.io/base

Several weeks ago when baseimage-docker was released (from the article "Your Docker image might be broken without you knowing it", http://phusion.github.io/baseimage-docker/ http://phusion.github.io/baseimage-docker/), many people pointed out that it shouldn't use SSH, but lxc-attach instead. I pointed out that Docker might not use LXC in the future, but people insisted on lxc-attach. Now, Docker is no longer LXC only. I guess the use of SSH - as a means to login to the container for one-off debugging, inspection and administrative work - is still justified.

shykes 13y ago
There is a pull request underway which allows injecting new processes into an existing container using the public Docker API. That could be implemented by lxc-attach in the lxc driver, and by calling setns(2) natively in libcontainer. That should offer a robust alternative to ssh.
- FooBarWidget 13y ago
  That is great to hear. Will it also be available as a 'docker' subcommand? The unavailability of such a subcommand is a minor pain right now.
  - shykes 13y ago
    Yes, probably as docker exec. While we're at it we will also fix the "pid 1" problem described in the phusion blog post (I would argue it's the most useful and constructive contribution in that blog post). Specifically, when a process runs as pid=1, it can't be killed by SIGKILL. It can only be affected by signals it explicitly chooses to handle. This is enforced by the kernel to prevent /sbin/init from being accidentally killed. And it is enforced in all namespaces, so that /sbin/init can be run inside a container and behave the usual way. Unfortunately this means that the same rules apply to a regular app (say, a python script) when it runs as pid 1, even though it is not programmed to handle these rules. In short, regular applications don't expect to be pid 1, and generally speaking they shouldn't. The future version of the libcontainer and lxc drivers should both fix that.
philips 13y ago
There is a tool called nsenter which is part of util-linux which can be used to enter the namespace of another PID. You can find the manpage here: http://man7.org/linux/man-pages/man1/nsenter.1.html http://man7.org/linux/man-pages/man1/nsenter.1.html This can be used for docker, lxc, libvirt-lxc or nspawn.
- FooBarWidget 13y ago
  That only works for the Docker backends that are based on Linux namespaces. What about backends like OpenVZ or FreeBSD jails? Even if I limit the scope to Linux namespaces, for arbitrary shell commands to work properly, I have to know exactly which namespaces Docker use, which may be version-specific or configuration-specific.
crosbymichael 13y ago
There is also a little tool in libcontainer that I use for testing and prototyping called nsinit. You can build and use it to spawn processes inside existing containers. https://asciinema.org/a/8090 https://asciinema.org/a/8090 Like shykes said, this functionality should make it into docker soon.

shykes 13y ago

There is a pull request underway which allows injecting new processes into an existing container using the public Docker API. That could be implemented by lxc-attach in the lxc driver, and by calling setns(2) natively in libcontainer. That should offer a robust alternative to ssh.

FooBarWidget 13y ago
That is great to hear. Will it also be available as a 'docker' subcommand? The unavailability of such a subcommand is a minor pain right now.
- shykes 13y ago
  Yes, probably as docker exec. While we're at it we will also fix the "pid 1" problem described in the phusion blog post (I would argue it's the most useful and constructive contribution in that blog post). Specifically, when a process runs as pid=1, it can't be killed by SIGKILL. It can only be affected by signals it explicitly chooses to handle. This is enforced by the kernel to prevent /sbin/init from being accidentally killed. And it is enforced in all namespaces, so that /sbin/init can be run inside a container and behave the usual way. Unfortunately this means that the same rules apply to a regular app (say, a python script) when it runs as pid 1, even though it is not programmed to handle these rules. In short, regular applications don't expect to be pid 1, and generally speaking they shouldn't. The future version of the libcontainer and lxc drivers should both fix that.

philips 13y ago

There is a tool called nsenter which is part of util-linux which can be used to enter the namespace of another PID. You can find the manpage here: http://man7.org/linux/man-pages/man1/nsenter.1.html http://man7.org/linux/man-pages/man1/nsenter.1.html This can be used for docker, lxc, libvirt-lxc or nspawn.

FooBarWidget 13y ago
That only works for the Docker backends that are based on Linux namespaces. What about backends like OpenVZ or FreeBSD jails? Even if I limit the scope to Linux namespaces, for arbitrary shell commands to work properly, I have to know exactly which namespaces Docker use, which may be version-specific or configuration-specific.

crosbymichael 13y ago

There is also a little tool in libcontainer that I use for testing and prototyping called nsinit. You can build and use it to spawn processes inside existing containers. https://asciinema.org/a/8090 https://asciinema.org/a/8090 Like shykes said, this functionality should make it into docker soon.