Should there be separate Docker containers for the web server (such as Apache), the database server (such as MySQL) and each part of the web application?
There is no correct answer to that question. If you will be using Docker in production, then try to run your Docker containers in your development environment as they will be in production. Else just use the Docker containers the easiest way you can.
Docker Hub provides ready to go containers for PHP, databases, etc. and it is easy to use them. On the other hand, you have to link them together to allow them to interact. For a development environment and if you use multiple containers, I would advise to use docker-compose.
Another path is to build a Docker image that is the closest to your production machine (assuming you have only one machine) which would run the database, the web server, and PHP. A container from such an image would have to run multiple processes. This can be achieved in different ways. Take a look at supervisor or phusion/baseimage.
When I talk about parts of the web application, I mean things like mysite.com, controlpanel.mysite.com, etc.
You could have them separated. If those applications need to share sessions, make sure sessions are stored in database or on a docker volume that is accessible to all.
Docker containers seem to be designed to be replaceable rather than me having to update the software inside them. What about the data they write that I don’t want to lose?
Docker has a thing called volume to allow data to be written on a filesystem out of the container. There are different ways to work with volumes: you can mount a directory from the Docker host to a container volume, or you can have data volume containers, or named volumes.
Docker volumes are an important concept and it is worthwhile to take the time to master them.
If you want to easily access the data used by your containers from your Docker host, mounting a directory on the Docker host is the way to go. Although it may be tricky regarding permissions and ownership of the files.
Regarding backups, take a look at the Docker user guide where everything you need to know in regards with volumes is detailed.
Is it a good idea to use Puppet to create and manage the Docker containers, both for the development server and production server?
The best practice is to operate on your development environment the same way you will operate on your production environment. There is no point going through setting up Puppet correctly for your development environment if all that work won’t be used for the production environment. Having a Vagrantfile that provision a VM with Docker is really easy with just shell provisioning ; IMHO puppet/chef/… are overkill.
You are asking the right questions, but there isn’t any answer that fits all situations. In my view there are two ways to do things:
- make your development environment replicate exactly your production environment
- make your development environment different from production, keeping it as simple and straightforward as you can so developers won’t feel the friction induced by using new tools