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

1656661214 vvedenie v nginx dlya razrabotchikov

Стефанос Вардалос

B7YkHifVjD8qcdMg3o2YN3HWqwNcj2UfoTiU

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

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

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

RooSvbKlAWsOjkz8JPactXH-GPf4Pe6DC3Ue
Архитектура NGINX

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

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

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

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

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

sudo apt-get updatesudo apt-get install nginx

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

sudo nginx -vnginx 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:

  • рабочие_процессы: Этот параметр определяет количество рабочих процессов, используемых 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/ каталоге с поддержкой сайтов ( Вы можете скопировать их туда, но символическая ссылка гарантирует наличие только одной копии каждого файла для отслеживания).

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

The 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         }        location /api/v1/ {            proxy_pass             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://         }}

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

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

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

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

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

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

Запустите NGINX

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

sudo service nginx start

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

service nginx reload

Наконец мы можем проверить статус NGINX с помощью команды ниже.

service nginx status

Вывод

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *