как проверить что nginx работает

Устранение неполадок установки и настройки Nginx

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

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

Каждый раздел может использоваться независимо от других, поэтому вы можете пропустить разделы, которые вам не нужны. Все условные значения в командах выделены красным; вместо этих значений вы можете подставить свои данные.

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

Примечание: Предполагается, что вы работаете с версией Nginx, установленной из репозитория по умолчанию в Debian-подобном дистрибутиве. Некоторые из команд и директив, описанных в этом руководстве, отсутствуют в других дистрибутивах или в версиях Nginx, установленных из других источников.

Установка Nginx

Обновите индекс пакетов, а затем установите Nginx:

sudo apt-get update
sudo apt-get install nginx

Проверка состояния Nginx

Чтобы проверить состояние веб-сервера на текущей машине, введите:

sudo systemctl status nginx

Автозагрузка Nginx

По умолчанию сервис Nginx запускается автоматически. Если вы хотите изменить это поведение, введите:

sudo systemctl disable nginx

Чтобы снова добавить Nginx в автозагрузку, введите:

sudo systemctl enable nginx

Управление сервисом Nginx

Чтобы остановить сервер Nginx, введите следующую команду:

sudo systemctl stop nginx

Чтобы запустить сервер Nginx, введите:

sudo systemctl start nginx

Чтобы остановить сервис и запустить его снова, введите:

sudo systemctl restart nginx

Если вы изменили конфигурацию, вы можете перезагрузить Nginx в текущей сессии. Введите следующую команду:

sudo systemctl reload nginx

Создание корневого каталога для статического контента

При создании сайтов на Nginx разработчики часто используют виртуальные хосты (или блоки server) – это хосты, которые обслуживают отдельные сайты или домены. Для этого нужно создать document root, каталог верхнего уровня, который Nginx проверяет при обслуживании контента.

Команды в приведенном ниже блоке создадут новый корневой каталог, передадут права на него пользователю sudo и изменят права доступа к каждому подкаталогу в подкаталога в /var/www/.

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

Помните, что права доступа должны меняться в соответствии с ситуацией.

Создание корневого каталога для динамических файлов

Если ваш сайт использует динамические модули типа PHP-FPM, вам может понадобиться передать права на некоторые файлы группе www-data. Если группе нужно право на запись в каталоге, передайте группе права собственности на каталог.

Предложенные ниже команды создают новый document root, передают его группе www-data и изменяют права на каждый подкаталог в /var/www.

Включение и отключение конфигурационных файлов

Чтобы включить виртуальный хост, нужно создать симлинк из каталога sites-available в каталог sites-enabled, который Nginx читает во время запуска.

Для этого введите комнаду:

После этого нужно перезагрузить Nginx, чтобы настройки обновились.

Устранение неполадок с хэш-таблицей

Nginx использует хэш-таблицы, чтобы быстро обрабатывать статические данные (имена серверов, MIME-типы). Если вы добавили несколько имен серверов, есть вероятность, что заданного размера хэша имени сервера будет не хватать, и при внесении изменений вы увидите ошибку server_names_hash_bucket_size. Ее можно устранить, отредактировав одно значение в файле /etc/nginx/nginx.conf.

Откройте этот файл:

sudo nano /etc/nginx/nginx.conf

Найдите в файле директиву server_names_hash_bucket_size. Удалите символ #, чтобы раскомментировать строку, и увеличьте значение директивы:

Это увеличит размер хэш-таблиц имен серверов Nginx и позволит сервису обрабатывать все имена серверов, которые вы добавили. Сохраните и закройте файл, а затем перезапустите Nginx, чтобы обновить настройки.

Тестирование конфигурации

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

Если в конфигурации есть ошибки, вывод команды укажет, где именно они обнаружены. Если же в конфигурационных файлах нет синтаксических ошибок, вы увидите примерно такой вывод:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Если ошибок нет, вы можете перезагрузить сервис:

sudo systemctl restart nginx

Важные файлы и каталоги Nginx

Контент

