Русский
Русский
English
Статистика
Реклама

Перевод Концепции nginx, о которых мне хотелось бы знать много лет назад

Nginx это веб-сервер, в котором используется архитектура Master-Slave. В nginx имеются обратный прокси-сервер, балансировщик нагрузки, почтовый прокси-сервер и HTTP-кеш.

Определение это сложное, полное специальных терминов. Если вы тоже так думаете значит, эта статья написана специально для вас. Сначала мы разберёмся с основными концепциями и понятиями nginx, а потом поговорим о том, как его устанавливать и настраивать.



Для того чтобы вам было легче просто помните о том, что nginx это отличный веб-сервер.

Веб-сервер, если описать его простыми словами, это нечто вроде посредника. Предположим, вам нужно посетить сайт dev.to. Вы вводите а адресной строке браузера следующее: dev.to. Браузер (клиент) находит адрес веб-сервера, а затем делается запрос к бэкенд-серверу, который возвращает клиенту ответ.

Прокси-сервер и обратный прокси-сервер


Одной из возможностей nginx являются реализации прокси-серверов. Поэтому нам, чтобы разобраться с nginx, надо знать о том, что такое прокси-сервер.

Прокси-сервер


Итак, у нас имеется как минимум один клиент, веб-сервер, являющийся системой-посредником (в данном случае мы будем называть его прокси-сервером), и обычный сервер. Во взаимодействии всех этих систем самое главное то, что обычный сервер не знает о том, какой именно клиент осуществляет к нему запрос. Звучит не очень понятно? Давайте взглянем на следующую схему.


Прокси-сервер

В данном случае Клиент 1 и Клиент 2 отправляют Запрос 1 и Запрос 2 к серверу через прокси-сервер. Этот сервер не знает о том, от какого именно клиента исходит тот или иной запрос, но, всё равно, выполняет то, что от него требуется.

Обратный прокси-сервер


Обратный прокси-сервер это, если говорить очень просто, прокси-сервер наоборот. Предположим, имеется всего один клиент, промежуточный веб-сервер и несколько бэкенд-серверов. Вот как это может выглядеть.


Обратный прокси-сервер

В данном случае клиент отправляет запрос через веб-сервер. А веб-сервер обращается к одному из множества серверов, выбирая конкретный сервер с использованием особого алгоритма. Например, с помощью очень приятного циклического (round-robin) алгоритма. Ответ на запрос отправляют клиенту через веб-сервер. В результате в данном случае клиент не знает о том, с каким именно бэкенд-сервером взаимодействует.

Балансировка нагрузки


Балансировка нагрузки это ещё одно понятие, которое надо освоить для понимания nginx. Но с тем, что это такое, разобраться будет уже не особенно сложно, так как балансировщик нагрузки это всего лишь один из экземпляров приложения, реализующего возможности обратного прокси-сервера.

Разберёмся с отличиями балансировщика нагрузки от обратного прокси-сервера. Для работы балансировщика нагрузки нужно как минимум 2 бэкенд-сервера. А вот для работы обычного обратного прокси-сервера это необязательно. Он может работать и с одним бэкенд-сервером.

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

Приложения, хранящие и не хранящие состояние


Мы пока ещё обсуждаем общие понятия, но обещаю, что очень скоро мы перейдём к работе с nginx. А сначала, всё же, давайте разберёмся с основами.

Приложения, хранящие состояние


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


Приложение, хранящее состояние

В нашем случае это означает, что если бэкенд-сервер Server 1 хранит какие-то данные, это не значит, что те же данные будут храниться и на Server 2. В результате клиент (тут это Bob) может получить (а может и не получить) желаемый результат, взаимодействуя то с Server 1, то с Server 2. В данном случае Server 1 позволит клиенту просматривать свой профиль, а Server 2 не позволит. Получается, что даже если это позволит ускорить работу, например, за счёт отсутствия необходимости взаимодействия с базой данных, обращение к Server 2 не даст того же результата, что и обращение к Server 1.

Приложения, не хранящие состояние


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


Приложение, не хранящее состояние

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

Что такое nginx?


Nginx это веб-сервер. Это понятие использовалось в данном материале до сих пор. Это, в сущности, посредник.


Nginx

Если вам кажется, что эта схема переусложнена, то знайте, что это не так. На ней просто собрано всё то, о чём мы до сих пор разговаривали. Тут имеются 3 бэкенд-сервера, работающих на портах 3001, 3002 и 3003. Все эти серверы используют одну и ту же базу данных, работающую на порте 5432.

Когда клиент отправляет запрос GET /employees к https://localhost (по умолчанию тут используется порт 433) этот запрос будет, на основе определённого алгоритма, отправлен одному из бэкенд-серверов. Сервер получит информацию из базы данных и отправит JSON-ответ nginx-серверу, после чего ответ попадёт клиенту.

Если для распределения задач по обработке запросов использовался бы некий алгоритм (вроде циклического), то, например, если Клиент 2 отправил бы запрос к https://localhost, то nginx-сервер переадресовал бы этот запрос на порт 3001, а потом отправил бы ответ клиенту. А другой запрос он мог бы передать на сервер, работающий на порте 3002 и так далее.

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

Установка nginx


Мы, наконец, добрались до практики! Очень хорошо то, что вы справились с теорией и дошли до этого места.

Процесс установка nginx до крайности прост. В любой системе этот веб-сервер можно установить с помощью простой однострочной команды. Я пользуюсь macOS. Поэтому тут будут приведены команды, рассчитанные на эту систему. Но примерно такие же команды сработают и в Ubuntu, и в других дистрибутивах Linux, и в Windows.

Итак, вот команда для установки nginx:

$ brew install Nginx

