Я работаю с приложением.NET Core, работающим как находящийся в systemd сервис, на размещенном Azure VM это выполняет NGINX. (VM уполномочен как среда разработки). Я создал Azure использования A-записи DNS, для указания на IP сервера. Когда я ввожу указанное имя хоста (myapplication.mycompany.com
) в браузере я вижу страницу приветствия NGINX:
Когда я ввожу URL, что я ожидаю возвращать число версии приложения, я вижу 404:
myapplication.mycompany.com/version.txt
Когда я работаю systemctl status myservicename
, Я вижу, что сервис.NET Core запускается, и что основная услуга работает следующим образом:
CGroup: /system.slice/myservicename.service
└─...PID... /usr/bin/dotnet /var/aspnetcore/myservicename/myservice.dll
Когда я затем заглядываю /var/aspnetcore/myservicename/wwwroot
, Я вижу файл version.txt
curl -v localhost:5000
возвраты a 302 found
, утверждение Server: Kestrel
, таким образом, я полагаю, что пустельга служит сервису на порт 5000
Когда я смотрю на конфигурацию NGINX на производстве VM (который является очень похожим изображением, выполняя сопоставимый экземпляр сервиса.NET Core), я не вижу ничего, что похоже, это делает любое специальное сцепление пустельге. Я смотрю на конфигурацию NGINX при помощи:
cat /etc/nginx/nginx.conf
cat /etc/nginx/conf.d
(эти файлы выглядят идентичными тем на разработке VM),
Где я должен смотреть, для определения то, что конфигурация для запросов маршрутизации к приложению.NET Core? И есть ли что-либо очевидное, это может вызывать 404, когда я запрашиваю ...hostname.../version.txt
?
ОБНОВЛЕНИЕ
Я узнал это /etc/nginx/sites-available/default
на веб-сервере NGINX имеет некоторые основные настройки. Таким образом, я добавил установку для имени сервера, которое соответствует моему имени хоста.
server {
listen 80;
server_name myapplication.mycompany.com;
Когда я посещаю myapplication.mycompany.com/version.txt
Я все еще добираюсь 404
:
Я узнал, что существует 2 файла конфигурации, которые определяют доступность веб-сайта:
/etc/nginx/sites-available/default
/etc/nginx/sites-enabled/default
им обоим нужна подобная настроенная маршрутизация, для определения веб-сайтов, которые доступны и включены на сервере NGINX:
Оба из файлов конфигурации устанавливают порт (80), который NGINX использует для слушания запросов и установила server_name, который связывает имя хоста Azure DNS с веб-сервером NGINX:
server {
listen 80;
server_name myapplication.mycompany.com;
конфигурация также определяет, как запросы обратные проксированный (по существу вЂforwarded’) на пустельгу, где запросы затем обработаны приложением через MVC.NET Core маршрутизация
location / {
... cacheing stuff
proxy_pass <http://localhost:5000;>