BLOG | NGINX

Tutorial: Proxying .NET Core e Kestrel com NGINX e NGINX Plus

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Nick Shadrin
Nick Shadrin
Publicado em 14 de fevereiro de 2017

Cerca de dois anos atrás, a Microsoft® anunciou o .NET Core , uma estrutura que permite desenvolver e executar aplicativos .NET nativamente em sistemas Linux e Mac. O ASP.NET Core inclui o Kestrel , uma biblioteca interna do servidor web.

Conforme indicado na documentação do Kestrel no site da Microsoft e no repositório GitHub , você normalmente executa o Kestrel por trás de um servidor web de produção, como IIS ou NGINX. Neste tutorial, descreveremos como implementar o Kestrel por trás do NGINX e do NGINX Plus.

Neste tutorial você aprenderá como:

Quando a instalação e a configuração estiverem concluídas:

  • .NET Core e Kestrel:

    • Execute o código do aplicativo dinâmico
    • Ouça em um endereço IP local e responda a solicitações HTTP
  • NGINX ou NGINX Plus, atuando como um proxy reverso:

    • Aceita tráfego HTTP/2 sobre IPv6 e IPv4
    • Fornece descarregamento SSL para o aplicativo .NET
    • Fornece serviço de arquivo estático
    • Fornece logs de acesso
    • Adiciona cache
  • NGINX Plus:

    • Fornece monitoramento de atividade ao vivo e métricas
    • Garante que o aplicativo esteja funcionando por meio de verificações de integridade ativas

A arquitetura de implantação de aplicativos .NET Core é semelhante à arquitetura de implantação de aplicativos Node.js ou Go. O NGINX fornece aos aplicativos .NET recursos de gerenciamento de tráfego que simplificam a implantação da produção e a escalabilidade dos aplicativos. Você pode executar vários aplicativos .NET na mesma máquina ou em máquinas diferentes, e o NGINX ou NGINX Plus executa o balanceamento de carga e o roteamento inteligente de tráfego entre eles.

Instruções

As instruções a seguir explicam como criar rapidamente um aplicativo “Hello World” usando .NET Core, executá-lo no Linux e implantá-lo por trás de um proxy reverso NGINX ou NGINX Plus com funcionalidade avançada de gerenciamento de tráfego.

  1. Instalar .NET Core, NGINX e NGINX Plus
  2. Execute o aplicativo “Hello World”
  3. Execute o servidor HTTP Kestrel
  4. Configurar NGINX ou NGINX Plus para fazer proxy reverso do aplicativo .NET
  5. Configurar o NGINX Plus Live Activity Monitoring e as verificações de integridade ativas

