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...

1. To serve static files, we're going to edit the default site configuration file /etc/nginx/conf.d/default.conf and 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; 
          }
      }

2. If the folder doesn't exist, create the /var/www/vhosts directory with the following command:

      mkdir -p /var/www/vhosts

3. Copy your existing website files into the /var/www/vhosts directory.
4. Ensure the files and folders have permission to be read by the nginx user:

      chmod -R o+r /var/www/vhosts
      chown -R nginx:nginx /var/www/vhosts

5. 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. Port 80 is 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 both www.yourname.com and yourname.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 (combined is the default).
• location: Lastly, we have a location block 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 the root directive. This defines where NGINX should look for the files.
• index: The second is the index directive. This lets NGINX know what name of a file to try if it hasn't been specified in the path. For example, if you put http://server.yourname.com/ into your browser, NGINX will try to load http://server.yourname.com/index.html instead of displaying a 404 error.