Поделиться через


Часть 2.2. Установка Nginx и настройка его в качестве обратного прокси-сервера

Область применения: .NET Core 2.1, .NET Core 3.1, .NET 5

В этой статье описывается, как установить Nginx и настроить его как обратный прокси-сервер.

Необходимые компоненты

Для выполнения упражнений, описанных в этой части, необходимо создать и развернуть одно веб-приложение Core ASP.NET в папке /var .

Цель этой части

В предыдущей части вы создали веб-приложение ASP.NET Core с помощью средства .NET CLI, а приложение развертывается в папке /var . Приложение также было настроено для прослушивания порта 5000 для HTTP-запросов, а перенаправление HTTPS было удалено.

На этом этапе клиенты должны указать номер порта при подключении к приложению (например, http://localhost:5000). Однако это не нужное поведение.

Наши цели в этой части приведены следующим образом:

  • Клиенты должны иметь возможность перемещаться без необходимости предоставлять номер порта. Например, клиенты должны подключаться с помощью http://localhost.
  • Веб-приложение должно запускаться автоматически, если он останавливается по какой-либо причине или после перезагрузки компьютера.

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

Что такое Nginx?

Nginx — это популярный, упрощенный и быстрый веб-сервер. Он может работать как в Linux, так и в Windows, и его можно настроить как обратный прокси-сервер.

Что такое управляющая программа?

Nginx выполняется в качестве управляющей программы. Управляющая программа — это альтернативный термин для службы, которая выполняется в фоновом режиме. Как и службы, выполняемые в Windows, управляющая программа может быть настроена для автоматического запуска во время запуска. Вы настроите приложение ASP.NET Core для запуска в качестве управляющей программы.

Установка Nginx с помощью APT

Установка Nginx проста. sudo apt install nginx Выполните команду, чтобы установить программу на виртуальной машине Ubuntu.

Снимок экрана: команда sudo.

После завершения установки запустите whereis nginx программу, чтобы узнать, где установлена программа. Вы можете увидеть, где находятся файлы конфигурации Nginx, проверив выходные данные. На следующем снимке экрана показано, что файлы конфигурации находятся в папке /etc/nginx .

Снимок экрана: команда whereis.

Примечание.

Если вы запускаете дистрибутив, отличный от Ubuntu или Debian, вы можете найти эквивалентную команду установки диспетчера пакетов или инструкции из официальной документации по установке Nginx.

Управление службами с помощью systemctl

Если вы не видите, что Nginx запущен, его можно запустить явным образом, выполнив команду sudo systemctl start nginx. Хотя это упражнение демонстрирует systemctl команды nginx, эти команды используются для настройки веб-приложения для автоматического запуска в качестве управляющей программы.

После завершения установки nginx уже настроен автоматически. Nginx выполняется в качестве управляющей программы. Вы можете проверить состояние управляющей программы с помощью systemctl.

Эта systemctl команда используется для управления "службами" для таких задач, как отображение состояния службы или запуск и остановка службы. Некоторые доступные параметры: запуск, остановка, перезапуск, включение, отключение и состояние. Чтобы проверить состояние Nginx, выполните команду systemctl status nginx.

Снимок экрана: команда systemctl.

Эта команда создает некоторые полезные сведения. Как показано на этом снимке экрана, Nginx находится в active (running) состоянии, а идентификатор процесса экземпляра Nginx равен 8539. Обратите внимание на инструкции enabled и vendor preset: enabled инструкции. Enabled означает, что эта управляющая программа запускается при перезапуске компьютера и vendor preset: enabled означает, что Nginx включен по умолчанию при его установке. Поэтому Nginx запускается автоматически при запуске сервера.

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

По умолчанию Nginx прослушивает порт 80. Так как она выполняется, вы сможете получить доступ к главной странице Nginx при просмотре localhost. Используется curl для тестирования Nginx, выполнив команду curl localhost. Желтый выделенный текст на следующем снимке экрана показана веб-страница nginx по умолчанию. Таким образом, Nginx выполняется:

Снимок экрана: команда curl.

Параметры команды systemctl

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

Перезапуск daemons

Возможно, вам придется перезапустить управляющей программы от времени. Чтобы перезапустить управляющая программа, выполните команду sudo systemctl restart <daemon_name>. Чтобы перезапустить Nginx, выполните команду sudo systemctl restart nginx. Убедитесь, что вы проверяете состояние Nginx до и после выполнения этой команды, чтобы отслеживать изменения идентификатора процесса.

Остановка управляющей программы

Чтобы остановить управляемую программу, выполните команду sudo systemctl stop <daemon_name>. Чтобы остановить Nginx, выполните команду sudo systemctl stop nginx, а затем проверьте состояние Nginx, снова выполнив команду systemctl status nginx . На этот раз служба отображается как неактивная (мертвая), но по-прежнему включена. Это означает, что хотя служба не запущена, она будет запускаться автоматически после перезапуска сервера.

Снимок экрана: команда stop.

Примечание.

Команда systemctl status также отображает несколько строк предыдущих записей журнала для управляющей программы.

После остановки Nginx запустите curl localhost еще раз.

Примечание.

Подключение отказано, так как ничто не прослушивает входящий трафик через порт 80.

Снимок экрана: BuggyAmb localhost.

Отключение daemons

Отключение управляющей программы отличается от остановки управляющей программы. Отключенная управляющая программа может быть запущена, но она не будет запускаться автоматически после перезапуска сервера. Чтобы отключить управляющая программа Nginx, запустите sudo systemctl disable nginxи проверьте состояние Nginx.

Снимок экрана: команда отключения.

На этом снимка экрана показано, что Nginx не запущен и отключен. Это означает, что Nginx не запускается автоматически после перезагрузки.

Запуск daemons

Чтобы запустить управляемую программу, выполните команду sudo systemctl start <daemon_name>. Чтобы запустить Nginx, запустите sudo systemctl start nginxи снова проверьте состояние службы.

Снимок экрана: команда start.

На этом снимка экрана показано, что Nginx запущен, но по-прежнему отключен. Хотя служба запущена, Nginx не запускается автоматически после перезагрузки, так как она отключена.

Включение daemons

Включение службы означает, что она начнется автоматически после перезапуска. Чтобы включить Nginx, запустите sudo systemctl enable nginxи снова проверьте состояние Nginx.

Снимок экрана: команда включения.

На этом снимка экрана показано, что Nginx запущен, и он будет запущен после перезапуска сервера.

Настройка Nginx в качестве обратного прокси-сервера для маршрутизации запросов в приложение ASP.NET Core

Теперь, когда вы узнали, как запустить, остановить и перезапустить службу Nginx, вы будете далее настраивать Nginx в качестве обратного прокси-сервера для маршрутизации запросов, выполненных через порт 80, в приложение ASP.NET Core, прослушивающее порт 5000.

Ниже приведена необходимая конфигурация. Выделены некоторые ключевые части.

http {
  map $http_connection $connection_upgrade {
    "~*Upgrade" $http_connection;
    default keep-alive;
  }

  server {
    listen        80;
    server_name _;
    location / {
        proxy_pass         http://localhost:5000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection $connection_upgrade;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
  }
}

Эта конфигурация указывает на следующее:

  • Nginx будет прослушивать порт 80 для всех запросов (директива: listen 80).
  • Nginx перенаправит запросы в http://localhost:5000 (директива: proxy_pass http://localhost:5000)

Примечание.

Строка server_name _ в коде. Это используется в качестве директивы catch-all. Если вы хотите узнать больше о server_name, обратитесь к официальной документации.

Изменения конфигурации отображаются простыми. Этот код будет использоваться для замены server раздела директив в файле конфигурации. Но где находится файл конфигурации?

Поиск правильного файла конфигурации Nginx

Основным файлом конфигурации Nginx является /etc/nginx/nginx.conf. Чтобы проверить конфигурацию, используйте cat /etc/nginx/nginx.conf команду и выполните поиск директивы сервера.

Снимок экрана: команда cat.

Прокрутите конфигурацию, чтобы найти директиву сервера. Вы должны ожидать, чтобы не найти его. Мы можем поместить нужные изменения конфигурации в файл конфигурации. Однако в идеале вы не хотите заменить исходный файл конфигурации. Это позволяет предотвратить возникновение ошибок конфигурации, которые могут препятствовать правильному запуску сервера. Раздел server не содержится в главном файле конфигурации. Если прокрутите файл конфигурации, вы обнаружите, что есть некоторые include директивы.

Снимок экрана: команда include.

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

  • Nginx загружает конфигурацию из каждого файла CONF , расположенного в каталоге /etc/nginx/conf.d .
  • Nginx загружает конфигурации из каждого файла, расположенного в каталоге /etc/nginx/sites .

При проверке этих каталогов вы не найдете файлы конфигурации в /etc/nginx/conf.d. Однако в /etc/nginx/sites включен один файл.

Снимок экрана: команда conf.

Файл конфигурации по умолчанию выглядит как основной кандидат для размещения конфигурации, которую мы ищем. Если проверить файл /etc/nginx/sites-enabled/default с помощьюcat /etc/nginx/sites-enabled/default, вы увидите, что директива сервера по умолчанию помещается в следующий код.

Снимок экрана: сведения по умолчанию.

Таким образом, файл /etc/nginx/sites-enabled/default необходимо изменить, чтобы изменить конфигурацию .

Изменение файла конфигурации с помощью vi

Вы узнали, как редактировать файлы при редактировании файла Startup.cs , чтобы удалить перенаправление HTTPS из конвейера ASP.NET. Теперь вы снова будете использовать vi для изменения файла конфигурации nginx.

Совет

Всегда создайте резервную копию измененных файлов. Если что-то не так после редактирования, можно использовать эту копию для восстановления файла до предыдущего состояния. В этом случае выполните копирование cp /etc/nginx/sites-enabled/default ~/nginx-default-backup файла конфигурации в домашний каталог. Имя файла резервной копии будет nginx-default-backup. Обратите внимание, что резервная копия не была выполнена в том же каталоге, что и исходный файл. Это связано с тем, что Nginx загружает все файлы конфигурации из этого каталога, и вы не хотите разорвать конфигурацию, загрузив две разные версии директивы сервера.

Запустите sudo vi /etc/nginx/sites-enabled/default , чтобы изменить файл конфигурации и заменить директиву сервера, как показано на следующем снимке экрана.

Снимок экрана: команда vi.

Ниже приведены некоторые советы и рекомендации по редактированию файлов с помощью vi:

  • Вы можете прокручивать вверх и вниз с помощью клавиш со стрелками.
  • Чтобы войти в режим редактирования, нажмите клавишу INSERT или I . Пока вы находитесь в режиме редактирования, в нижнем левом углу появится сообщение --INSERT- .
  • В режиме редактирования можно использовать клавиатуру для удаления символов по одному за раз.
  • В режиме редактирования операции копирования и вставки работают вместе с большинством терминалов. Таким образом, вы можете скопировать содержимое из этой статьи и вставить его в vi.
  • Чтобы выйти из режима редактирования, нажмите клавишу ESC.
  • Вы можете легко удалять строки в обычном режиме. В обычном режиме перейдите к началу строки, которую вы хотите удалить, и введите dd. Команда dd удаляет всю строку. Вы также можете ввести 5dd, чтобы удалить пять строк одновременно. Однако этот параметр следует использовать с осторожностью, чтобы избежать удаления дополнительного содержимого.
  • Как удалить линии в Vim / Vi статья является хорошим, чтобы узнать, как удалить несколько строк в vi.
  • Чтобы выйти из vi и сохранить изменения, введите :wq!, а затем нажмите клавишу ВВОД. Здесь двоеточие (:) означает, что вы выполняете команду, означает запись изменений, w q означает выход и ! означает переопределение изменений.
  • Чтобы выйти без сохранения изменений, введите :q!, а затем нажмите клавишу ВВОД.

Изменения теперь сохраняются, и необходимо перезапустить службу Nginx, чтобы эти изменения вступили в силу. Перед перезапуском sudo nginx -t службы можно выполнить команду для тестирования файла конфигурации. При выполнении этой команды Nginx проверяет синтаксис файла конфигурации, а затем пытается открыть файлы, на которые ссылается файл конфигурации.

Снимок экрана: команда t.

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

Необходимо перезапустить Nginx, чтобы изменения вступили в силу:

sudo systemctl restart nginx

После перезапуска вы ожидаете, что вы увидите ответ от приложения ASP.NET Core при выполнении запроса на http://localhost , так как Nginx должен работать в качестве обратного прокси-сервера для запросов, сделанных в порт 80.

Перезапустите службу Nginx, чтобы изменения вступили в силу, а затем отправьте запрос на localhost, выполнив команду curl localhost. Однако эта команда завершится ошибкой. Следующим шагом является выполнение wget localhost, а затем поиск некоторых подсказок по источнику проблемы.

Снимок экрана: команда wget.

Устранение неполадок с прокси-сервером Nginx

На предыдущем снимке экрана вы увидите следующие сведения:

Resolving localhost (localhost)... 127.0.0.1  
Connecting to localhost (localhost)|127.0.0.1|:80... connected.  
HTTP request sent, awaiting response... 502 Bad Gateway  
2020-12-27 21:15:53 ERROR 502: Bad Gateway.

Первая и вторая строки указывают, что вы можете разрешить localhost и подключиться к сокету 127.0.0.1:80 . Поэтому nginx должен работать. Чтобы проверить это, можно выполнить systemctl status nginx команду.

Третья строка указывает источник проблемы. Вы получаете сообщение об ошибке HTTP 502 Bad Gateway . Недопустимый шлюз HTTP 502 связан с прокси-серверами. Это означает, что обратный прокси-сервер не мог подключиться к внутреннему приложению. В этом случае это веб-приложение ASP.NET Core, которое должно выполняться и прослушиваться через порт 5000 для запросов. Мы должны проверить, запущено ли веб-приложение.

Чтобы начать устранение неполадок, выполните ту же netstat команду, что и раньше. На этот раз используйте grep для фильтрации порта приложения 5000. Затем выполните netstat -tlp | grep 5000.

Снимок экрана: команда netstat.

В этом примере выходных данных указано, что прослушивание порта 5000 не выполняется. Поэтому это причина ответа HTTP 502 , исходящего из Nginx, так как он не может найти процесс, прослушивающий порт 5000.

Решением является запуск приложения ASP.NET Core. Однако прежде чем идти дальше, вы можете ознакомиться с другим подходом к устранению этой проблемы. Не каждая проблема так легко устранить, как просто посмотреть на несколько строк содержимого журнала и найти первопричину. Иногда необходимо глубоко изучить другие системные журналы и журналы приложений.

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

Проверка журналов Nginx

Если вы снова запустите cat /etc/nginx/nginx.conf , а затем найдите logging settingsего, обратите внимание на следующее.

Снимок экрана: сведения о журнале.

В этом примере показано, что Nginx имеет два типа журналов: журналы доступа и журналы ошибок. Они хранятся в каталоге /var/log/nginx/ .

Журналы доступа похожи на файлы журналов IIS. Быстрая проверка содержимого показывает, что они похожи на следующий снимок экрана.

Снимок экрана: команда доступа.

Журналы доступа не отображают новые сведения, отличные от состояния ответа HTTP 502, который вы уже знали. Вы также можете проверить журналы ошибок, выполнив команду cat /var/log/nginx/error.log. Они показывают много больше о причине проблемы.

Снимок экрана: сведения об ошибке.

Признаки понятны: Nginx может получить запрос от клиента, но он не может подключиться к серверу http://127.0.0.1:5000 и к upstream приложению ASP.NET Core, которое должно было выполняться и прослушиваться на этом порту.

Обходное решение

Чтобы обойти эту проблему, запустите приложение ASP.NET Core вручную. Подключитесь к серверу с помощью второго сеанса терминала, а затем запустите приложение ASP.NET Core, как и раньше.

Снимок экрана: сведения aspnet.

Пока запущено приложение ASP.NET Core, переключитесь на другой сеанс терминала и выполните ту же curl localhost команду. Теперь вы можете получить доступ к приложению ASP.NET Core, работающему за Nginx. На следующем снимне экрана показано, что вы сделали запрос на localhost, запрос был обработан Nginx и перенаправлен в серверное приложение, и вы получили ответ от приложения ASP.NET Core.

Снимок экрана: команда curllocalhost.

Теперь вы настроили Nginx поведение в качестве обратного прокси-сервера для приложения ASP.NET Core, работающего в Linux.

Однако если приложение ASP.NET Core не запускается после перезагрузки, что будет результатом? Что произойдет, если веб-приложение завершает работу и не запускается, пока не заметите, что он не запущен? Следует ли запускать приложение ASP.NET Core после каждого перезапуска процесса?

Следующие шаги

Часть 2.3. Настройка приложения ASP.NET Core для автоматического запуска

Заявление об отказе от ответственности за сведения о продуктах сторонних производителей

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