Каталог /var/www/html хранит весь контент сайта (это корневой каталог сайта). Вы можете изменить стандартные настройки Nginx и указать другие каталоги в var/www.

Конфигурация сервера

Чтобы получить доступ к логам systemd процесса Nginx, запустите эту команду:

Заключение

Данный мануал перечислил общие процедуры по поддержке сервера Nginx. Чтобы узнать больше о работе с Nginx, ознакомьтесь со следующими руководствами:

Источник

Команды Nginx, которые вы должны знать

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

Если вы разработчик или системный администратор, скорее всего, вы имеете дело с Nginx на регулярной основе.

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

Подготовка

Запуск Nginx

Запустить Nginx довольно просто. Просто запустите следующую команду:

В случае успеха команда не производит никакого вывода.

Если вы используете дистрибутив Linux без systemd, для запуска Nginx введите:

Вместо того, чтобы вручную запускать службу Nginx, рекомендуется настроить ее запуск при загрузке системы:

Остановка Nginx

Остановка Nginx быстро завершает все рабочие процессы Nginx, даже если есть открытые соединения.

Чтобы остановить Nginx, выполните одну из следующих команд:

Перезапуск Nginx

Параметр перезапуска — это быстрый способ остановить, а затем запустить сервер Nginx.

Используйте одну из следующих команд для перезапуска Nginx :

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

Перезагрузка Nginx

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

Команда reload загружает новую конфигурацию, запускает новые рабочие процессы с новой конфигурацией и корректно завершает работу старых рабочих процессов.

Чтобы перезагрузить Nginx, используйте одну из следующих команд:

Тестирование конфигурации Nginx

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

Используйте следующую команду, чтобы проверить конфигурацию Nginx на наличие синтаксических или системных ошибок:

Результат будет выглядеть следующим образом:

Если есть ошибки, команда выводит подробное сообщение.

Просмотр статуса Nginx

Чтобы проверить статус службы Nginx, используйте следующую команду:

Результат будет выглядеть примерно так:

Проверка версии Nginx

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

Вы можете проверить свою версию Nginx, запустив:

Выводы

Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.

Источник

Как проверить, запущен ли nginx?

После запуска проекта ASP.NET vNext на моем локальном компьютере я был пытаюсь выяснить, как я могу запустить его на nginx, поскольку он выглядит как рекомендуемый выбор

После jsinh blog, я установил его, используя:

Я пытался понять, работает он или нет, используя:

Однако результат всегда один и тот же:

Как проверить, запущен ли nginx?

10 ответов

Глядя на ваше требование, следующая команда должна помочь:

Если вы используете Mac и установили nginx с помощью

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

Если вы используете Mac и установили nginx с помощью…

Вероятно, это зависит от системы, но это самый простой способ, который я нашел.

Это лучшее решение для написания сценариев.

Современный ( systemctl ) способ сделать это:

Вы можете использовать значение выхода в сценариях оболочки следующим образом:

Также можно использовать следующий код для проверки статуса nginx:

Не уверен, какому руководству вы следуете, но если вы заглянете на эту страницу,

Он использует другую команду

А также указывает, какой результат ожидается.

Другой способ увидеть это в командной строке Windows:

ИНФОРМАЦИЯ: не выполняются задачи, соответствующие указанным критериям.

Если есть запущенный nginx, вы их увидите

Источник

Руководство для начинающих

В этом руководстве даётся начальное введение в nginx и описываются некоторые простые задачи, которые могут быть решены с его помощью. Предполагается, что nginx уже установлен на компьютере читателя. Если нет, см. Установка nginx. В этом руководстве описывается, как запустить и остановить nginx и перезагрузить его конфигурацию, объясняется, как устроен конфигурационный файл, и описывается, как настроить nginx для раздачи статического содержимого, как настроить прокси-сервер на nginx, и как связать nginx с приложением FastCGI.

У nginx есть один главный и несколько рабочих процессов. Основная задача главного процесса — чтение и проверка конфигурации и управление рабочими процессами. Рабочие процессы выполняют фактическую обработку запросов. nginx использует модель, основанную на событиях, и зависящие от операционной системы механизмы для эффективного распределения запросов между рабочими процессами. Количество рабочих процессов задаётся в конфигурационном файле и может быть фиксированным для данной конфигурации или автоматически устанавливаться равным числу доступных процессорных ядер (см. worker_processes).

