Введение в NGINX для разработчиков

Представьте себе: вы создали веб-приложение и теперь ищете подходящий веб-сервер для его размещения.

Ваше приложение может состоять из нескольких статических файлов - HTML, CSS и JavaScript, серверной службы API или даже нескольких веб-служб. Возможно, вы ищете Nginx, и для этого есть несколько причин.

NGINX - это мощный веб-сервер, использующий непоточную архитектуру, управляемую событиями, которая позволяет ему превзойти Apache при правильной настройке. Он также может выполнять другие важные функции, такие как балансировка нагрузки, кеширование HTTP или использоваться в качестве обратного прокси.

В этой статье я расскажу о нескольких основных шагах по установке и настройке наиболее распространенных частей NGINX.

Базовая установка - Архитектура

Есть два способа установить NGINX: либо с помощью предварительно созданного двоичного файла, либо с его помощью из исходного кода.

Первый метод намного проще и быстрее, но его создание из исходного кода дает возможность включать различные сторонние модули, которые делают NGINX еще более мощным. Это позволяет нам настраивать его в соответствии с потребностями приложения.

Единственное, что вам нужно сделать, чтобы установить готовый пакет Debian:

sudo apt-get update
sudo apt-get install nginx

После завершения процесса установки вы можете убедиться, что все в порядке, выполнив приведенную ниже команду, которая должна распечатать последнюю версию NGINX.

sudo nginx -v
nginx version: nginx/1.6.2

Ваш новый веб-сервер будет установлен в папку /etc/nginx/. Если вы войдете в эту папку, вы увидите несколько файлов и папок. Наиболее важные из них, которые потребуют нашего внимания позже, - это файл nginx.conf и папка sites-available.

Настройки конфигурации

Основные настройки NGINX находятся в файле nginx.conf, который по умолчанию выглядит так.

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

events {
	worker_connections 768;
	# multi_accept on;
}

