

Deploying multiple WordPress sites on Docker for production - x5n1

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&#x27;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.<p>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&#x27;s being used in production.<p>http:&#x2F;&#x2F;www.dockerwordpress.com&#x2F;
======
finid
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.

~~~
x5n1
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.

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

~~~
x5n1
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...

