Tired of killing Docker containers by having to type in
docker rm <docker_container>? With every dull stroke of keys on the keyboard
you only wish that you could be saving earth from a possible invasion from
hell? Worry no longer! Now you can kill those Docker containers with the
proper tool, a rocket launcher (or BFG, or shotgun, or whatever)!
Stop talking, I want to run this now
Download and extract this binary on the Linux machine running docker:
Start up a few docker containers e.g.,:
Now run the downloaded docker binary:
You should receive output similar to:
Get a VNC Viewer up and running. You could try Chicken of the VNC.
Connect the VNC Viewer to the machine running
dockerdoomd at port 5900. The password is
After a few seconds you will see doom appear:
Now if you want to get the job done quickly enter the cheat
idspispopd and walk through the wall on your right. You should be greeted by your docker containers as little pink monsters. Press
CTRL to fire. If the pistol is not your thing, cheat with
idkfa and press
5 for a nice surprise. Pause the game with
ESC. Feel free to start up and shutdown docker containers in the background while the game is running.
Sounds familiar? This is based of the work done for psdoom. psdoom was used to kill *nix processes.
How does this magic work?
There is several parts at play. Let’s list them:
- The Docker binary, used to start and query Docker containers.
- The DOOM Docker container, running DOOM inside of it, called
dockerdoomd, a daemon that starts the DOOM Docker container, sets everything up and enables the DOOM Docker container to query and stop Docker containers.
- a socket file, enabling communication between DOOM and
- a VNC tcp connection, enabling a connection between DOOM’s X11 session and whatever computer you want it to be displayed on.
The best part of all of this, is that DOOM is running within a container. This allows easier deployment of DOOM to whoever wants to run it. So, not only is this a cool magic trick, but it also uses the awesome features that containers give us.
It’ll probably be best to explain this by drawing it all out.
When you start
dockerdoomd on your Linux host it will download the
DOOM docker image from the public repo. It will start this image as a container
dockerdoom. After starting the container it will open a Unix socket between
itself and the
dockerdoom container. The container will open an X11 VNC
session and wait for connections. DOOM will be started when the user first connects to the
dockerdoom container with VNC. DOOM will then periodically poll
the Unix socket for info on the running docker containers on the host.
dockerdoomd will do a
docker ps execution when it receives a
on the Unix socket. DOOM will spawn monsters for every docker container it
reads in response to a
list request. When you kill a monster in DOOM,
DOOM will send a
kill request to
dockerdoomd using the Unix socket.
dockerdoomd will then do the corresponding
You may ask why the need for the
dockerdoomd daemon and all the Unix socket
communication. A process inside of a Docker container should not be able to talk back to the
host’s docker setup, but the
dockerdoomd daemon is a way of exposing a subset
of docker commands to a specified docker container.
A Docker container having the ability to execute commands or code on the machine hosting the docker container is something I call a “sudo” Docker container. Simply put, I’m giving a docker container more privileges than is expected from a contained environment.
Food for thought
Is their value in having a “sudo” Docker container in real world production environments?
I think so. When maintaining a machine with many containers or VMs you tend to run some control software on the host. An annoyance is that the control software normally doesn’t use containers or VM’s, which means you can’t use the benefits of containers or VM’s.
Having your control software talk from a container to a host via a well defined API can help maintainers of the software understand what dependencies need to be managed and tested when modifying the software.
Of course there will still be some software running natively on the host, but hopefully they
can be written to be as small as possible acting only as proxies or adapters (e.g.
Running X11 or graphical software within docker containers.
I’m definitely not the first to do this. It’s popular to run Firefox in a container to add an extra sand box. I have not packaged or built a game for Linux before, but I’m sure there is many who have run into problems packaging games (or other software) and dealing with the various distro’s and their quirks. Containers and streaming technology (naively VNC) gives one possible solution to this problem.
Thanks to orsonteodoro for still keeping psdoom up to date. I’ve based my changes off of his version.
DOOM and related logos are registered trademarks of id Software.