Simon's picture

Hi there,

for reasons that don't matter, I need to move a few (initially 2, more later) Wordpress sites, (each on separate, unrelated domains) to a LAN based VMware environment, behind a single public IP.

I've deployed a VM running Turnkey Wordpress and so far, so good. Now because I need multiple, unrelated sites behind one public IP, I guess I need to front everything with a proxy, such as NGINX, that can read the incoming host requests and route them to the relevant WP instance?

VM resource isn't an issue, so I was initially going to spin up a Turnkey WP instance per site, plus one for NGINX to handle the redirections. Then I read about the LXC app and wondered if I could run all the WP images, plus NGINX in separate containers on the same LXC host?

I'm something of a Linux newbie, which is part of the Turnkey appeal - it just works! So, I'm looking for advice on how to best architect a system for running multiple WP sites behind a single IP, in the simplest, easiest to manage way.



Jeremy Davis's picture

Usage of the LXC appliance would be a fine way to go. Note that it will require you to use the commandline, but if you read through the info on the appliance page and follow the link to the usage docs, then hopefully it should all "just work".

Having said that, if resource usage isn't a consideration and you're happy to get your hands a bit dirty with config, then use of a reverse proxy (as you mentioned) is also a fine idea.

Nginx is a great option as it really excels at that sort of thing (as well as serving static content), especially in a low resource environment. FWIW our LXC appliance, and many of our appliances which include software which is "self hosting" (i.e. doesn't need a separate webserver) have Nginix running as a frontend, reverse proxying connections to back end servers (within the same VM).

However, it's worth noting that Apache can also be configured to act as a reverse proxy. Apache is a rock solid option (and I would argue is far more versatile and easier to configure than Nginx). Besides, if you are using our WordPress appliance, then it'll already be running! :)

So if you wanted to use Apache as a reverse proxy, one of your WordPress servers (probably the one getting the most traffic) could accept all the connections. If the traffic is for it, it could serve the content as required. If it's for the other server, then it could forward (i.e. reverse proxy) it on to the other server(s).

TurnKey v15.x appliances include Apache 2.4, so the Apache docs are probably the first place to start. TBH, I've never configured it myself, but from a glance, it looks like use of Apache's mod_proxy with a simple reverse proxy config should do the trick.

One thing to keep in mind though is that assuming you are using HTTPS, your "front end" server (the one initially accepting all the connections) will need to terminate the HTTPS connection and forward the content to the "backend" server(s) as plain HTTP. I.e. the "front end" server will need to have HTTPS certificates to cover all FQDNs (fully qualified domain names) that are in use.

The easiest (and least secure) way to resolve that, is to have all traffic between the "front end" server and "back end" server(s) be via HTTP only. So long as all the Apache servers are on the same network and there is no fear of interception of the traffic between the web servers (and/or it's not dealing with anything super sensitive), then that is generally acceptable.

Although it's fair to say that it's far from ideal! To work around that, you can either copy the certificates between the servers (if you use Confconsole's free Let's Encrypt certificates then I would suggest a cron job to auto copy the certs across via sftp/scp). If you have concerns about copying certificates then you can configure the connections between the 2 servers to use self signed HTTPS certificates. But that is a bit more advanced so I won't go into it further here.

You should be able to find plenty more specific info via the internet, although I've got a few pointers for you. It's worth noting that TurnKey v15.x is based on Debian 9/Stretch, so generally anything that relates to Debian 9/Stretch will also apply to TurnKey v15.x. It includes Apache 2.4, so Debian 8/Jessie and/or TurnKey v14.x should be close enough. Anything else you find regarding Apache 2.4 should also work (although please note that the upstream Apache config is laid out a little differently; as is Red Hat/CentOS). Ubuntu is also based on Debian so generally instructions related to that will also be relevant (I'd guess that 16.04 is probably the closest to Stretch; but any release with Apache 2.4 e.g. 18.04 should be close enough).

I hope that gets you headed in the right direction. Please feel free to post back if you need further assistance and/or clarification on anything. Also, when you do get it all set up and working, it'd be great if you could share what you did and how you did it as I'm sure that would be of value to other users.

Good luck! :)

Simon's picture

Wow, thank you for such a detailed and helpful answer. I'll look into all your suggestions and try out a few scenarios.

Many thanks.


Jeremy Davis's picture

Please let us know how it all goes, which direction you end up going and why. Also it'd be please feel free to share any resources you find useful.

Good luck with it all. :)

Add new comment