Nginx packt pdf

The following example specifies the prefix, user, group, paths, disables some modules, enables some others, and includes a couple of third-party modules:. Following a lot of output showing what configure was able to find on your system, a summary is printed out as follows:. As you can see, configure found all the items we were looking for, and acknowledged our preferences for certain paths. Now you can build your nginx and install it, as mentioned at the beginning of the chapter.

By compiling your own binary, you are able to tailor what functionality your nginx will provide. Building and installing software will not be new to you, so not a lot of time was spent on creating a build environment or making sure that all dependencies were present. An NGINX installation should be one that fits your needs, so feel free to enable or disable modules as you see fit. Dimitri Aivaliotis is a production engineer in Silicon Valley. His career has taken him from building a Linux-based computer network for a school up through multi-datacenter, high-availability infrastructures for banks and popular websites.

Make the most of your infrastructure and serve pages faster than ever with Nginx. Publication date: July Publisher Packt. Pages ISBN Chapter 1. Linux deb-based sudo apt-get install nginx Copy.

Note The sudo command is representative of what you need to execute on your operating system to achieve superuser root privileges. Preparing a build environment. Compiling from source. Table — Common configure options. Not recommended for production systems. Table — Configure options for optimization. Configuring for web or mail service. Configure options for a mail proxy. Table: Mail configure options. Option Explanation --with-mail This will enable the mail module, which is not activated by default.

Configure options to specify paths. Table — HTTP configuration options. Configuring SSL support. Enabling various modules. Table — HTTP module configure options. Disabling unused modules.

Table — Disable configure options. Finding and installing third-party modules. Download the module. Unpack the source. Adding support for Lua. Putting it all together. Browse publications by this author. This daemon functions on the principle of runlevels , which represent the state of the computer. Here is a table representing the various runlevels and their signification:. You can manually initiate a runlevel transition: use the telinit 0 command to shut down your computer or telinit 6 to reboot it.

For each runlevel transition, a set of services are executed. This is the key concept to understand here: when your computer is stopped, its runlevel is 0. When you turn it on, there will be a transition from runlevel 0 to the default computer start up runlevel. So let us summarize.

When you start your computer running CentOS, it operates a transition from runlevel 0 to runlevel 3. That transition consists of starting all services that are scheduled for runlevel 3. The question is—how to schedule a service to be started at a specific runlevel?

For each runlevel, there is a directory containing scripts to be executed. If you enter these directories rc0. Service startup scripts will indeed be placed in init.

An init script, also known as the service start up script or even SysV script, is a shell script respecting a certain standard. The script will control a daemon application by responding to commands such as start , stop , and others, which are triggered at two levels.

Firstly, when the computer starts, if the service is scheduled to be started for the system runlevel, the init daemon will run the script with the start argument. The other possibility for you is to manually execute the script by calling it from the shell:. The script must accept at least the start , stop , restart , force-reload , and status commands as they will be used by the system to respectively start up, shut down, restart, forcefully reload the service, or inquire its status.

However, for enlarging your field of action as a system administrator, it is often interesting to provide further options, such as a reload argument to reload the service configuration or a try-restart argument to stop and start the service again.

We will thus create a shell script for starting and stopping our Nginx daemon and also restarting and reloading it. The purpose here is not to discuss Linux shell script programming, so we will merely provide the source code of an existing init script, along with some comments to help you understand it. Due to differences in the format of the init scripts from one distribution to another, we will here discover two separate scripts: this first one is meant for older Debian-based distributions before they were switched to Systemd.

In the file you just created, copy the following script carefully. Make sure that you change the paths to make them correspond to your actual setup. You will need root permissions to save the script into the init.

The complete init script for Debian-based distributions can be found in the code bundle. Due to the system tools, shell programming functions, and specific formatting that it requires, the previously described script is only compatible with older Debian-based distributions. If your server is operated by a SystemD-based distribution such as CentOS, Fedora, newer Debian-based and many more, you will need an entirely different script.

The complete init script for SystemD-based distributions can be found in the code bundle. Placing the file in the init. There are additional steps that will be required for enabling the service. First of all, you need to make the script executable. So far, it is only a piece of text that the system refuses to run.

