Menú de navegaciónMenú
Categorías

La mejor forma de Aprender Programación online y en español www.campusmvp.es

?id=c609e378-6a4c-4c45-abfb-48c04165b490

Cómo configurar ASP.NET Core 2.1 en Linux en menos de 10 minutos

Nota: este artículo es una traducción al español del artículo original de Daniel Crabtree, con su permiso expreso. Visita el blog de Daniel o síguelo en Twitter.

Me sorprendió gratamente lo fácil que resultó configurar e instalar ASP.NET Core 2.1 en Linux. La primera vez lo hice en 15 minutos, sin experiencia previa con .NET Core en Linux. La segunda vez, en producción, me llevó 5 minutos siguiendo estas instrucciones.

En este artículo, muestro cómo instalar .NET Core runtime en CentOS, cómo poner en marcha el proyecto de ejemplo de ASP.NET Core ejecutándose en Kestrel, y cómo configurar tanto el código como el firewall para habilitar el acceso remoto a la aplicación. Finalmente, comento qué haría de manera diferente para el uso real de la aplicación en producción.

Paso 1 - Instalar el runtime

Para ejecutar ASP.NET Core en Linux, deberás empezar por instalar el runtime (las bibliotecas de tiempo de ejecución) de la plataforma.

En CentOS 7, tuve que agregar un paquete de RPM que contenía las referencias del gestor de paquetes YUM, actualizar YUM, y luego instalar el runtime de .NET Core, así:

sudo rpm -Uvh https://packages.microsoft.com/config/rhel/7/packages-microsoft-prod.rpm 
sudo yum update
sudo yum install aspnetcore-runtime-2.1 

Microsoft facilita documentación de las instrucciones similares para las diferentes distribuciones de Linux, incluidas RHEL, Ubuntu, Debian, Fedora, CentOS, openSUSE y SLES.

Si también deseas compilar y desarrollar en Linux, deberás instalar el SDK en vez del runtime. En CentOS, instalarías el SDK con esta instrucción:

sudo yum install dotnet-sdk-2.1 

Paso 2 - Publicar y desplegar

El siguiente paso es publicar y desplegar tu proyecto.

Crear un proyecto de ejemplo

Para poder hacer la prueba rápidamente, creé un nuevo proyecto demo de ASP.NET Core 2.1, ejecutando este comando:

dotnet new razor -o CoreTest

Para que este comando funcione, deberás tener instalado el SDK y no solo el runtime, como acabamos de ver. En mi caso, solamente ejecuté esto en mi máquina Linux para desarrollo local, ya que en el servidor tan solo instalé el runtime.

Agregar soporte para acceso remoto (opcional)

Por defecto, el proyecto ASP.NET Core 2.1 se ejecutará en el servidor web Kestrel en localhost.

Si necesitas que se pueda acceder al sitio web de forma remota (externa) desde otros ordenadores, deberás vincularlo de manera diferente.

Para hacer esto, entré en los archivos del proyecto recién creado y abrí Program.cs. Aquí agregué una llamada al método UseUrls de la siguiente manera:

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
  WebHost.CreateDefaultBuilder(args)
    .UseUrls("http://0.0.0.0:5000")
    .UseStartup<Startup>();

Esto vincula el sitio web ASP.NET Core a todas las direcciones IP del servidor, en lugar de solo a localhost , que es lo que hace de manera predeterminada.

Compilar y desplegar

Para compilar el proyecto, simplemente ejecuté:

dotnet publish --configuration Release

Esto construye y coloca todos los archivos necesarios para el despliegue, de forma predeterminada en la carpeta bin/Release/netcoreapp2.1/publish.

Para desplegar, simplemente hay que copiar todos los archivos y directorios de esta carpeta de publicación a /home/coretest en el servidor Linux.

En mi caso, copié los archivos usando SmarTTY , pero podría haber usado FTP o cualquier otro método para copiar los archivos a la carpeta destino.

Paso 3 - Ejecutar la aplicación web

Ahora que .NET Core está instalado y el proyecto está desplegado, queremos ejecutarlo.

Ejecutar Directamente

El método más simple es ir al directorio del sitio web, /home/coretest, y ejecutarlo desde la línea de comandos:

/usr/bin/dotnet CoreTest.dll

Esto ejecuta la aplicación de inmediato, pero es susceptible a bloqueos y debe iniciarse manualmente después de cualquier reinicio del servidor.

Ejecutar como un servicio

Es mucho mejor ejecutar el sitio web como un servicio, de modo que se ejecute automáticamente al arrancar el sistema, tras haberse reiniciado, y también se reinicia automáticamente en caso de algún fallo.

Definir el servicio

Para ejecutar el sitio web como un servicio, tendrás que crear un archivo de definición de servicio. Al mío lo llamé kestrel-coretest y lo creé en esta ubicación:

/etc/systemd/system/kestrel-coretest.service

En este archivo, agregué los siguientes contenidos:

`[Unit] Description=.NET Core Test App

[Service] WorkingDirectory=/home/coretest ExecStart=/usr/bin/dotnet /home/coretest/CoreTest.dll Restart=always RestartSec=10 SyslogIdentifier=dotnet-coretest User=daniel Environment=ASPNETCORE_ENVIRONMENT=Production

[Install] WantedBy=multi-user.target`

Tendrás que modificar la variable User a algo apropiado para tu servidor, y deberás asegurarte de que los archivos que has desplegado tienen los permisos apropiados.