Instalar .NET Core, NGINX e NGINX Plus

  1. Instale o .NET Core usando as instruções no site da Microsoft.

    No nosso exemplo, estamos usando o Ubuntu 16.04. Os comandos a seguir estavam corretos no momento da escrita, mas estão sujeitos a alterações porque o Kestrel ainda está em desenvolvimento. Consulte a documentação do .NET Core conforme necessário.

    $ sudo apt-get install apt-transport-https $ sudo sh -c 'echo "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet-release/ xenial main" > /etc/apt/sources.list.d/dotnetdev.list' $ sudo apt-key adv --keyserver apt-mo.trafficmanager.net --recv-keys 417A0893 $ sudo apt-get update $ sudo apt-get install dotnet-dev-1.0.0-preview2-003131
    
  2. Instalar o NGINX:

    $ sudo apt-get install nginx
  3. Instale o NGINX Plus se quiser monitoramento de atividades em tempo real, verificações de integridade ativas ou ambos. Veja as instruções no Guia de administração do NGINX Plus .

    1. Edite o arquivo ./project.json para adicionar o Kestrel como uma dependência do projeto.

      { "versão": "1.0.0-*", "buildOptions": { "debugType": "portable", "emitEntryPoint": true }, "dependencies": {}, "frameworks": { "netcoreapp1.0": { "dependencies": { "Microsoft.NETCore.App": { "type": "platform", "version": "1.0.1" } , "Microsoft.AspNetCore.Server.Kestrel": "1.0.0" }, "importações": "dnxcore50" } } }
      
    2. Copie este código para um aplicativo simples para um novo arquivo chamado Program.cs . Ele retorna a data e hora atuais, executando o Kestrel na porta 5000 no host local.

      usando System;usando Microsoft.AspNetCore.Builder;
      usando Microsoft.AspNetCore.Hosting;
      usando Microsoft.AspNetCore.Http;
      
      namespace ConsoleApplication
      {
      classe pública Programa
      {
      público estático vazio Main(string[] args)
      {
      var host = new WebHostBuilder()
      .UseKestrel()
      .Configure(app =>
      {
      app.Run(async (contexto) => await context.Response.WriteAsync("Data atual: " + DateTime.Now + "n"));
      })
      .Build();
      
      host.Run();
      }
      }
      }
      
    3. Execute o comando dotnet run para iniciar o servidor .NET Core:

      $ dotnet run O aplicativo de projeto (.NETCoreApp,Version=v1.0) será compilado porque as entradas foram modificadas Compilando aplicativo para .NETCoreApp,Version=v1.0 Compilação bem-sucedida.
          0 Aviso(s) 0 Erro(s) Tempo decorrido 00:00:01.9047678 Olá, mundo!
      Ambiente de hospedagem: Caminho raiz do conteúdo de produção: /app/bin/Debug/netcoreapp1.0 Agora escutando em: http://localhost:5000 Aplicativo iniciado. Pressione Ctrl+C para desligar.
      
    4. Execute o comando curl para testar a conectividade e o HTTP:

      $ curl -v localhost:5000 * URL reconstruída para: localhost:5000/ * Tentando ::1... * Conectado ao localhost (::1) porta 5000 (#0) > GET / HTTP/1.1 > Host: localhost:5000 > User-Agent: curl/7.47.0 > Aceitar: */* > < HTTP/1.1 200 OK < Data: Ter, 14 Fev 2017 19:50:59 GMT < Transfer-Encoding: chunked < Servidor: Kestrel < Data atual: 14/02/17 12:50:59 PM * Conexão #0 com o host localhost deixada intacta
      
    1. Instale um certificado SSL. Existem várias maneiras de obter um:

      • Compre de uma autoridade de certificação (CA) bem conhecida
      • Peça ao seu grupo de TI corporativo ou CA para gerá-lo
      • Exporte-o de um servidor IIS existente
      • Use uma CA gratuita como a Let's Encrypt
      • Gerar um certificado autoassinado diretamente

      Para fins de criação rápida de um aplicativo .NET Core de exemplo com SSL, estamos gerando um certificado autoassinado e uma chave associada com este comando openssl . Estamos instalando o certificado e a chave no local padrão do NGINX, /etc/nginx , mas você pode escolher um local diferente.

      $ openssl req -x509 -subj /CN=localhost -days 365 -set_serial 2 -newkey rsa:4096 -keyout /etc/nginx/cert.key -nodes -out /etc/nginx/cert.pem Gerando uma chave privada RSA de 4096 bits .........++ ............................++ gravando uma nova chave privada em '/etc/nginx/cert.key' -----
      
    2. Configure o proxy reverso no arquivo de configuração padrão do NGINX e do NGINX Plus para servidores virtuais HTTP.

      O arquivo de configuração principal do NGINX e do NGINX Plus é /etc/nginx/nginx.conf . Entretanto, várias distribuições NGINX (assim como o NGINX Plus) seguem a convenção de que você não coloca muita configuração real no arquivo principal, mas, em vez disso, cria arquivos menores e específicos de função em um subdiretório de /etc/nginx :

      • Para compilações NGINX Open Source fornecidas por nginx.org e para NGINX Plus, o diretório é /etc/nginx/conf.d e o arquivo padrão para servidores virtuais HTTP é default.conf .
      • Para compilações NGINX Open Source distribuídas com o Ubuntu, o diretório é /etc/nginx/sites-enabled , e o arquivo padrão para servidores virtuais HTTP é default .

      O conteúdo dos arquivos específicos da função nesses diretórios é então lido no arquivo principal ( nginx.conf ) com uma diretiva include , por exemplo:

      incluir /etc/nginx/conf.d/*.conf;incluir /etc/nginx/sites-enabled/*;
      

      Se você não tiver certeza de qual é o arquivo de configuração padrão para servidores virtuais HTTP em seu sistema, encontre a diretiva include relevante em /etc/nginx/nginx.conf .

      Para configurar o NGINX ou o NGINX Plus como um proxy reverso, adicione os três blocos de configuração a seguir ao arquivo de configuração padrão para servidores virtuais HTTP:

      • O primeiro bloco do servidor aceita solicitações HTTP na porta 80 e as redireciona para o servidor virtual para solicitações HTTPS.

      • O segundo bloco de servidores aceita solicitações HTTPS na porta 443 e as envia por proxy para um grupo de um ou mais servidores upstream (backend), aqui chamados de dotnet . (Se na Etapa 1 você instalou seu certificado SSL autoassinado em um diretório diferente de /etc/nginx , substitua o caminho correto nas diretivas ssl_certificate e ssl_certificate_key .)

      • O bloco upstream define o grupo dotnet de servidores backend.

        Em Executar o servidor HTTP Kestrel , configuramos o Kestrel em localhost:5000 , o que significa que ele escuta tanto o tráfego IPv4 quanto o IPv6 nessa porta. (Configurar o Kestrel para apenas um protocolo pode causar instabilidade e potencialmente502 erros.) Da mesma forma, o NGINX e o NGINX Plus resolvem o localhost para seus endereços IPv4 e IPv6 (127.0.0.1 e ::1). Para simplificar, aqui identificamos o servidor upstream como127.0.0.1 em vez de localhost , para que ele escute apenas tráfego IPv4. Você pode usar o localhost se estiver confortável com uma configuração mais avançada que inclua IPv6.

      servidor { ouvir 80 default_server;
      ouvir [::]:80 default_server;
      retornar 301 https://$host$request_uri;
      }
      
      servidor {
      ouvir 443 ssl http2 default_server;
      ouvir [::]:443 ssl http2 default_server;
      
      certificado_ssl /etc/nginx/cert.pem;
      chave_certificado_ssl /etc/nginx/cert.key;
      
      localização / {
      senha_proxy http://dotnet;
      cabeçalho_conjunto_proxy Host $host;
      }
      }
      
      upstream dotnet {
      zona dotnet 64k;
      servidor 127.0.0.1:5000;
      }
      
    3. Execute este comando curl para testar a conectividade com o aplicativo .NET Core via HTTPS. (Você também pode apontar seu navegador para seu servidor Linux.)

      $ curl -kv https://localhost * URL reconstruída para: https://localhost/ * Tentando ::1... * Conectado ao localhost (::1) porta 443 (#0) ...[ IGNORADO ]... < HTTP/1.1 200 OK < Servidor: nginx/1.10.0 (Ubuntu) < Data: Ter, 14 Fev 2017 20:22:07 GMT < Transfer-Encoding: chunked < Connection: keep-alive < Data atual: 14/02/17 13:22:07
      

      Observação:  Se você ver 502 Ruim Porta de entrada erros, significa que o NGINX ou o NGINX Plus não pode se conectar ao seu aplicativo .NET. Certifique-se de que ele esteja em execução e fornecendo respostas na porta 5000.

      Se você instalou o pacote nghttp2 , também pode executar o seguinte comando nghttp para testar a conectividade via HTTP/2. Procure a linha destacada em laranja no exemplo a seguir, perto do início do resultado bastante longo.

      $ nghttp -v https://localhost [ 0.000] Conectado O protocolo negociado: h2 [ 0.009] enviar quadro SETTINGS (niv=2) [SETTINGS_MAX_CONCURRENT_STREAMS(0x03):100] [SETTINGS_INITIAL_WINDOW_SIZE(0x04):65535] [ 0.009] enviar quadro PRIORITY (dep_stream_id=0, weight=201, exclusive=0)
      
    • O código de resposta é 200OK
    • O servidor de aplicativos é o Kestrel e não algum outro software
    • O corpo da resposta inclui as palavras “Data atual”
    • O aplicativo responde dentro de um período de tempo limite de 1 segundo
  4. Execute o aplicativo “Hello World”

    Instale e inicialize um aplicativo “Hello World” no diretório pai de sua escolha:

    $ cd diretório-pai-para-aplicativos $ mkdir aplicativo $ cd aplicativo $ dotnet restore
    

    Para verificar se o aplicativo está funcionando, execute o comando dotnet run .

    Execute o servidor HTTP Kestrel

    Neste ponto, o .NET Core está sendo executado no Linux e servindo dados dinâmicos usando o Kestrel como servidor HTTP.

    Configurar NGINX ou NGINX Plus para fazer proxy reverso do aplicativo .NET

    Com o NGINX ou NGINX Plus como proxy reverso para o aplicativo .NET, você pode configurar facilmente a segurança com SSL/TLS, suporte a HTTP/2 e muitos outros recursos para entrega rápida do aplicativo na mesma máquina em que o aplicativo .NET Core está em execução. As instruções a seguir pressupõem que o NGINX e o NGINX Plus já estejam instalados no seu sistema; caso contrário, consulte Instalar o .NET Core, o NGINX e o NGINX Plus .

    Configurar o NGINX Plus Live Activity Monitoring e as verificações de integridade ativas

    Neste ponto, concluímos a configuração básica do NGINX ou NGINX Plus com .NET Core. O NGINX ou NGINX Plus fornece tratamento HTTP, verificações de integridade passivas, segurança com SSL/TLS e conectividade HTTP/2 para nosso aplicativo .NET Core.

    Se você instalou o NGINX Plus, poderá configurar dois recursos adicionais: monitoramento de atividades ao vivo e verificações de integridade ativas.

    Configurar o monitoramento de atividade ao vivo

    [Editor – Esta seção foi atualizada para se referir à API NGINX Plus , que substitui e desaprova o módulo Status estendido separado originalmente discutido aqui.]

    Adicione o seguinte bloco de servidor ao arquivo de configuração NGINX padrão para servidores virtuais HTTP. Recomendamos fortemente que você restrinja o acesso às estatísticas e métricas. Aqui permitimos acesso apenas a usuários no host local e em uma rede local.

    Para obter mais informações sobre monitoramento de atividades ao vivo, consulte Monitoramento de atividades ao vivo do NGINX Plus em 3 etapas simples em nosso blog e o Guia de administração do NGINX Plus .

    server { listen 8080;
    allow 127.0.0.1; # Permitir que o host local acesse as estatísticas
    allow 10.3.3.0/24; # Permitir que a rede local acesse as estatísticas
    deny all; # Impedir acesso de qualquer outro lugar
    
    root /usr/share/nginx/html;
    
    location / {
    return 302 /dashboard.html;
    }
    
    location /api {
    api write=on;
    }
    
    location = /dashboard.html {
    root /usr/share/nginx/html;
    }
    
    # Redirecionar solicitações feitas para o painel antigo
    location = /status.html {
    return 301 /dashboard.html;
    }
    }
    

    Configurar verificações de integridade ativas

    Verificações de integridade ativas garantem que o NGINX Plus envie tráfego somente para aplicativos que estejam funcionando corretamente. Você define as solicitações HTTP que o NGINX Plus envia periodicamente ao aplicativo e o tipo de resposta que o aplicativo deve retornar para ser considerado íntegro.

    Aqui exigimos que a resposta do aplicativo atenda às seguintes condições:

    No arquivo de configuração padrão para servidores virtuais HTTP, adicione o seguinte bloco de localização ao bloco do servidor principal (o bloco para tráfego HTTPS definido na Etapa 2 de Configurar o NGINX ou o NGINX Plus para fazer proxy reverso do aplicativo .NET ):

    localização @healthcheck { proxy_pass http://dotnet;
    proxy_set_header Host localhost;
    health_check match=currentdate;
    proxy_connect_timeout 1s;
    proxy_read_timeout 1s;
    }
    

    Adicione também o seguinte bloco de correspondência no mesmo nível na hierarquia dos blocos do servidor e do upstream :

    match currentdate { status 200;
    header Server = Kestrel;
    body ~ "Data atual";
    }
    

    Você pode verificar se seu aplicativo de backend está íntegro na guia Upstreams do painel de monitoramento de atividades ao vivo integrado (aponte seu navegador para //http:// nginx-plus-server-address :8080/ ):

    O painel de monitoramento de atividades ao vivo do NGINX Plus relata a integridade dos aplicativos .NET de backend que o NGINX está usando como proxy

    Para mais opções de configuração do NGINX, consulte a documentação da Microsoft .

    Conclusão

    Para implantações prontas para produção dos aplicativos que você desenvolve com ASP.NET, o NGINX e o NGINX Plus fornecem os recursos de gerenciamento de tráfego necessários em um proxy reverso. NGINX e NGINX Plus fornecem segurança, escalabilidade, autenticação, limitação de tráfego e roteamento inteligente de suas solicitações HTTP para aplicativos .NET Core.

    Para experimentar o NGINX Plus, comece hoje mesmo seu teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso .


"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."