So you've just gotten your new self-managed server and want to install and configure NGINX. Congratulations on a wise decision. As a savvy web professional, you likely already know some of the advantages of the NGINX web server as opposed to the traditional Apache configuration. This guide will help you with replacing Apache with NGINX on a new server. It assumes a certain level of previous server administration knowledge, or at least a willingness to learn. This guide is not for everyone, but if you're ready to grab the bull by the horns and deploy a web stack using NGINX, then you may use this guide as a first step to building common web stacks such as Node.js, LEMP, and popular web frameworks such as Django.
What is NGINX?
NGINX (pronounced Engine ex) was released for production in 2004 and is rapidly becoming a popular alternative to the traditional Apache web server suite. It features an event-driven design, which can make better use of today’s computer hardware than Apache’s process-driven design. Because of this, NGINX is often seen as the "faster" alternative to Apache, being able to handle a higher load of concurrent connections while using less resources. There are many comparisons out there between Apache and NGINX; we'll leave the debate up to the community. But here are a few pointers that outline the key reasons to choose Apache versus NGINX. At the end of the day, the choice of the web server platform is entirely dependent on what you're doing with the server.
NGINX vs. Apache
If you are ...
- Using the server to host a single website with high traffic
- Comfortable with doing advanced configuration and tweaking, and have the skillset to do so
- Wanting to go with newer frameworks, such as Node.js, Python/Django
- Wanting to use an alternate to CGI/FastCGI, such as WSGI
- Are OK with less add-ons, components, or modules
- Are OK with a more complex configuration
... then NGINX might be a good fit for you.
If you are ...
- Using traditional MySQL/PHP applications, such as WordPress or Drupal
- Planning to host many websites with different configurations per site through an .htaccess
- Are more comfortable with a platform that is very well known and documented
- Want access to a variety of different modules, add-ons, and components
- Want your web server to work right out of the box
... then you probably want to stick with Apache.
Here's a good rule of thumb: If you want to run ONE site at lightning speed on an advanced configuration, NGINX is probably the server for you. If you want to run MANY sites with easy configuration and flexibility, Apache is still your bread and butter.
At the end of the day, both are a good fit for most sites. Apache is included with all major Linux distributions and requires much less configuration. However, most benchmarks have clocked NGINX at serving websites faster. You can also see some configurations that run both — it's all up to you as the admin.
Pre-flight check
Before we begin, let's make sure we have everything we need.In order to perform this task, you’ll need an active Fedora server, as well as an SSH client such as PuTTY (for Windows) or Terminal (Mac). We recommend a GoDaddy VPS if you’re just getting started, or a full dedicated server if you’re ready to take total control.
A domain. We will, of course, need to tie a domain to your NGINX web server, so we'll need a domain to use. All of our examples will use the domain nginxsite.com. When going through the article, replace any instance of nginxsite.com with the domain you want to use for your site.
Make sure you can connect to the server through SSH. You can find instructions here. If this is step is a challenge, then I'll level with you — this article might not be for you.
A browser window open to your search engine of choice. Unlike Apache, NGINX has a lot of custom tinkering that you might need to do according to your needs as webmaster, and other variables that this article not account for. But this shouldn't phase you — you're a sysadmin, and search engines are your ally.
If all of these elements are in place, we're ready for take-off. Let's set up NGINX.
Installing and configuring NGINX on Fedora
Step 1: Turn Apache off
Every major Linux distribution comes packages with Apache by default; its literally integrated into the OS by now (similar to how Windows comes packaged with IIS natively). However, since we are setting up a dedicated space for NGINX, its possible that the existing Apache configuration can cause problems when NGINX is put in its place. What we are going to do is turn Apache off, then configure Apache so that it does not start upon server reboot.
Turning Apache off on a server with live sites will bring those sites down. Act accordingly.
- Log into your server via SSH, then get to the root user by running:
sudo su -
Note: We will remain as the root user for the remainder of the guide.
- Shut Apache Down. This will bring down any current websites that are hosted on the server.
service httpd stop
- Remove Apache from the boot cycle, so that it doesn't try to start up during server boot.
systemctl disable httpd
Note: If you have buyer's remorse later on about NGINX, and want Apache to start on boot again, you can easily correct this previous command by running:
systemctl enable httpd
Apache is now fully shut down, and won't be starting up again until we say so.
Step 2: Install NGINX
Now that Apache is riding off into the sunset, we can start to install NGINX.
- Use yum to install NGINX.
yum -y install nginx
- Start NGINX.
service nginx start
- Tell the server to start NGINX upon reboot.
systemctl enable nginx
Easy! You should now be able to see an NGINX test page by going to http://1.2.3.4, using your IP address for your server.
Step 3: Configure NGINX to serve for your domain
Alrighty, we've switched from the Apache schooner to the NGINX steamboat. Now it's time to get it working for your domain.
Create a new user for the webspace
Before doing anything, we need to create a UNIX user for your webspace.
- Type the following command to create your user:
useradd
To demonstrate, I'll add my user nginxsite:
useradd nginxsite
- Give this user a password with the following:
passwd
//for our example:
passwd nginxsite
- You will then be prompted to set the password for this user.
Your characters won't register in the terminal when you type — it's just Linux protecting you by not logging the password entry. Follow safe password practices. Your user should now be properly set up.
Create a new directory for the site DocumentRoot
Next, we need to create the directory that will act as the DocumentRoot for this website. It is a good idea to follow a standard naming convention if you are hosting multiple websites.
- We'll follow the standard used by cPanel, and make our DocumentRoot based on the name public_html, like so:
mkdir -p /var/www/nginxsite.com/public_html
- Let's create a test index.html in this directory so that we have something to look at when we test the configuration later:
vim /var/www/nginxsite.com/public_html/index.html
- Use the HTML below the fold for this test index file:
www.nginxsite.com
Success! Nginx is properly serving on this domain!
Now that our directory and test index is created, we must give ownership of that directory over to the user in question.
So following our previous example:
chown -R nginxsite:nginxsite /var/www/nginxsite.com/public_html
Now set permissions for this folder so that it can be viewed by the outside world:
chmod 755 /var/www/nginxsite.com/public_html
Our directory is now set up, and we have a test index.html file to use.
Configure NGINX to recognize new VirtualHosts (Server Blocks)
Now for the fun part. Configuring a VirtualHost for NGINX is very similar to Apache, though the layout of the configuration file is a bit different. Also, in NGINX, they are referred to as 'server blocks,' and not the Apache VirtualHost label. It is worth noting that when editing an Apache configuration file we are editing XML. With NGINX, we are actually editing the C code.
- First, we need to set up our directories where the server blocks will live:
mkdir /etc/nginx/sites-available
mkdir /etc/nginx/sites-enabled
Note: In theory, instead of doing this by having a directory tree, you could simply edit the global configuration file. However, by setting up a directory tree (which is what Debian-based Linux distros, such as Ubuntu will do), it allows for an easier configuration down the line as more website are added.
- Tell NGINX to use look at those directories for the server blocks. Open the global NGINX configuration file in the text editor of your choice; we will use vim:
vim /etc/nginx/nginx.conf
- Add these lines to the end of the http {} block, then save the file:
include /etc/nginx/sites-enabled/*.conf;
server_names_hash_bucket_size 64;
Great. Now NGINX can recognize the server block.
Configure the actual NGINX server blocks
- Create a new file specifically for the server block for your site. The line below will do this and open it in vim:
vim /etc/nginx/sites-available/nginxsite.com.conf
- Paste a new NGINX server block in here. It should look like this:
Example NGINX server block
server { listen 80; server_name nginxsite.com www.nginxsite.com; location / { root /var/www/nginxsite.com/public_html; index index.html index.htm; try_files $uri $uri/ =404; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } }
Let's break down a few important parts of this: server_name: This is the domain you will be using for your site. Instead of localhost, we will use the public facing domain and www version of the domain you want to use, like so: server_name nginxsite.com www.nginxsite.com; root: This should be set to the directory where the files live. In our example this can be changed to /var/www/nginxsite.com/public_html root /var/www/nginxsite.com/public_html; try_files: This is something we need to add in the location block. What we are doing here is telling the server to display a 404 error when a given file is not found. So you'll place this right under the index definition, before the closing } bracket:
try_files $uri $uri/ =404;
- Create your server block using these parameters, then save and close the file.
- Create a symbolic link between sites-available and sites-enabled:
ln -s /etc/nginx/sites-available/nginxsite.com.conf /etc/nginx/sites-enabled/nginxsite.com.conf
- Restart NGINX:
service nginx restart
You're done! Provided your DNS and/or hosts file is pointed for your domain, you should now be able to go to the domain in a web browser and see the test HTML page we created earlier.
In with the new
Out with the old, and in with the new. You have successfully disabled Apache on your system, and substituted it with the sleek and sexy NGINX web server. You're now ready to start tinkering and deploying sites of all different kinds on top of the NGINX server. Common web stacks using NGINX include LEMP, Django/Bottle/Flask, Ruby/Rails/Passenger —whatever your heart desires! As always, there will likely be more advanced configuration you want to do with NGINX to optimize the web server for your site. We highly suggest reviewing the documentation with NGINX for any additional configuration you may want to do on the web server. Otherwise, happy developing!