Granting executable permissions on the script is done with the chmod command:. If you created the file as the root user, you will need to be logged in as root to change the file permissions.

The last step here will be to make it so the script is automatically started at the proper runlevels. Unfortunately, doing this entirely depends on what operating system you are using. For the Debian based distribution, a simple command will enable the init script for the system runlevel:.

This command will create links in the default system runlevel folders. For the reboot and shutdown runlevels, the script will be executed with the stop argument; for all other runlevels, the script will be executed with start.

You can now restart your system and see your Nginx service being launched during the boot sequence. For the Red Hat-based systems family, the command differs, but you get an additional tool for managing system startup. Adding the service can be done via the following command:. Another tool will be useful to you for managing system services, namely, ntsysv.

It lists all services scheduled to be executed on system startup and allows you to enable or disable them at will:. Prior to using ntsysv , you must first run the chkconfig nginx on command, otherwise nginx will not appear in the list of services. The announcement came as a surprise for the open source community but several companies quickly jumped on the bandwagon and reported amazing improvements in terms of performance and scalability.

Nginx, Inc. The product is developed and supported by the core engineering team at Nginx Inc. As business requirements continue to evolve rapidly, such as the shift to mobile and the explosion of dynamic content on the Web, CIO's are continuously looking for opportunities to increase application performance and development agility, while reducing dependencies on their infrastructure. NGINX Plus provides a flexible, scalable, uniformly applicable solution that was purpose built for these modern, distributed application architectures.

Professional support from the Nginx team is included and discounts can be offered for multiple-instance subscriptions. This book covers the open source version of Nginx only and does not detail advanced functionality offered by Nginx Plus. This chapter covered a number of critical steps.

We first made sure that your system contained all the required components for compiling Nginx. We then proceeded to select the proper version branch for your usage — will you be using the stable version or a more advanced yet potentially less stable one?

After downloading the source and configuring the compilation process by enabling or disabling features and modules such as SSL, GeoIP, and more, we compiled the application and installed it on the system in the directory of your choice. We created an init script and modified the system boot sequence to schedule for the service to be started.

From this point on, Nginx is installed on your server and automatically starts with the system. Your web server is functional, though it does not yet answer the most basic functionality — serving a website. The first step towards hosting a website will be to prepare a suitable configuration file.

The next chapter will cover the basic configuration of Nginx and will teach you how to optimize performance based on the expected audience and system resources. Martin Fjordvald is a year-old Danish entrepreneur who started his company straight out of high school.

Backed by a popular website, he became a jack of all trades having to deal with the business, programming, and marketing side of his business. The popularity of his website grew and so did the performance requirements of his code and servers.

He got involved with the community project to document Nginx early on and has written several blog posts and wiki articles detailing how Nginx works. After teaching computer science, programming, and systems administration at several eastern Chinese universities, he worked as a technology consultant in France, specialized in the web and.

NET software development as well as Linux server administration. Since , he has also been administering a major network of websites in his spare time, which allowed him to discover Nginx.

Clement now works as CTO. From fundamentals and design patterns to the different strategies for creating secure and reliable architectures in AWS cloud, learn everything you need to become a successful solutions architect. Learn algorithms for solving classic computer science problems with this concise guide covering everything from fundamental algorithms, such as sorting and searching, to modern algorithms used in machine learning and cryptography.

Get started with Docker on your local machine and progress towards deploying useful applications in production with this simplified, practical guide. About this book Nginx is a lightweight HTTP server designed for high-traffic websites, with network scalability as the primary objective. Publication date: February Publisher Packt. Pages ISBN Chapter 1. Downloading and Installing Nginx. Installing via package managers Downloading and installing the prerequisites for compiling Nginx binaries Downloading a suitable version of the Nginx source code Configuring Nginx compile-time options Controlling the application with an init script Configuring the system to launch Nginx automatically on startup A quick overview of the possibilities offered by the Nginx Plus platform.