Запуск, остановка, перезагрузка конфигурации

Где сигнал может быть одним из нижеследующих:

Например, чтобы остановить процессы nginx с ожиданием окончания обслуживания текущих запросов рабочими процессами, можно выполнить следующую команду:

Команда должна быть выполнена под тем же пользователем, под которым был запущен nginx.

Изменения, сделанные в конфигурационном файле, не будут применены, пока команда перезагрузить конфигурацию не будет вручную отправлена nginx’у или он не будет перезапущен. Для перезагрузки конфигурации выполните:

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

Дополнительную информацию об отправке сигналов процессам nginx можно найти в Управление nginx.

Структура конфигурационного файла

nginx состоит из модулей, которые настраиваются директивами, указанными в конфигурационном файле. Директивы делятся на простые и блочные. Простая директива состоит из имени и параметров, разделённых пробелами, и оканчивается точкой с запятой ( ; ). Блочная директива устроена так же, как и простая директива, но вместо точки с запятой после имени и параметров следует набор дополнительных инструкций, помещённых внутри фигурных скобок ( < и >). Если у блочной директивы внутри фигурных скобок можно задавать другие директивы, то она называется контекстом (примеры: events, http, server и location).

Часть строки после символа # считается комментарием.

Раздача статического содержимого

Во-первых, создайте каталог /data/www и положите в него файл index.html с любым текстовым содержанием, а также создайте каталог /data/images и положите в него несколько файлов с изображениями.

В блок server добавьте блок location следующего вида:

Далее, добавьте второй блок location :

Он будет давать совпадение с запросами, начинающимися с /images/ ( location / для них тоже подходит, но указанный там префикс короче).

Итоговая конфигурация блока server должна выглядеть следующим образом:

Чтобы применить новую конфигурацию, запустите nginx, если он ещё не запущен, или отправьте сигнал reload главному процессу nginx, выполнив:

Настройка простого прокси-сервера

Одним из частых применений nginx является использование его в качестве прокси-сервера, то есть сервера, который принимает запросы, перенаправляет их на проксируемые сервера, получает ответы от них и отправляет их клиенту.

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

Во-первых, создайте проксируемый сервер, добавив ещё один блок server в конфигурационный файл nginx со следующим содержимым:

