@Chempo
Honestly, I can’t really think of a situation where NGINX wouldn’t be a good fit :-). While Apache can do some of the same things as NGINX, I find the syntax a bit cluttered and dated.
For me, as a developer/programmer, I find the syntax of NGINX to be far cleaner.
As a basic example, the typical VirtualHost block for Apache looks something like:
<VirtualHost *:80>
ServerAdmin you@domain.com
ServerName domain.com
ServerAlias www.domain.com
DocumentRoot /var/www/domain.com/public_html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
<Directory /path/to/dir>
...
...
...
</Directory>
...
...
...
</VirtualHost>
Some will argue that’s pretty clean, though with NGINX, the above would look like:
server {
listen 80;
listen [::]:80;
server_name domain.com www.domain.com;
access_log /path/to/domain.com.access.log;
error_log /path/to/domain.com.error.log;
root /path/to/home/dir;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ [^/]\.php(/|$) {
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi_params;
}
}
The above is a simple server block to handle WordPress sites. Comparing the two, the syntax of NGINX is much like a programming language, so without any other considerations, I naturally draw to it.
Beyond the programming-like syntax, it’s super simple to setup Proxying. For example, if we wanted to proxy a NodeJS application, our server block would look something like:
upstream @backend {
server 127.0.0.1:2356;
}
server
{
listen 80;
listen [::]:80;
server_name _;
location /
{
proxy_pass http://@backend;
proxy_buffers 16 32k;
proxy_buffer_size 64k;
proxy_busy_buffers_size 128k;
proxy_cache_bypass $http_pragma $http_authorization;
proxy_connect_timeout 59s;
proxy_hide_header X-Powered-By;
proxy_http_version 1.1;
proxy_ignore_headers Cache-Control Expires;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504 http_404;
proxy_no_cache $http_pragma $http_authorization;
proxy_pass_header Set-Cookie;
proxy_read_timeout 600;
proxy_redirect off;
proxy_send_timeout 600;
proxy_set_header Accept-Encoding '';
proxy_set_header Cookie $http_cookie;
proxy_set_header Host $host;
proxy_set_header Referer $http_referer;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_temp_file_write_size 64k;
proxy_set_header X-Original-Request $request_uri;
}
}
Now I know that looks complex, though that’s working configuration. You’d need to change the port in @backend at the top to match your NodeJS application port, and server_name to match your domain, but that will just work 99% of the time.
Beyond that, if you wanted to do something really crazy, you could load balance, proxy an application, serve multiple WordPress sites, and cache all with the same NGINX server. It’s not ideal, but you can. NGINX functions as a reverse proxy, load balancer, PHP-FPM proxy, caching proxy, etc.
The repo that I noted in the above post sets up a fully configured NGINX installation from source with numerous example configurations that work.
The configuration is already tweaked/tuned for production use and works well (I used it on many sites).
…
As far as recommendations, I would start with at least 1GB RAM, though 2GB would be preferred. That’s not because NGINX is RAM-hungry, it’s because MySQL/MariaDB and WordPress + NodeJS applications are from time to time.
You need RAM to run NGINX, PHP-FPM, MySQL/MariaDB, and NodeJS on the same server, and without a good amount, services crash.
The good news is that in those installers, there’s a also installers for MariaDB (a MySQL fork that has better overall performance), PHP-FPM (5.6, 7.0, and 7.1), as well as NodeJS.
So you could run the installers and easily setup each piece of software with relative ease :-).
App Platform: Run Node apps without managing servers
Product
Tool
Question