Installing via package managers. Nginx provided packages. Compiling from source. GNU Compiler Collection. The PCRE library. Note Both components are already present on the system. The zlib library. Note Please be aware of the laws and regulations in your own country. Downloading Nginx. Websites and resources. Version branches. Stable version : This version is usually recommended, as it is approved by both developers and users, but is usually a little behind the mainline version.

Mainline version : This is the latest version available for download and comes with the newest developments and bug fixes. It was formerly known as the development version. Although it is generally solid enough to be installed on production servers, there is a small chance that you will run into the occasional bug.

As such, if you favor stability over novelty, going for the stable version is recommended. Legacy version : If, for some reason, you are interested in looking at the older versions, you will find several of them.

Serving static and index files, auto indexing; open file descriptor cache; accelerated reverse proxying with caching; load balancing and fault tolerance. Downloading and extracting. Configure options.

The easy way. Path options. The base folder in which Nginx will be installed. The path where the Nginx binary file should be installed. The path of the main configuration file. Directory used for storing temporary files generated by client requests. Location of the temporary files used by the proxy. Location of the application build. Prerequisite options. Specifies an alternate location for the C compiler.

Specifies an alternate location for the C preprocessor. Defines additional options to be passed to the C compiler command line. Defines additional options to be passed to the C linker command line. Should be enabled if planning to use dynamic modules.

Allows you to specify the path of the PCRE library source code. Additional options for building the PCRE library. Specifies the path to the zlib library sources.

By the time you've read this book, you will be able to adapt and use a wide variety of NGINX implementations to solve any problems you have. NGINX is a powerful software suite which has progressed well beyond a basic web server package.

Some of the additional features, such as the reverse proxy and load balancing options, are well known. Originally designed to tackle the C10k problem of handling 10, concurrent connections, NGINX differentiated itself from Apache with an event-driven architecture. While Apache 2. This book describes how to use NGINX in a number of different scenarios and is aimed at providing you with a working solution rather than being an in-depth review of all NGINX features.

Since the mainline release currently 1. The stable and mainline branches don't necessarily reflect system stability, but configuration and module integration stability. Unless you have third-party integration which requires the stable release, we highly recommend the mainline release.

Different Linux distributions have varying package managers, so we'll briefly cover the installation procedures for the more commonly used ones. If the distribution you use isn't covered here, refer to the official NGINX documentation for further guidance.

Replace codename with the release name; for example, if you're using Debian 8, this will be set to jessie. Replace codename with the release name; for example, if you're using Ubuntu Although having the precompiled packages is nice, not all of the modules are available out of the box.

You can simply build from source without any of the packaging tools for CentOS or Debian, however, it makes upgrades and compatibility more difficult.

My preference is to base the build on the official package sources, rather than the plain source code. There aren't many extra steps involved, but it makes the ongoing management much easier.

If you're looking for vanilla build instructions without packages , these are easily available on the web. This will install quite a few packages on your system, so if you're trying to keep your production environment lean, then I'd recommend that you use a separate build box to complete this.

Once you have the required build dependencies, we can now get a copy of the source code. Again, rather than the plain TAR file, we're going to get the packaged variant so that we can easily build them. Here's how we do it:. You should now have a directory with the original TAR file, the Debian description, and any Debian specific patches. The apt-get source command will automatically extract and apply patches, as required, into a source directory. Compiling the code may take a while, depending on how many processors your workstation or server has.

Once it has compiled, you should see two binaries in the parent nginxbuild directory. The resulting files should be:. In this example, we'll be using a CentOS 7-based release. Once all of the development packages have been downloaded, we can now extract the files from the SRPM:. Nginx will print the configure-time options. This is shown in the following:. Using the output of the preceding command, reproduce the entire build environment, including the Nginx source tree of the corresponding version and modules that were included into the build.

Here, the output of the Nginx -V command is trimmed for simplicity. In reality, you will be able to see and copy the entire command line that was passed to the configuration script at the build time. You might even want to reproduce the version of the compiler used in order to produce a binary-identical Nginx executable file we will discuss this later when discussing how to troubleshoot crashes. Once this is done, run the. When Nginx is installed, we can quickly study the structure of the installation.

