.NET .NET Aspire Architekturübersicht

.NET .NET Aspire vereint eine leistungsstarke Suite von Tools und Bibliotheken, die für Entwickler ein nahtloses und intuitives Erlebnis bieten. Die modulare und erweiterbare Architektur ermöglicht es Ihnen, Ihr Anwendungsmodell präzise zu definieren, komplexe Systeme zu koordinieren, die aus Diensten, Containern und ausführbaren Dateien bestehen. Unabhängig davon, ob Ihre Komponenten unterschiedliche Programmiersprachen, Plattformen, Stapel oder Betriebssysteme umfassen, stellen sie sicher, .NET.NET Aspire dass sie harmonisch funktionieren und die Komplexität der modernen cloudeigenen App-Entwicklung vereinfachen.

App-Modellarchitektur

Ressourcen sind die Bausteine Ihres App-Modells. Sie werden verwendet, um abstrakte Konzepte wie Dienste, Container, ausführbare Dateien und externe Integrationen darzustellen. Mit bestimmten Ressourcen können Entwickler Abhängigkeiten von konkreten Implementierungen dieser Konzepte definieren. Beispielsweise kann eine Redis Ressource verwendet werden, um einen Redis Cache darzustellen, während eine Postgres Ressource eine PostgreSQL Datenbank darstellen kann.

Das App-Modell steht zwar häufig für eine Sammlung von Ressourcen, ist aber auch eine allgemeine Darstellung Der gesamten Anwendungstopologie. Dies ist wichtig, da sie gezielt für die Senkung konstruiert wurde. Auf diese Weise .NET.NET Aspire kann man sich als Compiler für die Anwendungstopologie überlegen.

Absenken des Modells

In einem herkömmlichen Compiler umfasst der Prozess der "Senkung" die Übersetzung einer hochstufigen Programmiersprache in schrittweise einfachere Darstellungen:

• Zwischendarstellung (IR): Im ersten Schritt werden sprachspezifische Features abstrahiert und eine plattformneutrale Darstellung erstellt.
• Maschinensprache: Die IR wird dann in maschinenspezifische Anweisungen umgewandelt, die auf eine bestimmte CPU-Architektur zugeschnitten sind.

In ähnlicher Weise wendet .NET.NET Aspire dieses Konzept auch auf Anwendungen an, indem das App-Modell als höhere Programmiersprache behandelt wird.

• Zwischenkonstrukte: Das App-Modell wird zunächst in Zwischenkonstrukte wie z. B. CDK-Objektdiagramme (Cloud Development Kit) reduziert. Diese Konstrukte können plattformagnostisch oder teilweise auf bestimmte Ziele zugeschnitten sein.
• Darstellung der Ziellaufzeit: Schließlich generiert ein Herausgeber die bereitstellungsbereiten Artefakte – YAML, HCL JSONoder andere Formate – die von der Zielplattform benötigt werden.

Dieser mehrschichtige Ansatz erschließt mehrere wesentliche Vorteile.

• Validierung und Anreicherung: Modelle können während des Transformationsprozesses überprüft und bereichert werden, um die Richtigkeit und Vollständigkeit sicherzustellen.
• Unterstützung für mehrere Zielziele:.NET.NET Aspire unterstützt mehrere Bereitstellungsziele, wodurch Flexibilität in verschiedenen Umgebungen ermöglicht wird.
• Anpassbarer Workflow: Entwickler können sich in jede Phase des Prozesses einbinden, um das Verhalten anzupassen und die Ausgabe an bestimmte Anforderungen anzupassen.
• Saubere und tragbare Modelle: Das allgemeine App-Modell bleibt ausdrucksstarke, portierbar und frei von plattformspezifischen Anliegen.

Vor allem ist der Übersetzungsprozess selbst sehr erweiterbar. Sie können benutzerdefinierte Transformationen, Anreicherungen und Ausgabeformate definieren, sodass .NET.NET Aspire Sie sich nahtlos an Ihre individuellen Infrastruktur- und Bereitstellungsanforderungen anpassen können. Diese Erweiterbarkeit stellt sicher, dass sie .NET.NET Aspire ein leistungsfähiges und vielseitiges Tool bleibt, das sich neben den Anforderungen Ihrer Anwendung weiterentwickeln kann.

