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: