Docker : How To Dockerize And Deploy multiple instances of a LAMP Application

Question

I need to deploy many instances of the same LAMP (or LEMP) application :

• each instance will be accessible from a subdomain, with front loadbalancer/ proxy
• each instance must have its own db data and files data.
• each instance might be monitored
• memory limit / cpu might be set per app instance
• easy to automate the deployment of an new webapp instance
• environment might be easily reproducible for test and development.

Application requires :

• dameon processes (Nginx, MariaDB, PHPFPM)
• binaries (composer, bower, ...)
• other systems specific libs & config

After reading Docker documentation and many howtos, I see different solutions to dockerize this web application :

---

Solution 1 : Use an all-in-one Container

All the stack is in one container :

• webapp source files, EMP daemon processes, binaries, …
• mounted volumes for mysql and webapp data files

Examples :

• Tutum provides an all-in-one container for Wordpress Application : https://github.com/tutumcloud/tutum-docker-wordpress

• Phusion, which provides base image optimized for Docker, precises in documentation (https://github.com/phusion/baseimage-docker#docker_single_process) :

  Docker runs fine with multiple processes in a container. In fact, there is no technical reason why you should limit yourself to one process

Pros (IMHO) :

• Seems easy to automate deploiement, to monitor, to destroy….
• Easy to use in prod, test and dev environment.

Cons (IMHO):

• Monolithic
• Hard to scale
• Does not use all the strength of Docker

---

Solution 2 : Use a containers stack per webapp instance

For each webapp to deploy, a containers stack is deployed :

• One container per process : Nginx, Mysql, PHP-FPM,
• Binary containers (composer, bower,...) can be also dockerized, or merged in the phpfpm container
• mount volumes for mysql and webapp data files

Examples :

• the orchestror tool Gaudi provides an example with a LEMP architecture based on 3 “daemon” containers (nginx, mysql, phpfpm), and 2 app containers (composer, bower) (http://marmelab.com/blog/2014/06/04/demo-symfony-with-docker-and-gaudi.html)

Pro (IMHO) :

• Decoupled
• processes isolated per instance
• One process per container, no need daemon manager as RUnit or Supervisord

Cons (IMHO) :

• Seems more complicated to do work
• Hard to maintain, to see a “big picture” of all containers states, links, version...

---

Solution 3 : Mixin the 2 previous solutions

• One “app” container with : app src files, nginx, phpfmp, composer, git..
• One container for db mysql, which can be shared or not with the app container

---

I'm more Dev than Ops, also it's confused for me.

So, Questions :

1. What are the criteria, pros/cons to consider when choosing between theses solutions?
2. Howto to manage all the containers stacks if i choose Solution 2, to have a "big picture" of all containers states, links, version... ?
3. App src files (PHP) might be built in the container or mounted as volume, eg. /var/www ?

Answer 1

I recently went through analysis on Docker for this type of setup. I know there are some who view Docker as a sort of MicroVM, but my take is the Docker philosophy leans more toward single process per container. This tracks well with the Single Responsibility principle in programming. The more a Docker container does, the less reusable and more difficult to manage. I posted all my thoughts here:

http://software.danielwatrous.com/a-review-of-docker/

I then went on to build a LEMP stack using Docker. I didn't find a lot of value in splitting the PHP and Nginx processes into separate Docker containers, but the Web and Database functions are in separate containers. I also show how to manage linking and volume sharing to avoid running SSH daemons in your containers. You can follow what I did here as a point of reference.

http://software.danielwatrous.com/use-docker-to-build-a-lemp-stack-buildfile/

To your point about increased complexity for the single function per container, you are correct. It will look and feel just like you had distinct, distributed tiers. Very large applications have done this for years and it does increase complexity when it comes to communication, security and management. Of course it brings a number of benefits as well.