Это всё, что нужно для установки nginx. Как по мне так это просто замечательно.

Запуск nginx


Запустить nginx не сложнее, чем установить:

$ nginx# или$ sudo nginx

После выполнения этой команды откройте свой любимый браузер и перейдите по адресу http://localhost:8080/. Если всё работает как надо вы увидите сообщение, напоминающее то, которое показано на следующем рисунке.


Nginx готов к работе

Основы настройки nginx


Разберём пошаговый пример настройки nginx. Для начала создадим на локальном компьютере следующую структуру директорий:

. nginx-demo  content   first.txt   index.html   index.md  main   index.html temp-nginx outsider index.html

Нужно, кроме того, поместить какие-нибудь данные в HTML- и MD-файлы.

Чего мы пытаемся добиться?


Тут имеются две папки nginx-demo и temp-nginx. В каждой из них содержатся статические HTML-файлы. Мы собираемся организовать доступ к этим двум папкам, используя один порт и настроить правила работы nginx.

Теперь вернёмся к nginx. Для того чтобы внести изменения в стандартные настройки nginx нужно отредактировать файл nginx.conf, который находится в папке usr/local/etc/nginx. Я для решения подобных задач использую vim, но вы вполне можете пользоваться любым другим редактором.

$ cd /usr/local/etc/nginx$ vim nginx.conf

Вышеприведённая команда позволяет открыть конфигурационный файл nginx, но мне этого делать не хотелось бы. Обычно я поступаю при настройке nginx так: делаю копию этого конфигурационного файла, а уже потом вношу в исходный файл изменения. Предлагаю поступить так же:

$ cp nginx.conf copy-nginx.conf$ rm nginx.conf && vim nginx.conf

В результате в нашем распоряжении окажется пустой файл. Свои настройки мы будем описывать именно в нём.

Шаг 1


Для начала выполним базовые настройки.

http {server {listen 5000;root /path/to/nginx-demo/main/;}}events {}

Обратите внимание на то, что тут необходима конструкция events {}, так как она обычно используется для описания количества рабочих процессов nginx. Здесь используется ключевое слово http, которое сообщает nginx о том, что мы собираемся работать на 7 уровне модели OSI.

Мы предлагаем nginx прослушивать порт 5000 и указываем путь к корневой директории main, в которой находится HTML-файл.

Шаг 2


Теперь настроим дополнительные правила для URL /content и /outsider. При этом URL /outsider будет соответствовать директории, находящейся за пределами пути к корневой директории, упомянутой на первом шаге настройки nginx.

http {server {listen 5000;root /path/to/nginx-demo/main/;location /content {root /path/to/nginx-demo/;}location /outsider {root /path/temp-nginx/;}}}events {}

Здесь конструкция location /content указывает на то, что к объявленному в ней root-пути будет добавлен дополнительный URL content. В результате то, что корневая директория для /content задана в виде root /path/to/nginx-demo/, означает, что мы сообщаем nginx о том, что при обращении по адресу http://localhost:5000/path/to/nginx-demo/content/ нужно выдать данные, хранящиеся в соответствующей папке.

Но возможности nginx не ограничены лишь настройкой корневых директорий, соответствующих неким URL. Nginx позволяет, кроме того, запрещать клиентам просмотр некоторых файлов.

Шаг 3


Опишем в настройках основного сервера дополнительное правило, предназначенное для блокировки доступа к любым .md-файлам. При настройке nginx можно использовать регулярные выражения. Правило будет выглядеть так:

location ~ .md {return 403;}

Шаг 4


Изучим популярное правило proxy_pass, используемое при настройке nginx. Мы уже разобрались с тем, что такое прокси-сервер, что такое обратный прокси-сервер, и с тем, какое отношение к ним имеют бэкенд-серверы. Опишем в настройках ещё один бэкенд-сервер, работающий на порте 8888. В результате у нас будет два бэкенд-сервера. Одному соответствует порт 5000, а второму порт 8888.

server {listen 8888;location / {proxy_pass http://localhost:5000/;}location /new {proxy_pass http://localhost:5000/outsider/;}}

В результате получается, что если клиент обращается к порту 8888 через nginx, то мы перенаправляем запрос к порту 5000 и отправляем клиенту ответ.

Полный файл настроек nginx


А вот как выглядит полный файл с нашими настройками nginx:

http {server {listen 5000;root /path/to/nginx-demo/main/;location /content {root /path/to/nginx-demo/;}location /outsider {root /path/temp-nginx/;}location ~ .md {return 403;}}server {listen 8888;location / {proxy_pass http://localhost:5000/;}location /new {proxy_pass http://localhost:5000/outsider/;}}}events {}

Эти настройки будут использованы при запуске nginx командой sudo nginx.

Некоторые команды, используемые при работе с nginx


Первый запуск nginx:

$ nginx#или$ sudo nginx

Перезагрузка работающего nginx-сервера:

$ nginx -s reload#или$ sudo nginx -s reload

Остановка работающего nginx-сервера:

$ nginx -s stop#или$ sudo nginx -s stop

Выяснение того, какие процессы nginx работают в системе:

$ ps -ef | grep Nginx

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

Для остановки процесса, при условии знания его PID, можно воспользоваться такой командой:

$ kill -9 <PID>#или$ sudo kill -9 <PID>

Итоги


Теперь вы, в общих чертах, знакомы с сервером nginx и с его настройками. А значит можете продолжить изучение этой системы, например, обратившись к официальной документации.

Пользуетесь ли вы nginx?

Источник: habr.com
К списку статей
Опубликовано: 29.01.2021 16:08:57
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Блог компании ruvds.com

Nginx

Серверное администрирование

Разработка

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru