Deploying a basic site
If you have a static website, this is very easy to deploy with NGINX. With systems such as Jekyll (which powers the GitHub Pages), static site deployments can be easy to generate and are far less hassle when it comes to security and exploits. Quite simply, a static website can't be hacked and doesn't suffer from any performance issues.
How to do it...
- To serve static files, we're going to edit the default site configuration file
/etc/nginx/conf.d/default.confand make a few small changes.
Edit the file and add the following:
server {
listen 80;
server_name server.yourdomain.com;
access_log /var/log/nginx/log/host.access.log combined;
location / {
root /var/www/html;
index index.html;
}
}- If the folder doesn't exist, create the
/var/www/vhostsdirectory with the following command:
mkdir -p /var/www/vhosts- Copy your existing website files into the
/var/www/vhostsdirectory. - Ensure the files and folders have permission to be read by the
nginxuser:
chmod -R o+r /var/www/vhosts chown -R nginx:nginx /var/www/vhosts
- From your web browser, browse the site and check that it's working.
How it works...
Let's go through this setup file to understand each directive:
listen 80;: This defines the port which NGINX will listen to. Port80is the default standard for HTTP, which is why it doesn't need to be specified in the browser URL.server_name server.yourname.com;: This directive tells the server what hostname to match from the request. This allows you to run name-based virtual servers from one IP address, but with different domain names. You can also use different aliases here; for example, you can have bothwww.yourname.comandyourname.com.access_log /var/log/nginx/log/host.access.log combined;: The access log records all client access to the site, stores it in the specified file (the second parameter), and uses the third parameter to define the format of the log (combinedis the default).location: Lastly, we have alocationblock directive. This one is for a root directive (represented by/), meaning everything in the URL path. There are then two directives contained within this block—the first is therootdirective. This defines where NGINX should look for the files.index: The second is theindexdirective. This lets NGINX know what name of a file to try if it hasn't been specified in the path. For example, if you puthttp://server.yourname.com/into your browser, NGINX will try to loadhttp://server.yourname.com/index.htmlinstead of displaying a 404 error.