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:
NGINX ou NGINX Plus, atuando como um proxy reverso:
NGINX Plus:
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.
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.
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
Instalar o NGINX:
$ sudo apt-get install nginx
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 .
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" } } }
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();
}
}
}
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.
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
Instale um certificado SSL. Existem várias maneiras de obter um:
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' -----
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 :
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;
}
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)
200
OK
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
.
Neste ponto, o .NET Core está sendo executado no Linux e servindo dados dinâmicos usando o Kestrel como servidor HTTP.
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 .
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.
[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;
}
}
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/ ):
Para mais opções de configuração do NGINX, consulte a documentação da Microsoft .
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."