Transition Virtual Hosts to Docker Containers

Question

I currently run a Red Hat Linux server with Plesk to host a hundred or so domains. For multiple reasons I'd like to transition away from Plesk and to Docker containers with each virtual host as one or more containers. I'm unclear from what I've read so far what would be the best approach to this.

A typical site includes the doc root file area and one or two MySQL databases. We run PHP on all the sites. Some sites may have constraints on the version of PHP they can run. Some of the sites use SSL. I don't believe there are any constraints on the MySQL versions, but it's of course possible that future MySQL versions could deprecate some feature that is needed. I don't believe there's any dependency on the Apache version, but I do rely on some specific Apache modules being installed. There may be a site or two that have dependencies outside of their doc root and not part of the basic virtual host setup, but I don't believe any require a specific version of Linux.

I would like the containers to have maximum portability so that I can have flexibility in moving sites to whatever server or cloud service I choose. Part of my goal is to retire the current server and move sites to servers which best fit them.

I would also like to try upgrading the PHP version after the containers are created.

So would a single container include the entire doc root file system, including the data directories where users can upload/ftp files? Would it include the MySQL database, or would that be separate? I assume I would include the current version of PHP so that I could upgrade each one when I was ready. Would it include Apache when specific Apache modules are required? Is there a reason to include Apache and/or MySQL in all containers?

One last piece. I'm looking into using CoreOS which utilizes Docker as an integral part.

Any and all inputs are appreciated.

Dollarbird

Answer 1

The whole idea of Docker is running processes/components isolated, to keep them easily upgradable. I have tinkered with this in the past and have come up with the following.

• Create four containers per instance (customer):
  • Apache or nginx
  • php-fpm
  • MySQL
  • Busybox (as a data container)
• Link all of them together and set volumes to all data that should persist in the data container. MySQL data and /var/www plus site config files for example.

This way you can always switch out one of the components while keeping the others. It's questionable though if Docker is a solution to a full virtual server though, as Docker containers do not have a full init system and you'll have to resort to bending things quite a bit to resemble a full virtual machine. Think more of it as "application containers", hence the idea with the separation of concerns.

Update:

Newer Docker versions come with the docker-compose tool which greatly eases this task.

Lactometer

I'm looking at moving away from a full virtual server and instead moving to multiple AWS instances. Regarding your answer, would you put all the PHP application files into the php-fpm container? I was under the impression people typically created 2 containers, an application container which held all the application dependencies (Apache, PHP, MySQL and the application program), and a data container which contained the databases, data file, config files, etc. Then if you want to upgrade PHP or MySQL, you simply rebuild the application container. What is the advantage of the 4 containers? – Dollarbird

The advantage is that you can modularize your stack and don't need to use and init system like runit or supervisor. Also, if you needed to add Redis for example, you could just start up and link a Redis container, no need to completely rebuild the application container. Usually you would expose paths inside of each container by setting the VOLUME instruction in its Dockerfile on creation. This enables other containers to use those exposed paths via --volumes-from. If you ran the one data container with multiple --volumes-from statements, you could effectivly link all data paths to it. – Lactometer

This is making sense. I'm still an extreme newbie with Docker, so I'm going to try what you're suggesting and see if I run into any issues. – Dollarbird

You're welcome. Let me know when you run into trouble and I'll be happy to assist. – Lactometer

Answer 2

I am trying to solve the same issues with cPanel instead of Plesk.

We can try and accomplish this using the plugins for cpanel or plesk however we have to worry about few things.

and we have to create some premade template images for containers that our clients can use.. it cannot be just any container from dockerhub,user Dockerfiles,etc Because cPanel/Plesk will look for specific log files available on specifc locations for bw calculations, disk quota,etc.

Biggest advantage with this solution is that we can provide CloudLinux kind of isolation and easy resource allocation/ fair sharing. However it is not as easy.

To answer your question:

Every container will be nearly a complete system so you will need to have less clients per host, because each container might be like 1G and by default have to run its own webserver/php and hence more ram foot print.

Its painful to run a Mysql inside each container and it is better to use mysql on the host or 1 dedicated container and share it. this way the Plesk's tools will help.

You may also have to use the standard apache and then reverse proxy it to each container after ssl termination so Plesk's standard tools are used but then I think containers will have to run its own webserver itself or we may have to do some trickery with php-fpm to allow host's apache to talk to each container's php-fpm processes . This is more painful than allowing each container to just run its own Nginx but possible.

It doesnt prevent users from installing their own Mysql server within their container if they need.

This kind of stuff is easy for someone from cPanel or Plesk to do.. but for others it will need a lot of Dedicated development time + testing to make sure all this works.

I was going to invest some time in creating this kind of plugin for cPanel but still undediced. I may try this if I can rope in some investors.

You can see amount of interest , CPanel shows on this issue : http://features.cpanel.net/responses/dockerio-support

I will leave you to decide

Also as an alternative solution:

so Instead of playing to the Cpanel's tune I created this . https://github.com/paimpozhil/WhatPanel Here every site runs in its own container ( and its own VM if needed.).

Migration is simple as exporting/importing a container with tools like : on github.com /paimpozhil/docker-volume-backup & acaranta/docker-backuper

I didnt complete the migrator/ php upgrade tools ,etc here but will do when i have free time.

Semi

I wasn't clear enough that I'm migrating away from Plesk (moving to AWS). I've read more about Docker and I can see that I should create one container for the site application (including Apache, PHP, and any other dependencies) and another for the site data. Then attach the data container to the application. This way I can recreate the application container at any time without affecting the data (probably why having MySQL inside the container was a pain). And as you mentioned, setup a reverse proxy on the server to point the domains to the containers running their own web servers. – Dollarbird