Phusion Releases Robust Docker Base Image

Minimalism has it’s place, but there is such a thing as an installed system being too bare-bones. Many Docker images are built like they are full Linux installs, but don’t run like they are due to a lack of common daemons running inside the container. To address the issue, Phusion, the Rails company behind Passenger and Ruby Enterprise Edition, has released Baseimage. Baseimage is a Docker image that closer mimics a real Linux environment with proper init, syslog, SSH, and runit daemons.

It has been my experience that application daemons are often far more fragile than the base operating system. This is especially true with init, the daemon in charge of all other daemons, but in some Docker setups the application becomes the first and only running process, so if it stops the entire container stops. Phusion’s Baseimage solves this problem by starting a proper init daemon inside the container:

Baseimage-docker comes with an init process /sbin/my_init that reaps orphaned child processes correctly, and responds to SIGTERM correctly. This way your container won’t become filled with zombie processes, and docker stop will work correctly.

In hindsight, this is obviously the right way to build images. In addition to init, Baseimage also starts syslog-ng, cron, and the new-to-me daemon runit. The runit daemon looks like a great way to start and stop your application inside of a Docker image. I think the use of syslog and cron should be validated for your application, but I can certainly see where they are useful. Phusion doesn’t stop there though, they also start SSH, which is where we part ways. I’ll be investigating Baseimage as part of our overall research into Docker and Linux containers in general, but I question the decision of including and starting SSH.

In a Docker environment, the host operating system is, most likely, already running SSH, so the developer has access. The developer, or sysadmin, can SSH into the host and run lxc-attach to enter the running container, if needed. Running SSH in each container opens more ports into the system, which widens the overall system attack vector. While OpenSSH is reasonably secure (and far, far better than telnet), security researchers have found many vulnerabilities in the daemon in the past, and will likely find more in the future.

However, the bigger issue is encouraging SSH access at all. I subscribe to the concept that if you have to SSH to a server, your automation has failed. Docker encourages a fully automated system of deployment for individual applications-as-containers. If you start to treat each container as an independent server instead of multiple instances of the same application, you open your environment up to unnecessary complication. Of all the configuration changes in the Baseimage Docker image, this is the only one that I can see as being wrong.