веб сервер nginx что это
Nginx — быстрый, дерзкий и суперпопулярный сервер
Мы постепенно рассказываем о веб-серверах — это программы, которые отвечают за то, чтобы нам выдавались сайты. В прошлой серии показывали Apache — один из первых массовых веб-серверов, который до сих пор работает в огромном количестве компьютеров. А сегодня — новое поколение.
Короткая предыстория
Главная проблема веб-сервера Apache, про который мы говорили прошлый раз, — это падение производительности с ростом трафика. Чем больше людей заходят на сайт, тем хуже он справляется. Решения на тот момент были такие:
И то и другое — дорого. Чтобы решить эту проблему, в 2002 году системный администратор Игорь Сысоев начал разрабатывать собственный веб-сервер, который сможет решить проблему с проседанием под нагрузкой. Тогда Игорь работал в «Рамблере».
Через два года вышел первый релиз его веб-сервера Nginx. Сейчас это самый популярный веб-сервер в России и в тройке самых известных — в мире.
Архитектура
Apache работает так: все запросы, которые попадают на этот сервер, обслуживаются до тех пор, пока не будет дан полный ответ на запрос. Это значит, что если для ответа нужно будет попросить движок сайта собрать новую страницу, то Apache даст задание движку, а сам будет ждать ответ, пока не дождётся. Когда запросов много, сервер начинает тратить свои ресурсы на простой и ожидания, а не на реальную работу.
В Nginx всё устроено немного иначе:
Получается, что так как Nginx не тратит время на ожидание результата, то он может одновременно обрабатывать гораздо больше запросов, чем Apache. В этом и есть суперсила Nginx.
В чём ещё отличия от Apache
Документация. У Apache документации, форумов и примеров гораздо больше, потому что проект начался на 7 лет раньше и все материалы сразу были на английском — стандартном языке для всех программистов.
Nginx появился позже и в России, поэтому почти вся документация изначально была на русском. Из-за этого разработчикам из других стран было трудно использовать Nginx, но со временем ситуация выровнялась: сейчас проект ведётся одновременно на русском и на английском языках.
Работа с модулями. В Apache всё просто: прописал название модуля и веб-сервер сразу его подгрузил и начал использовать. Не нужно — выгрузил, тоже на ходу. Это позволяет очень гибко настраивать поведение сервера в разные моменты времени.
Чтобы добавить модули в Nginx, их нужно выбрать заранее и скомпилировать вместе с ядром сервера. С одной стороны, это неудобно: нужно на старте чётко представлять, что будет делать сервер и в каких ситуациях. Но с другой — это повышает безопасность: не получится на лету подключить какой-то неизвестный и непроверенный модуль, в котором будет дыра в безопасности.
Nginx + Apache = ❤️
Может показаться, что Nginx и Apache воюют друг с другом за долю рынка, но на самом деле они отлично работают вместе:
Получается так: Nginx занимается самыми простыми запросами, которые можно выполнить моментально, а всю динамику и сборки отправляет в Apache и продолжает заниматься своими делами.
В итоге польза всем: пока Apache ждёт или собирает страницы, Nginx успевает переделать кучу дел и не тратит своё время на ожидание. Системные администраторы часто используют такую связку, чтобы сбалансировать нагрузку на сервер и более эффективно использовать ресурсы.
Кто использует
Если вы назовёте три любых крупных ИТ-компании, то две из них точно будут использовать Nginx. В этом можно легко убедиться самому, посмотрев на список тех проектов, где используют эту программу:
Причина такой популярности — в скорости работы, надёжности и универсальности Nginx. К нему можно прикрутить почти любой софт и получить любую конфигурацию ответов на запросы.
Конфликт с «Рамблером»
В 2019 году произошла такая история: Рамблер заявил, что раз Сысоев во время создания Nginx работал у них, то и все права на этот веб-сервер тоже принадлежат им. В итоге завели дело по статье о нарушении авторских прав, а Рамблер требовал возместить им ущерб в 50 миллионов рублей.
Через полгода уголовное дело прекратили за отсутствием состава преступления: компания не смогла найти подтверждения своим словам и не смогла получить права на код Nginx.
По иронии судьбы на Nginx сейчас работают серверы и самого Рамблера 🙂
Веб-сервер nginx
nginx — это веб-сервер, который используется в качестве самостоятельного веб-сервера, либо проксирующего frontend-сервера для передачи данных на другой веб-сервер, кеширования запросов, балансировки нагрузки.
Распространено использование связки nginx в качестве frontend-сервера, обслуживающего запросы к статическому содержимому и проксирующего запросы на Apache, который в качестве backend-сервера обрабатывает динамическое содержимое. Подобная реализация присутствует на серверах нашего хостинга.
Конфигурационные файлы для отдельных сайтов расположены в каталоге:
Debian/Ubuntu: /etc/nginx/sites-available
CentOS: /etc/nginx/conf.d
Блочные директивы называются контекстами. Они вложены друг в друга в следующем порядке:
Пример:
Установка
Установка веб-сервера nginx осуществляется следующим образом:
CentOS/RHEL
Debian/Ubuntu
Установка модулей
Если в текущей сборке веб-сервера отсутствуют необходимые модули, для их установки потребуется скомпилировать nginx самостоятельно.
Компиляция nginx выполняется следующим образом:
Более подробно о процессе компиляции и конфигурации nginx вы можете узнать из официальной документации.
Настройка
Проверка конфигурации
Для избежания ошибок в работе веб-сервера после внесения изменений, необходимо проверить корректность конфигурации с помощью команды:
Если в результате обнаружены какие-либо ошибки, их необходимо исправить перед запуском веб-сервера.
Применение изменений
После внесения любых изменений в конфигурационный файл, для их применения необходимо перезагрузить веб-сервер:
HTTP2
Также в конфигурационный файл nginx необходимо добавить директивы:
Скрыть версию веб-сервера
Для скрытия версии веб-сервера в теле HTTP-запроса, в конфигурационный файл nginx.conf в секцию http требуется добавить директиву:
Перенаправление на другой домен
Для настройки перенаправления, в блок server для сайта, с которого надо настроить перенаправление, добавляем директиву return с нужным кодом ответа и целевым доменом:
Расширение статических файлов и их кеширование в браузере
Настройка nginx + PHP + MySQL
nginx не имеет встроенной поддержки обработки PHP, поэтому потребуется менеджер процессов fastCGI, который умеет интерпретировать PHP, и внести изменения в конфигурационный файл.
Введение в NGINX: как его установить и настроить
В этой статье будем учиться, как правильно устанавливать и настраивать основные части конфигурации NGINX на примере ОС Linux Debian.
Представьте ситуацию: вы создали веб-приложение и теперь ищете подходящий веб-сервер для его размещения. Ваше приложение может состоять из нескольких статических файлов – HTML, CSS и JavaScript, бэкэнда API-сервиса или даже нескольких веб-сервисов. Использование NGINX может быть тем, что вы ищете, и для этого есть несколько причин.
NGINX – это мощный веб-сервер, использующий не потоковую, управляемую событиями архитектуру, которая позволяет ему превосходить Apache при правильной настройке (подробная информация здесь). Он также может выполнять другие важные функции, такие как балансировка нагрузки, кеширование HTTP и использование в качестве обратного прокси.
Базовая установка – архитектура
Существует два способа установки NGINX – либо использовать установку из пакетов, либо компилировать из исходников.
Первый способ быстрее и проще, но компиляция из исходников дает возможность подключать сторонние библиотеки и модули, что делает NGINX еще более мощным инструментом. Такой способ позволит настроить все “под себя” и для нужд приложения.
Чтобы установить веб-сервер из пакета в ОС Debian, нужно всего лишь:
По завершении процесса установки вы можете проверить, что все в порядке, выполнив приведенную ниже команду, которая выведет на экран установленную версию NGINX.
Ваш веб-сервер будет установлен в директорию /etc/nginx/. Если перейти в эту директорию, можно увидеть несколько файлов и папок. Наиболее важные из них – это файл nginx.conf и папка sites-available.
Конфигурирование – основы
Основной файл настроек NGINX – это файл nginx.conf, который по умолчанию выглядит так:
Файл состоит из директив. Первая из них – events, а вторая – http. Структура из этих блоков создает основу всей конфигурации. Параметры и свойства родителей наследуется всеми дочерними блоками, и могут быть переопределены при необходимости.
Конфигурирование – параметры
Различные параметры этого файла могут быть изменены при необходимости, но NGINX настолько прост, что все будет работать с настройками по умолчанию. Рассмотрим некоторые важные параметры конфигурационного файла:
Ваш установленный сервер может поддерживать больше одного сайта, а файлы, которые описывают сайты вашего сервера, находятся в каталоге /etc/nginx /sites-available.
Файлы в этом каталоге не являются «живыми» – у вас может быть столько файлов, описывающих сайты, сколько вы хотите, но веб-сервер ничего не будет с ними делать, если они не будут привязаны символической ссылкой на папку /etc/nginx/site-enabled.
Это дает вам возможность быстро помещать сайты в онлайн и отправлять их в автономный режим без фактического удаления каких-либо файлов. Когда вы будете готовы перевести сайт в онлайн – делайте символическую ссылку на sites-enabled и перезапускайте процесс.
Рабочая директория
В директории sites-available находится конфигурационный файл для виртуальных хостов. Этот файл позволяет настроить веб-сервер на мультисайтовость, чтобы каждый сайт имел свой отдельный конфиг. Сайты в этом каталоге не активны и будут включены только в том случае, если мы создадим символическую ссылку на папку sites-enabled.
Теперь создайте новый файл для своего веб-приложения или отредактируйте дефолтный. Типичный конфиг выглядит так:
Этот файл имеет похожую структуру на nginx.conf – все та же блочная иерархия (и все они также вложены внутри HTTP-контекста nginx.conf, поэтому они также наследуют все от него).
Блок server описывает специфику работы виртуального сервера, который будет обрабатывать запросы пользователей. У вас может быть несколько таких блоков, и веб-сервер сам будет выбирать между ними на основании директив listen и server_name.
Внутри блока сервера мы определяем несколько контекстов location, которые используются для определения того, как обрабатывать клиентские запросы. Всякий раз, когда приходит запрос, сервер будет пытаться сопоставить свой URI с одним из этих определений location и обрабатывать его соответствующим образом.
Существует много важных директив, которые могут быть использованы, среди них:
Блок upstream определяет пул серверов, на который будут отправляться запросы. После того, как мы создадим блок upstream и определим сервер внутри него, мы можем ссылаться на него по имени внутри наших блоков location. Кроме того, в upstream контексте может быть назначено множество серверов, поэтому NGINX будет выполнять некоторую балансировку нагрузки при проксировании запросов.
Запуск NGINX
После того, как все настройки завершены и сайт перемещен в нужную директорию, мы можем запускать наш веб-сервер следующей командой:
После какого-либо изменения в файле конфигурации, мы должны заставить процесс NGINX перечитать конфиг (без перезагрузки) такой командой:
И наконец, мы можем проверить состояние процесса командой:
Заключение
Даже имея огромное количество настраиваемых параметров, NGINX может стать отличным вариантом для управления приложением, или быть использованным в качестве HTTP прокси, или балансировщика нагрузки для веб-сервера. Понимание как работает веб-сервер, и как он обрабатывает запросы, позволит гибко настроить и сбалансировать нагрузку ваших приложений.