Building a Better Web Platform – Optimizing – Part 5

Building Nginx-1.Latest on Oracle Linux-7.Latest

This is where we get to dive into the technical details, and show commands and configurations. Sometimes it feels weird to share exactly how things are configured. The speed and performance of our configurations is something we sell ourselves on.

That feeling quickly fades when we remember why we are here: To help lead clients to success. Loading complex pages in less than a second is only a tiny part of our platform. It’s something we think every host should strive for. If a company wants to steal our configurations, technical implementations, and all of our business, we say let them. We’re here for the clients. Even if that means sending clients to competitors.

Additionally in the not altruistic sense, our hope is that by submitting our configurations to peer review, we can glean improvements and recommendations that we can pass on to our clients.

Binary Package vs Source Compile

Given the choice between compiling from source and installing from distribution provided packages, we usually favor the package route, due to ease of configuration, patch management and speed.

When it comes to the mission critical software, like Nginx, PHP-FPM, and MariaDB, we usually opt for source compilation. Automatic patches from upstream can be nice… But we tend to ride a couple of versions ahead of the upstream repositories available.

Having control over the features installed and the ability to add in third party patches and software is very important. We pride ourselves on providing a unique performance platform. Such features help us achieve this. Nginx in our platform gives us a solid opportunity to talk about these points. The caching mechanism that we provide, the caching mechanism that helps drive our insane load times, relies on custom compiled addons. This is a setup that would be difficult to replicate, unless we were running our own package management system / repository.

Finally, writing solid documentation about the deployment of system / software allows it to be replicated time after time and usually between versions with little ill-effect.To that end, as I write out this post, I will be doing the steps live on a VM in my local lab just to verify the flow and correctness of steps.

Setting up the Build Environment

When we are installing a distribution of Linux on a VM, especially our web hosts which tend to have larger disks, we like to verify that the installer is not doing anything weird. In simple setups, like the one we will be doing today, we like to keep the system limited closely to one large / root partition. Sometimes the installers can decide to stick all of the available space in /home when automatic partitioning is selected. That’s not something we’ll want for this use case.

Once the fresh login prompt appears after installing the OS, go ahead and log in as root. Our first step will be to get the network to a stable point. For me, that means adding the following to “/etc/sysconfig/network-scripts/ifcfg-eth0”:

Configure Networking

Your mileage may vary here depending on your provider’s network setup. You can check my Wiki for the complex steps we take to configure static IPv4 and IPv6 at our provider.

Patching and Dependencies

We run the following two commands once we have gotten networking operational. The commands install any available updates and install some dependencies required to get Nginx up and running.

Install Updates and Dependencies

The “&&” means “run the next command if this one succeeds” and the “\” allows us to specify the command over several lines for readability. We find the reboot to be good practice to to ensure any new kernels are loaded up successfully.

A Place to Build

The following is a habit I picked up from a professor in college. When he was teaching our Unix Systems Administration class, we had to do a lot of compiling from source. He had a unique way of handling the work space. Something I hated at the time. I wish he would have spent some time explaining why after so many years he had settled on this way of doing things. Perhaps he did and my brazen young mind tuned him out… The system involves creating a “/opt/src” and a “/opt/work” directory. All compilation / etc is done in /opt/src and /opt/work becomes the installation path for all software. At the time I thought that the installed files for any package should be in their “correct” places across the filesystem. Config files in “/etc” and data in “/var”…

A wiser me decided that having all of the files for a given package under a single location made tracking them down much easier. We’ll get into some of this as exemplary anecdotes as we proceed through this build. For the time being, I strongly urge you to take a leap of faith and use the same installation paths we do.

Create Build Area

The “{src,work}” expands to create both directories in a single command.

We need to do some planning here. We don’t want Nginx to run as “root”. Root is a super user and a mistake in the Nginx code would stand to give a malicious user full control of our new server. We don’t want Nginx to run as “nobody” either. We need Nginx to do some writing to the filesystem that is not possible with the nobody user. To this end, we’re going to create a special user: “nginx”.

Add Nginx User

Starting the Build

We need to get the source code for Nginx to get this project rolling. The latest version of Nginx is usually announced at the Nginx Homepage. The link to the latest version can usually be plugged into the code below.

Get the Nginx Source Code

This is where things start to get a little bit real… The general process to compile source code in Linux is to run “./configure && make && make install”. That could serve us well for a bare bones install, but we’d like to specify some custom flags. We aren’t sure which ones yet.

See the Compilation Options

After reviewing the options available we decide to go for some really simple settings at first. We’ll be sure to demonstrate that it is trivial to come back later and add options.

Configure the Compile

The “–prefix” flag tells the compiler where we would like the final product to be installed. The “–user” flag tells the compiler which user to run as and the “group” does the same for … the group.

Observant… observers will notice that we are not including any third party patches or even doing any major tuning. That is correct for two reasons.

1. We want to get a functioning base system online before ripping open the hood
2. Nginx is a fairly polished product and relying on defaults can yield decent results.

Now if you are lucky, there should not be any errors from the configure command. If there are, some googling may reveal a missing package or skipped step. If you hit a wall and can’t find a solution, please feel free to comment here and we will see if we can help out.

Actually Compiling

For being such a short and simple command, this is likely to be the most stressful part. A bunch of text is going to scroll by. That is normal. If we get to the end and the word ERROR doesn’t appear anywhere, then we have succeeded.

Installation

The above command should not be too much trouble. It copies files around. The final step here is to just do some tidying.

Clean Things Up

The “rm” command removes the .tar.gz that we won’t be using anymore. The “ln” command creates a “link” or “shortcut” so that we can address our Nginx installation as /opt/work/nginx instead of including the version number.

Start Nginx

If there is no output, it’s a good sign. We can’t access it just yet though. We need to open access through the firewall.

Open the Firewall with Firewalld

If your system is not running firewalld, we’ll include the iptables statement:

Open the Firewall with IPTABLES

Accessing the New Nginx Instance

Grab a browser and navigate to the IP Address of your new server. You should be greeted with the Nginx Welcome message.

In the next part of the series we will look at configurations and starting Nginx at boot before moving on to customizing it.