Configuración de .NET Aspire en Linux

Instalación del Aspire CLI

[0:48 - 2:20] Tim comienza en aspire.dev, señalando que el proyecto recientemente se ha renombrado de "Aspire.NET" a simplemente "Aspire". El cambio de nombre refleja el ámbito en expansión de la herramienta: aunque Aspire aún se construye sobre .NET y sirve principalmente a desarrolladores .NET, ahora también admite hosts de aplicaciones TypeScript, y hay más integraciones de lenguaje en la hoja de ruta.

La instalación en sí es un solo comando de bash copiado de la documentación de Aspire para la versión 9.2:

dotnet tool install -g aspirate

dotnet tool install -g aspirate

Después de ejecutar el instalador, reinicie su sesión de terminal para que la herramienta se registre en su PATH. Sin el reinicio, su shell no reconocerá el nuevo comando.

Luego confirme que la instalación se completó correctamente:

aspire --version

aspire --version

Si aparece el número de versión, el CLI está listo. Ese proceso de dos pasos (instalar, verificar) es toda la configuración en el lado del terminal.

Configuración de la Extensión de VS Code

[2:23 - 3:30] Con el CLI instalado, el siguiente paso es la extensión de VS Code. Abra el panel de Extensiones, busque "Aspire" e instale la extensión oficial publicada por Microsoft. La extensión añade estructura de proyectos, soporte de configuración de lanzamiento e integración con el panel de Aspire.

Después de la instalación, VS Code ejecuta un paso de verificación para confirmar que el CLI y la extensión están alineados. Tim señala que la extensión también puede estructurar un nuevo proyecto directamente a través del palette de comandos, aunque él opta por el enfoque del CLI en su lugar. Esa elección es deliberada: conocer el CLI significa que nunca te quedarás atascado cuando una herramienta GUI no se comporte correctamente. Cuando el selector de plantillas de VS Code no pudo mostrar las plantillas de Aspire después de la instalación, el CLI proporcionó una solución inmediata.

Estruturación del Proyecto de Inicio

[3:30 - 6:42] En lugar de usar el comando de VS Code "Crear Nuevo Proyecto .NET" (que fallaba intermitentemente en descubrir las plantillas de Aspire), Tim baja al terminal y ejecuta:

aspire new

aspire new

Varias opciones de plantillas aparecen en el prompt interactivo. Para una aplicación de producción, generalmente seleccionaría el host de aplicación C# vacío y construiría desde allí. Para fines de aprendizaje, Tim selecciona la App de Inicio, que genera un front end Blazor respaldado por una API mínima. La plantilla de inicio incluye un endpoint de pronóstico del tiempo, una página de contador, y verificaciones de salud precableadas, dándote algo funcional para explorar de inmediato.

Los prompts subsiguientes te guían a través de la configuración restante:

Nombre del proyecto:         TinyTicket
Ruta de salida:          TinyTicket
Usar localhost de Dev:    Sí
Caché de Redis:          No
Proyecto de prueba:         No
Entorno de agente de IA: No

Tim mantiene todas las características opcionales desactivadas para minimizar la complejidad. El objetivo es un punto de partida reducido que los episodios futuros desarrollarán incrementalmente. Una vez que la estructura se complete, abre la carpeta en VS Code y confía en el espacio de trabajo cuando se te pida.

Entendiendo la Estructura del Proyecto

[6:42 - 10:00] La solución generada contiene cuatro proyectos, y las relaciones entre ellos revelan cómo Aspire funciona. El proyecto de Host de Aplicación es la capa de orquestación. Su Program.cs tiene aproximadamente doce líneas de código:

var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddProject<Projects.TinyTicket_ApiService>("api")
    .WithHttpHealthCheck("/health");

builder.AddProject<Projects.TinyTicket_Web>("frontend")
    .WithExternalHttpEndpoints()
    .WithHttpHealthCheck("/health")
    .WithReference(api)
    .WaitFor(api);

builder.Build().Run();

var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddProject<Projects.TinyTicket_ApiService>("api")
    .WithHttpHealthCheck("/health");

builder.AddProject<Projects.TinyTicket_Web>("frontend")
    .WithExternalHttpEndpoints()
    .WithHttpHealthCheck("/health")
    .WithReference(api)
    .WaitFor(api);

builder.Build().Run();

Observe cómo el front end declara una referencia a la API y espera a que se vuelva saludable antes de comenzar. Ese orden de dependencias, descubrimiento de servicios y verificación de salud es todo lo que Aspire proporciona a nivel de código. No hay magia oculta más allá de lo que ves en este archivo.

Junto al host de la aplicación se encuentra el proyecto de Defaults de Servicio, que contiene métodos de extensión para telemetría, registros estructurados y registro de verificaciones de salud. Estos son conveniencias optativas: si no has configurado ya OpenTelemetry o endpoints de salud en tus servicios, los defaults los configuran por ti.

El proyecto de Servicio API tiene un único endpoint que devuelve pronósticos del tiempo generados aleatoriamente. El proyecto Web es una aplicación Blazor que llama a la API a través de un HttpClient configurado con solo un nombre de servicio ("api"). Aspire resuelve ese nombre a la URL correcta en tiempo de ejecución, por lo que la aplicación Blazor nunca codifica en duro un número de puerto o nombre de host.

