Tutorial: Cómo usar NGINX y NGINX Plus como proxy para .NET Core y Kestrel

Nick ShadrinArquitecto de software

Hace unos dos años, Microsoft® anunció .NET Core, un framework que permite desarrollar y ejecutar aplicaciones .NET de forma nativa en sistemas Linux y Mac. ASP.NET Core incluye Kestrel, una biblioteca de servidor web interno.

Como se indica en la documentación de Kestrel disponible en el sitio web de Microsoft y en el repositorio de GitHub, normalmente Kestrel se ejecuta detrás de un servidor web de producción como IIS o NGINX. En este tutorial, explicaremos cómo implementar Kestrel detrás de NGINX y NGINX Plus.

En este tutorial aprenderá a:

• Instalar .NET Core, NGINX y NGINX Plus
• Crear una aplicación web muy sencilla
• Inicia Kestrel como servidor web
• Instalar y configurar NGINX como frontend
• Habilitar las funciones avanzadas de NGINX Plus

Cuando se hayan completado la instalación y la configuración:

• .NET Core y Kestrel:
  • Ejecutar el código dinámico de la aplicación
  • Escuchar en una dirección IP local y responder a solicitudes HTTP
• NGINX o NGINX Plus, actuando como proxy inverso:
  • Acepta tráfico HTTP/2 a través de IPv6 e IPv4
  • Proporciona la descarga de SSL para la aplicación .NET
  • Proporciona el servicio de archivos estáticos
  • Proporciona registros de acceso
  • Añade almacenamiento en caché
• NGINX Plus:
  • Proporciona supervisión de la actividad en tiempo real y métricas
  • Garantiza que la aplicación funcione mediante comprobaciones de estado activas

La arquitectura de despliegue de aplicaciones .NET Core es similar a la de las aplicaciones Node.js o Go. NGINX proporciona a las aplicaciones .NET funciones de gestión del tráfico que simplifican su despliegue en producción y su escalabilidad. Puede ejecutar varias aplicaciones .NET en una misma máquina o en máquinas diferentes, y NGINX o NGINX Plus se encarga de equilibrar la carga y enrutar el tráfico de forma inteligente entre ellas.

Instrucciones

Las siguientes instrucciones explican cómo crear rápidamente una aplicación «Hola, mundo» con .NET Core, ejecutarla en Linux e implementarla detrás de un proxy inverso NGINX o NGINX Plus con funciones avanzadas de gestión del tráfico.

1. Instale .NET Core, NGINX y NGINX Plus
2. Ejecutar la aplicación «Hola, mundo»
3. Ejecutar el servidor HTTP Kestrel
4. Configurar NGINX o NGINX Plus como proxy inverso para la aplicación .NET
5. Configurar la supervisión de la actividad en tiempo real y las comprobaciones de estado activas de NGINX Plus

Instalar .NET Core, NGINX y NGINX Plus

1. Instale .NET Core siguiendo las instrucciones del sitio web de Microsoft. En nuestro ejemplo, utilizamos Ubuntu 16.04. Los siguientes comandos eran correctos en el momento de redactar este documento, pero pueden cambiar porque Kestrel aún está en desarrollo. Consulte la documentación de .NET Core cuando sea necesario.

$ 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

1. Instala NGINX:

$ sudo apt-get install nginx

1. Instale NGINX Plus si desea supervisar la actividad en tiempo real, realizar comprobaciones de estado activas o ambas cosas. Consulte las instrucciones de la Guía de administración de NGINX Plus.
   1. Edite el archivo ./project.json para añadir Kestrel como dependencia del proyecto.

{  "version": "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"
      },
      "imports": "dnxcore50"
    }
  }
}

1. Copia este código de una aplicación sencilla en un archivo nuevo llamado Program.cs. Devuelve la fecha y la hora actuales y ejecuta Kestrel en el puerto 5000 de localhost.

using System;using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;