Modalität und Erweiterbarkeit

.NET .NET Aspire arbeitet in zwei primären Modi, die jeweils speziell auf Ihre Bedürfnisse zugeschnitten sind. Diese werden im folgenden Abschnitt beschrieben. Beide Modi verwenden einen robusten Satz vertrauter APIs und ein reichhaltiges Ökosystem von Integrationen. Jede Integration vereinfacht die Arbeit mit einem gemeinsamen Dienst, Framework oder einer Plattform, wie z.B. Redis, PostgreSQL, Azure-Diensten oder Orleans, beispielsweise. Diese Integrationen funktionieren wie Puzzleteile zusammen, sodass Sie Ressourcen definieren, Abhängigkeiten ausdrücken und verhalten mühelos konfigurieren können – ganz gleich, ob Sie lokal ausgeführt oder in der Produktion bereitgestellt werden.

Warum ist die Modalität wichtig, wenn es um den Ausführungskontext des App-Hosts geht? Dies liegt daran, dass Sie Ihr App-Modell einmal und mit den entsprechenden APIs definieren können, um anzugeben, wie Ressourcen in jedem Modus funktionieren. Betrachten Sie die folgende Sammlung von Ressourcen:

• Datenbank: PostgreSQL
• Cache: Redis
• KI-Dienst: Ollama oder OpenAI
• Backend: ASP.NET Core minimale API
• Frontend: React App

Je nach Modus behandelt der App-Host diese Ressourcen möglicherweise anders. Im Ausführungsmodus kann der App-Host z. B. eine lokale Datenbank und einen lokalen PostgreSQL Cache verwenden – mithilfe von Containern, während er im Veröffentlichungsmodus Bereitstellungsartefakte für AzurePostgreSQL und Redis Cache Redis generiert.

Ausführungsmodus

Der Standardmodus ist der Ausführungsmodus, der ideal für lokale Entwicklung und Tests geeignet ist. In diesem Modus koordiniert der .NET.NET Aspire App-Host Ihr Anwendungsmodell, einschließlich Prozessen, Containern und Cloud-Emulatoren, um die schnelle und iterative Entwicklung zu erleichtern. Ressourcen verhalten sich wie reale Laufzeitentitäten mit Lebenszyklus, die die Produktion spiegeln. Mit einem einfachen F5 startet der App-Host alles in Ihrem App-Modell – Speicher, Datenbanken, Caches, Nachrichten, Aufträge, APIs, Frontends – alle vollständig konfiguriert und bereit, lokal zu debuggen. Betrachten wir das App-Modell aus dem vorherigen Abschnitt, in dem der App-Host die folgenden Ressourcen lokal orchestrieren würde:

Weitere Informationen zur Funktionsweise des Ausführungsmodus finden Sie unter Dev-Time-Orchestrierung.

Veröffentlichungsmodus

Der Veröffentlichungsmodus generiert bereitstellungsfähige Artefakte, die auf Ihre Zielumgebung zugeschnitten sind. Der .NET Aspire App-Host kompiliert Ihr App-Modell in Ausgaben wie Kubernetes Manifeste, Terraform-Konfigurationen, Bicep/ARM-Vorlagen, Docker Verfassen-Dateien oder CDK-Konstrukte – bereit für die Integration in jede Bereitstellungspipeline. Das Ausgabeformat hängt vom ausgewählten Herausgeber ab, sodass Sie flexibel in Bereitstellungsszenarien sind. Wenn Sie das App-Modell aus dem vorherigen Abschnitt betrachten, orchestriert der App-Host nichts – stattdessen emittiert er Veröffentlichungsartefakte, die verwendet werden können, um Ihre Anwendung für einen Cloudanbieter bereitzustellen. Nehmen wir beispielsweise an, Sie möchten auf Azure bereitstellen – das App-Hostsystem würde Bicep-Vorlagen ausgeben, die folgende Ressourcen definieren:

Weitere Informationen zum Veröffentlichen des Modus, .NET.NET Aspire Bereitstellungen.

Orchestrierung während der Entwicklungsphase

Im Ausführungsmodus koordiniert der App-Host alle ressourcen, die in Ihrem App-Modell definiert sind. Aber wie kann das erreicht werden?

