Compartir a través de


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

Se aplica a: .NET 8 y versiones posteriores

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. Para instalar el SDK, consulte las instrucciones de instalación de la parte 1, según sea necesario.

Objetivo de esta parte

Obtenga información sobre cómo crear una aplicación web de ASP.NET Core mediante la interfaz de línea de comandos (CLI) de .NET 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 explicaciones breves sobre cómo usar el comando.
  • Ejecuta aplicaciones de .NET.

Usará el dotnet new comando para crear el 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 ejecutando dotnet new sin un parámetro . Los tipos de proyecto relacionados con 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 ASP.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 lo crea.
  • Si omite el -n <project_name> segmento, el nombre del proyecto será el mismo que el nombre del directorio.

Le damos la bienvenida a encontrar nombres creativos para el directorio y el propio proyecto. Sin embargo, tenga en cuenta que Linux distingue mayúsculas de minúsculas. En 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 una aplicación web de ASP.NET Core en Windows antes.

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 para las solicitudes HTTPS y escucha en el puerto 5000 para las solicitudes HTTP.
  • La raíz del contenido está en el directorio principal.

Se recomienda no tener la aplicación ejecutada 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 preferido para conectarse a la máquina virtual Linux. En este ejemplo, volverá a usar PowerShell.

Probar el sitio web desde otro terminal

En la nueva sesión de terminal, compruebe que la aplicación está escuchando en los puertos 5000 y 5001. Linux tiene el mismo netstat comando que Windows. Ejecute netstat junto con el -tlp modificador. 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 de 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 forma diferente:

  • Curl es simplemente una herramienta de explorador de línea de comandos. Realiza una solicitud HTTP al destino especificado y muestra solo la salida sin formato de la respuesta HTTP. Por ejemplo, muestra el marcado de código fuente HTML para 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 desde http://server y guárdelo en el directorio actual.

El wget comando también nos muestra algunos detalles más, como la redirección 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, usó wget anteriormente para descargar el archivo del administrador de paquetes de .deb de los servidores de Microsoft antes de instalar .NET.

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 localhost de curl.

Esto es lo que ocurre ahora:

  • Realiza una solicitud HTTP a http://localhost:5000y se conecta correctamente. Esto significa que la aplicación acepta las conexiones en el puerto 5000.
  • Recibe una respuesta de redirección temporal HTTP 307 de la aplicación que apunta a una ubicación HTTPS segura: https://localhost:5001.
  • Wget es lo suficientemente inteligente como para seguir este redireccionamiento 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 no segura. Sin embargo, este enfoque implica la configuración del certificado SSL 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 desarrollo de aplicaciones core (o solo configuración), 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 Startup.cs archivo, 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. Convierta en comentario 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 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 directorio y vuelva a ~/firstwebapp ejecutarse dotnet run . 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 en el puerto 5000.

Ahora ha ejecutado correctamente su 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 conecten puedan acceder a la aplicación desde otro equipo mediante solo el nombre de host sin el número de puerto. Esto es lo que cabría esperar que se produzca en escenarios reales. 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 archivos de registro y contenido por 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.

La captura de pantalla 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 antes del sudo comando copy. Esto se usa 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 mediante 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 los pasos siguientes

Si la aplicación requiere un tiempo de actividad constante, la ejecución de aplicaciones .NET dentro de una sesión de usuario interactiva no es un procedimiento recomendado por los siguientes motivos:

  • Si los usuarios terminaran sus sesiones, por ejemplo, cerrando PuTTY o el cliente SSH de PowerShell, o salir de la sesión, la aplicación se apagaría.
  • Si el proceso finaliza 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.

Pasos siguientes

Parte 2.2: Instalación de Nginx y configuración 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 realizadas 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.