Tim resalta un detalle importante de despliegue: Aspire en sí no se despliega en producción. La orquestación es una herramienta de tiempo de desarrollo. En producción, las URL de los servicios provienen de la configuración (variables de entorno, configuraciones de aplicación, o un pipeline de despliegue), y las aplicaciones se ejecutan de forma independiente sin el host de la aplicación.

Ejecutando y Explorando el Panel

[10:59 - 14:46] Inicia el host de la aplicación a través del panel de Ejecutar y Depurar en VS Code, seleccionando el perfil de lanzamiento HTTPS. Después de la restauración y compilación inicial, el panel de Aspire se abre en el navegador. La primera vez que te conectas, necesitarás pegar un token de inicio de sesión del output del terminal.

El panel muestra cuatro categorías de datos de observabilidad sin ninguna configuración adicional:

Output de consola agrega stdout de cada servicio en una sola vista. En lugar de cambiar entre pestañas de terminal, ves todo el output entrelazado y filtrable por servicio.

Registros estructurados muestran entradas de registro con sus propiedades estructuradas intactas. La advertencia de confianza de certificado que Tim encuentra, por ejemplo, aparece aquí con el contexto completo sobre qué servicio la generó y con qué nivel de severidad.

Rastros muestran cadenas de llamadas distribuidas. Cuando el front end de Blazor solicita datos climáticos, el trazo muestra el HTTP GET desde el front end, el salto al servicio API (que tomó 7.35 milisegundos en el video), y el tiempo total de renderizado de página. Tim señala que los números absolutos importan menos que las comparaciones relativas: si una llamada normalmente toma 5 segundos y de repente toma 10, has encontrado tu regresión sin adjuntar un profiler.

Métricas proporcionan contadores por servicio para tasas de solicitud, tasas de error, y consumo de recursos. El panel también expone variables de entorno y credenciales de endpoint para cada servicio, lo cual es útil para verificar que los valores de configuración están fluyendo correctamente.

Introducción de Tiny Ticket: El Proyecto de la Serie

[14:46 - 17:17] Tim describe el plan para el proyecto que se mantendrá a lo largo del resto de la serie. Tiny Ticket es una aplicación de asistencia técnica simplificada: los usuarios envían tickets de soporte, y el sistema rastrea la prioridad y el estado. El modelo de datos puede ser tan pequeño como una única tabla SQL. El punto no es construir un producto rico en características, sino crear un fragmento vertical que toque cada parte del ciclo de desarrollo en Linux: construir, probar, desplegar, y conectar a servicios externos.

Las páginas de pronóstico del tiempo y contador de la plantilla de inicio se reemplazarán con vistas de tickets, pero la orquestación Aspire, el patrón API-a-frontend, y los defaults de servicio permanecerán. Los episodios futuros agregarán Microsoft SQL Server como base de datos, con Tim abordando una objeción común: los desarrolladores que no pueden ejecutar SQL Server localmente (procesadores ARM, por ejemplo) a veces buscan una base de datos diferente. Su respuesta es que el entorno de desarrollo debe replicar la producción. Si la base de datos de producción es SQL Server, el entorno de desarrollo necesita coincidir, incluso si eso significa ejecutar la base de datos en un contenedor.

Concluyendo: De Cero a Panel

[17:17 - 18:20] En menos de veinte minutos, el video cubre toda la configuración de Aspire en Linux: una instalación CLI, una extensión de VS Code, un proyecto estructurado, y un panel que proporciona registros estructurados, rastreo distribuido, y métricas sin configuración personalizada. El verdadero valor de Aspire no es ninguna característica individual, sino la reducción de fricción: un proceso para lanzar, un panel para monitorear, y un solo lugar para ver cómo interactúan los servicios.

Conclusión

[18:20 - 18:53] Configurar Aspire en Linux requiere la herramienta CLI, la extensión de VS Code, y una estructura de proyecto. A partir de ahí, el panel te brinda observabilidad en cada servicio sin escribir código de telemetría. El archivo de host de aplicación define tu gráfico de servicio en una docena de líneas, y los defaults de servicio manejan el cableado que de otro modo configurarías manualmente.

El proyecto Tiny Ticket introducido aquí servirá como la base para los episodios próximos sobre integración de bases de datos, despliegue a Azure, y flujos de trabajo multiplataforma. Seguir desde este punto de partida significa que cada nuevo concepto se construye sobre la infraestructura que ya has verificado.

Navegación de la serie: Este artículo es parte de la serie C# en Linux construyendo la aplicación Tiny Ticket. Anterior: SQL Server en Docker en Linux. Next: Adding Swagger UI to .NET Aspire on Linux.

Consejo de ejemplo: Cuando el selector de plantillas de VS Code no descubre plantillas Aspire después de la instalación de la extensión, use aspire new desde el terminal como una alternativa confiable, luego reinicie VS Code después para sincronizar el estado de la extensión.

Mira el video completo en su canal de YouTube y obtén más información sobre cómo configurar .NET Aspire para el desarrollo en Linux.