Well, I think so anyway. But, I’m coming at Docker as a System Administrator, having used OpenVZ in production before, and seen the benefits of portable, containerized, vm-like mini-systems.
Putting ONLY, EVER, ONE app in a container, and letting the container itself be a static thing has its advantages. With Docker, you can do file and volume mounts for application configuration and var directories. This way you don’t depend on the container holding any of the application configuration or logging or data. The container can be a static default application. And so, updates to the application are just new “docker pull” requests. That is pretty nice.
But, there are valid use cases for Fat docker containers. Specifically, for fat applications – or applications that are tightly integrated with other applications, have a lot of dependencies that might need customization, etc.. Consider an application like Nagios that needs some of these things:
- specific versions of perl or php
- possibly a specific mail server configuration to send email
- a variety of scripting support python/perl/php/expect available
- various other fat things: GD, httpd, rrdtool, net-snmp tools, pnp4nagios +
This is a good case for a Fat Docker container. Using Docker with a simple init script like Yelp’s dumb-init lets you run multiple applications inside a Docker container, and interact with them from a shell within the container. Docker works much like OpenVZ if used this way. Containers can still be run, committed, pushed, pulled, exported, and imported too, of course.
If you choose to store a lot of data inside a container, it can grow quite large. Also, every “docker commit” results in a docker image layer, so an occasional docker export and docker import is probably a good idea, to “flatten” the docker image.
And, one more note on security. By default Docker lets all external IPs access any ports that are exposed on the host. After wrestling with iptables for a while, I found this post to help me solve that problem.
The benefits of a fat docker container:
- Easy to move the application to another host, since it’s all in one container/tarball, and all dependencies, configurations, and data is included.
- Easy to backup or snapshot using Docker commands. Because your configuration files and data are all in the container, they don’t have to be backed up separately. So, backup is a simple commit, or commit & push.
- You have to treat your fat containers more like VMs. So you have to update/patch and monitor them just like VMs.
- Without the one-app-per-container approach, you are tied to whatever major version of software you installed in the container, so upgrading the applications inside the container is more difficult, if not boringly traditional.