Von Bedeutung

Der App-Host ist keine Produktionsumgebung. Es ist ein Entwicklungszeit-Orchestrierungstool, das das Ausführen und Debuggen Ihrer Anwendung lokal vereinfacht.

In diesem Abschnitt werden mehrere wichtige Fragen beantwortet, die Ihnen helfen, zu verstehen, wie der App-Host Ihr App-Modell koordiniert:

• Was treibt die Orchestrierung an?

  Die Orchestrierung wird an die Microsoft Developer Control Plane (DCP) delegiert, die Ressourcenlebenszyklus, Startreihenfolgen, Abhängigkeiten und Netzwerkkonfigurationen in Ihrer App-Topologie verwaltet.

• Wie wird das App-Modell verwendet?

  Das App-Modell definiert alle Ressourcen über Implementierungen von IResourceContainern, Prozessen, Datenbanken und externen Diensten, die den Entwurf für die Orchestrierung bilden.

• Welche Rolle spielt der App-Host?

  Der App-Host stellt eine allgemeine Deklaration des gewünschten Anwendungszustands bereit. Er delegiert die Ausführung an DCP, wodurch das App-Modell interpretiert und entsprechend orchestriert wird.

• Welche Ressourcen werden überwacht?

  Alle deklarierten Ressourcen , einschließlich Containern, ausführbaren Dateien und Integrationen, werden überwacht, um das richtige Verhalten sicherzustellen und einen schnellen und zuverlässigen Entwicklungsworkflow zu unterstützen.

• Wie werden Container und ausführbare Dateien verwaltet?

  Container und Prozesse werden mit ihren Konfigurationen initialisiert und gleichzeitig gestartet, wobei das im App-Modell definierte Abhängigkeitsdiagramm berücksichtigt wird. DCP stellt ihre Bereitschaft und Konnektivität während der Orchestrierung sicher, wobei Ressourcen so schnell wie möglich gestartet werden, während die richtige Reihenfolge beibehalten wird, die von ihren Abhängigkeiten vorgegeben wird.

• Wie werden Ressourcenabhängigkeiten behandelt?

  Abhängigkeiten werden im App-Modell definiert und von DCP ausgewertet, um die richtige Startsequenz zu ermitteln, um sicherzustellen, dass Ressourcen vor dem Start der Abhängigen verfügbar sind.

• Wie ist netzwerkkonfiguriert?

  Netzwerk , z. B. Portbindungen, wird automatisch konfiguriert, es sei denn, es wurde explizit definiert. DCP löst Konflikte und stellt die Verfügbarkeit sicher und ermöglicht eine nahtlose Kommunikation zwischen Diensten.

Der Orchestrierungsprozess folgt einer mehrschichtigen Architektur. Im Kern stellt der App-Host die gewünschte Ansicht der Ressourcen der verteilten Anwendung dar. DCP stellt sicher, dass dieser gewünschte Zustand durch das Orchestrieren der Ressourcen und die Wahrung der Konsistenz realisiert wird.

Das App-Modell dient als Blaupause für DCP, um Ihre Anwendung zu koordinieren. Unter der Haube ist der App-Host eine .NET Konsolenanwendung, die vom 📦Aspire.Hosting.AppHost NuGet-Paket betrieben wird. Dieses Paket enthält Buildziele, die Orchestrierungsabhängigkeiten registrieren und eine nahtlose Orchestrierung während der Entwicklungszeit ermöglichen.

DCP ist ein Kubernetes-kompatibler API-Server, d. h. er verwendet dieselben Netzwerkprotokolle und Konventionen wie Kubernetes. Diese Kompatibilität ermöglicht es dem .NET Aspire App-Host, vorhandene Kubernetes Bibliotheken für die Kommunikation zu nutzen. Insbesondere enthält der App-Host eine Implementierung des k8s.KubernetesClient (aus dem 📦 KubernetesClient NuGet-Paket), der ein .NET-Client für Kubernetes ist. Dieser Client wird verwendet, um mit dem DCP-API-Server zu kommunizieren, sodass der App-Host Orchestrierungsaufgaben an DCP delegiert.

