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

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

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

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

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

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

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

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

В предыдущих частях этой серии показано, как настроить Nginx в качестве обратного прокси-сервера и как устранить ошибку прокси-сервера HTTP 502. Причиной кода ответа HTTP 502 является то, что серверное приложение ASP.NET Core не выполнялось, когда Nginx пытался перенаправить трафик в него.

Проблема была временно устранена путем запуска приложения ASP.NET Core вручную. Но что делать, если приложение завершается сбоем? Или сервер должен быть перезапущен? Перезапуск приложения ASP.NET Core вручную не является практическим решением. Поэтому в этом разделе вы настроите Linux для запуска приложения после сбоя.

До сих пор вы настроили Nginx и ASP.NET Core для совместной работы. Nginx прослушивает порт 80 и направляет запросы к приложению ASP.NET Core, которое прослушивает порт 5000. Хотя Nginx запускается автоматически, приложение ASP.NET Core должно запускаться вручную при каждом перезапуске сервера. В противном случае приложение ASP.NET Core завершается корректно или завершается сбоем.

Если вы запускаете ASP.NET Core с помощью iis в качестве прокси-сервера, служба IIS ASP.NET Core Module (ANCM) обрабатывает управление процессами, а процесс ASP.NET Core запускается автоматически. Другим вариантом является запуск ASP.NET Core в качестве службы в Windows, чтобы функция автоматического запуска была настроена сразу после запуска компьютера.

Создание файла службы для приложения ASP.NET Core

Помните, что systemctl команда используется для управления "службами" или "daemons". Управляющая программа — это аналогичная концепция службы Windows. При запуске системы такая служба может быть перезапущена автоматически.

Что такое файл службы?

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

Эти файлы службы находятся в одном из следующих каталогов:

  • /usr/lib/systemd/: хранит файлы службы для загруженных приложений
  • /etc/systemd/system/: хранит файлы службы, созданные системными администраторами

Проверьте файл службы Nginx. Он устанавливается с помощью диспетчера пакетов. Его файл конфигурации должен находиться в папке /usr/lib/systemd/systemd/system/ . systemctl status nginx При выполнении команды также отображается расположение файла службы.

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

Это то, как выглядит файл службы Nginx.

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

Пример файла службы для приложений ASP.NET Core

В следующем примере содержимое файла единицы взято из узла ASP.NET Core в Linux с Nginx:

[Unit]
Description=Example .NET Web API App running on Ubuntu

[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/bin/dotnet /var/www/helloapp/helloapp.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

Ниже приведены некоторые ключевые аспекты этого содержимого:

  • WorkingDirectory — каталог, в котором вы публикуете приложение.
  • ExecStart — это фактическая команда, которая запускает приложение.
  • Restart=always является самообъяснительным. Этот процесс всегда запускается, если он останавливается по какой-либо причине, будь то вручную или из-за сбоя.
  • RestartSec=10 также является самообъяснительным. После остановки процесса он будет запущен через 10 секунд.
  • SyslogIdentifier важно. Это означает "идентификатор системного журнала". Сведения о управляющей программе регистрируются под этим именем в системных журналах. Этот идентификатор также можно использовать для поиска ИДЕНТИФИКАТОРа процесса.
  • User — это пользователь, который управляет службой. Он должен существовать в системе и иметь соответствующее владение файлами приложения.
  • Можно задать любое количество переменных среды в файле службы.

Примечание.

Пользователь www-data является специальным пользователем в системе. Эту учетную запись можно использовать. Вы создадите нового пользователя для практики разрешений пользователей в Linux. Тем не менее, это нормально использовать www-data , если вы не хотите создать другого пользователя Linux.

Создание файла службы для приложения ASP.NET Core

Вы будете использовать vi для создания и изменения файла службы. Файл службы перейдет в папку /etc/systemd/system/system/ . Помните, что в этой серии вы опубликовали первое приложение в папку /var/firstwebapp/ . Таким образом, WorkingDirectory должен указывать на эту папку.

Ниже приведен окончательный файл конфигурации:

[Unit]
Description=My very first ASP.NET Core applications running on Ubuntu

[Service]
WorkingDirectory=/var/firstwebapp/
ExecStart=/usr/bin/dotnet /var/firstwebapp/AspNetCoreDemo.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=myfirstapp-identifier
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Development
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

Запустите sudo vi /etc/systemd/system/myfirstwebapp.service , вставьте окончательную конфигурацию и сохраните файл.

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

Это завершает необходимую конфигурацию веб-приложения ASP.NET Core для запуска в качестве управляющей программы.

Так как веб-приложение теперь настроено как услуга, его состояние можно проверить, выполнив команду systemctl status myfirstwebapp.service. Как видно на следующем снимке экрана, приложение отключено (не запускается автоматически после перезагрузки системы), и оно в настоящее время не выполняется.

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

Чтобы запустить службу, выполните sudo systemctl start myfirstwebapp.service команду и снова проверьте состояние. На этот раз вы увидите, что служба запущена, и рядом с ней должен быть указан идентификатор процесса. В выходных данных команды также показаны последние несколько строк из системных журналов для созданной службы, и она показывает, что служба прослушивает http://localhost:5000.

Снимок экрана: команда запуска sudo systemctl.

Если веб-приложение непредвиденно остановится, он автоматически начнется снова через 10 секунд.

Существует один последний шаг: служба запущена, но не включена. Значение "Включено" означает, что он запускается автоматически после запуска сервера. Это требуемая окончательная конфигурация. Выполните следующую команду, чтобы убедиться, что служба включена:

sudo systemctl enable myfirstwebapp.service

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

Это веха для приложения ASP.NET Core, так как вы настроили его автоматически после перезапуска сервера или завершения процесса.

Проверьте, выполняется ли автоматическое перезапуск ASP.NET core приложения

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

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

Таким образом, каждый раз, когда служба ASP.NET Core останавливается, она должна перезапуститься через 10 секунд. Чтобы проверить это поведение, вы принудительно остановите процесс. Вы можете ожидать, что он снова начнется через 10 секунд.

Примечание.

Текущий идентификатор процесса приложения ASP.NET Core. Идентификатор процесса для попытки, показанной здесь, был 5084 до того, как процесс был убит. Чтобы найти идентификатор процесса для приложения ASP.net Core, выполните systemctl status myfirstwebapp.service команду.

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

sudo kill -9 <PID>

Примечание.

9 Вот тип сигнала. Согласно команде man сигнала, 9 используется SIGKILL (сигнал убийства). Чтобы узнать больше об этом разделе, можно открыть страницы справки с помощью man команды "kill and signal".

systemctl status myfirstwebapp.service Выполните команду сразу после kill команды, подождите около 10 секунд, а затем снова выполните ту же команду.

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

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

  • Перед убийством процесс ASP.NET Core имел идентификатор процесса 5084.
  • Состояние службы указало, что процесс, использующий PID 5084, был убит, и он активируется снова, так как настроен автоматический перезапуск.
  • Через несколько секунд был запущен новый процесс (PID 5181).

Если вы попытаетесь получить доступ к сайту с помощью curl localhost, вы увидите, что приложение ASP.NET Core по-прежнему отвечает.

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

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