This is a quick followup to the strange stunnel behavior I was seeing that I wrote about previously.
After discussing the issue with a colleague, we came up with two different solutions to this problem with stunnel writing to /dev/console inside a docker container.
Indirect route with docker exec
In his method, we invoke the container and detach it. This causes /dev/console to be associated with the detached session.
:; docker run -d -it -v $HOME/.xe:/root/.xe xenapi 48b1bc76119581437b32f34edf1aa864a6c9f2f986f98f3b0d2f22a855a28a34 :; docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 48b1bc761195 xenapi "/bin/bash" 3 seconds ago Up 2 seconds lonely_spence
Next, we exec into the running container. This does not allocate a tty.
:; docker exec -it lonely_spence /bin/bash [root@48b1bc761195 /]# tty not a tty
Now, when we run the xe command, the output is directed to /dev/console, but in the detached container so we never see the output.
[root@48b1bc761195 /]# xe host-list uuid ( RO) : ed97198a-3f44-4d7f-9ee5-d9727c162390 name-label ( RW): vmhost name-description ( RW): Default install [root@48b1bc761195 /]#
This method is useful to know, but the multiple steps make this a killer to deal with. I’d hate having to do multiple commands just to get into a container to bypass the /dev/console output.
Direct route with docker run
In my method, we tie /dev/log of the container host to /dev/log of the container via a bind mount.
:; docker run -t -i -v $HOME/.xe:/root/.xe -v /dev/log:/dev/log xenapi /bin/bash
[root@09cad64371cb /]# xe host-list
uuid ( RO) : ed97198a-3f44-4d7f-9ee5-d9727c162390
name-label ( RW): vmhost
name-description ( RW): Default install
This allows the container to write to a valid /dev/log so we never get the output sent to /dev/console, muddying up our output. This also makes it much nicer when invoking scripted instances of xe from within the container.
A general method for fixing stunnel behavior?
Another method that I came across when debugging this was starting a separate container to manage a syslog instance. You would expose the /dev/log from this container to all your other containers that may need to write there. This would isolate you from writing into the container host’s logging and co-mingling the data, but it would have been overkill for what I was attempting.
For me, the direct route for fixing the stunnel behavior was the most straight forward and simplest path.
