Sign In Start Free Trial
Account

Add to playlist

Create a Playlist

Modal Close icon
You need to login to use this feature.
  • Book Overview & Buying Mastering NGINX
  • Table Of Contents Toc
  • Feedback & Rating feedback
Mastering NGINX

Mastering NGINX - Second Edition

By : Aivaliotis
5 (1)
close
close
Mastering NGINX

Mastering NGINX

5 (1)
By: Aivaliotis

Overview of this book

NGINX is a high-performance HTTP server and mail proxy designed to use very few system resources. But despite its power it is often a challenge to properly configure NGINX to meet your expectations. Mastering Nginx is the solution – an insider’s guide that will clarify the murky waters of NGINX’s configuration. Tune NGINX for various situations, improve your NGINX experience with some of the more obscure configuration directives, and discover how to design and personalize a configuration to match your needs. To begin with, quickly brush up on installing and setting up the NGINX server on the OS and its integration with third-party modules. From here, move on to explain NGINX's mail proxy module and its authentication, and reverse proxy to solve scaling issues. Then see how to integrate NGINX with your applications to perform tasks. The latter part of the book focuses on working through techniques to solve common web issues and the know-hows using NGINX modules. Finally, we will also explore different configurations that will help you troubleshoot NGINX server and assist with performance tuning.
Table of Contents (15 chapters)
close
close
10
A. Directive Reference
13
D. Persisting Solaris Network Tunings
14
Index

Installing NGINX from source

NGINX downloads are available for two separate branches of NGINX code—mainline and stable. The mainline branch is the one in which active development is taking place. Here is where new features will be found and integrated before finding their way into the stable branch. When a mainline version is released, it has undergone the same QA and a similar set of functional tests as the stable branch, so either branch may be used on production systems. The major difference between the two branches lies in the support of third-party modules. The internal API may change in the mainline release, whereas it stays the same on the stable branch, so backward compatibility for third-party modules is only available for stable releases.

Preparing a build environment

In order to compile NGINX from source, certain requirements need to be met on your system. Besides a compiler, you also need the OpenSSL and Perl Compatible Regular Expressions (PCRE) libraries and development headers if you want to enable SSL support and be able to use the rewrite module, respectively. The rewrite module is enabled by default, so if you don't have PCRE libraries and headers, you'll need to disable the rewrite module during the configuration phase. Depending on your system, these requirements may already be met in the default installation. If not, you will need to both locate the appropriate package and install it, or download the source, unpack it, and point NGINX's configure script to this location.

NGINX will attempt to build a dependent library statically if you include a --with-<library>=<path> option to configure. You might do this if you want to ensure that NGINX is not dependent on any other part of the system and/or would like to squeeze that extra bit of performance out of your nginx binary. If you are using features of external libraries that are only available from a certain version onwards (for example, the next protocol negotiation TLS extension available from OpenSSL Version 1.0.1), then you have to specify the path to the unpacked sources of that particular version.

There are other, optional, packages that you can provide support for, if you like. These include MD5 and SHA-1 hashing algorithm support, zlib compression, and libatomic library support. The hashing algorithms are used in many places in NGINX, for example, to compute the hash of a URI to determine a cache key. The zlib compression library is used for delivering gzipped content. If the atomic_ops library is available, NGINX will use its atomic memory update operations to implement high-performance memory-locking code.

Compiling from source

NGINX can be downloaded from http://nginx.org/en/download.html. Here you will find the source of either branch in .tar.gz, or .zip format. Unpack the archive into a temporary directory as follows:

$ mkdir $HOME/build
$ cd $HOME/build && tar xzf nginx-<version-number>.tar.gz

Configure it using the following command:

$ cd $HOME/build/nginx-<version-number> && ./configure

And compile it as follows:

$ make && sudo make install

When compiling your own nginx binary, you are much more free to include only what you need. Can you already say under which user NGINX should run? Do you want to specify the default log file locations so that they don't need to be explicitly set in the configuration? The following table of configure options will help you design your own binary. These are options that are valid for NGINX, independent of which module is activated.

Table – Common configure options

Option

Explanation

--prefix=<path>

The root of the installation. All other installation paths are relative to this one.

--sbin-path=<path>

The path to the nginx binary. If not specified, this will be relative to the prefix.

--conf-path=<path>

The path to where nginx will look for its configuration file, if not specified on the command line.

--error-log-path=<path>

This is where nginx will write its error logfile, unless configured otherwise.

--pid-path=<path>

This is where nginx will write the pid file of the master process, usually under /var/run.

--lock-path=<path>

The path to the shared memory mutex lock file.

--user=<user>

The user under which the worker processes should run.

--group=<group>

The group under which the worker processes should run.

--with-file-aio

