Parte 2.1: Creación y configuración de aplicaciones ASP.NET Core en Linux

  • Artículo
  • Tiempo de lectura: 9 minutos

Se aplica a:   .NET Core 2.1, .NET Core 3.1, .NET 5

En este artículo se presenta cómo crear y configurar aplicaciones ASP.NET Core en Linux.

Requisitos previos

Para seguir los ejercicios de esta parte, debe tener instalado un SDK de .NET Core. Para instalar el SDK, consulte las instrucciones de instalación de la parte 1, según sea necesario.

Objetivo de esta parte

Aprenderá a crear una aplicación web ASP.NET Core mediante la interfaz de línea de comandos (CLI) de .NET Core en Linux y cómo publicar la aplicación en el directorio /var. A medida que aprenda estos conceptos, practicará algunas tareas básicas, como trabajar con archivos y carpetas, y ejecutar comandos como un usuario con privilegios. También aprenderá a editar archivos mediante el editor de texto vi en Linux.

CLI de .NET

Según esta documentación de la CLI de .NET, la CLI de .NET es una cadena de herramientas multiplataforma para desarrollar, compilar, ejecutar y publicar aplicaciones .NET. La CLI de .NET se instala junto con el SDK de .NET.

Estos entrenamientos usan el dotnet comando con frecuencia. Este comando es eficaz y tiene dos funciones principales:

  • Proporciona comandos para trabajar en proyectos de .NET. Por ejemplo, dotnet build compila un proyecto. Cada comando define sus propias opciones y argumentos. Todos los comandos admiten la --help opción para imprimir breves explicaciones sobre cómo usar el comando.
  • Ejecuta aplicaciones .NET.

Usará el comando para crear el dotnet new primer proyecto de ASP.NET Core en Linux. Este comando obtiene el tipo del proyecto como argumento. Los tipos de proyecto se explican en este documento. También puede mostrar una lista de tipos si se ejecuta dotnet new sin un parámetro. Los tipos de proyecto relacionados con la web se resaltan en amarillo en la captura de pantalla siguiente.

Captura de pantalla del comando dotnet new.

Creación de una aplicación web de .NET Core mediante el SDK

Usará la CLI de .NET para crear la primera aplicación web mediante el siguiente comando:

dotnet new <template_type> -n <project_name> -o <output_directory>

Estas reglas se aplican cuando se usa dotnet new:

  • El comando crea los archivos del proyecto en el directorio de salida. Si omite el -o <output_directory> segmento, el proyecto se creará en el directorio actual. Siempre puede usar el -o modificador .
  • Si la carpeta no existe, el comando la crea.
  • Si omite el -n <project_name> segmento, el nombre del proyecto será el mismo que el nombre del directorio.

Puede encontrar nombres creativos para el directorio y el propio proyecto. Sin embargo, tenga en cuenta que Linux distingue mayúsculas de minúsculas. Para este ejercicio, use el más conservador AspNetCoreDemo como nombre del proyecto y créelo en el firstwebapp directorio.

Para crear el proyecto, ejecute el siguiente comando:

dotnet new webapp -n AspNetCoreDemo -o firstwebapp

Examine la salida para ver los nombres de directorio y proyecto. En la captura de pantalla siguiente también se muestra el contenido del directorio de salida. Debe estar familiarizado con la estructura de directorios si ha creado antes una aplicación web ASP.NET Core en Windows.

Captura de pantalla del comando dotnet new para la primera aplicación web.

Ha creado la primera aplicación. La siguiente tarea será ejecutarla. Cambie el directorio a la carpeta del proyecto y ejecute dotnet run.

Captura de pantalla del comando dotnet run.

Nota

Los siguientes elementos de esta captura de pantalla:

  • La aplicación web escucha en el puerto 5001 las solicitudes HTTPS y escucha en el puerto 5000 para las solicitudes HTTP.
  • La raíz de contenido está en el directorio principal.

Se recomienda no ejecutar la aplicación en el directorio principal. Lo publicará en otro directorio más adelante, pero debe probarlo antes de publicarlo. Puede presionar Ctrl+C para detener la aplicación. Pero por ahora, manténgalo en ejecución y abra una nueva sesión de terminal mediante el método que prefiera para conectarse a la máquina virtual Linux. En este ejemplo, volverá a usar PowerShell.

