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

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

Este artigo discute como configurar um segundo site no Nginx usando o nome do host e como testar a configuração.

Pré-requisitos

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

• Nginx rodando automaticamente e escutando solicitações enviadas na porta 80.
• Nginx configurado como um proxy reverso e roteando todas as solicitações HTTP de entrada para o primeiro aplicativo principal ASP.NET que está escutando na porta 5000 (você pode usar qualquer aplicativo principal ASP.NET como um aplicativo de back-end em execução nessa porta.)
• Esse primeiro ASP.NET aplicativo Core configurado para sempre ser executado (se o processo for interrompido ou o servidor for reiniciado, o aplicativo ASP.NET Core deverá ser iniciado automaticamente).
• O firewall local do Linux habilitado e configurado para permitir o tráfego de entrada SSH e HTTP.
• Um segundo aplicativo ASP.NET Core configurado para escutar na porta 5001 (esse aplicativo também deve ser configurado para sempre ser executado e o aplicativo BuggyAmb sample ASP.NET Core deve ser configurado como o segundo aplicativo na configuração.)

Objetivo desta parte

Atualmente, há um site configurado no Nginx. Qualquer solicitação que chegue na porta 80 para o Nginx é roteada para esse site. O nome do host não importa nesta configuração. Use o endereço IP ou qualquer nome de host que seja resolvido para o endereço IP. Todas as solicitações serão roteadas para o site padrão. Esse site padrão atua como um proxy reverso e roteia as solicitações para o primeiro aplicativo principal ASP.NET que está escutando na porta 5000.

Nesta parte do tutorial, você criará um segundo site no Nginx. Esse site também atuará como um proxy reverso e qualquer solicitação que tenha um nome de host específico será roteada para o segundo aplicativo principal ASP.NET que está escutando na porta 5001.

Você também configurará o site para ouvir um nome de host específico. No final, haverá dois sites acessíveis e que possuem esses nomes de host:

• Primeiro site: http://myfirstwebsite direcionará o tráfego para o primeiro aplicativo de demonstração ASP.NET Core.
• Segundo site: http://buggyamb direcionará o tráfego para o segundo aplicativo com bugs de amostra ASP.NET Core.

Adicione myfirstwebsite e buggyamb ao arquivo hosts de seus computadores Windows e Linux clientes. Dessa forma, você pode usar essas URLs para testar a nova configuração.

Esses nomes de host são apenas para demonstração. Sinta-se à vontade para usar qualquer outro nome de host de sua preferência, desde que use consistentemente os mesmos nomes de host ao longo dos exercícios desta parte.

Configurar uma segunda web usando um nome de host no Nginx

Se você se lembra, um dos diretórios nos quais o Nginx carrega as configurações do site é /etc/nginx/sites-enabled/. Atualmente, há um arquivo de configuração padrão. O arquivo é semelhante à captura de tela a seguir.

Observação

Observe as partes destacadas porque você terá que modificá-las:

• server_name: Você pode definir o nome do host desejado aqui. Atualmente, isso está configurado para o valor _. Isso significa qualquer nome de host.
• proxy_pass: Este é o aplicativo principal ASP.NET real que está em execução e escutando em uma determinada URL. As solicitações são roteadas para esse URL.

Configure o primeiro site para escutar no cabeçalho http://myfirstwebsitedo host. Para conseguir isso, altere o server_name arquivo de configuração /etc/nginx/sites-enabled/default , conforme mostrado na captura de tela a seguir. Como lembrete, você terá que usar o sudo vi /etc/nginx/sites-enabled/default comando para editar este arquivo.

Crie um segundo arquivo de configuração do Nginx para o segundo site. Use esse arquivo como modelo para criar uma cópia desse arquivo no mesmo diretório de configuração. Nomeie o arquivo buggyamb.config.

sudo cp /etc/nginx/sites-enabled/default /etc/nginx/sites-enabled/buggyamb.config