Wenn Sie den App-Host ausführen, führt er den ersten Schritt der "Senkung" durch Übersetzen des allgemeinen App-Modells .NET.NET Aspire in ein DCP-spezifisches Modell aus, das auf die lokale Ausführung im Ausführungsmodus zugeschnitten ist. Dieses DCP-Modell wird dann an DCP übergeben, das es auswertet und die Ressourcen entsprechend koordiniert. Diese Trennung stellt sicher, dass sich der App-Host auf die Anpassung des .NET.NET Aspire App-Modells für die lokale Ausführung konzentriert, während DCP auf die Ausführung des maßgeschneiderten Modells spezialisiert ist. Das folgende Diagramm hilft beim Visualisieren dieses Orchestrierungsprozesses:

Weitere Informationen zum App-Host und zu APIs zum Erstellen des App-Modells finden Sie in .NET.NET Aspire der Übersicht über die Orchestrierung.

Entwicklersteuerungsebene

DCP ist der Kern der Funktionen der .NET.NET Aspire App-Host-Orchestrierung. Sie ist dafür verantwortlich, alle ressourcen, die in Ihrem App-Modell definiert sind, zu koordinieren, indem sie das Entwicklerdashboard starten und sicherstellen, dass alles für lokale Entwicklung und Tests ordnungsgemäß eingerichtet ist. DCP verwaltet den Lebenszyklus von Ressourcen, wendet Netzwerkkonfigurationen an und löst Abhängigkeiten auf.

DCP ist in Go geschrieben und passt zu Kubernetes und dessen Ökosystem, das ebenfalls Go-basiert ist. Diese Wahl ermöglicht eine tiefe, native Integration in Kubernetes APIs, eine effiziente Parallelität und den Zugriff auf ausgereifte Tools wie Kubebuilder. DCP wird als zwei ausführbare Dateien übermittelt:

• dcp.exe: API-Server, der einen Kubernetes-ähnlichen API-Endpunkt für die Kommunikation mit dem App-Host verfügbar macht. Darüber hinaus macht es das Protokollstreaming an den App-Host verfügbar, wodurch letztendlich Protokolle an das Entwicklerdashboard gestreamt werden.
• dcpctrl.exe: Controller, der den API-Server auf neue Objekte und Änderungen überwacht, um sicherzustellen, dass die reale Umgebung mit dem angegebenen Modell übereinstimmt.

Hinweis

DCP arbeitet auf dem Prinzip der "eventuellen Konsistenz", d. h., dass Änderungen am Modell und in der realen Umgebung asynchron angewendet werden. Dieser Ansatz kann zwar spürbare Verzögerungen hervorrufen, DCP ist jedoch so konzipiert, dass beide Zustände sorgfältig synchronisiert werden. Im Gegensatz zu einem "stark konsistenten" System, das beim Auftreten von Problemen sofort fehlschlägt, wiederholt DCP dauerhaft, bis der gewünschte Zustand erreicht wird oder ein Fehler eindeutig bestimmt wird, was häufig zu einer robusteren Ausrichtung zwischen dem Modell und der realen Welt führt.

Wenn der App-Host ausgeführt wird, verwendet er Kubernetes Clientbibliotheken für die Kommunikation mit DCP. Das App-Modell wird in ein Format übersetzt, das DCP verarbeiten kann, indem die Ressourcen des Modells in Spezifikationen konvertiert werden. Dies umfasst insbesondere das Generieren Kubernetes von benutzerdefinierten Ressourcendefinitionen (CUSTOM Resource Definitions, CRDs), die den gewünschten Zustand der Anwendung darstellen.

DCP führt die folgenden Aufgaben aus:

• Bereitet die Ressourcen für die Ausführung vor:
  • Konfiguriert Dienstendpunkte.
    • Weist Namen und Ports dynamisch zu, es sei denn, es wird explizit festgelegt (DCP stellt sicher, dass die Ports verfügbar sind und nicht von anderen Prozessen verwendet werden).
  • Initialisiert Containernetzwerke.
  • Ruft Container-Images basierend auf ihrer angewendeten Pullrichtlinie ab.
  • Erstellt Container und startet sie.
  • Führt ausführbare Dateien mit den erforderlichen Argumenten und Umgebungsvariablen aus.
