Menu
In the dark ages, my usual setup for development of LAMP web applications was to test locally on my machine. PHP (in my case), the database and the web server were all installed natively.
The server was set up with standard installs of Apache and MySQL, and I had multiple virtual hosts for different parts of the web application. When I was happy with the results I had on my local machine, I'd logged into the server and did git pull in the staging environment.
Assuming everything was working as well on the server as it was on my machine, I'd do the same thing for production.
New beginnings…
So now I'm starting a brand new web application from scratch, and I want to do it "the proper way". I've read up about Docker, Vagrant and Puppet (and Chef, although I personally prefer Puppet's system of dependencies rather than Chef's iterative process). Despite all the research I've done, there still seem to be several questions I can't seem to find answers for:
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?
When I talk about parts of the web application, I mean things like mysite.com, controlpanel.mysite.com, etc. These "parts" will share the same database.
Since Docker seems to provide ready-made containers for things like the web and database servers, it seems like those things at least should be in separate containers. Should the different parts of my web application be in separate containers, too?
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?
The database server will manage files related to the content of my database (that I'll want to be backing up). The web server will be creating logs, and my web applications will be managing various files and caches, etc. All these files need to be written outside of the application's containers (because I might replace them when updating?), so where do they go? Straight into the host machine's file system? Or into a separate "Docker Volume"?
If they go into Docker volumes, should I use a separate volume for the database, web server, application, etc.? Can I still easily access the contents using SFTP from my local machine like I do now? I don't want to lose any convenience here!
Is it a good idea to use Puppet to create and manage the Docker containers, both for the development server and production server?
It seems Puppet has support for managing Docker containers directly, so this seems like a reasonably good way of easily setting up a server or the production environment (using Vagrant) from scratch.
Hopefully I've asked some relevant questions; it would be great to get some proper "best practices" for development and production of LAMP-like web applications. it's just there doesn't seem to be much that I've found!
688
Create a Dockerfile for a new container image based on a starter image from Docker Hub. Add files to an image using Dockerfile commands. Configure an image's startup command with Dockerfile commands. Build and run a web application packaged in a Docker image.
Docker is very useful for web applications running on a server or console-based software. But if your product is a standard desktop application, especially with a rich GUI, Docker may not be the best choice.
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:
155
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
