How to develop a LAMP web application using Docker, Puppet and Vagrant?

Question

In the dark ages, my usual setup for building LAMP web applications was to test locally on my machine. PHP (in my case), database and web server were installed initially.

The server was configured with standard Apache and MySQL installations, and I had several virtual hosts for different parts of the web application. When I was pleased with the results obtained on my local computer, I went to the server and git pull into the intermediate environment. Assuming everything works on the server, as it was on my machine, I would do the same for production.

New beginnings ...

So now I am starting a new web application from scratch, and I want to do it “right”. I read about dockers, vagabonds and dolls (and chefs, although I personally prefer the puppet system rather than the iterative Chef process). Despite all my research, there are still a few questions that I cannot find answers to:

Should there be separate Docker containers for the web server (e.g. Apache), database server (e.g. MySQL) and each part of the web application?

When I talk about parts of a web application, I mean things like mysite.com, controlpanel.mysite.com, etc. These "parts" will use the same database.

Since Docker seems to offer ready-made containers for things like web servers and database servers, it looks like these things should at least be in separate containers. Should different parts of my web application also be in separate containers?

Docker containers seem to be intended to be replaced, not to update software within them. What about the data they write that I do not want to lose?

The database server will manage the files associated with the contents of my database (that I want to back up). The web server will create logs, and my web applications will manage various files and caches, etc. All of these files must be written outside of the application containers (because I can replace them when upgrading?), So where do they go? Directly to the host machine file system? Or in a separate "docker volume"? If they come in docker volumes, should I use a separate volume for the database, web server, application, etc.? Can I access content using SFTP from my local machine, as of now? I do not want to lose convenience here!

Is it useful to use Puppet to create and manage Docker containers for both the development server and the production server?

Puppet seems to support managing Docker containers directly, so this seems like a reasonably good way to easily set up a server or production environment (using Vagrant) from scratch.

I hope I asked some important questions; it would be great to get some proper “best practices” for developing and producing LAMP-like web applications, but it doesn't seem like much that I found!

Answer 1

Should there be separate Docker containers for the web server (e.g. Apache), database server (e.g. MySQL) and each part of the web application?

There is no correct answer to this question. If you will use docker in production, try running your docker containers in your development environment, as they will be in production. Else just use docker containers in the easiest way.

Docker Console provides ready-made containers for php, databases, etc., and are easy to use. On the other hand, you need to tie them together so that they can interact. For the dev environment, and if you use multiple containers, I would recommend using docker-compose .

Another way is to create a docker image closest to your production machine (assuming you only have one machine), which will run the database, web server and php. A container from such an image should start several processes. This can be achieved in many ways. Take a look at supervisor or phusion / baseimage .

When I talk about parts of a web application, I mean things like mysite.com, controlpanel.mysite.com, etc.

You could separate them. If these applications need to exchange sessions, make sure that the sessions are stored in a database or on a docker volume that is accessible to everyone.

Docker containers appear to be intended to replace, not to update software within. What about the data they write that I do not want to lose?

Docker has a thing called volume, which allows you to write data from the file system from the container. There are different ways to work with volumes: you can mount the directory from the docker host in the container volume, or you can have data volume containers or named volumes .

Volumes of dockers are an important concept, and it is worth spending time to master them.

If you want to easily access the data used in your containers, you can create a directory on the docker host.

For backups, check out the docker user guide for details on everything you need to know about volumes.

Is it good to use Puppet to create and manage Docker containers for both the development server and the production server?

Best practice is to work in your developer's environment just as you would in your production environment. There is no point in properly setting up the puppet for your development environment if all of this work will not be used for the production environment. Having a Vagrantfile that provides a docker virtual machine is very simple with a shell ; IMHO puppet / chef / ... crowded.

---

You ask the right questions, but there is no answer that would answer all situations. In my opinion, there are two ways to do something:

• Make your development environment replicate your production environment
• make your development environment different from production, keeping it as simple and straightforward as possible, as you may think that developers will not feel the friction caused by the use of new tools.

Answer 2

While @Thomasleveil's answer is already very good and covers all the important parts, I would like to add additional points.

Tramp, Puppet / Chef and docker writer

When you create a virtual machine using Vagrant, you usually use Puppet or Chef to install the necessary packages for your server ... along with several shell scripts. PuPHPet is a great source for setting up the LAMP stack in a virtual machine and learning how Puppet and Vagrant work together in a more complex setup. An alternative is Protobox .

When you use Docker containers with Vagrant in the same way as with virtual machines. Then, with vagrant up you essentially launch vagrant up containers with the Docker provider. Vagrant will build containers for you from the Docker file or use an existing image more or less similar to docker-compose ( fig ) and run them.

The main reason for choosing Vagrant for your Docker installation is if you or your team partially work in a Windows environment, as Vagrant allows you to keep your setup consistent no matter what your host system is (see Host VM ).

If you use OS X, you can use docker-compose with a virtual virtual machine, if you are running Linux, you can use Docker natively. You can also always log in to boot2docker (or another Docker Host virtual machine) via ssh , whether you are on Windows or OS X.

Note. You should not use SSH in your containers, but this is a different topic.

As of February 2015

docker-compose feels a little more spectacular for me, and it also starts, stops and restores containers more efficiently.

The advantage of Vagrant is to specify another host virtual machine, for example. per project, if you prefer this setting.

Note: It also provides a Docker mechanism, which is more related to the Puppet build process.

---

Should there be separate Docker containers for the web server (e.g. Apache), database server (e.g. MySQL) and each part of the web application?

When using Docker containers, you mostly use single isolated processes. Using a supervisor should be avoided and also not necessary for the LAMP stack.

So my answer is definitely: Yes, there must be separate containers!

---

When I talk about parts of a web application, I mean things like mysite.com, controlpanel.mysite.com, etc.

It depends on your needs, I suggest you read the 12factor documentation, which describes important things that you need to take care of in a very detailed way.

---

Docker containers appear to be intended to replace, not to update software within. What about the data they write that I do not want to lose?

In addition to @Thomasleveil's answer, I would also recommend a separate backend for storing users like Amazon S3, SFTP or WebDAV.

In my opinion, your web application container should be considered as a client application that accesses your database and backends (services) of data storage, and also not rely on data from volumes when working in a production environment.

---

Is it good to use Puppet to create and manage Docker containers for both the development server and the production server?

I don’t know about the possibilities of Puppet orchestration, but to create containers, if you use Vagrant, I don’t see the need for Puppet, due to Docker’s own assistant for Vagrant.

---

Bonus

For all the things described above, you can see my 12factor PHP-template application based on the Yii 2.0 Framework with the LAMP docker stack. With Docker, you can also easily connect reverse proxies or containers for testing selenium into your project, as they exist as pre-build images and can be downloaded and configured in a few minutes and started in a few seconds.