Часть 2.7. Настройка второго веб-сайта с помощью имени узла в Nginx

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

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

Предварительные требования

Для этой части необходимо настроить следующие элементы:

• Nginx выполняется автоматически и прослушивает запросы, отправленные через порт 80.
• Nginx, настроенный как обратный прокси-сервер, и маршрутизация всех входящих HTTP-запросов в первое приложение ASP.NET Core, прослушивающее порт 5000 (вы можете использовать любое приложение ASP.NET Core в качестве серверного приложения, работающего на этом порту.)
• Это первое приложение ASP.NET Core, настроенное на всегдае выполнение (если процесс останавливается или сервер перезапускается, приложение ASP.NET Core должно запускаться автоматически.)
• Локальный брандмауэр Linux включен и настроен для разрешения Входящего трафика SSH и HTTP.
• Второе приложение ASP.NET Core, настроенное для прослушивания порта 5001 (это приложение также должно быть настроено для всегдаго запуска, а пример приложения BuggyAmb ASP.NET Core должен быть настроен в качестве второго приложения в установке.)

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

В настоящее время в Nginx настроен один сайт. Любой запрос, поступающий через порт 80 в Nginx, направляется на этот сайт. Имя узла не имеет значения в этой настройке. Используйте IP-адрес или любое имя узла, которое разрешается в IP-адрес. Все запросы будут перенаправлены на веб-сайт по умолчанию. Этот веб-сайт по умолчанию выступает в качестве обратного прокси-сервера и направляет запросы к первому приложению ASP.NET Core, которое прослушивается через порт 5000.

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

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

• Первый веб-сайт: http://myfirstwebsite будет направлять трафик на первое демонстрационное приложение ASP.NET Core.
• Второй веб-сайт: http://buggyamb будет направлять трафик во второй ASP.NET пример приложения с ошибками Core.

Добавьте myfirstwebsite и buggyamb в файл узлов клиентских компьютеров Windows и Linux. Таким образом, эти URL-адреса можно использовать для проверки новой конфигурации.

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

Настройка второго веб-сайта с помощью имени узла в Nginx

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

Примечание.

Обратите внимание на выделенные части, так как вам придется изменить следующие элементы:

• server_name: здесь можно задать требуемое имя узла. В настоящее время это значение настроено _. Это означает любое имя узла.
• proxy_pass: это фактическое приложение ASP.NET Core, которое выполняется и прослушивает заданный URL-адрес. Запросы направляются по этому URL-адресу.

Настройте первый веб-сайт для прослушивания заголовка http://myfirstwebsiteузла. Для этого измените server_name файл конфигурации /etc/nginx/sites-enabled/default , как показано на следующем снимке экрана. Как напоминание, вам придется использовать sudo vi /etc/nginx/sites-enabled/default команду для редактирования этого файла.

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

sudo cp /etc/nginx/sites-enabled/default /etc/nginx/sites-enabled/buggyamb.config

Измените файл конфигурации, выполнив sudo vi /etc/nginx/sites-enabled/buggyamb.config команду. Ниже приведена окончательная версия файла /etc/nginx/sites-enabled/buggyamb.config .

Результирующая настройка должна иметь два файла конфигурации в каталоге конфигурации сайта Nginx: buggyamb.config и default. Чтобы перезагрузить изменения конфигурации, необходимо задать Nginx. Однако сначала необходимо протестировать новую конфигурацию, чтобы убедиться, что при внесении изменений не были внесены ошибки. sudo nginx -t Выполните команду и убедитесь, что конфигурация правильна. Затем запустите sudo nginx -s reload , чтобы перезагрузить конфигурацию и прочитать в новых изменениях.

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

myfirstwebsite Задайте имена узлов, buggyamb чтобы разрешить правильные IP-адреса. При доступе к сайтам с компьютера Linux эти имена узлов должны разрешаться до 127.0.0.1 и для внешних клиентов, таких как клиентский компьютер Windows. Имена узлов должны разрешаться на общедоступный IP-адрес виртуальной машины Linux. Этот IP-адрес можно получить из портал Azure.

Примечание.

Сопоставления узлов хранятся в файле /etc/hosts в Linux и в файле C:\WINDOWS\System32\drivers\etc\hosts в Windows.

Это содержимое файла узлов Linux.

Вы можете запустить команды и curl buggyamb выполнить curl myfirstwebsite запросы к каждому из двух сайтов.

Ниже приведены выходные curl myfirstwebsite данные. Ответ, кажется, правильно отображает HTML-содержимое на домашней странице демонстрации ASP.NET основного приложения, которое было первоначально развернуто и прослушивает порт 5000.

И вот выходные curl buggyamb данные. Откроется HTML-содержимое на домашней странице примера приложения BuggyAmb, работающего через порт 5001.

Вы должны иметь возможность просматривать те же URL-адреса с клиентского компьютера с помощью браузера. Это также должно работать при правильной настройке файла узлов. Это то, что отображается при просмотре http://buggaymb из браузера, работающего на компьютере с Windows.

До этого момента у вас есть следующая настройка:

• Nginx, на котором размещены два веб-сайта:

  • Первый веб-сайт прослушивает запросы с помощью заголовка myfirstwebsite узла и направляет запросы в демонстрационное приложение ASP.NET Core. Это приложение прослушивает порт 5000.
  • Второй веб-сайт прослушивает входящий HTTP-трафик с помощью значения buggyambзаголовка узла и направляет запросы во второй ASP.NET пример приложения ошибки Core. Это приложение прослушивает порт 5001.

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

• Локальный брандмауэр Linux включен и настроен для разрешения трафика SSH и HTTP.

Советы по устранению неполадок

При просмотре сайта может возникать ошибка HTTP 502 — ошибка плохого шлюза. "HTTP 502 — недопустимый шлюз" означает, что Nginx не смог взаимодействовать с серверным приложением ASP.NET Core. Это происходит, если серверное приложение не запущено.

В данном случае:

• Убедитесь, что оба приложения ASP.NET Core прослушивают разные порты. Один должен прослушивать порт 5000, а другой должен прослушивать порт 5001.
• Убедитесь, что оба приложения ASP.NET Core настроены для автоматического запуска.
• Проверьте состояние служб приложений ASP.NET Core, использующих systemctl status команды. Если он не запущен, устраните ее, проверив системные журналы, выполнив journalctl команду. Используется syslogIdentifier для фильтрации журналов.
• Убедитесь, что установлены как .NET Core 3.1, так и .NET 5.0. Один сайт использует .NET Core 3.1, другой использует .NET 5.0.

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

Часть 3.1. Подготовка к устранению неполадок