Compartilhar via

Parte 2.3 - Configurar o aplicativo ASP.NET Core para iniciar automaticamente

Aplica-se a: .NET Core 2.1, .NET Core 3.1, .NET 5

Este artigo apresenta como configurar o aplicativo ASP.NET Core para garantir que o aplicativo seja iniciado automaticamente após a reinicialização do servidor.

Pré-requisitos

Para seguir os exercícios desta parte, você deve ter um aplicativo Web ASP.NET Core instalado e implantado no Linux.

Você também precisa configurar o servidor Web Nginx como um proxy reverso para rotear as solicitações para o aplicativo back-end ASP.NET Core da porta 80.

Objetivo desta parte

As partes anteriores desta série mostraram como configurar o Nginx como um proxy reverso e como solucionar um erro de proxy HTTP 502. A causa do código de resposta HTTP 502 é que o back-end ASP.NET aplicativo Core não estava em execução quando o Nginx tentou encaminhar o tráfego para ele.

O problema foi resolvido temporariamente executando seu aplicativo ASP.NET Core manualmente. Mas e se o aplicativo travar? Ou o servidor precisa ser reiniciado? Reiniciar manualmente o aplicativo ASP.NET Core todas as vezes não é uma solução prática. Portanto, nesta seção, você configurará o Linux para iniciar seu aplicativo depois que ele falhar.

Até agora, você configurou o Nginx e o ASP.NET Core para trabalharem juntos. O Nginx escuta na porta 80 e roteia as solicitações para o aplicativo ASP.NET Core que escuta na porta 5000. Embora o Nginx seja iniciado automaticamente, o aplicativo ASP.NET Core deve ser iniciado manualmente toda vez que o servidor for reiniciado. Caso contrário, o aplicativo ASP.NET Core será encerrado normalmente ou travará.

Se você executar o ASP.NET Core tendo o IIS como proxy, o IIS ASP.NET Core Module (ANCM) manipulará o gerenciamento do processo e o processo do ASP.NET Core será iniciado automaticamente. Outra opção é executar o ASP.NET Core como um serviço no Windows para que o recurso de inicialização automática possa ser configurado assim que o computador for iniciado.

Criar arquivo de serviço para seu aplicativo principal ASP.NET

Lembre-se de que o systemctl comando é usado para gerenciar os "serviços" ou "daemons". Um daemon é um conceito semelhante ao de um serviço do Windows. Esse serviço pode ser reiniciado automaticamente quando o sistema é iniciado.

O que é um arquivo de serviço?

No Linux, também existem arquivos de configuração de unidade que possuem uma extensão ".service" que é usada para controlar o comportamento dos daemons quando o processo é encerrado. Eles também são conhecidos como arquivos de serviço, arquivos de unidade e arquivos de unidade de serviço.

Esses arquivos de serviço estão localizados em um dos seguintes diretórios:

  • /usr/lib/systemd/: Armazena arquivos de serviço para aplicativos baixados
  • /etc/systemd/system/: Armazena arquivos de serviço criados por administradores do sistema

Inspecione o arquivo de serviço Nginx. Ele é instalado por meio de um gerenciador de pacotes. Seu arquivo de configuração deve estar na pasta /usr/lib/systemd/system/ . A execução do systemctl status nginx comando também exibe o local do arquivo de serviço.

Captura de tela do comando systemctl status nginx.

É assim que o arquivo de serviço Nginx se parece.

Captura de tela do comando cat.

Arquivo de serviço de amostra para aplicativos ASP.NET Core

O conteúdo do arquivo de unidade de exemplo a seguir é obtido do Host ASP.NET Core no Linux com 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

Aqui estão alguns aspectos-chave deste conteúdo:

  • WorkingDirectory é o diretório em que você publica seu aplicativo.
  • ExecStart é o comando real que inicia o aplicativo.
  • Restart=always é autoexplicativo. Esse processo é sempre iniciado se parar por algum motivo, seja manualmente ou por causa de uma falha.
  • RestartSec=10 também é autoexplicativo. Depois que o processo for interrompido, ele será iniciado após 10 segundos.
  • SyslogIdentifier é importante. Significa "identificador de log do sistema". As informações sobre o daemon são registradas com esse nome nos logs do sistema. Você também pode usar esse identificador para encontrar o PID do seu processo.
  • User é o usuário que gerencia o serviço. Ele deve existir no sistema e ter a propriedade apropriada dos arquivos do aplicativo.
  • Você pode definir qualquer número de variáveis de ambiente no arquivo de serviço.

Observação