This will help you to know your installation better and manage it more confidently. For each installation method, we have a set of generic locations and default paths. Let's see what these default locations contain. This folder contains the main configuration file and a set of parameter files. The following table describes the purpose of each of the default parameter files:. This contains the default proxy module parameters. This parameter set is required for certain web servers when they are behind Nginx, so that they can figure out they are behind a proxy.

These are the Cyrillic character set conversion tables. The default configuration contains references to this site as root. It is not recommended that you use this directory for real sites, as it is not a good practice for the Nginx folders hierarchy to contain the site hierarchy. Use this directory for testing purposes or for serving auxiliary files. This is the location of virtual host configuration files.

The recommended structure of this folder is to have one file per virtual host in this folder or one folder per virtual host, containing all files related to this virtual host.

In this way, you will always know which files were used and which are now being used, and what each of the files contain and which files can be purged.

This is the location for Nginx log files. The default access log file and error log file will be written to this location.

Nginx uses temporary files for receiving large request bodies, and proxies large files from upstream. Files that are created for this purpose can be found in this folder. Now that you know how to install Nginx and the structure of its installation, we can study how to configure Nginx. Simplicity of configuration is one of the reasons Nginx is popular among webmasters, because this saves them a lot of time.

In a nutshell, Nginx configuration files are simply sequences of directives that can take up to eight space-separated arguments, for example:. In the configuration file, the directives are delimited by a semicolon ; from one another. Some of the directives may have a block instead of a semicolon. A block can contain arbitrary text data, for example:.

A block can also contain a list of other directives. In this case, the block is called a section. A section can enclose other sections, thus establishing a hierarchy of sections. Most important directives have short names; this reduces the effort required to maintain the configuration file. In general, a directive can have arbitrary quoted or unquoted strings as arguments. But many directives have arguments that have common value types. To help you quickly get your head around the value types I listed them in the following table:.

Variables are named objects that can be assigned a textual value. Variables can only appear inside the http section. Alternatively, a variable reference can enclose a variable name in curly brackets to prevent merging with surrounding text. This is equivalent to the following:. The captures are specified in a regular expression using round brackets.

The preceding configuration will set the HTTP header X-Version-Name in the forwarded request to the value of the ver query argument in the original request. Variables must be declared by Nginx modules before they can be used in the configuration. Built-in Nginx modules provide a set of core variables that allow you to operate with the data from HTTP requests and responses. Refer to the Nginx documentation for the complete list of core variables and their functions.

Third-party modules can provide extra variables. These variables have to be described in the third-party module's documentation. Any Nginx configuration section can contain inclusions of other files via the include directive. This directive takes a single argument containing a path to a file to be included, as shown here:. Once specified, the include directive instructs Nginx to process the contents of the file or files specified by the argument of this directive as if they were specified in place of the include directive.

Relative paths are resolved with respect to the path of the configuration file the directive is specified in. This is good to keep in mind when the include directive is specified in another included file, such as when a virtual host configuration file contains a relative include directive.

The include directive can also contain a globbed path with wild cards, either relative or absolute. In this case, the globbed path is expanded and all files matching the specified pattern are included in no particular order. Take a look at the following code:. The include directive with wild cards is an obvious solution for including site configurations, as their number can vary greatly. Using the include directive, you can properly structure the configuration file or reuse certain parts multiple times.

A section is a directive that encloses other directives in its block. Each section's delimiters must be located in the same file, while the content of a section can span multiple files via the include directive.

It is not possible to describe every possible configuration directive in this chapter. Refer to the Nginx documentation for more information. However, I will quickly go over the Nginx configuration section types so that you can orient in the structure of the Nginx configuration files. It has the server and upstream declarations. As far as individual directives are concerned, the http section usually contains those that specify defaults for the entire HTTP service.

The http section must contain at least one server section in order to process HTTP requests. Here is a typical layout of the http section:. Here and in other examples of this book, we use […] to refer to omitted irrelevant parts of the configuration. At the end of the configuration stage, all listening addresses are grouped together and all listening addresses are activated at startup. The server section contains the location sections, as well as sections that can be enclosed by the location section see description of other sections types for details.

Directives that are specified in the server section itself go into the so-called default location. In that regard, the server section serves the purpose of the location section itself.