Web server configuration: Difference between revisions
No edit summary |
(→Nginx) |
||
Line 29: | Line 29: | ||
==Why Nginx?== | ==Why Nginx?== | ||
==Important Files & Directories== | |||
=Varnish= | =Varnish= |
Revision as of 18:02, 22 December 2017
Architecture
Our http(s) content is served using the following web servers:
- Nginx
- Varnish
- Apache
The traffic flows in-order, ie: Internet -> nginx -> varnish -> apache
And then back out to the client in the reverse order: apache -> varnish -> nginx -> Internet
Why??
OSE's principles aims for simplicity--so you ask, "Why aren't we simply using only Apache? Why Nginx as well? And why Varnish?" Great question!
Before simplicity, OSE is radically committed to using FLOSS. We're also an ecologically-aware, low-budget, non-profit with limited financial & computational resources. Keeping this in mind, below are the reasons for the complexity described in this documentation:
- Varnish is a cache. It's an essential component that allows us to serve a very high volume of requests on many websites from a single server. Unfortunately, the free version of Varnish does not speak https.
- Nginx is our tls-terminator. It listens to our encrypted traffic over https & passes unencrypted http traffic internally onto varnish.
- Nginx has great DOS protection and rate-limiting built-in.
- Nginx being distinct from Apache gives us the ability to serve a SITE_DOWN vhost to users for a specific domain, while devs are still able to iterate & test changes to the backend Apache server. Note that we have only 1 dedicated host, and we don't have a load balancer.
- Most people who use https + varnish specifically use Nginx to terminate their https. Therefore, there is better documentation & a user-support-base for this architecture.
- History. I (Michael Altfield) came on-board in 2017 with only Apache running. I added https to protect our user's passwords that were being sent in cleartext, and--in doing so--I had to abandon CloudFront so a third-party didn't have our private keys. At the time, CF was our CDN cache, so I had to implement a self-hosted cache. I chose varnish, and then had to add nginx before it for https termination.
Nginx
This section will describe our use of the Nginx server in our web server configuration, which serves as our https terminator, basic DOS protection, and SITE_DOWN tool.
Why Nginx?
Important Files & Directories
Varnish
This section will describe our use of the Varnish server in our web server configuration, which serves as our in-memory cache.
Why Varnish?
Our biggest site is this wiki (running on Mediawiki). As of 2017, Wikipedia (the largest site running on Mediawiki) has chosen Varnish as their cache-of-choice, after experimenting with Squid & Nginx caching. If the biggest user of our biggest site's application backend is using Varnish, we should use it too. And I found good wordpress plugins that play nicely with Varnish as well.
Apache
This section will describe our use of the Apache server in our web server configuration, which serves as our backend application web server.