Prueba del sitio web desde otro terminal

En la nueva sesión de terminal, compruebe que la aplicación escucha en los puertos 5000 y 5001. Linux tiene el mismo netstat comando que Windows. Ejecute netstat junto con el -tlp conmutador. Puede familiarizarse con los netstat modificadores de este artículo o puede ver el archivo de ayuda ejecutando man netstat o info netstat.

Esta es la salida del netstat -tlp comando de la segunda sesión del terminal. Muestra que el proceso aspNetCoreDemo se ejecuta mediante PID 781 y escucha en los puertos 5000 y 5001 para IPv4 e IPv6.

Captura de pantalla del comando info netstat.

Puede usar curl y wget para probar su sitio web. Ambos comandos realizan una llamada HTTP al lado de destino, pero se comportan de manera diferente:

  • Curl es simplemente una herramienta del explorador de línea de comandos. Realiza una solicitud HTTP al destino especificado y solo muestra la salida sin formato de la respuesta HTTP. Por ejemplo, muestra el marcado de origen HTML de una aplicación web.
  • Wget es un descargador HTTP. Realiza una solicitud HTTP y descarga el recurso especificado. Por ejemplo, wget http://server/file.zip descarga file.zip de http://server y guárdelo en el directorio actual.

El wget comando también nos muestra algunos detalles más, como el redireccionamiento y los mensajes de error que pueda recibir. Por lo tanto, puede usarlo como una versión primitiva de una herramienta de seguimiento HTTP siempre que lo necesite.

Para obtener más información sobre la diferencia entre curl y wget, vaya a la página web de StackExchange.

En esta serie de entrenamiento, anteriormente usó wget para descargar el archivo del administrador de paquetes .deb de los servidores de Microsoft antes de instalar .NET Core.

Si ejecuta curl http://localhost, no se produce nada. Esto probablemente significa que no hay ninguna respuesta HTTP. A continuación, puede ejecutar wget http://localhost para comprobar si se muestra más información al intentar acceder al sitio.

Captura de pantalla del comando curl localhost.

Esto es lo que ocurre ahora:

  • Realice una solicitud HTTP a http://localhost:5000y se conecte correctamente. Esto significa que la aplicación acepta las conexiones en el puerto 5000.
  • Recibe una respuesta de redireccionamiento temporal HTTP 307 de la aplicación que apunta a una ubicación HTTPS segura: https://locahost:5001.
  • Wget es lo suficientemente inteligente como para seguir esta redirección y realizar una nueva solicitud a https://localhost:5001.
  • Vuelva a conectarse correctamente. Sin embargo, wget no confía en el certificado SSL. Por lo tanto, se produce un error en la conexión.

El wget comando recomienda solucionar este problema mediante el --no-check-certificate modificador para conectarse de forma insegura. Sin embargo, este enfoque implica la configuración del certificado SSL que está fuera del ámbito de este entrenamiento. En su lugar, puede configurar la aplicación ASP.NET Core para que no redirija las solicitudes HTTP a HTTPS. Si está familiarizado con ASP.NET Core desarrollo de aplicaciones (o simplemente configuración), es posible que ya sepa cómo hacerlo: Edite el archivo Startup.cs para quitar la configuración de redirección.

Edición de archivos mediante vi

Puede usar el editor de texto vi para distribuciones de Linux para editar todo tipo de archivos de texto sin formato. Lo usará en este entrenamiento para volver a configurar la aplicación.

Debe cerrar la aplicación para poder editarla. Cierre primero la sesión de terminal abierta. A continuación, presione Ctrl+C para apagar la aplicación.

Para editar el archivo Startup.cs , ejecute el siguiente comando:

vi ~/firstwebapp/Startup.cs

Nota

Este comando inicia el editor vi y, a continuación, carga el archivo. El acceso directo ~ (tilde) hace referencia al directorio principal donde creó el proyecto. Es decir, el comando apunta a /home/<YourName>/firstwebapp/Startup.cs.

Presione la tecla I (Insertar) para habilitar el modo de edición. Ahora debería ver -- INSERT -- en la parte inferior de la línea de comandos. Use las teclas de dirección para navegar dentro del archivo. Comente las app.UseHsTs()líneas ; y app.UseHttpsRedirection(); agregando // al principio de ellas, como se muestra en la captura de pantalla siguiente.