Enables asynchronous I/O for FreeBSD 4.3+ and Linux 2.6.22+.

--with-debug

This option will enable debug logging. Not recommended for production systems.

You are also able to compile with optimizations that you may not get in a packaged installation. This is where the following options can be especially useful:

Table – Configure options for optimization

Option

Explanation

--with-cc=<path>

If you would like to set a C compiler that is not in your default PATH.

--with-cpp=<path>

This is the corresponding path to the C preprocessor.

--with-cc-opt=<options>

Here is where the path to the necessary include files may be indicated (-I<path>), as well as optimizations (-O4) and specifying a 64-bit build.

--with-ld-opt=<options>

The options to the linker include library path (-L<path>) and run path (-R<path>).

--with-cpu-opt=<cpu>

A build specific to a particular CPU family may be specified with this option.

Configuring for web or mail service

NGINX is unique among high-performing web servers in that it was also designed to be a mail proxy server. Depending on your goals in building NGINX, you can configure it for web acceleration, a web server, a mail proxy, or all three. It may be beneficial to have one package that you can install on any server in your infrastructure and be able to set NGINX's role through configuration, or it may serve your needs better to have a slimmed-down binary to use in high-performance environments where every extra KB counts.

Configure options for a mail proxy

The following table specifies configuration options that are unique to the mail module.

Table: Mail configure options

Option

Explanation

--with-mail

This will enable the mail module, which is not activated by default.

--with-mail_ssl_module

In order to proxy any kind of mail transaction that uses SSL/TLS, this module will need to be activated.

--without-mail_pop3_module

When enabling the mail module, the POP3 module may be disabled separately.

--without-mail_imap_module

When enabling the mail module, the IMAP module may be disabled separately.

--without-mail_smtp_module

When enabling the mail module, the SMTP module may be disabled separately.

--without-http

This option will completely disable the http module; use it if you know you only want to compile in mail support.

For a typical mail proxy, I would recommend configuring NGINX as follows:

$ ./configure --with-mail --with-mail_ssl_module --with-openssl=${BUILD_DIR}/openssl-1.0.1p

SSL/TLS is needed nowadays on almost every mail installation and not having it enabled on a mail proxy robs users of expected functionality. I've recommended compiling OpenSSL statically so that there are no dependencies on the operating system's OpenSSL library. This does mean, though, that you will have to be vigilant and ensure that your statically-compiled OpenSSL is kept up-to-date and rebuild your binary when necessary. The BUILD_DIR variable referenced in the preceding command would of course have to be set beforehand.

Configure options to specify paths

The following table shows what configuration options are available to the http module, from activating the Perl module to specifying the location of temporary directories.

Table – HTTP configuration options

Option

Explanation

--without-http-cache

When using the upstream module, NGINX can be configured to cache the contents locally. This option disables that cache.

--with-http_perl_module

NGINX configuration can be extended by using Perl code. This option activates that module. (Use of this module, however, degrades performance when blocking I/O is done.)

--with-perl_modules_path=<path>

This option specifies the path to additional Perl modules needed for using the embedded Perl interpreter. It may also be specified as a configuration option.

--with-perl=<path>

The path to Perl (Version 5.6.1 and higher), if not found on the default path.

--http-log-path=<path>

The default path to the HTTP access log.

--http-client-body-temp-path=<path>

When receiving the request from the client, this is the directory used as a temporary location for the body of that request. If the WebDAV module is enabled, it is recommended to set this path to be on the same filesystem as the final destination.

--http-proxy-temp-path=<path>

When proxying, this is the directory used as a location to store temporary files.

--http-fastcgi-temp-path=<path>

The location for FastCGI temporary files.

--http-uwsgi-temp-path=<path>

The location for uWSGI temporary files.

--http-scgi-temp-path=<path>

The location for SCGI temporary files.

Visually different images
CONTINUE READING
83
Tech Concepts
36
Programming languages
73
Tech Tools
Icon Unlimited access to the largest independent learning library in tech of over 8,000 expert-authored tech books and videos.
Icon Innovative learning tools, including AI book assistants, code context explainers, and text-to-speech.
Icon 50+ new titles added per month and exclusive early access to books as they are being written.
Mastering NGINX
notes
bookmark Notes and Bookmarks search Search in title playlist Add to playlist font-size Font size

Change the font size

margin-width Margin width

Change margin width

day-mode Day/Sepia/Night Modes

Change background colour

Close icon Search
Country selected

Close icon Your notes and bookmarks

Confirmation

Modal Close icon
claim successful

Buy this book with your credits?

Modal Close icon
Are you sure you want to buy this book with one of your credits?
Close
YES, BUY

Submit Your Feedback

Modal Close icon
Modal Close icon
Modal Close icon