Установка и запуск#

CentOS

yum install nginx

Debian

apt install nginx

Для автоматического запуска после загруски системы вводим:

systemctl enable nginx

Запуск службы вручную:

systemctl start nginx

NGINX как HTTP-сервер#

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

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

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

Главный процесс NGINX отвечает за чтение конфигурационного файла, работу с сокетами, запуск рабочих процессов, открытие файлов журналов и компиляции встроенных скриптов на языке Perl. F nfr;t несколько вспомогательных процессов для выполнения специализированных задач. Среди них загрузчик кэша и **диспетчер кэша **.

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

Базовый модуль HTTP#

Модуль http является центральным в NGINX, он отвечает за взаимодействие с клиентами по протоколу HTTP.

Директива server#

Директива server открывает новый контекст. В NGINX сервером по умолчанию называется первый из множества серверов, прослушивающих один и тот же IP-адрес и порт, указанные в директиве listen .

Сервер по умолчанию можно также назначить с помощью параметра default_server в директиве listen.

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

server {
        listen 127.0.0.1:80;
        server_name default.example.com;
        server_name_in_redirect on;
}

server {
        listen 127.0.0.1:80;
        server_name www.example.com;
}

Директива server_name позволяет решить целый ряд задач конфигурирования. По умолчанию ее значение равно “” , то есть секция server без директивы server_name сопоставляется с запросом, в котором отсутствует заголовок Host . Этимможно воспользоваться, например, для отбрасывания запросов без этого заголовка:

server {
        listen 80;
        return 444;
}

Нестандартный код ответа HTTP 444 , использованный в этом примере, заставляет NGINX немедленно закрыть соединение.

Директивы HTTP-сервера

  • port_in_redirect - Определяет, нужно ли указывать данный порт при переадресации средствами NGINX

  • server - Создает новый конфигурационный контекст, определяющий виртуальный хост.

  • listen - определяет один или несколько IP-адресов и портов

  • server_name – значения заголовка Host, которым этот контекст соответствует

  • server_name - Задает имя виртуального хоста

  • server_name_in_redirect - Разрешает использовать первое из указанных в директиве server_name значений при любой переадресации, произведенной NGINX в данном

контексте * server_tokens - разрешает или запрещает включение номера версии NGINX в отправляемые сообщения об ошибках и заго ловок Server (по умолчанию принимает значение on)

Протоколирование#

В NGINX реализована очень гибкая модель протоколирования. На каждом уровне конфигурации может быть свой журнал доступа. Кроме того, на одном уровне можно задавать несколько журналов доступа с разными форматами с помощью директивы log_format . Эта директива, которая должна находиться в секции http , позволяет точно указать, что протоколировать.

  • access_log - Определяет, куда и как записывать журналы доступа.

Первый параметр – путь к файлу журнала. Путь может содержать переменные. Специальное значение off отключает протоколирование. Необязательный второй параметр определяет директив log_format, описывающую формат журнала. Если этот параметр не задан, используется предопределенный формат. Необязательный третий параметр задает размер буфера в случае, если запись в журнал буферизуется.

  • log_format - Определяет состав и формат полей в журнале.

http {
        log_format downloads ‘$time_iso8601 $host $remote_addr ‘ ”$request” $status $body_bytes_sent $request_ time’;
        open_log_file_cache max=1000 inactive=60s;
        access_log logs/access.log;

        server {
                server_name ~^(www\.)?(.+)$;
                access_log logs/combined.log;

                location /downloads {
                        access_log logs/downloads.log downloads;
                }
        }
}

Поиск файлов#

Чтобы ответить на запрос, NGINX передает его обработчику содержимого, определяемому директивой location .

Директива location может стречаться в секции с описанием виртуального сервера и содержит в качестве параметра URI-адрес, поступивший от клиента или в результате внутренней переадресации. Местоположения могут быть вложенными (с несколькими исключениями). Их назначение – определить максимально специализированную конфигурацию для обработки запроса. Местоположение задается следующим образом:

location [модификатор] uri {...}

Можно задавать также именованные местоположения:

location @name {…}

Именованное местоположение доступно только при внутренней переадресации и может быть задано лишь на уровне контекста сервера. При этом сохраняется тот URI, который был перед входом в блок location.

Как осуществляется поиск определяется сочетанием нескольких директив.

  • root - Задает путь к «корню документов». При поиске файлов заданный в запросе URI добавляется в конец этого пути.

Note

Директиву root лучше всего определять внутри сервера по умолчанию или, по крайней мере, вне директив location, чтобы она относилась ко всему серверу

server {
        root /home/customer/html;
        location / {
                index index.html index.htm;
        }
        location /downloads {
                autoindex on;
        }
}

В этом примере возвращаемые файлы следует искать в каталоге /home/customer/html , который считается корневым. Если клиент указал только имя домена, NGINX попытается найти файл index.html. Если такого файла нет, то NGINX будет искать файл index.htm. Если пользователь укажет в браузере URI-адрес /downloads , то получит список файлов в этом каталоге в формате HTML.

  • try_files - Проверяет существование файлов, указанных в параметрах. Если ни один файл, кроме последнего, не найден, то последний параметр считается «последней надеждой», поэтому необходимо, чтобы такой файл или именованное местоположение существовали

Ее задача – поискать перечисленные в параметрах файлы в указанном порядке; как только будет найден первый файл, поиск прекращается. Обычно этот механизм применяется, чтобы сопоставить потенциальные файлы с некоторой переменной, а затем передать обработку именованному местоположению, как показано в следующем примере:

location / {
        try_files $uri $uri/ @mongrel;
}
location @mongrel {
        proxy_pass http://appserver;
}

Здесь если переданному URI не соответствует файл, то неявно производится попытка найти каталог, а затем обработка перепоручается серверу appserver с помощью прокси.

Все директивы, которые используются в блоке server, могут использоваться и в блоках location. Но не обязательно указывать root и index в каждом location. Если их опустить, то будут наследоваться те, которые были указаны в родительском блоке.

Блоки server ведут себя аналогичным образом, поэтому, если мы указан другой путь к access.log, то будет использоваться путь, указанный в /etc/nginx/nginx.conf и так далее.

Взаимодействие с клиентами#

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

  • default_type - Определяет подразумеваемый по умолчанию MIME-тип ответа. Используется в случае, когда MIME-тип файла не удается сопоставить ни с одним из определенных в директиве types

  • error_page - Определяет URL-адрес страницы, которую нужно вернуть, если код ответа попадает в диапазон ошибок. Необязательный параметр, следующий за знаком =, позволяет изменить код ответа. Если после знака равенства не указан код ответа, то он берется из URI- адреса, при этом соответствующая страница должна возвращаться каким-то проксируемым сервером.

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

http {
        # обобщенная страница, возвращаемая при любой ошибке самого сервера
        error_page 500 501 502 503 504 share/examples/nginx/50x.html;

        server {
                server_name www.example.com;
                root /home/customer/html;

                # если файл не найден, то возвращается содержимое файла
                # /home/customer/html/404.html
                error_page 404 /404.html;

                location / {
                        # ошибки сервера для этого виртуального хоста переадресуются
                        # специальному обработчику в приложении
                        error_page 500 501 502 503 504 = @error_handler;
                }

                location /microsite {
                        # если не существует файл в области /microsite,
                        # то клиенту демонстрируется страница с другого сервера
                        error_page 404 http://microsite.example.com/404.html;
                }

                # именованное местоположение, содержащее специальный
                # обработчик ошибок
                location @error_handler {
                        # мы задаем здесь тип по умолчанию, чтобы браузер

                        # корректно отобразил страницу ошибки
                        default_type text/html;
                        proxy_pass http://127.0.0.1:8080;
                }
        }
}