Getting up and run with Nginx - Nginx tutorial

1. Introduction #

nginx [engine x] is an HTTP and reverse proxy server, a mail proxy server, and a generic TCP proxy server, originally written by Igor Sysoev.

According to the official definition, nginx is an HTTP server and a reverse proxy server. apache should be familiar to everyone, and nginx is a web server that provides static web pages similar to apache. nginx is an event-based asynchronous IO concurrency model with better performance than apache's multi-process and multi-thread concurrency model. nginx is a lightweight server.

2. Installation #

To install nginx on an ubuntu system, you only need one command.

sudo apt-get install nginx

If you want to compile and install nginx, it's easy to follow the same three-step process.

. /configure
make
sudo make install

The parameters of the installation can be configured according to your needs. For example.

. /configure \
--user=nginx \
--group=nginx \
--prefix=/etc/nginx \
--sbin-path=/usr/sbin/nginx \
--conf-path=/etc/nginx/nginx.conf \
--pid-path=/var/run/nginx.pid \
--lock-path=/var/run/nginx.lock \
--error-log-path=/var/log/nginx/error.log \
--http-log-path=/var/log/nginx/access.log \
--with-http_gzip_static_module \
--with-http_stub_status_module \
--with-http_ssl_module \
--with-pcre \
--with-file-aio \
--with-http_realip_module \
--without-http_scgi_module \
--without-http_uwsgi_module \
--without-http_fastcgi_module

For details on how to compile and install, please refer to this official article configure.

3. Command Line Syntax #

To start, restart, and stop the nginx service is also very simple.

You can do this.

sudo /etc/init.d/nginx restart # or start, stop

Or this.

sudo service nginx restart # or start, stop

Sometimes we change the configuration file just to make it take effect, so you don't have to restart it, just reload it.

sudo nginx -s reload

For more commands, see this article beginners_guide.

4. Configuration file syntax #

nginx is a modular system, and the entire system is divided into modules. Each module is responsible for a different function. For example, http_gzip_static_module is responsible for compression, and http_ssl_module is responsible for encryption. If you don't use a module, you can remove it and make the whole nginx smaller and more suitable for you. The configure directive above comes with a lot of parameters, which is where certain modules can be added or removed before compilation.

The modules you want to use have already been compiled into nginx and become part of it, so how do you use them? This is similar to a traditional linux service, where you change the functionality through a configuration file. nginx modules are used through something called a directive. The entire configuration file is controlled by directives. nginx also has its own built-in directives, such as events, http, server, and location, which will be mentioned below.

For ubuntu systems, the configuration file is stored in /etc/nginx/nginx.conf after installation.

Remove the comments.

user www-data;
worker_processes 1;
pid /run/nginx.pid;

events {
  worker_connections 768;
events { worker_connections 768; }

http {

  sendfile on;
  tcp_nopush on;
  tcp_nodelay on;
  keepalive_timeout 65;
  types_hash_max_size 2048;

  include /etc/nginx/mime.types;
  default_type application/octet-stream;

  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log;

  gzip on;
  gzip_disable "msie6";

  include /etc/nginx/conf.d/*.conf;
  include /etc/nginx/sites-enabled/*;
}

In this file, ignoring the three lines above for now, it is made up of two blocks (blocks).

events {
}

http {
}

mail {
}

Blocks can also be nested between blocks. For example, you can put server under http.

http {
 server {
 }
}

This is the main configuration file. Sometimes just one configuration file is not enough, especially when the configuration file is very large, you can't just stuff all the logic into one file, so the configuration file needs to be managed as well. Look at the last two lines of include, which means that the files ending with conf in the directory /etc/nginx/conf.d/ are automatically included, as well as all the files in the directory /etc/nginx/sites-enabled/.

Under /etc/nginx/conf.d/ there is a configuration file called rails.conf, which reads roughly like this.

upstream rails365 {
    # Path to Unicorn SOCK file, as defined previously
    server unix:///home/yinsigan/rails365/shared/tmp/sockets/unicorn.sock fail_timeout=0;
server}
server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    server_name www.rails365.net;
    root /home/yinsigan/rails365/current/public;
    keepalive_timeout 70;

  ...

    # redirect server error pages to the static page /50x.html
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root html;
    }

  ...
}

server {
  listen 80;
  server_name rails365.net;

  return 301 $scheme://www.rails365.net$request_uri;
}

The final structure of the entire configuration file looks something like this.

# Here is some configuration
...
http {
  # Here are some configurations
  ...
  # This part may exist in the /etc/nginx/conf.d/ directory
  upstream {

  upstream { }
  server {
    listen 8080;
    root /data/up1;

    location / {
    }
  }
  server {
    listen 80;
    root /data/up2;

    location / {
    }
  }
  Here are some configurations
  ...
}

mail {
}

For the sake of space, some of the content is omitted.

There is a hierarchy and inheritance between directives and instructions. For example, the directive within http affects the server.

If you want to deploy a web service now, just add a new file to the /etc/nginx/conf.d/ directory.

http is the same level as events and mail. http is web-related.

server, as the name implies, is a service, for example, you now have a domain name, to deploy a website, then you have to create a server block.

Let's say you have a domain name called foo.bar.com, and you want to be able to access it when you type it in your browser, then you might have to do this.

server {
  listen 80;
  root /home/yinsigan/foo;
  server_name foo.bar.com;
  location / {
  
  }
}

Here's what it means. listen is the port to listen on. If not specified, port 80 is the port normally used by websites.

root is the root directory of the site's source code static files. Generally speaking, the latest html file, such as index.html, will be placed in the directory specified by root.

server_name specifies the domain name.

With these, typing http://foo.bar.com under the browser will allow us to access the content of the index.html file under the directory /home/yinsigan/foo. But sometimes we need to access http://foo.bar.com/articles? Then we need to use a location, like this.

server {
  ...
  server_name foo.bar.com;
  location /articles {

  }
}

Besides http://foo.bar.com/articles, there are also http://foo.bar.com/groups, /menus/1 and many others, do we have to create a location for each of them? We have dynamic methods to handle it.

Here's an example.

server {
    listen 80;
    server_name example.org www.example.org;
    root /data/www;

    location / {
        index index.html index.php;
    index.html index.php; }

    location ~* \. (gif|jpg|png)$ {
        expires 30d;
    }

    location ~ \.php$ {
        fastcgi_pass localhost:9000;
        fastcgi_param SCRIPT_FILENAME
                      $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

When the user visits http://example.org it goes to read /var/root/index.html, if it can't find it it reads index.php and it forwards the logic inside fastcgi_pass. When the user visits http://example.org/about.html it will read the /var/root/about.html file, and by the same token, when the user visits http://example.org/about.gif it will read the /var/root/about.gif file and it will expire after 30 days, i.e. 30 days of caching.

Tags:

Nginx