Edite o arquivo de configuração executando o sudo vi /etc/nginx/sites-enabled/buggyamb.config comando. Aqui está a versão final do arquivo /etc/nginx/sites-enabled/buggyamb.config .

A configuração resultante deve ter dois arquivos de configuração no diretório de configuração do site do Nginx: buggyamb.config e default. Você terá que configurar o Nginx para recarregar as alterações de configuração. No entanto, você deve primeiro testar a nova configuração para garantir que nenhum erro tenha sido introduzido quando você fez alterações. Execute o sudo nginx -t comando e verifique se a configuração está correta. Em seguida, execute sudo nginx -s reload para recarregar a configuração e ler as novas alterações.

Testar a nova configuração

Defina os nomes de myfirstwebsite host e buggyamb para resolver para os endereços IP corretos. Quando você acessa os sites do computador Linux, esses nomes de host devem ser resolvidos para 127.0.0.1 e para os clientes externos, como o computador cliente Windows. Os nomes de host devem ser resolvidos para o endereço IP público da máquina virtual Linux. Você pode recuperar esse endereço IP do portal do Azure.

Observação

Os mapeamentos de Hosts são armazenados no arquivo /etc/hosts no Linux e no arquivo C:\WINDOWS\System32\drivers\etc\hosts no Windows.

Este é o conteúdo do arquivo hosts do Linux.

Você pode executar os curl myfirstwebsite comandos and curl buggyamb para fazer solicitações para cada um dos dois sites.

Aqui está a curl myfirstwebsite saída. A resposta parece estar exibindo corretamente o conteúdo HTML da home page da demonstração ASP.NET aplicativo principal que foi implantado inicialmente e está escutando na porta 5000.

E aqui está a curl buggyamb saída. Isso exibe o conteúdo HTML da home page do aplicativo de exemplo BuggyAmb que está em execução na porta 5001.

Você deve ser capaz de navegar pelas mesmas URLs do computador cliente usando um navegador. Isso também deve funcionar se você configurar o arquivo hosts corretamente. Isso é o que é exibido ao navegar em http://buggaymb um navegador em execução em um computador Windows.

Até este ponto, você tem a seguinte configuração:

• Nginx hospedando dois sites:

  • O primeiro site escuta as solicitações usando o cabeçalho do myfirstwebsite host e roteia as solicitações para nosso aplicativo de demonstração ASP.NET Core. Este aplicativo escuta na porta 5000.
  • O segundo site escuta o tráfego HTTP de entrada usando o valor do cabeçalho do host de , e roteia as solicitações para o segundo aplicativo com bugs de amostra do buggyambASP.NET Core. Este aplicativo escuta na porta 5001.

• Ambos os aplicativos ASP.NET Core estão sendo executados como serviços que são reiniciados automaticamente quando o servidor é reiniciado ou os aplicativos param de responder.

• O firewall local do Linux é habilitado e configurado para permitir tráfegos SSH e HTTP.

Dicas de solução de problemas

Você pode receber o erro HTTP 502 - Bad Gateway ao navegar em um site. "HTTP 502 - Gateway inválido" significa que o Nginx não conseguiu se comunicar com o aplicativo back-end ASP.NET Core. Isso ocorrerá se o aplicativo de back-end não estiver em execução.

Nesse caso:

• Certifique-se de que ambos os aplicativos ASP.NET Core ouçam em portas diferentes. Um deve ouvir na porta 5000, enquanto o outro deve ouvir na porta 5001.
• Certifique-se de que ambos os aplicativos ASP.NET Core estejam configurados para iniciar automaticamente.
• Verifique o status dos serviços de aplicativos ASP.NET Core que estão usando os systemctl status comandos. Se um não estiver em execução, solucione o problema examinando os logs do sistema executando o journalctl comando. Use syslogIdentifier para filtrar os logs.
• Verifique se o .NET Core 3.1 e o .NET 5.0 estão instalados. Um site usa o .NET Core 3.1, o outro usa o .NET 5.0.

Próximas etapas

Parte 3.1 - Prepare-se para a solução de problemas