O www-data usuário é um usuário especial no sistema. Você pode fazer uso desta conta. Você criará um novo usuário para praticar as permissões de usuário no Linux. No entanto, não há problema em usar www-data se você não quiser criar outro usuário do Linux.

Criar um arquivo de serviço para o aplicativo ASP.NET Core

Você usará vi para criar e editar o arquivo de serviço. Seu arquivo de serviço irá para a pasta /etc/systemd/system/ . Lembre-se de que, nesta série, você publicou seu primeiro aplicativo na pasta /var/firstwebapp/ . Portanto, WorkingDirectory deve apontar para essa pasta.

Aqui está o arquivo de configuração final:

[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

Execute sudo vi /etc/systemd/system/myfirstwebapp.service , cole a configuração final e salve o arquivo.

Captura de tela do comando sudo.

Isso conclui a configuração necessária para que o aplicativo Web ASP.NET Core seja executado como um daemon.

Como o aplicativo Web agora está configurado como um serviço, você pode verificar seu status executando systemctl status myfirstwebapp.serviceo . Como você pode ver na captura de tela a seguir, o aplicativo está desabilitado (não inicia automaticamente após a reinicialização do sistema) e não está em execução no momento.

Captura de tela do comando systemctl status.

Para iniciar o serviço, execute o sudo systemctl start myfirstwebapp.service comando e verifique o status novamente. Desta vez, você deve ver o serviço em execução e uma ID de processo deve ser listada ao lado dele. A saída do comando também mostra as últimas linhas dos logs do sistema para o serviço recém-criado e mostra que o serviço está escutando no http://localhost:5000.

Captura de tela do comando sudo systemctl start.

Se o aplicativo da web parar inesperadamente, ele será reiniciado automaticamente após 10 segundos.

Há uma etapa final: o serviço está em execução, mas não habilitado. "Ativado" significa que ele é iniciado automaticamente após o servidor ser iniciado. Esta é a configuração final desejada. Execute o seguinte comando para certificar-se de que o serviço está habilitado:

sudo systemctl enable myfirstwebapp.service

Captura de tela do comando sudo systemctl enable.

Esse é um marco para o aplicativo ASP.NET Core porque você o configurou para iniciar automaticamente após uma reinicialização do servidor ou um encerramento do processo.

Testar se ASP.NET aplicativo Core é reiniciado automaticamente

Antes de avançar para a próxima parte, certifique-se de que tudo esteja funcionando conforme o esperado. A configuração atual é a seguinte

  • O Nginx é executado automaticamente e escuta as solicitações enviadas na porta 80.
  • O Nginx é configurado como um proxy reverso e roteia solicitações para o aplicativo ASP.NET Core. O aplicativo está escutando na porta 5000.
  • O aplicativo ASP.NET Core é configurado para iniciar automaticamente após a reinicialização do servidor ou se o processo for interrompido ou travar.

Portanto, sempre que o serviço ASP.NET Core for interrompido, ele deverá ser reiniciado em 10 segundos. Para testar esse comportamento, você forçará a parada do processo. Você pode esperar que ele comece novamente em 10 segundos.

Observação

A ID do processo atual do aplicativo ASP.NET Core. A ID do processo para a tentativa mostrada aqui era 5084 antes de o processo ser encerrado. Para localizar o ID do processo para seu aplicativo ASP.net Core, execute o systemctl status myfirstwebapp.service comando.

Para forçar a parada do processo, execute o seguinte comando:

sudo kill -9 <PID>

Observação

9 Aqui está o tipo de sinal. De acordo com o man comando signal, 9 é SIGKILL (kill signal). Você pode abrir as páginas de Ajuda usando o man comando "kill and signal" para saber mais sobre este tópico.

Execute o systemctl status myfirstwebapp.service comando imediatamente após o kill comando, aguarde cerca de 10 segundos e execute o mesmo comando novamente.

Captura de tela do comando kill.

Nesta captura de tela, você pode ver as seguintes informações:

  • Antes de ser eliminado, o processo ASP.NET Core tinha uma ID de processo de 5084.
  • O status do serviço indicou que o processo que usa o PID 5084 foi encerrado e está sendo ativado novamente porque a reinicialização automática está configurada.
  • Alguns segundos depois, um novo processo (PID 5181) foi iniciado.

Se você tentar acessar o site usando curl localhosto , verá que o aplicativo principal do ASP.NET ainda está respondendo.

Próximas etapas

Parte 2.3.1 - [Opcional] Configure o aplicativo ASP.NET Core no Linux para iniciar automaticamente em um usuário diferente.