Deploying multiple WordPress sites on Docker for production | Hacker News Reader

Deploying multiple WordPress sites on Docker for production

3 pointsx5n14 comments

This tutorial shows how to deploy a micro docker container with WordPress. Each microcontainer has its own instance of Nginx and PHP-FPM. An Nginx server as a proxy sits on the front end serving connections to one or more sites hosted in the containers. It uses Alpine Linux and persists all data on the host's file system. The logging is also available on the host system. The benefit of doing it this way is that each site sits in its own container, so if it is compromised, no harm comes to any other site or services running on the host system.

It also does not link containers, instead opting to attach the database to the first IP address of the network Docker sets up, thereby avoiding the need for complicated service discovery. It also includes instructions on how to deploy Redis on the same box and use that with WordPress. Also includes instructions on how to do SSL for each site. It's being used in production.

http://www.dockerwordpress.com/

This is very good, but should have been submitted as a link directly to your site.

> each site sits in its own container, so if it is compromised, no harm comes to any other site or services running on the host system.

But what about the security shortcoming of running Docker containers? this does not seem to do anything to address it.

The process serving the website, Nginx and PHP-FPM, does not run as root. It's no less secure than running a non-root user like www-data to serve your site. If you can breakout to root within the container, you can potentially get to the host system. But that's absolutely no different than any other Linux system. If you break out of www-data on a normal setup to root, then you have root.

All that Docker is acting as is a chroot that's easier to deploy and configure with its own networking stack.

There is one weakness that I will be addressing soon, which is that Dockergen is running within the same container as as the Nginx proxy, and that's a bit dangerous -- not that dangerous because there is no user defined code that executes in the proxy's container and no way to upload anything to that container... but if there were a weakness in Nginx that would allow users to upload code to the proxy container and execute that then it might be problematic. For this reason Dockegen will be moved to a separate container that is not interacting with the web.

Just as a precaution, you should probably not be using their logos on your site without either company giving you permission.

thanks, i decided to ditch the logos. though i am just attempting to promote their product and if they prefer i don't do that, then that's their choice...

Reply on news.ycombinator.com