Часть 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 в качестве прокси-сервера, управление процессом обрабатывается модулем ASP.NET CORE IIS (ANCM), и процесс ASP.NET Core запускается автоматически. Другой вариант — запустить ASP.NET Core как услугу в Windows, чтобы можно было настроить функцию автозапуска сразу же после запуска компьютера.
Создание файла службы для приложения ASP.NET Core
Напомним systemctl
, что команда используется для управления "службами" или "управляющими программами". Управляющая программа — это концепция, аналогичная концепции службы Windows. Такая служба может быть автоматически перезапущена при запуске системы.
Что такое файл службы?
В Linux также существуют файлы конфигурации единиц с расширением .service, которое используется для управления поведением управляющих программ при завершении процесса. Они также называются файлами служб, файлами единиц и файлами единиц обслуживания.
Эти файлы службы находятся в одном из следующих каталогов:
- /usr/lib/systemd/: файлы службы для скачанных приложений
- /etc/systemd/system/: хранит файлы служб, созданные системными администраторами.
Проверьте файл службы Nginx. Он устанавливается через диспетчер пакетов. Файл конфигурации должен находиться в папке /usr/lib/systemd/system/ . При выполнении systemctl status nginx
команды также отображается расположение файла службы.
Вот как выглядит файл службы Nginx.
Пример файла службы для приложений 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
имеет важное значение. Это означает "идентификатор системного журнала". Сведения о управляющей программе регистрируются под этим именем в системных журналах. Этот идентификатор также можно использовать для поиска PID процесса. -
User
— это пользователь, который управляет службой. Он должен существовать в системе и иметь соответствующие права владения файлами приложения. - В файле службы можно задать любое количество переменных среды.
Примечание.
Пользователь www-data
является особым пользователем в системе. Эту учетную запись можно использовать. Вы создадите нового пользователя для практики разрешений пользователей в Linux. Однако его можно использовать www-data
, если вы не хотите создавать другого пользователя Linux.
Создание файла службы для приложения ASP.NET Core
Вы будете использовать для vi
создания и изменения файла службы. Файл службы перейдет в папку /etc/systemd/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
, вставьте окончательную конфигурацию и сохраните файл.
Это завершает необходимую настройку веб-приложения ASP.NET Core для запуска в качестве управляющей программы.
Так как веб-приложение теперь настроено как служба, его состояние можно проверка, запустив systemctl status myfirstwebapp.service
. Как видно на следующем снимке экрана, приложение отключено (не запускается автоматически после перезапуска системы) и в настоящее время не выполняется.
Чтобы запустить службу, выполните sudo systemctl start myfirstwebapp.service
команду и снова проверка состояние. На этот раз вы увидите запущенную службу, а рядом с ней должен быть указан идентификатор процесса. Выходные данные команды также показывают последние несколько строк из системных журналов для только что созданной службы и показывают, что служба прослушивает http://localhost:5000
.
Если веб-приложение неожиданно остановится, оно автоматически запустится снова через 10 секунд.
Существует один последний шаг: служба запущена, но не включена. Значение "Включено" означает, что он запускается автоматически после запуска сервера. Это желательная окончательная конфигурация. Выполните следующую команду, чтобы убедиться, что служба включена:
sudo systemctl enable myfirstwebapp.service
Это веха для приложения 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 секунд, а затем снова выполните ту же команду.
На этом снимке экрана вы увидите следующие сведения:
- До того, как он был убит, ASP.NET Core процесс имел идентификатор процесса 5084.
- Состояние службы указывает, что процесс, использующий PID 5084, был остановлен, и он активируется снова, так как настроен автоматический перезапуск.
- Через несколько секунд был запущен новый процесс (PID 5181).
Если вы попытаетесь получить доступ к сайту с помощью curl localhost
, вы увидите, что ASP.NET Core приложение по-прежнему отвечает.