Serving 1< Phoenix Web Apps on a Linux VM with NGINX

[nelsonic]

As a developer wanting to *deploy (1< small-ish phoenix) web app(s) on a (single) VM, I need a way to proxy the Phoenix app(s) transparently so that I can still use edeliver to deploy the app(s) using Travis-CI

Context

We can easily deploy apps to Heroku https://github.com/dwyl/learn-heroku ✅ But apps deployed for "free" will go to "sleep" https://blog.heroku.com/app_sleeping_on_heroku 💤 see: https://stackoverflow.com/questions/2606190/why-are-my-basic-heroku-apps-taking-two-seconds-to-load and https://www.quora.com/Scalability/Scalability-How-does-Heroku-work-2 and thus take a while to respond for the average visitor/user ... ⌛️ 😞

If we instead chose to pay for Heroku (as we do for https://www.dwyl.com ...) it will cost $7/month (min) but as soon as we want to store any data it's another $10/month (min)

By contrast a $5/month VM can host several Phoenix apps (which each average 50Mb RAM) including millions of rows of data in PostgreSQL

Todo

• [x] remove IPTables port forwarding from 80 --> 4000 (let NGINX handle that)
• [x] configure NGINX to proxy a basic Phoenix App on a given TCP Port using virtualhost
• [x] configure a subdomain to point to the virtualhost
• [x] get certificate from let's encrypt
• [x] configure SSL/TLS for the subdomain

[nelsonic]

reading: https://dennisreimann.de/articles/phoenix-nginx-config.html

[nelsonic]

sudo iptables -t nat -L -n -v

This rule was added using the following command:

sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 4000

so to remove it we use:

sudo iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 4000

the difference is the -D which is DELETE ... see: https://serverfault.com/questions/159544/undoing-the-port-forwarding

[nelsonic]

the default nginx index on ubuntu 16.04 is:

/var/www/html/index.nginx-debian.html

default config is:

/etc/nginx/nginx.conf

which has the line:

include /etc/nginx/sites-enabled/*;

So we should do our custom configuration in a site-specific file in there.

the default "sites-enabled" config is a symbolic link to /etc/nginx/sites-available/default:

[nelsonic]

let's remove the symbolic link to /etc/nginx/sites-available/default from /etc/nginx/sites-enabled

unlink /etc/nginx/sites-enabled/default

now create a new configuration file: /etc/nginx/sites-available/healthlocker_staging (or whatever you want to call it):

server {
  listen 80;
  server_name staging.healthlocker.uk www.staging.healthlocker.uk;

  location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_pass http://localhost:4000;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }
}

save the file contents and test that it's valid:

/usr/sbin/nginx -t -c /etc/nginx/sites-available/healthlocker_staging

create a new symlink:

sudo ln -s /etc/nginx/sites-available/healthlocker_staging /etc/nginx/sites-enabled/

and restart nginx:

sudo service nginx restart

works:

[nelsonic]

Next: The SSL Cert from Let's Encrypt: https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04

[nelsonic]

install certbot:

sudo add-apt-repository ppa:certbot/certbot -y
sudo apt-get update
sudo apt-get install certbot -y

[nelsonic]

Run the certbot command:

sudo certbot certonly --webroot --webroot-path=/var/www/html -d staging.healthlocker.uk

output:

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/staging.healthlocker.uk/fullchain.pem. Your
   cert will expire on 2017-10-11. To obtain a new or tweaked version
   of this certificate in the future, simply run certbot again. To
   non-interactively renew *all* of your certificates, run "certbot
   renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

the files are in:

/etc/letsencrypt/archive/staging.healthlocker.uk

[nelsonic]

(cold) restart NGINX:

sudo service nginx stop
sudo service nginx start

[nelsonic]

Result: visiting staging.healthlocker.uk gets automatically re-directed to: https://staging.healthlocker.uk

However there is a "content warning" because an image is still being served over HTTP (unencrypted). And that image is: Which is not available over HTTPS ... 😞

So until SLaM update their "media" server, (or we remove this image from the HL homepage), we will continue to see the ❗️ in the URL bar in Chrome/FF.

[nelsonic]

Relates to: https://github.com/healthlocker/healthlocker/issues/907 Full NGINX Config:

# redirect all http requests to https
# and also listen on IPv6 addresses
server {
  listen 80;
  listen [::]:80;
  server_name staging.healthlocker.uk;

  return 301 https://$server_name$request_uri;

  # let's encrypt *temporary*:
  location ~ /.well-known {
    root /var/www/html;
    allow all;
  }
}

# the main server directive for ssl connections
# where we also use http2 (see asset delivery)
server {
  listen 443 ssl http2 default_server;
  listen [::]:443 ssl http2 default_server;
  server_name staging.healthlocker.uk;

  # paths to certificate and key provided by Let's Encrypt
  ssl_certificate /etc/letsencrypt/live/staging.healthlocker.uk/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/archive/staging.healthlocker.uk/privkey1.pem;

  # SSL settings that currently offer good results in the SSL check
  # and have a reasonable backwards-compatibility, taken from
  # - https://cipherli.st/
  # - https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_prefer_server_ciphers on;
  ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
  ssl_ecdh_curve secp384r1;
  ssl_session_cache shared:SSL:10m;
  ssl_session_tickets off;
  ssl_stapling on;
  ssl_stapling_verify on;
  # ssl_dhparam /etc/ssl/certs/dhparam.pem;

  # security enhancements
  add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
  add_header X-Frame-Options DENY;
  add_header X-Content-Type-Options nosniff;

  # Let's Encrypt keeps its files here
  location ~ /.well-known {
    root /var/www/html;
    allow all;
  }

  # besides referencing the extracted upstream this stays the same
  location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_pass http://localhost:4000;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }
}