Parte 2.6 - Executar dois aplicativos ASP.NET Core ao mesmo tempo

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

Este artigo discute como fazer com que dois aplicativos ASP.NET Core sejam executados lado a lado, ouçam em portas diferentes e processem solicitações de entrada.

Pré-requisitos

Para concluir esta parte do tutorial, você deve ter os seguintes itens configurados:

• Os SDKs do .NET Core 3.1 e do .NET 5.0 instalados.
• Nginx rodando automaticamente e escutando solicitações enviadas na porta 80.
• Nginx configurado como um proxy reverso e roteando todas as solicitações para o aplicativo ASP.NET Core (escutando na porta 5000).
• Um ASP.NET aplicativo Core que está em execução e configurado para iniciar automaticamente depois que o servidor é reiniciado ou depois que o processo é interrompido.
• Firewall local do Linux habilitado e configurado para permitir tráfego SSH e HTTP.
• Exemplo de aplicativo ASP.NET Core com bugs baixado e extraído para o diretório /var/buggyamb_v1.1 .

O primeiro aplicativo de demonstração do ASP.NET Core usado nesta série é um aplicativo ASP.NET Core 5.0. O segundo aplicativo é um aplicativo ASP.NET Core 3.1. Se você não tiver os SDKs do .NET Core 3.1 e do .NET 5.0 instalados, instale o ausente antes de continuar.

Observação

Você pode verificar a versão instalada de runtimes e SDKs executando o dotnet --info comando. A instalação do .NET Core foi discutida nas partes anteriores desta série.

Objetivo desta parte

No final desta parte, você terá dois aplicativos ASP.NET Core que estão sendo executados lado a lado, escutando em portas diferentes e processando solicitações de entrada.

A maioria das ações que você executará nesta parte será semelhante: criar um arquivo de serviço para o segundo aplicativo ASP.NET Core para que ele possa ser iniciado sempre que o servidor for reiniciado ou o processo for interrompido.

Executar segundo aplicativo

Execute um segundo aplicativo como um serviço semelhante ao primeiro aplicativo em execução. Antes de criar o arquivo de serviço, verifique se ele é executado corretamente.

Lembre-se de que, nos capítulos anteriores, você foi instruído a copiar o aplicativo de depuração de teste para o diretório /var/buggyamb_v1.1/ e, em seguida, executar o aplicativo usando o dotnet /var/buggyamb_v1.1/BuggyAmb.dll comando. Você pode ver a seguinte mensagem de erro:

System.IO.IOException: Falha ao vincular ao endereço http://127.0.0.1:5000: endereço já em uso.

De acordo com esta mensagem, outro processo já está usando a porta 5000. Isso é óbvio. Mas como você pode saber qual processo está usando a porta? Executando o sudo netstat -tulpn | grep 5000 comando. Na captura de tela a seguir, o PID é 12536 e o nome do processo é dotnet. Você provavelmente verá que o ID do processo será diferente:

A próxima etapa é entender qual aplicativo principal do ASP.NET é hospedado pelo processo dotnet que está escutando na porta 5000. Você pode executar o cat /proc/12536/cmdline comando para obter um resultado semelhante à captura de tela a seguir.

Este é o primeiro aplicativo ASP.NET Core configurado nesta série. Está escutando na porta 5000. Portanto, nosso novo aplicativo com bugs ASP.NET Core não pode escutar na mesma porta.

Observação

Você aprendeu algo novo aqui. Há um diretório chamado /proc. Se você listar o conteúdo desse diretório, verá diretórios nomeados para cada PID em execução naquele momento. Cada subpasta terá vários arquivos que você pode usar para obter propriedades de cada processo, como a linha de comando e informações de memória ou CPU. Por enquanto, não se concentre nisso porque discutiremos isso quando abordarmos ferramentas e processos.

A solução para o problema de conflito de porta não é parar de executar o primeiro aplicativo. Como o objetivo é ter os dois aplicativos em execução ao mesmo tempo, a solução é, na verdade, executar o segundo aplicativo ASP.NET Core em uma porta diferente.