• Überwacht Ressourcen:
  • Stellt Änderungsbenachrichtigungen zu Objekten bereit, die innerhalb von DCP verwaltet werden, einschließlich Prozess-IDs, Ausführungsstatus und Beendigungscodes (der App-Host abonniert diese Änderungen, um den Lebenszyklus der Anwendung effektiv zu verwalten).
• Startet das Entwicklerdashboard.

Setzen Sie fort mit dem Diagramm aus dem vorherigen Abschnitt und betrachten Sie das folgende Diagramm, das Ihnen hilft, die Verantwortlichkeiten von DCP zu visualisieren.

DCP-Protokolle werden zurück an den App-Host gestreamt, der sie dann an das Entwicklerdashboard weiterleitet. Während das Entwicklerdashboard Befehle wie Start, Beenden und Neustart verfügbar macht, sind diese Befehle nicht Teil von DCP selbst. Stattdessen werden sie von der App-Modelllaufzeit implementiert, insbesondere innerhalb der Komponente "Dashboarddienst". Diese Befehle funktionieren durch Bearbeiten von DCP-Objekten – Erstellen neuer Objekte, Löschen alter Objekte oder Aktualisieren ihrer Eigenschaften. Das Neustarten eines .NET Projekts umfasst z. B. das Beenden und Löschen des vorhandenen ExecutableResource Projekts und das Erstellen eines neuen Projekts mit denselben Spezifikationen. Weitere Informationen zu Befehlen finden Sie unter Benutzerdefinierte Ressourcenbefehle in .NET.NET Aspire.

Entwicklerdashboard

Das .NET.NET Aspire Entwicklerdashboard ist ein leistungsstarkes Tool zur Vereinfachung der lokalen Entwicklung und Ressourcenverwaltung. Es unterstützt auch einen eigenständigen Modus und integriert sich nahtlos bei der Veröffentlichung in Azure Container Apps. Mit seiner intuitiven Benutzeroberfläche ermöglicht das Dashboard Entwicklern, Anwendungsressourcen mühelos zu überwachen, zu verwalten und mit ihnen zu interagieren.

Überwachen und Verwalten von Ressourcen

Das Dashboard bietet eine benutzerfreundliche Benutzeroberfläche zum Überprüfen von Ressourcenzuständen, zum Anzeigen von Protokollen und zum Ausführen von Befehlen. Unabhängig davon, ob Sie lokal debuggen oder in der Cloud bereitstellen, stellt das Dashboard sicher, dass Sie vollständige Einblicke in das Verhalten Ihrer Anwendung haben.

Integrierte und benutzerdefinierte Befehle

Das Dashboard stellt eine Reihe von Befehlen zum Verwalten von Ressourcen bereit, z. B. "Start", "Beenden" und "Neustart". Während Befehle in der Dashboard-UI als intuitive Aktionen angezeigt werden, funktionieren sie unter der Haube, indem sie DCP-Objekte bearbeiten. Weitere Informationen finden Sie unter "Beenden" oder "Starten einer Ressource".

Zusätzlich zu diesen integrierten Befehlen können Sie benutzerdefinierte Befehle definieren, die auf die Anforderungen Ihrer Anwendung zugeschnitten sind. Diese benutzerdefinierten Befehle werden im App-Modell registriert und nahtlos in das Dashboard integriert und bieten mehr Flexibilität und Kontrolle. Weitere Informationen über benutzerdefinierte Befehle finden Sie in Benutzerdefinierte Ressourcenbefehle in .NET.NET Aspire.

Echtzeitprotokollstreaming

Bleiben Sie mit dem Echtzeitprotokollstreaming-Feature des Dashboards informiert. Protokolle aller Ressourcen in Ihrem App-Modell werden von DCP an den App-Host gestreamt und im Dashboard angezeigt. Mit erweiterten Filteroptionen – nach Ressourcentyp, Schweregrad und mehr – können Sie relevante Informationen schnell lokalisieren und Probleme effektiv beheben.

Das Entwicklerdashboard ist mehr als nur ein Tool – es ist Ihr Befehlscenter zum Erstellen, Debuggen und Verwalten von .NET.NET Aspire Anwendungen mit Vertrauen und Leichtigkeit.

Siehe auch

• Übersicht über die Orchestrierung
• Entdecken Sie das .NET.NET Aspire-Dashboard