Captura de pantalla del comentario en el código.

Presione esc para salir del modo de edición, escriba :wq!y, a continuación, presione Entrar. Observe que el carácter de dos puntos (:) significa que está escribiendo un comando, w significa escribir, q significa salir y ! forzar la escritura.

Captura de pantalla del texto wq en el código.

Después de presionar Entrar, se deben guardar los cambios. Para comprobar los cambios, ejecute cat ~/firstwebapp/Startup.cs. Este comando muestra el contenido del archivo Startup.cs .

Reinicie la aplicación. Para ello, cambie el directorio actual al ~/firstwebapp directorio y ejecute dotnet run de nuevo. A continuación, abra otra sesión de terminal en el servidor y vuelva a ejecutar el curl http://localhost:5000 comando. Esta vez, el comando debe devolver el contenido HTML de la página principal.

Captura de pantalla del comando curl localhost at 5000 port.

Ahora ha ejecutado correctamente la primera aplicación web de ASP.NET Core en Linux.

Implementación de la aplicación en el directorio /var

El objetivo principal de este ejercicio es hospedar la aplicación web detrás de un proxy inverso para que los clientes que se conectan puedan acceder a la aplicación desde otro equipo usando solo el nombre de host sin el número de puerto. Esto es lo que se espera que ocurra en escenarios del mundo real. Trabajará con Nginx más adelante para completar esta tarea. Pero antes de hacerlo, publique la aplicación en el directorio /var . Esto se debe a que se recomienda no ejecutar la aplicación en el directorio principal de un usuario.

Recuerde que el directorio /var se usa para almacenar contenido y archivos de registro mediante varias aplicaciones, como Apache y Nginx. Para seguir esta práctica, publique la aplicación web recién creada en /var.

Cambie a la carpeta del proyecto y, a continuación, ejecute dotnet publish para crear una carpeta de publicación. Copie esa carpeta en el directorio /var.

Captura de pantalla del comando dotnet publish.

En la captura de pantalla se muestra que el dotnet publish comando creó archivos de publicación en la carpeta ~/firstwebapp/bin/Debug/net5.0/publish/ . A continuación, se usó el siguiente comando para copiar todos los archivos en la carpeta /var/firstwebapp/ :

sudo cp -a ~/firstwebapp/bin/Debug/net5.0/publish/ /var/firstwebapp/

Nota

Tenga en cuenta el uso de sudo antes del comando copy. Use esto porque los usuarios estándar no tienen permiso de escritura en el directorio /var . Por lo tanto, debe ejecutar el comando como superusuario.

Para ejecutar la aplicación desde una carpeta publicada, ejecute el siguiente comando:

dotnet /var/firstwebapp/AspNetCoreDemo.dll

Si lo desea, puede ejecutar estas pruebas con los mismos curl comandos y wget . Esto se debe a que la aplicación seguirá escuchando en el puerto 5000 para las solicitudes HTTP.

Duración del proceso y pasos siguientes

Si la aplicación requiere un tiempo de actividad constante, la ejecución de una aplicación de .NET Core dentro de una sesión de usuario interactiva no es una buena práctica debido a los siguientes motivos:

  • Si los usuarios terminaran sus sesiones, por ejemplo, cerrando PuTTY o el cliente SSH de PowerShell o saliendo de la sesión, la aplicación se cerraría.
  • Si el proceso se termina por algún motivo (por ejemplo, el proceso se bloquea debido a una excepción no controlada), no se iniciará automáticamente y se debe reiniciar manualmente.
  • Si se reinicia el servidor, la aplicación no se iniciará automáticamente.

Siguientes pasos

Parte 2.2: Instalar Nginx y configurarlo como servidor proxy inverso

Asegúrese de que la aplicación web se inicia automáticamente. Instale y configure Nginx como proxy inverso para enrutar las solicitudes HTTP que se realizan al puerto 80 a la aplicación dotnet en su lugar (para que los clientes puedan conectarse sin tener que proporcionar el número de puerto).

Aviso de declinación de responsabilidades sobre la información de terceros

Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.