http {

	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;
	keepalive_timeout 65;
	types_hash_max_size 2048;
	# server_tokens off;

	# server_names_hash_bucket_size 64;
	# server_name_in_redirect off;

	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";

	# gzip_vary on;
	# gzip_proxied any;
	# gzip_comp_level 6;
	# gzip_buffers 16 8k;
	# gzip_http_version 1.1;
	# gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

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

Файл разбит на контексты. Первый - это контекст события, а второй - контекст http. Эта структура позволяет использовать некоторые дополнительные уровни вашей конфигурации, поскольку каждый контекст может иметь другие вложенные контексты, которые наследуют все от своего родителя, но также могут переопределять настройку по мере необходимости.

Различные вещи в этом файле могут быть изменены в зависимости от ваших потребностей, но NGINX настолько прост в использовании, что вы можете согласиться даже с настройками по умолчанию. Некоторые из наиболее важных частей конфигурационного файла NGINX:

• worker_processes: этот параметр определяет количество рабочих процессов, которые NGINX будет использовать. Поскольку NGINX является однопоточным, это число обычно должно быть равно количеству ядер ЦП.
• worker_connections: это максимальное количество одновременных подключений для каждого рабочего процесса, которое сообщает нашим рабочим процессам, сколько людей может одновременно обслуживаться NGINX. Чем он больше, тем больше пользователей NGINX сможет обслуживать одновременно.
• access_log и error_log: это файлы, которые NGINX будет использовать для регистрации любых ошибок и попыток доступа. Эти журналы обычно проверяются на предмет отладки и устранения неполадок.
• gzip: это настройки сжатия GZIP ответов NGINX. Включение этого параметра вместе с различными вложенными настройками, которые по умолчанию закомментированы, приведет к довольно большому повышению производительности. В под-настройках GZIP следует обратить внимание на gzip_comp_level, который представляет собой уровень сжатия и находится в диапазоне от 1 до 10. Как правило, это значение не должно быть выше 6 - выигрыш с точки зрения уменьшения размера незначителен, так как ему требуется гораздо больше загрузки ЦП. gzip_types - это список типов ответов, к которым будет применено сжатие.

Ваша установка NGINX может поддерживать гораздо больше, чем один веб-сайт, а файлы, определяющие сайты вашего сервера, находятся в каталоге / etc / nginx / sites-available.

Однако файлы в этом каталоге не являются «живыми» - здесь вы можете иметь столько файлов определений сайта, сколько захотите, но NGINX на самом деле ничего не будет с ними делать, если они не привязаны к файлу / etc / nginx / site-enabled каталог (вы также можете скопировать их туда, но символьная ссылка гарантирует, что будет отслеживаться только одна копия каждого файла).

Это дает вам способ быстро подключать веб-сайты и переводить их в автономный режим без фактического удаления каких-либо файлов - когда вы готовы к подключению сайта к сети, сделайте символическую ссылку на сайты с поддержкой и перезапустите NGINX.

Каталог sites-available содержит конфигурации для виртуальных хостов. Это позволяет настроить веб-сервер для нескольких сайтов, имеющих разные конфигурации. Сайты в этом каталоге не работают и будут доступны только в том случае, если мы создадим символическую ссылку на папку sites-enabled.

Либо создайте новый файл для своего приложения, либо отредактируйте файл по умолчанию. Типичная конфигурация выглядит так, как показано ниже.

upstream remoteApplicationServer {
    server 10.10.10.10;
}

upstream remoteAPIServer {
    server 20.20.20.20;
    server 20.20.20.21;
    server 20.20.20.22;
    server 20.20.20.23;
}


server {
    listen 80;
    server_name www.customapp.com customapp.com
    root /var/www/html;
    index index.html

        location / {
            alias /var/www/html/customapp/;
            try_files $uri $uri/ =404;
        }

        location /remoteapp {
            proxy_set_header   Host             $host:$server_port;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
            proxy_pass http://remoteAPIServer/;
        }

        location /api/v1/ {
            proxy_pass https://remoteAPIServer/api/v1/;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
            proxy_redirect http:// https://;
        }
}

Подобно nginx.conf, здесь также используется концепция вложенных контекстов (и все они также вложены в контекст HTTP файла nginx.conf, поэтому они также наследуют все от него).

Контекст server определяет конкретный виртуальный сервер для обработки запросов ваших клиентов. У вас может быть несколько серверных блоков, и NGINX будет выбирать между ними на основе директив listen и server_name.

Внутри блока сервера мы определяем несколько контекстов местоположения, которые используются для принятия решения о том, как обрабатывать клиентские запросы. Каждый раз, когда приходит запрос, NGINX пытается сопоставить свой URI с одним из этих определений местоположения и обрабатывать его соответствующим образом.

Есть много важных директив, которые можно использовать в контексте местоположения, например:

• try_files будет пытаться обслуживать статический файл, находящийся в папке, которая указывает на корневую директиву.
• proxy_pass отправит запрос на указанный прокси-сервер.
• rewrite перезапишет входящий URI на основе регулярного выражения, чтобы другой блок местоположения мог его обработать.

Контекст восходящего потока определяет пул серверов, на которые NGINX будет передавать запросы. После того, как мы создадим блок восходящего потока и определим внутри него сервер, мы можем ссылаться на него по имени внутри наших блоков местоположения. Кроме того, в восходящем контексте может быть назначено множество серверов, так что NGINX будет выполнять некоторую балансировку нагрузки при проксировании запросов.

Запустить NGINX

После того, как мы закончили настройку и переместили наше веб-приложение в соответствующую папку, мы можем запустить NGINX, используя следующую команду:

sudo service nginx start

После этого, когда мы что-то меняем в нашей конфигурации, нам нужно только перезагрузить ее (без простоя), используя команду ниже.

service nginx reload

Наконец, мы можем проверить статус NGINX, используя команду ниже.

service nginx status

Заключение

Благодаря такому количеству готовых функций NGINX может быть отличным способом обслуживания вашего приложения или даже использоваться в качестве HTTP-прокси или балансировщика нагрузки для других ваших веб-серверов. Понимание того, как NGINX работает и обрабатывает запросы, даст много возможностей для масштабирования и балансировки нагрузки ваших приложений.