My OVH box went down a few weeks ago and refused to get back up. I couldn’t even ssh in. No clue why. On the bright side, I got to use this as an opportunity to learn more about keeping things fail-safe. I’d say “more fail-safe”, but apart from github for my source-code, nothing was backed up.

Restart services on reboot

The first thing I want (Now that the reminder-agent is deployed and live) is for my applications to come back up when the server restarts.

I’ve installed ubuntu on my server, so the “apache2” service came back up without any issues. Yay. My Torquebox server didn’t, though. So I went down the rabbit-hole to figure out how to work with Torquebox on Docker. Its a little bit of a pain. Especially if you start thinking about using torquebox in a cluster. What if you have 3 servers, and docker on each of them, and a torquebox container for each machine? How do you tell each torquebox instance in each docker container about other torqueox instances so that it can do its torquebox magic w.r.t. clustering and all that? What a pain.

Deploy on Torquebox inside Docker

And what happens if you have each TB (torquebox) instance serving more than one application? You should do that, so you don’t have multiple JVMs taking up RAM. But after a few hours I figured that the best option (assuming no clustering) would be to:

• package the application in a KNOB file
• log into the server
• use nsenter to get into the docker container that runs TB
• download the KNOB file
• deploy the KNOB file

This seems rather manual (a.k.a., painful). So for now, while I don’t have to deal with clustering for my toy applications, I’m just going to run TB on the host and make an Upstart file to ensure that TB is started on any reboots that happen.

Another option, if you very much want TB in docker, is to do a mixture of the official JBOSS torquebox image and mguymon’s image. This uses a volume in the docker image to use a deployments directory on the host filesystem so you can save a KNOB file (Or just the YAML descriptor) in that directory and use the TorqueBox deployment markers to manage the server.

This is a very neat idea, but I kept running into permissions issues for the volume. I’ve read that the solution to that is to create a “torquebox” user on the host as well as the docker image with the same UID and GUID. I’m not comfortable with that. We would essentially be placing configuration (make this user) on the host system, and I’d just rather not do that and depend on me remembering to do that with every host system I build. I’m not comfortable with this solution for now

Database on Docker

The good news is that my database is now exclusively on Docker. I found this amazing docker image that depends on Phusion’s baseimage. You set it up, and then you are golden. If you are into PostGIS, use this image instead, that just derives from the straight-postgresql one.

Right now my database container is set with exposed ports on my host machine, since I am not using docker for my applications. But once I figure out a comfortable way to get multiple TB application deployments through a docker container, I should be able to just link the containers together so that I don’t have the database exposed and accessible through the host system. That would be very nice to figure out.

Why Phusion baseimage?

By default, docker will probably restart your containers on reboot. But I read issues occur with application restarts if the application itself shut down before the container did. Phusion uses “runit”, and that just makes sure that your application (Or whatever) will keep running if the container is running. I like that. The docker website suggests setting up init scripts on your host to ensure that applications are running. That brings me back to having configuration on the host. I don’t like that. Hence, I’m just going to stick to Phusion baseimage for all my containers in the foreseeable future.