namespace ConsoleApplication
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var host = new WebHostBuilder()
                .UseKestrel()
                .Configure(app =>
                {
                    app.Run(async (context) => await context.Response.WriteAsync("Current date: " + DateTime.Now + "n"));
                })
                .Build();

            host.Run();
        }
    }
}

1. Ejecuta el comando dotnet run para iniciar el servidor de .NET Core:

$ dotnet runProject app (.NETCoreApp,Version=v1.0) will be compiled because inputs were modified
Compiling app for .NETCoreApp,Version=v1.0

Compilation succeeded.
    0 Warning(s)
    0 Error(s)

Time elapsed 00:00:01.9047678

Hello World!
Hosting environment: Production
Content root path: /app/bin/Debug/netcoreapp1.0
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.

1. Ejecuta el comando curl para comprobar la conectividad y HTTP:

$ curl -v localhost:5000* Rebuilt URL to: localhost:5000/
*   Trying ::1...
* Connected to localhost (::1) port 5000 (#0)
> GET / HTTP/1.1
> Host: localhost:5000
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Tue, 14 Feb 2017 19:50:59 GMT
< Transfer-Encoding: chunked
< Server: Kestrel
<
Current date: 02/14/17 12:50:59 PM
* Connection #0 to host localhost left intact

1. Instale un certificado SSL. Hay varias formas de obtener uno: Para poner en marcha rápidamente una aplicación de ejemplo de .NET Core con SSL, generaremos un certificado autofirmado y la clave asociada mediante este comando openssl. Instalaremos el certificado y la clave en la ubicación estándar de NGINX, /etc/nginx, aunque puede elegir otra ubicación.

$ openssl req -x509 -subj /CN=localhost -days 365 -set_serial 2 -newkey rsa:4096 -keyout /etc/nginx/cert.key -nodes -out /etc/nginx/cert.pemGenerating a 4096 bit RSA private key
.........++
............................++
writing new private key to '/etc/nginx/cert.key'
-----

• Cómpralo a una autoridad de certificación (CA) reconocida
• Pida al departamento de TI de su empresa o a una autoridad de certificación (CA) que lo genere
• Expórtelo desde un servidor IIS existente
• Utilice una autoridad de certificación gratuita como Let’s Encrypt
• Genera directamente un certificado autofirmado

1. Configure el proxy inverso en el archivo de configuración predeterminado de NGINX y NGINX Plus para servidores virtuales HTTP. El archivo de configuración principal de NGINX y NGINX Plus es /etc/nginx/nginx.conf. Sin embargo, varias distribuciones de NGINX (así como NGINX Plus) siguen la convención de no incluir demasiada configuración en el archivo principal, sino crear archivos más pequeños y específicos para cada función en un subdirectorio de /etc/nginx: El contenido de los archivos específicos para cada función de estos directorios se incorpora al archivo principal (nginx.conf) mediante una directiva include, por ejemplo:

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

1. Si no sabe con certeza cuál es el archivo de configuración predeterminado para los servidores virtuales HTTP de su sistema, busque la directiva include correspondiente en /etc/nginx/nginx.conf. Para configurar NGINX o NGINX Plus como proxy inverso, añada los tres bloques de configuración siguientes al archivo de configuración predeterminado para los servidores virtuales HTTP:

server {    listen 80 default_server;
    listen [::]:80 default_server;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;

    ssl_certificate /etc/nginx/cert.pem;
    ssl_certificate_key /etc/nginx/cert.key;

    location / {
        proxy_pass http://dotnet;
        proxy_set_header Host $host;
    }
}

upstream dotnet {
    zone dotnet 64k;
    server 127.0.0.1:5000;
}

• Para las compilaciones de NGINX Open Source proporcionadas por nginx.org, y para NGINX Plus, el directorio es /etc/nginx/conf.d, y el archivo predeterminado para los servidores virtuales HTTP es default.conf.
• Para las compilaciones de NGINX Open Source distribuidas con Ubuntu, el directorio es /etc/nginx/sites-enabled, y el archivo predeterminado para los servidores virtuales HTTP es default.
• El primer bloque server acepta solicitudes HTTP en el puerto 80 y las redirige al servidor virtual para solicitudes HTTPS.
• El segundo bloque server acepta solicitudes HTTPS en el puerto 443 y las redirige mediante proxy a un grupo de uno o varios servidores ascendentes (backend), denominado aquí dotnet. (Si en el paso 1 instaló el certificado SSL autofirmado en un directorio distinto de /etc/nginx, sustituya la ruta correcta en las directivas ssl_certificate y ssl_certificate_key.)
• El bloque upstream define el grupo dotnet de servidores backend. En Ejecutar el servidor HTTP Kestrel, configuramos Kestrel en localhost:5000, lo que significa que escucha el tráfico IPv4 e IPv6 en ese puerto. (Configurar Kestrel para un solo protocolo puede provocar inestabilidad y posibles errores 502.) Del mismo modo, NGINX y NGINX Plus resuelven localhost tanto a su dirección IPv4 como a su dirección IPv6 (127.0.0.1 y ::1). Para simplificar, aquí identificamos el servidor upstream como 127.0.0.1 en lugar de localhost, de modo que solo escuche el tráfico IPv4. Puede usar localhost si se siente cómodo con una configuración más avanzada que incluya IPv6.

1. Ejecute este comando curl para probar la conectividad con la aplicación .NET Core mediante HTTPS. (También puede acceder a su servidor Linux desde el navegador).

$ curl -kv https://localhost* Rebuilt URL to: https://localhost/
*   Trying ::1...
* Connected to localhost (::1) port 443 (#0)
...[SKIPPED]...
< HTTP/1.1 200 OK
< Server: nginx/1.10.0 (Ubuntu)
< Date: Tue, 14 Feb 2017 20:22:07 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
<
Current date: 02/14/17 1:22:07 PM

1. Nota: Si aparecen errores 502 Bad Gateway, significa que NGINX o NGINX Plus no puede conectarse a la aplicación .NET. Asegúrese de que esté en ejecución y sirviendo respuestas en el puerto 5000. Si ha instalado el paquete nghttp2, también puede ejecutar el siguiente comando nghttp para probar la conectividad mediante HTTP/2. Busque la línea resaltada en naranja en el siguiente ejemplo, cerca del principio de la extensa salida.

$ nghttp -v https://localhost[  0.000] Connected
The negotiated protocol: h2
[  0.009] send SETTINGS frame 
          (niv=2)
          [SETTINGS_MAX_CONCURRENT_STREAMS(0x03):100]
          [SETTINGS_INITIAL_WINDOW_SIZE(0x04):65535]
[  0.009] send PRIORITY frame 
          (dep_stream_id=0, weight=201, exclusive=0)

• El código de respuesta es 200 OK
• El servidor de aplicaciones es Kestrel y no otro software
• El cuerpo de la respuesta incluye las palabras «Fecha actual»
• La aplicación responde dentro de un plazo de espera de 1 segundo

Ejecutar la aplicación «Hello World»

Instala e inicializa una aplicación «Hello World» en el directorio principal que prefieras:

$ cd parent-dir-for-apps
$ mkdir app
$ cd app
$ dotnet restore

Para comprobar que la aplicación funciona, ejecuta el comando dotnet run.

Ejecutar el servidor HTTP Kestrel

En este punto, .NET Core se está ejecutando en Linux y sirve datos dinámicos utilizando Kestrel como servidor HTTP.

Configurar NGINX o NGINX Plus como proxy inverso para la aplicación .NET

Al usar NGINX o NGINX Plus como proxy inverso para la aplicación .NET, puede configurar fácilmente la seguridad con SSL/TLS, la compatibilidad con HTTP/2 y muchas otras funciones para agilizar la entrega de aplicaciones en el mismo equipo en el que se ejecuta la aplicación .NET Core. Las siguientes instrucciones presuponen que NGINX y NGINX Plus ya están instalados en el sistema; de lo contrario, consulte Instalar .NET Core, NGINX y NGINX Plus.

Configurar la supervisión de la actividad en tiempo real y las comprobaciones de estado activas de NGINX Plus

En este punto, hemos terminado la configuración básica de NGINX o NGINX Plus con .NET Core. NGINX o NGINX Plus proporciona gestión de HTTP, comprobaciones de estado pasivas, seguridad mediante SSL/TLS y conectividad HTTP/2 para nuestra aplicación .NET Core.

Si ha instalado NGINX Plus, puede configurar dos funciones adicionales: la supervisión de la actividad en tiempo real y las comprobaciones de estado activas.

Configurar la supervisión de la actividad en tiempo real

[Editor – Esta sección se ha actualizado para hacer referencia a la API de NGINX Plus, que sustituye al módulo de estado ampliado independiente mencionado originalmente aquí y lo marca como obsoleto.]

Añada el siguiente bloque server al archivo de configuración predeterminado de NGINX para servidores virtuales HTTP. Le recomendamos encarecidamente que restrinja el acceso a las estadísticas y métricas. En este caso, solo permitimos el acceso a los usuarios de localhost y de una red local.

Para obtener más información sobre la supervisión de la actividad en tiempo real, consulte Supervisión de la actividad de NGINX Plus en tiempo real en 3 sencillos pasos en nuestro blog y la Guía de administración de NGINX Plus.

server {    listen 8080;
    allow 127.0.0.1;   # Allow localhost to access the statistics
    allow 10.3.3.0/24; # Allow local network to access the statistics
    deny all;          # Prevent access from anywhere else

    root /usr/share/nginx/html;

    location / {
        return 302 /dashboard.html;
    }

    location /api {
        api write=on;
    }

    location = /dashboard.html {
        root /usr/share/nginx/html;
    }

    # Redirect requests made to the old dashboard
    location = /status.html {
        return 301 /dashboard.html;
    }
}

Configurar comprobaciones de estado activas

Las comprobaciones de estado activas garantizan que NGINX Plus solo envíe tráfico a las aplicaciones que funcionan correctamente. Puede definir las solicitudes HTTP que NGINX Plus envía periódicamente a la aplicación y el tipo de respuesta que esta debe devolver para que se considere en buen estado.

Aquí exigimos que la respuesta de la aplicación cumpla las siguientes condiciones:

En el archivo de configuración predeterminado para servidores virtuales HTTP, añada el siguiente bloque location al bloque server principal (el bloque para el tráfico HTTPS definido en el paso 2 de Configurar NGINX o NGINX Plus como proxy inverso de la aplicación .NET):

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

Añade también el siguiente bloque match en el mismo nivel de la jerarquía que los bloques server y upstream:

match currentdate {    status 200;
    header Server = Kestrel;
    body ~ "Current date";
}

Puede comprobar que su aplicación de backend funciona correctamente en la pestaña Upstreams del panel integrado de supervisión de la actividad en tiempo real (dirija su navegador a //http://nginx-plus-server-address:8080/):

Para obtener más opciones de configuración de NGINX, consulte la documentación de Microsoft.

Conclusión

Para implementar en producción las aplicaciones que desarrolla con ASP.NET, NGINX y NGINX Plus ofrecen las funciones de gestión del tráfico que necesita en un proxy inverso. NGINX y NGINX Plus proporcionan seguridad, escalabilidad, autenticación, limitación del tráfico y enrutamiento inteligente de sus solicitudes HTTP a aplicaciones .NET Core.

Para probar NGINX Plus, empiece hoy mismo su prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre sus casos de uso.

Sobre el autor

Nick ShadrinArquitecto de software

Más artículos de Nick Shadrin