Далее, используйте конфигурацию сервера из предыдущего раздела и видоизмените её, превратив в конфигурацию прокси-сервера. В первый блок location добавьте директиву proxy_pass, указав протокол, имя и порт проксируемого сервера в качестве параметра (в нашем случае это http://localhost:8080 ):

Итоговая конфигурация прокси-сервера выглядит следующим образом:

Чтобы применить новую конфигурацию, отправьте сигнал reload nginx’у, как описывалось в предыдущих разделах.

Существует множество других директив для дальнейшей настройки прокси-соединения.

Настройка проксирования FastCGI

nginx можно использовать для перенаправления запросов на FastCGI-серверы. На них могут исполняться приложения, созданные с использованием разнообразных фреймворков и языков программирования, например, PHP.

Источник

Установка и настройка nginx

В данной статье описана установка и настройка высокопроизводительного современного веб-сервера nginx на примере облачной платформы Selectel. Все действия актуальны для ОС Ubuntu 20.04 LTS 64-bit.

Nginx — это веб-сервер с открытым исходным кодом, созданный работать под высокой нагрузкой, чаще всего используемый для отдачи статического контента, например, html страниц, медиафайлов, документов, архивов, картинок и т.д.

Подготовка сервера

Для начала установим сам сервер. После прохождения регистрации, необходимо войти в панель управления. Далее в меню «Облачная платформа» — «Создать сервер».

Откроется оснастка создания сервера, где необходимо задать понятное для дальнейшей работы имя сервера, в примере это «WebSrv01». Регион и зону можно оставить без изменения. Для выбора операционной системы необходимо нажать кнопку «Выбрать другой источник».

Откроется меню «Выбор источника».

В поле «Операционные системы», выбираем Ubuntu, в левом поле появится список всех доступных образов операционных систем на базе данной ОС, выбираем «Ubuntu 20.04 LTS 64-bit» и нажимаем кнопку «Выбрать».

Перемещаемся вниз по странице. В нашем примере используется только «Локальный диск», флажок установлен, в поле «Сетевые диски» нажимаем кнопку «Удалить диск».

В поле «Сеть», поскольку это наш первый сервер выбираем «Приватная подсеть + 1 плавающий IP», после выбора значение в поле сменится на «Новый плавающий IP адрес».

Необходимо скопировать «Пароль для root», он понадобиться для первоначальной настройки сервера через SSH протокол.

Нажимаем кнопку «Создать», сервер будет доступен примерно через 1 минуту. Переходим в меню «Облачная платформа» — «Серверы».

В списке появится сервер с именем, что задали ранее, его IP адрес, который будем использовать для удаленного подключения, на скриншоте в области с цифрой 3, статус сервера ALIVE, означает готовность сервера. Подключаемся к серверу, используя любой SSH-клиент.

Проведем небольшую первоначальную настройку сервера. Обновим информацию о доступных пакетах из подключенных репозиториев:

Создадим непривилегированного пользователя, в нашем случае webuser:

Появится интерактивный диалог, в ходе которого необходимо будет задать пароль (New password), подтвердить его (Retype new password), остальные пункты можно не заполнять, просто нажимая ENTER. В последнем вопросе Is the information correct? [Y/n] необходимо нажать Y и нажать ENTER.

Добавляем пользователя webuser в группу sudo для повышения привилегий:

Открываем конфигурационный файл SSH-сервера:

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

Переходим к строке PermitRootLogin yes, меняем значение на no, тем самым запретив вход пользователя root напрямую:

Находясь в редакторе, нажимаем комбинацию клавиш Ctrl+O, внизу появится строка подтверждения: File Name to Write: /etc/ssh/sshd_config, нажимаем ENTER для сохранения изменений, затем Ctrl+X для выхода из редактора.

После изменений файла конфигурации SSH сервера, необходимо выполнить его перезапуск для того, чтобы изменения вступили в силу:

Установка nginx

Установка сервера nginx может быть выполнена как непосредственно на машину, так и в виде docker контейнера. У каждого метода есть свои преимущества и недостатки, описание которых выходит за рамки данной статьи. Мы посмотрим оба варианта.

Начнем с непосредственной установки на сервер:

Будет задан вопрос: Do you want to continue? [Y/n]
Нажимаем Y, затем ENTER.

Дожидаемся окончания процесса установки.

Разрешим автозапуск сервера:

Если в ответ получили «enabled», значит nginx успешно добавлен в автозагрузку.

Запуск nginx

Стартуем наш веб-сервер:

Если в статусе присутствует строка Active: active (running), значит сервер работает. Также в этом можно убедиться, набрав в адресной строке браузера IP адрес сервера, будет отображено приветственное сообщение от nginx, которое выглядит так:

Nginx в Docker

Для установки Docker, нужно подготовить систему. Устанавливаем необходимые пакеты:

Будет задан вопрос: Do you want to continue? [Y/n]
Нажимаем Y, затем ENTER.

Добавляем GPG ключ официального репозитория Docker в систему:

В следующей строке появится надпись OK, добавляем репозиторий Docker:

Теперь необходимо обновить информацию о пакетах:

Проверим, что установка Docker будет происходить из его репозитория:

В ответ должны получить много строк, среди которых должен присутствовать адрес репозитория, добавленный ранее, в нашем примере это:

Будет задан вопрос: Do you want to continue? [Y/n]
Нажимаем Y, затем ENTER.

Дожидаемся окончания процесса установки. После docker будет автоматически запущен и добавлен в автозагрузку. Проверим:

В выводе команды должна присутствовать строка Active: active (running), значит процесс-демон работает.

В ответе увидели «enabled», значит docker успешно добавлен в автозагрузку. На этом установка Docker завершена, переходим к запуску в контейнере веб-сервера nginx.

Создадим проект и его структуру папок в домашнем каталоге нашего пользователя webuser:

Устанавливаем и запускаем nginx в Docker одной командой:

Docker скачает официальный образ nginx с Docker Hub, сконфигурирует и запустит контейнер.

Проверяем, работает ли контейнер:

Вывод команды должен быть примерно следующим:

Стоит обратить внимание на столбец NAMES, где обнаруживаем имя созданного ранее контейнера nginx_myproject, колонка STATUS, в которой отображается состояние контейнера, в данном случае он работает уже 7 часов. Если набрать в адресной строке браузера IP адрес сервера и через двоеточие порт, используемый контейнером 8080, т.е. конструкцию вида 123.123.123.123:8080, то в ответ получим:

Мы научились запускать веб-сервер nginx в контейнере!

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

Иерархия каталогов nginx

Администрирование сервера nginx в основном заключается в настройке и поддержке его файлов конфигурации, которые находятся в папке /etc/nginx. Рассмотрим подробнее:

Настройка nginx

Рассмотрим главный конфигурационный файл nginx — /etc/nginx/nginx.conf. По умолчанию он выглядит следующим образом:

Конфигурационный файл состоит из директив. О них и пойдет речь дальше.

Директивы

Существует два вида директив – простые и блочные. Простая директива состоит из имени и параметров, разделённых пробелами, и в конце строки ставится точкой с запятой (;). Блочная директива устроена так же, как и простая директива, но вместо точки с запятой после имени и параметров следует набор дополнительных инструкций, помещённых внутри фигурных скобок ( <и >). Рассмотрим те, которые пригодятся нам для примера:

Переменные в nginx

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

Установка и настройка php-fpm

Для работы веб приложений, написанных на языке PHP необходимо установить php-fpm в качестве бэкэнда:

Будет задан вопрос: Do you want to continue? [Y/n]
Нажимаем Y, затем ENTER.

После установки сервис будет автоматически запущен и добавлен в автозагрузку. Создаем файл пула для конкретного сайта sampledomain.ru:

Создаем следующую конфигурацию:

Нажимаем комбинацию клавиш Ctrl+O, внизу появится строка подтверждения: File Name to Write: /etc/php/7.4/fpm/pool.d/sampledomain.ru.conf, нажимаем ENTER для сохранения изменений, затем Ctrl+X для выхода из редактора.

Перезагружаем сервис php-fpm, чтобы он мог перечитать файлы конфигураций:

Проверяем, что сервис перезапустился корректно и наша новая конфигурация sampledomain.ru обслуживается:

О том, что сервис запущен, свидетельствует наличие строки Active: active (running), чуть ниже список обслуживаемых конфигураций в виде дерева, где можно увидеть php-fpm: pool sampledomain.ru, значит все работает.

Конфигурация nginx

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

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

Заполняем его следующим содержимым:

Нажимаем комбинацию клавиш Ctrl+O, внизу появится строка подтверждения: File Name to Write: /etc/nginx/sites-available/sampledomain.ru.conf, нажимаем ENTER для сохранения изменений, затем Ctrl+X для выхода из редактора.

Создаем символическую ссылку на данный виртуальный хост из директории /etc/nginx/sites-available в директорию /etc/nginx/sites-enabled, чтобы nginx его обслуживал:

Необходимо создать структуру каталогов веб проекта:

Создаем файл для тестирования работы связки nginx и php-fpm:

Задаем владельца каталогов и находящихся внутри файлов:

Добавляем пользователя www-data в группу webuser:

Конфиги написаны, директории созданы, перезапускаем nginx для того, чтобы он перечитал файлы конфигураций:

Переходим в браузере по адресу http://sampledomain.ru и должны увидеть такую картину:

Все настроили правильно.

Команды nginx

Рассмотрим несколько команд, которые полезно знать администратору. После внесения изменений в конфигурационные файлы сервера, рекомендуется провести их синтаксический контроль:

Если все хорошо, в результате получим сообщение:

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

Можно получить расширенную информацию об nginx – его версию, параметры конфигурации сборки:

Когда существует необходимость оперативно, но аккуратно перезапустить веб-сервер, чтобы пользователи на данный момент, работающие с ним, не потеряли соединение, но в то же время, вновь подключившиеся уже работали с учетом последних изменений конфигурации. В таком случае, вместо restart необходимо использовать команду reload:

Настройка SSL сертификата

Получение SSL сертификата необходимо для использования протокола HTTPS. Данный протокол защищает соединение между сервером и клиентом, особенно критично для чувствительных данных, таких как логины, пароли, данные по банковским картам, переписка и так далее. Последние несколько лет поисковые системы наиболее лояльны к сайтам, использующих данный протокол, есть прекрасная возможность получить ssl сертификат бесплатно от Let’s Encrypt, устанавливаем его клиент certbot из официального репозитория:

Будет задан вопрос: Do you want to continue? [Y/n]
Нажимаем Y, затем ENTER.

Запрашиваем сертификат у Certbot:

Появится вопрос о передаче вашего адреса электронной почты компании партнеру: (Y)es/(N)o:
Жмем Y, потом ENTER.

Сертификат успешно получен, если появилось сообщение:

Сертификат действителен 90 дней. Теперь необходимо позаботиться об автоматическом продлении сертификатов, открываем файл:

Приводим его к следующему виду:

Нажимаем комбинацию клавиш Ctrl+O, внизу появится строка подтверждения: File Name to Write: /etc/cron.d/certbot, нажимаем ENTER для сохранения изменений, затем Ctrl+X для выхода из редактора.

Дважды в день будет происходить проверка необходимости обновления сертификатов на сервере, если какому-либо осталось 30 дней и меньше до истечения срока действия – он будет обновлен, а nginx перезагружен.

Протестируем процесс обновления без внесения изменений:

Ждем около полминуты, на экран будет выведен подробный отчет. Если присутствует строка Congratulations, all renewals succeeded – значит все настроено правильно. Если когда-либо в процессе обновления произойдет сбой – Let’s Encrypt уведомит о приближающимся конце срока действия сертификата по электронной почте, указанной при первом запросе.

Редирект с http на https

После получения сертификата необходимо прописать директивы в файл конфигурации виртуального хоста, отвечающие за поддержку SSL. Сразу же реализуем перенаправление всех запросов, приходящих на 80-й порт к порту 443, т.е. с http протокола на https. Открываем файл:

Приводим его к следующему виду:

Нажимаем комбинацию клавиш Ctrl+O, внизу появится строка подтверждения: File Name to Write: /etc/nginx/sites-available/sampledomain.ru.conf, нажимаем ENTER для сохранения изменений, затем Ctrl+X для выхода из редактора.

Теперь в браузере при попытке перехода по адресу http://sampledomain.ru будет выполнено перенаправление на https://sampledomain.ru

Кэширование в nginx

Основная задача кэширования – это минимизация времени доступа к данным. Nginx умеет работать с несколькими видами кэширования: на стороне сервера, на стороне клиента. Серверное кэширование может иметь самую разнообразную конфигурацию, в зависимости от архитектуры проекта. Поэтому в нашем частном случае рассмотрим кэширование на стороне клиента (браузера) для статического контента.

Открываем файл нашего тестового виртуального хоста:

Находим location, указывающий на отдачу статического контента и добавляем директиву expires:

Как обычно сохраняем результат Ctrl+O, подтверждаем нажатием ENTER, выходим из редактора Ctrl+X. В данном случае файлы, расширения которых соответствуют приведенным выше, будут храниться в браузере клиента, только после истечения суток – они будут запрошены повторно.

Кэширование позволяет значительно уменьшить время доставки контента и его объем, снизить нагрузку на сервер, а значит, ваш сайт сможет работать значительно быстрее и принять больше посетителей.

Мониторинг nginx

В nginx существует стандартная возможность мониторинга работы сервера, выясним доступность модуля в нашей сборке:

Если в ответ получили with-http_stub_status_module – модуль доступен. Рассмотрим включение мониторинга на примере виртуального хоста, открываем файл:

Добавляем location /nginx_status, в итоге файл выглядит следующим образом:

Сохраняем результат Ctrl+O, подтверждаем нажатием ENTER, выходим из редактора Ctrl+X. Перезапускаем веб-сервер:

В браузере при переходе по адресу sampledomain.ru/nginx_status будет представлена статистика работы сервера:

Также статистику можно получить из командной строки:

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

Проксирование запросов

Nginx умеет проксировать запросы на другие сервера, понадобиться это для масштабирования и защиты back-end серверов. В качестве примера, запустим back-end сервер apache в контейнере:

Дожидаемся процесса скачивания образа, контейнер запуститься автоматически, убеждаемся, что среди запущенных контейнеров присутствует backend_apache:

Открываем файл виртуального хоста:

Изменим блок location / так, чтобы при обращении к sampledomain.ru запрос был передан веб-серверу apache, работающему в контейнере:

Сохраняем результат Ctrl+O, подтверждаем нажатием ENTER, выходим из редактора Ctrl+X. Перезапускаем веб-сервер:

Директива proxy_pass задает протокол, адрес и порт проксируемого ресурса, proxy_set_header директивы настраивают заголовки запросов, передают проксируемому ресурсу информацию о соединении.

Если перейти в браузере по адресу http://sampledomain.ru, можно увидеть «It works!», отдаваемый ранее созданным контейнером с apache.

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

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

Открываем файл виртуального хоста:

Над блоком server добавляем следующее:

Также вносим изменения в блок location /:

Сохраняем результат Ctrl+O, подтверждаем нажатием ENTER, выходим из редактора Ctrl+X. Перезапускаем веб-сервер:

Директива upstream перечисляет все back-end сервера, между которыми следует распределить нагрузку. В блоке location / изменился параметр директивы proxy_pass на http://backends, где backends – имя, которое присвоили группе серверов директивы upstream.

Ранее мы запустили два контейнера: первый с nginx на порту 8080, второй с apache на порту 8081. Теперь перейдя в браузере по ссылке http://sampledomain.ru и несколько раз обновляя страницу можно наблюдать чередование ответов «It works!» и «Hello from NGINX in Docker!», значит балансировка работает.

Существует несколько методов балансировки:

round-robin – используется по умолчанию, нагрузка распределяется равномерно между серверами с учетом веса.

least_conn – запросы поступают к менее загруженным серверам.

ip_hash — запросы распределяются по серверам на основе IP-адресов клиентов, т.е. запросы одного и того же клиента будут всегда передаваться на один и тот же сервер, пример:

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

Разберем на примере:

В данной конфигурации, из 7 запросов, 5 будет обработано сервером 127.0.0.1:8080, а 2 машиной 127.0.0.1:8081

Безопасность nginx

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

HTTP аутентификация

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

Установим утилиту для генерации хешированных паролей:

Будет задан вопрос: Do you want to continue? [Y/n]
Нажимаем Y, затем ENTER.

Теперь создадим файл, в котором будет содержаться список логинов и паролей пользователей:

Добавим пользователя user:

Будет предложено ввести пароль, вводимые символы не отображаются, это нормально, после нажать ENTER:

Ввести повторно тот же пароль:

Появление ответа Adding password for user user означает, что все сделано верно. Точно так же можно добавить других пользователей. Чтобы сменить пароль пользователя user – нужно повторно ввести предыдущую команду, данные в файле будут обновлены.

В примере будем защищать доступ к нашему виртуальному хосту, а конкретно к статистике работы сервера, открываем файл конфигурации:

Редактируем location /nginx_status следующим образом:

Сохраняем результат Ctrl+O, подтверждаем нажатием ENTER, выходим из редактора Ctrl+X. Перезапускаем nginx:

Теперь при переходе в раздел просмотра статистики sampledomain.ru/nginx_status необходимо будет сначала ввести логин и пароль для доступа к разделу, в противном случае сервер выдаст ошибку: 401 Authorization Required.

Авторизацию по паролю рекомендуется использовать исключительно для служебных целей и совместно с протоколом https, иначе данные передаются в открытом виде.

Ограничение доступа по IP адресу

В качестве примера отредактируем тренировочный виртуальный хост:

Рассмотрим блок location /nginx_status, приведем его к виду:

Сохраняем результат Ctrl+O, подтверждаем нажатием ENTER, выходим из редактора Ctrl+X. Перезапускаем nginx:

В данном примере разрешен доступ для компьютеров из сети 192.168.0.0 с маской подсети 255.255.255.0 (/24) и хоста с адресом 192.168.1.1. Для всех остальных доступ закрыт.

Комбинация ограничений

Рассмотрим ситуацию, когда имеется предприятие, с внутренней сетью 192.168.0.0/24, и сотрудники из нее должны беспрепятственно попадать в нужный раздел, но в то же время необходимо предоставить доступ снаружи, используя авторизацию по логину и паролю. Тогда location /nginx_status принимает следующий вид:

Сфокусируем внимание на директиве satisfy. В данном случае она имеет параметр any, что означает предоставление доступа при выполнении хотя бы одного из условий. При смене параметра на all – сотрудникам предприятия будет разрешен доступ только из внутренней сети с аутентификацией по логину и паролю.

Предотвращение DDoS атак

DDoS — это распределенная атака отказа в обслуживании, происходит с нескольких IP адресов, направлена на ухудшение или полное отсутствие доступности сервера за счёт огромного количества запросов. Чаще всего, это происки недобросовестных конкурентов, реже из хулиганских побуждений. В nginx предусмотрен механизм, позволяющий, если не полностью подавить атаку, то как минимум смягчить ее влияние на работу системы.

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

Доводим до следующего состояния:

Сохраняем результат Ctrl+O, подтверждаем нажатием ENTER, выходим из редактора Ctrl+X. Перезапускаем nginx:

.php$, ссылающаяся на зону разделяемой памяти, задающая лимит на количество соединений с одного IP адреса, в данном случае 10.

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

Ошибки nginx

В работе любых систем, а особенно на этапе пуско-наладочных работ, возникают ошибки, в данном разделе рассмотрим наиболее распространенные и методы их устранения.

502 bad gateway

Эта ошибка говорит о том, что back-end, обрабатывающий запрос от nginx – перестал отвечать. Произойти это могло также по нескольким причинам. Во-первых, back-end мог упасть полностью и для восстановления его необходимо запустить. Во-вторых, если nginx и back-end сервер находятся на физически разных машинах – между ними могла банально пропасть связь. Для проверки необходимо воспользоваться командой ping. Так же, возможно, часть процессов php-fpm перегружены или не хватает их количества для обслуживания всех клиентов, тогда эта ошибка будет иметь «плавающий» характер. Открываем файл:

Если действительно проблема в нехватке процессов — стоит «покрутить» следующие настройки:

504 Gateway Time-out

Одна из причин возникновения ошибки – превышение времени ожидания ответа от сервера, например от php-fpm. Такое случается, когда скрипты php долго выполняются или зависли. Если обработка запроса требует большего времени – увеличим время ожидания на передачу запроса fastcgi_send_timeout и получение ответа fastcgi_read_timeout, редактируем блок location

Сохраняем результат Ctrl+O, подтверждаем нажатием ENTER, выходим из редактора Ctrl+X. Перезапускаем nginx:

413 Request Entity Too Large

Ошибка возникает, когда на сервер загружается файл, превышающий значение директивы client_max_body_size, по умолчанию – 1 Мб. Добавим в блок server:

В примере максимально допустимый размер тела запроса клиента увеличен до 50 Мб. При повторном возникновении ошибки – снова увеличить. Не забываем сохраняться и после изменений – перезапускать nginx:

Искать причины возникновения тех или иных ошибок правильнее всего в логах, которые находятся в папке /var/log/nginx/. Однако, у начинающего администратора возникают сложности с интерпретацией, содержащейся в них информации.

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

Источник