Hosting

Our website is hosted on two separate AWS servers. One is for the actual website and one is for the database. The server for the website holds the URL http://caloriekiller.club handles all incoming requests, makes requests to the database server, and creates and serves the actual website. The DB server was covered more in depth in the DB section, but broadly handles incoming database requests and updates the database system. The database server also backs itself up every 48 hours with a cronjob to protect the integrity of the data.

We have chosen to not autoupdate the server so that we don't actually break the site and instead ssh in and update the site with a few commands whenever the team has decided that we have reached a significant milestone. To update, all that must be run is first to git pull origin master in the idb/ directory, run make install if any new libraries are required as described in requirements.txt, and then run sudo make restart-prod. The server should successfully restart both NGINX and Gunicorn. As a final precaution to make sure everything is running fine, the error logs can be checked with

journalctl -u nginx.service -e and journalctl -u idb.service -e. These logs will describe if the website is working fine and are the general source of error information for debugging the site, especially idb.service.

The website server is set up with an NGINX, Gunicorn, Flask setup. NGINX was chosen as the server of choice because of its increased speed and features compared to Apache. Although Apache does have more documentation and more time in the field, we believed NGINX to be mature enough and uncomplicated enough to service our simple needs. Gunicorn was chosen to allow multiple workers to handle requests at the same time and to allow for easy rebooting of the site should any worker error. Both NGINX and Gunicorn are setup as systemd jobs that are enabled at boot.

NGINX config:

server {
  listen 80;
  server_name caloriekiller.club api.caloriekiller.club;

  location / {
    include proxy_params;
    proxy_pass http://unix:/home/ubuntu/idb/idb.sock;
  }
}

This config says that it is defining a new server that listens to incoming requests from the internet (port 80) that are looking for the human readable URLs caloriekiller.club or api.caloriekiller.club. It routes both URLs to the same place and we have let Flask decide where these URLs actually route. It talks to Gunicorn through a socket that is created on service startup in home/ubuntu/idb/idb.sock. Gunicorn listens on the socket for any traffic from NGINX and then processes it.

Gunicorn config:

[Unit]
Description=Gunicorn instance to serve idb
After=network.target

[Service]
User=ubuntu
Group=www-data
WorkingDirectory=/home/ubuntu/idb
Environment="PATH=/home/ubuntu/idb/env/bin"
ExecStart=/home/ubuntu/idb/env/bin/gunicorn --workers 5 --bind unix:idb.sock -m 007 idb:app

[Install]
WantedBy=multi-user.target

This config describes a systemd service that is then enabled on boot. It starts after the internet is set up on the machine, runs at /home/ubuntu/idb, and starts Gunicorn with 5 workers that listen on the socket described earlier and each individually run a copy of our website which is packaged as idb. The number of workers does not have a direct relationship to the number of simultaneous users on the site, the way workers work is more complicated than that. Although an in depth analysis and benchmark of the site could be done to determine the optimal number of workers (this is mainly related to the number of cores on the server and the number of threads per core), a default of 5 workers is even overkill for our small site.

results matching ""

    No results matching ""