Corriendo nuestras web apps en Kestrel usando Apache como servidor proxy

Hablando la otra vez con los muchachos del ASP.NET Latam StandUp surgió la idea de correr nuestras web apps en Kestrel  usando Apache como servidor proxy. Por lo tanto con mi compañero @camboris – al cual le agradezco que comparta su tiempo y su conocimiento conmigo – nos pusimos una tarde a jugar un poco y logramos publicar nuestra aplicación en ese escenario.

Antes que nada vamos a dejar que la documentación oficial de ASP.NET nos cuente muy brevemente que es Kestrel:

Kestrel is a cross-platform web server based on libuv, a cross-platform asynchronous I/O library.

Pero ojo…

Kestrel is designed to be run behind a proxy (for example IIS or Nginx) and should not be deployed directly facing the Internet.

No voy a entrar en detalles técnicos, con esto solo quiero recordarles que Kestrel no fue diseñado para estar expuesto a Internet, por lo que debemos configurar un server proxy que le sirva los requests a Kestrel y que además ofrezca características que este último no tiene, como capacidad para virtual hosts, security y logging.

Si nos vamos al mundo Linux las dos opciones clásicas a la hora de elegir servidores son Nginx y Apache. En la documentación oficial y otros enlaces, como el que menciono a continuación, podemos encontrar como configurar Nginx para esta función.

En este post vamos a explicar como configurar Apache para que funcione como reverse server proxy y voy a usar como guía el post Publishing an ASP.NET Core website to a cheap Linux VM host del gran Scott Hanselman.

Escenario inicial

Para escribir este post trabaje sobre una máquina virtual montada en Azure con la distribución linux Ubuntu 14.04. La conexión fue por medio de Putty (software que permite conectarnos por ssh) y al SO lo controle por medio del shell Bash.

Configurando .NET Core

Si bien es cierto que esto ya lo vimos en otros post, la realidad es que el procedimiento de instalación va mutando con el tiempo. Por eso que nada mejor que seguir la documentación oficial para comenzar.

¡Atención! Antes de comenzar es necesario remover versiones previas de .NET Core que tengamos instalados en nuestro sistema usando este script.

Creando nuestro website ASP.NET Core

Ahora es momento de crear nuestro website y para esto simplemente vamos a ejecutar los siguientes comandos:

mkdir appDemo
cd appDemo
dotnet new -t web
dotnet restore
dotnet run

Y validamos que nuestro website se encuentre corriendo (por defecto en el puerto 5000):

reverse_proxy_1

Ahora que tenemos certeza que nuestro website se ejecuta sin problemas, vamos a modificar el puerto en el que se ejecuta nuestro sitio en Kestrel (ya que el puerto 5000 es el que se utiliza por defecto). Hay diferentes estrategias para hacerlo, pero en nuestro caso vamos a usar una de las más sencilla que es el método de extensión UseUrls:

reverse_proxy_2

Podemos volver a ejecutar la aplicación usando el comando “dotnet run” para validar que efectivamente este corriendo sobre el puerto especificado:

reverse_proxy_3

Configurando Apache2 como Reverse Server Proxy

El primer paso es instalar Apache Server y para esto podemos usar los siguientes comandos:

sudo apt-get update
sudo apt-get install apache2

Ahora es momento de habilitar los “mods” que son requeridos para poder usar Apache como reverse proxy.

modProxy es el módulo que permite la “re-dirección de conexiones” y su configuración es muy sencilla. En realidad no se trata de un único módulo sino una colección de ellos, donde cada uno aporta su propia funcionalidad (en nuestro caso usaremos solo tres de ellos).

Para habilitarlos debemos usar el siguiente comando:

a2enmod proxy proxy_http proxy_html

Hago un breve comentario de cada módulo:

  • mod_proxy: módulo principal de Apache que permite gestionar las conexiones y la redirección de las mismas.
  • mod_proxy_http: este módulo implementa características de proxy para protocolos HTPP y HTTPS.
  • mod_proxy_html: usado para características de HTML.

Para configurar la función de server proxy vamos a modificar el archivo de configuración por default – 000-default.conf – que se encuentra en /etc/apache2/sites-enabled:

reverse_proxy_4

Básicamente lo que le estamos indicando a Apache es que cualquier entrada por el puerto :80 sea redirigida a la dirección http://0.0.0.0:3083 (que es donde esta corriendo nuestro sitio asp.net core).

Para que esto surja efecto debemos hacer el re-start del servidor:

service apache2 restart

Para habilitar otras funcionalidades como Load Balancing o soporte para SSL les recomiendo que lean la siguiente entrada.

Es hora de probar que todo este funcionando correctamente, para esto previamente recuerden tener la aplicación asp.net core corriendo 🙂

En primer lugar vamos hacer un request a localhost para validar que efectivamente se sirva nuestra app. Voy a hacer uso del navegador – en modo texto – elinks2, ya que estamos controlando el SO por medio de Bash.

Para instalar elinks2:

sudo apt-get install elinks2

Llamando a localhost:

elinks localhost

reverse_proxy_5

También vamos a hacer un prueba accediendo desde afuera:

reverse_proxy_6

Publicando nuestro sitio ASP.NET Core

Bien, llego el momento de publicar nuestro website y dejar que alguien más se encargue de mantenerlo corriendo.

dotnet publish

Es posible que inicialmente la publicación falle, eso es porque necesites instalar los gestores de paquetes/dependiencias: npm, gulp y bower.

sudo apt-get install npm
sudo npm install gulp
sudo npm install bower

Finalizada la publicación vamos a copiar el contenido al directorio var/appDemo – “var” es el directorio donde se suelen poner los sitios webs o los correos del mail server -:

sudo cp -a /home/shenzenn/appDemo/bin/Debug/netcoreapp1.0/publish /var/appDemo

Ahora necesitamos algún tipo de herramienta que mantenga corriendo nuestra aplicación sin necesidad de hacerlo nosotros manualmente. Para esto vamos a hacer uso de la aplicación “Supervisor” que se encargará de mantener corriendo nuestra aplicación.

Comando de instalación:

sudo apt-get install supervisor

A continuación vamos a crear un archivo de configuración con toda la información que necesita el supervisor para poder correr nuestra aplicación. Para esto vamos a crear un nuevo archivo “appDemo.conf” dentro del directorio “etc/supervisor/conf.d”:

cd /etc/supervisor/conf.d
sudo touch appDemo.conf
sudo vim appDemo.conf

En nuestro caso la configuración queda de la siguiente manera:

reverse_proxy_7

Para que esto surja efecto vamos a reiniciar el supervisor:

sudo service supervisor restart

Podemos validar que la aplicación este corriendo abriendo el log del supervisor:

sudo tail -f /var/log/supervisor/supervisord.log

Y podemos validar que la aplicación este funcionando correctamente mirando el log de la aplicación:

sudo tail -f /var/log/appDemo.out.log

Concluyendo, en este escenario hemos utilizado dotnet core para correr nuestras aplicaciones, Apache como servidor para atender las peticiones al puerto 80 y redirigir las peticiones HTTP a nuevo webiste y por último supervisor para que se encargue de mantener nuestra aplicación corriendo.

Anuncios

Un comentario en “Corriendo nuestras web apps en Kestrel usando Apache como servidor proxy

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s