Configurar o aplicativo de segunda ASP.NET Core para escutar em uma porta diferente

Existem diferentes maneiras de atingir esse objetivo:

• Use UseUrls() para definir a porta em Program.cs: Isso significa que a porta está codificada no aplicativo. Embora possamos ler o port de um arquivo de configuração, você não deseja alterar o aplicativo e compilar novamente. Portanto, este treinamento não se concentrará nessa solução.
• Argumentos de linha de comando: use o --urls parâmetro ao executar seu aplicativo.
• Variáveis de ambiente: defina a URL para escutar para usar uma variável de ambiente. Use DOTNET_URLS ou ASPNETCORE_URLS nomes de variáveis de ambiente para conseguir isso.

As variáveis de ambiente e a abordagem de argumento de linha de comando são opções a serem consideradas. Tente testar a --urls opção, conforme mostrado na captura de tela a seguir.

Lembre-se de que o objetivo é executar o aplicativo como um serviço. Isso requer que você tenha um arquivo de serviço no qual possa definir variáveis de ambiente. Você pode definir o comando executável como mostrado anteriormente ou pode definir variáveis de ambiente. Os exemplos a seguir usam variáveis de ambiente para configurar o aplicativo para escutar em uma porta alternativa.

Criar um arquivo de unidade de distribuição de dados para o segundo aplicativo

Você usará a seguinte definição de serviço em seu arquivo de unidade de serviço. Lembre-se de que o segundo aplicativo será executado no diretório /var/buggyamb_v1.1 .

Observação

A Environment=ASPNETCORE_URLS=http://localhost:5001 linha declarará uma variável de ambiente nomeada ASPNETCORE_URLS e informará ao nosso aplicativo para escutar na porta 5001:

[Unit]
Description=BuggyAmb is a really buggy application
 
[Service]
WorkingDirectory=/var/buggyamb_v1.1/
ExecStart=/usr/bin/dotnet /var/buggyamb_v1.1/BuggyAmb.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=buggyamb-identifier
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Development
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false
Environment=ASPNETCORE_URLS=http://localhost:5001
 
[Install]
WantedBy=multi-user.target

O nome do arquivo de serviço será buggyamb.service e será criado no diretório /etc/systemd/system/. Assim como você fez antes, use o editor vi e execute o sudo vi /etc/systemd/system/buggyamb.service comando para criar o arquivo de definição de serviço. Copie e cole essa configuração e salve-a. Novamente, observe como você define a variável de ASPNETCORE_URLS ambiente:

Agora você configurou o aplicativo Web ASP.NET Core com bugs para ser executado como um daemon. Isso é suficiente para atingir a meta que declaramos no início do treinamento? Habilite e inicie o serviço executando os sudo systemctl enable buggyamb.service comandos and sudo systemctl start buggyamb.service . Em seguida, verifique o status do serviço executando systemctl status buggyamb.service, conforme mostrado na captura de tela a seguir.

Você está no ponto em que agora pode verificar se o aplicativo BuggyAmb funciona conforme o esperado. Execute o curl localhost:5001 comando para que a página de boas-vindas do HTML do BuggyAmb seja exibida no console, conforme mostrado na captura de tela a seguir.

O aplicativo ainda não pode ser testado no cliente porque está escutando na porta 5001. Essa porta não é permitida nas configurações do firewall. Como o Nginx não expõe a porta à Internet, você pode configurar o Nginx para escutar na porta 80 e rotear o tráfego para o BuggyAmb quando as solicitações HTTP recebidas forem feitas usando um determinado nome de host. Por exemplo, você pode usar os nomes de host: http://buggyamb ou http://buggyweb. Você também pode usar qualquer outro nome de host que desejar.

Por enquanto, a meta é atingida para ter o segundo aplicativo ASP.NET Core rodando lado a lado com o primeiro aplicativo de demonstração. No próximo capítulo, continuaremos a configurar o Nginx conforme o descrevemos nesta parte.

Próximas etapas

Parte 2.7 - Configurar um segundo site com o nome do host no Nginx