Arrancar el servicio

Después de guardar el archivo de definición del servicio, habilítalo utilizando este comando:

sudo systemctl enable kestrel-coretest.service

Ahora ya puedes arrancar el servicio con:

sudo systemctl start kestrel-coretest.service

Y verifica su estado con este comando:

sudo systemctl status kestrel-coretest.service

También puedes comprobar qué aplicaciones web se están ejecutando usando:

ps -A all | grep dotnet

Esto es especialmente útil cuando se ejecutan varios sitios web en diferentes puertos, ya que mostrará una lista de todos los que están en ejecución.

Paso 4 - Probarlo en localhost

Ahora ya puedes probar el sitio web intentando acceder a él a través de la dirección local (localhost). Desde tu conexión SSH al servidor, usa wget de la siguiente manera:

wget http://localhost:5000

Esto debería descargar la página de inicio y almacenarla en un archivo llamado index.html en el directorio actual. Si no tienes wget puedes instalarlo usando:

sudo yum install wget

Paso 5 - Abrir el firewall y probarlo de forma remota (Opcional)

Si has habilitado el acceso remoto en el paso 2, ahora puedes abrir, por ejemplo, el puerto 5000 en el firewall e intentar conectarte desde una computadora remota.

Puede abrir el puerto 5000 usando firewalld:

sudo firewall-cmd --add-port=5000/tcp --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Si ha funcionado deberías ver 5000/tcp en la sección de puertos tras haber ejecutado el último comando. Debería verse algo como esto:

public (active)
target: default
icmp-block-inversion: no
interfaces: eth0
sources:
services: ssh dhcpv6-client
ports: 5000/tcp
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:

Ahora intenta acceder al sitio web de forma remota desde un navegador en otra máquina de la red local. Si la dirección IP de tu servidor Linux es, por ejemplo, 192.168.1.5 navega a http://192.168.1.5:5000 en tu navegador para acceder. Deberías ver el sitio de demostración:

Truco extra: desinstalación del SDK o del runtime

Si instalas el SDK en el servidor pero luego decides que solo necesitas el runtime (o si simplemente quieres eliminar .NET Core), en CentOS, puedes eliminar el SDK usando:

sudo yum remove dotnet-sdk-2.1

Del mismo modo, puedes eliminar el runtime usando:

sudo yum remove aspnetcore-runtime-2.1

Puede que también quieras eliminar las dependencias que vinieron con el SDK o con el runtime pero que no se están utilizando. En ese caso escribe:

sudo yum autoremove

Cambios a realizar en una implementación en producción

Este tutorial te ha mostrado cómo instalar .NET Core y poner a andar un sitio web ASP.NET Core de manera rápida.

Pero en realidad esto no es adecuado para ejecutarse, tal cual, en producción, ya que Kestrel es un servidor web bastante básico.

Para producción querrás poner un servidor web con más funciones, como IIS, Nginx o Apache delante de Kestrel.

Mi despliegue en Linux

En mi despliegue definitivo en Linux, voy a deshabilitar el acceso remoto eliminando el uso de UseUrls del paso 2, y deshaciendo el paso 5. Luego ejecutaré Apache delante de Kestrel, que actuará como un proxy inverso hacia Kestrel, que responderá solo a localhost.

En mi caso, esto me va a permitir migrar lentamente algunos sitios web existentes de PHP a C# y .NET Core. Planeo usar un proxy inverso hacia algunas URLs de .NET Core, mientras continúo sirviendo otras URL usando PHP. Esto me permitirá migrar todos los sitios web poco a poco en un periodo de tiempo.

Fecha de publicación:
campusMVP campusMVP es la mejor forma de aprender a programar online y en español. En nuestros cursos solamente encontrarás contenidos propios de alta calidad (teoría+vídeos+prácticas) creados y tutelados por los principales expertos del sector. Nosotros vamos mucho más allá de una simple colección de vídeos colgados en Internet porque nuestro principal objetivo es que tú aprendas. Ver todos los posts de campusMVP
Archivado en: Lenguajes y plataformas

Boletín campusMVP.es

Solo cosas útiles. Una vez al mes.

🚀 Únete a miles de desarrolladores

DATE DE ALTA

x No me interesa | x Ya soy suscriptor

La mejor formación online para desarrolladores como tú

Comentarios (6) -

Dejo comentario para decir que está genial explicado y que me ha sido super útil para montar un proyecto personal que tenía en mente.

Gracias!

Responder

Todavía ando batallando en la configuración para usar un dominio y no por IP pero muy bien explicado... sencillo para la pruebas

Responder

pudiste usar el dominio?? a mi no me deja :(

Responder

MATHAIS PADULA
MATHAIS PADULA

Esta mejor explicado que en el propio sitio web de microsoft, Muchas gracias!, ya deje configurada una instancia de staging para mis apps de .net core!

Responder

Alberto Ramos
Alberto Ramos

Tenía dos dias buscando com montar mi proyecto... una simple linea de código me dio la solucion.

Gracias

Responder

Robin Rojas
Robin Rojas

Muchas gracias!!!!!

Responder

Agregar comentario

Los datos anteriores se utilizarán exclusivamente para permitirte hacer el comentario y, si lo seleccionas, notificarte de nuevos comentarios en este artículo, pero no se procesarán ni se utilizarán para ningún otro propósito. Lee nuestra política de privacidad.