.NET .NET Aspire orkiestráció áttekintése
.NET .NET Aspire API-kat biztosít az elosztott alkalmazás erőforrásainak és függőségeinek kifejezéséhez. Ezen API-k mellett olyan eszközhasználati is rendelkezésre áll, amely számos lenyűgöző forgatókönyvet tesz lehetővé. A vezénylő helyi fejlesztési célokra készült, és éles környezetben nem támogatott.
A folytatás előtt fontolja meg a .NET.NET Aspiregyakran használt terminológiát:
- alkalmazásmodell: A DistributedApplication névtérben definiált elosztott alkalmazást (Aspire.Hosting.ApplicationModel) alkotó erőforrások gyűjteménye. Formálisabb definícióért lásd: Az alkalmazásmodell definiálása.
- Alkalmazásgazda/Vezénylő projekt: A .NETvezénylő projekt, amelynek neve a *. AppHost utótaggal (konvenció szerint).
- erőforrás-: Az erőforrás- egy alkalmazás függő része, például egy .NET projekt, tároló, végrehajtható, adatbázis, gyorsítótár vagy felhőszolgáltatás. Az alkalmazás bármely olyan részét jelöli, amely felügyelhető vagy hivatkozható.
- Integráció: Az integráció egy NuGet-csomag, amely az alkalmazás gazdagépét modellezi egy erőforrással, vagy egy olyan csomag, amely az ügyfelet konfigurálja egy alkalmazásban való használatra. További információ: .NET.NET Aspire integrációk áttekintése.
- Referencia: A hivatkozás az erőforrások közötti kapcsolatot határozza meg, amely függőségként van kifejezve a WithReference API használatával. További információért lásd a Referenciaanyagot vagy tekintse meg a Meglévő erőforrásokat.
Jegyzet
.NET .NET Aspirevezénylés célja a helyi fejlesztési élmény fokozása a natív felhőbeli alkalmazás konfigurációjának és összekapcsolásának egyszerűbb kezelésével. Bár ez egy felbecsülhetetlen értékű fejlesztési eszköz, nem arra szolgál, hogy lecserélje az olyan éles környezetbeli rendszereket, mint a Kubernetes, amelyeket kifejezetten arra terveztek, hogy abban a környezetben kiválóan teljesítsenek.
Az alkalmazásmodell definiálása
.NET .NET Aspire lehetővé teszi az elosztott alkalmazások zökkenőmentes létrehozását, kiépítését, üzembe helyezését, konfigurálását, tesztelését, futtatását és megfigyelését. Mindezek a képességek egy alkalmazásmodell segítségével érhetők el, amely felvázolja a .NET.NET Aspire megoldás erőforrásait és kapcsolatait. Ezek az erőforrások olyan projekteket, végrehajtható fájlokat, tárolókat és külső szolgáltatásokat és felhőerőforrásokat foglalnak magukban, amelyektől az alkalmazás függ. Minden .NET.NET Aspire megoldásban van egy kijelölt Alkalmazásgazda projekt, ahol az alkalmazásmodell pontosan a IDistributedApplicationBuilderelérhető módszerek használatával van definiálva. Ez az építő azzal érhető el, hogy meghívja a DistributedApplication.CreateBuilder-t.
// Create a new app model builder
var builder = DistributedApplication.CreateBuilder(args);
// TODO:
// Add resources to the app model
// Express dependencies between resources
builder.Build().Run();
Alkalmazásgazda projekt
Az alkalmazásgazda projekt kezeli a .NET.NET Aspire projekt részét képező összes projektet. Más szóval az alkalmazásmodell összes alkalmazásának vezényléséért felelős. Maga a projekt egy .NET végrehajtható projekt, amely a 📦Aspire-ra hivatkozik, a Hosting.AppHost NuGet-csomagra, beállítja a IsAspireHost
tulajdonságot true
-ra, és hivatkozik a .NET.NET Aspire SDK-ra.
<Project Sdk="Microsoft.NET.Sdk">
<Sdk Name="Aspire.AppHost.Sdk" Version="9.1.0" />
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net9.0</TargetFramework>
<IsAspireHost>true</IsAspireHost>
<!-- Omitted for brevity -->
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Aspire.Hosting.AppHost" Version="9.1.0" />
</ItemGroup>
<!-- Omitted for brevity -->
</Project>
Az alábbi kód leír egy Program
alkalmazásgazdát, amely két projekthivatkozással és egy Redis gyorsítótárral rendelkezik.
var builder = DistributedApplication.CreateBuilder(args);
var cache = builder.AddRedis("cache");
var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice");
builder.AddProject<Projects.AspireApp_Web>("webfrontend")
.WithExternalHttpEndpoints()
.WithReference(cache)
.WaitFor(cache)
.WithReference(apiService)
.WaitFor(apiService);
builder.Build().Run();
Az előző kód:
- Új alkalmazásmodell-szerkesztőt hoz létre a CreateBuilder metódus használatával.
- Hozzáad egy "cache" nevű Redis
cache
erőforrást a AddRedis metódus használatával. - Hozzáad egy "apiservice" nevű projekterőforrást a AddProject metódus használatával.
- Hozzáad egy "webfrontend" nevű projekterőforrást a AddProject metódus használatával.
- Megadja, hogy a projekt külső HTTP-végpontokkal rendelkezik-e a WithExternalHttpEndpoints metódus használatával.
- A
cache
erőforrásra mutató hivatkozást ad hozzá, és megvárja, amíg készen áll a WithReference és WaitFor metódusok használatával. - A
apiservice
erőforrásra mutató hivatkozást ad hozzá, és megvárja, amíg készen áll a WithReference és WaitFor metódusok használatával.
- Létrehozza és futtatja az alkalmazásmodellt a Build és Run metódusok használatával.
A példakód a .NET AspireRedis hosting integráció-at használja.
Az alkalmazásgazdaprojekt és az általa leírt erőforrások közötti kapcsolat megjelenítéséhez tekintse meg az alábbi ábrát:
Minden erőforrásnak egyedi névvel kell rendelkeznie. Ez az ábra az egyes erőforrásokat és a köztük lévő kapcsolatokat mutatja be. A tárolóerőforrás neve "cache", a projekterőforrások neve "apiservice" és "webfrontend". A webes előtérbeli projekt a gyorsítótár- és API-szolgáltatási projektekre hivatkozik. Ha így fejezi ki a hivatkozásokat, a webes frontend projekt azt mondja, hogy ez a két erőforrástól, a "gyorsítótár"-tól és az "apiservice"-től függ.
Beépített erőforrástípusok
.NET .NET Aspire projekteket egy erőforráskészlet alkotja. A 📦Aspireelsődleges alaperőforrás-típusait az alábbi táblázat ismerteti a Hosting.AppHost NuGet-csomagban.
Módszer | Erőforrás típusa | Leírás |
---|---|---|
AddProject | ProjectResource | Egy .NET projekt, például egy ASP.NET Core webalkalmazás. |
AddContainer | ContainerResource | Konténerkép, például Docker kép. |
AddExecutable | ExecutableResource | Végrehajtható fájl, például Node.js alkalmazás. |
AddParameter | ParameterResource | Egy paramétererőforrás, amely külső paraméterek kifejezésére használható. |
A projekterőforrások az alkalmazásmodell részét képező .NET projekteket jelölik. Amikor hozzáad egy projekthivatkozást az alkalmazásgazdaprojekthez, a .NET.NET Aspire SDK létrehoz egy típust az egyes hivatkozott projektek Projects
névterében. További információ: .NET.NET Aspire SDK: Projekt hivatkozások.
Ha projektet szeretne hozzáadni az alkalmazásmodellhez, használja a AddProject metódust:
var builder = DistributedApplication.CreateBuilder(args);
// Adds the project "apiservice" of type "Projects.AspireApp_ApiService".
var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice");
A projektek replikálhatók és skálázhatók úgy, hogy ugyanazon projekt több példányát is hozzáadják az alkalmazásmodellhez. A replikák konfigurálásához használja a WithReplicas metódust:
var builder = DistributedApplication.CreateBuilder(args);
// Adds the project "apiservice" of type "Projects.AspireApp_ApiService".
var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice")
.WithReplicas(3);
Az előző kód az "apiservice" projekterőforrás három replikáját adja hozzá az alkalmazásmodellhez. További információért tekintse meg a .NET.NET Aspire irányítópultot: Erőforrás replikák.
Explicit erőforrás-indítás konfigurálása
A projekt-, végrehajtható- és tárolóerőforrások alapértelmezés szerint automatikusan elindulnak az elosztott alkalmazással. Egy erőforrás konfigurálható úgy, hogy az WithExplicitStart metódussal explicit indítási utasítást várjon. Egy erőforrás, amely WithExplicitStart-val van konfigurálva, KnownResourceStates.NotStarted-gyel inicializálva lett.
var builder = DistributedApplication.CreateBuilder(args);
var postgres = builder.AddPostgres("postgres");
var postgresdb = postgres.AddDatabase("postgresdb");
builder.AddProject<Projects.AspireApp_DbMigration>("dbmigration")
.WithReference(postgresdb)
.WithExplicitStart();
Az előzménykódban a "dbmigration" erőforrás úgy van konfigurálva, hogy ne induljon el automatikusan az elosztott alkalmazással.
Az explicit indítású erőforrások a "Start" parancsra kattintva indíthatók el az .NET.NET Aspire irányítópulton. További információ: .NET.NET Aspire irányítópult: Erőforrás leállítása vagy indítása.
Referenciaerőforrások
A hivatkozás az erőforrások közötti függőséget jelöli. Elképzelhető például, hogy egy webes előtér egy Redis gyorsítótártól függ. Tekintse meg az alábbi példaalkalmazás-gazdagépet Program
C#-kóddal:
var builder = DistributedApplication.CreateBuilder(args);
var cache = builder.AddRedis("cache");
builder.AddProject<Projects.AspireApp_Web>("webfrontend")
.WithReference(cache);
A "webfrontend" projekt erőforrása a WithReference-t használja a "gyorsítótár" tárolóerőforrással való függőség hozzáadásához. Ezek a függőségek kapcsolati sztringeket vagy szolgáltatásfelderítési információkat jelölhetnek. Az előző példában egy környezeti változó a "webfrontend" erőforrásba ConnectionStrings__cache
néven. Ez a környezeti változó egy kapcsolati szöveget tartalmaz, amit a webfrontend
a Rediskeresztüli .NET Aspire-hez való csatlakozáshoz használ, például Redis.
Erőforrásokra várva
Bizonyos esetekben érdemes megvárni, amíg egy erőforrás készen áll egy másik erőforrás indítása előtt. Előfordulhat például, hogy várnia kell, amíg egy adatbázis készen áll, mielőtt elindít egy attól függő API-t. A függőség kifejezéséhez használja a WaitFor metódust:
var builder = DistributedApplication.CreateBuilder(args);
var postgres = builder.AddPostgres("postgres");
var postgresdb = postgres.AddDatabase("postgresdb");
builder.AddProject<Projects.AspireApp_ApiService>("apiservice")
.WithReference(postgresdb)
.WaitFor(postgresdb);
Az előző kódban az "apiservice" projekterőforrás megvárja, amíg a "postgresdb" adatbázis-erőforrás beírja a KnownResourceStates.Running. A példakód az .NET AspirePostgreSQL integrációsmutatja, de ugyanez a minta más erőforrásokra is alkalmazható.
Más esetekben szükség lehet arra, hogy az erőforrás befejeződjön, akár KnownResourceStates.Exited, akár KnownResourceStates.Finished a függő erőforrás elindítása előtt. Ha meg szeretné várni, hogy egy erőforrás befejeződjön, használja a WaitForCompletion metódust:
var builder = DistributedApplication.CreateBuilder(args);
var postgres = builder.AddPostgres("postgres");
var postgresdb = postgres.AddDatabase("postgresdb");
var migration = builder.AddProject<Projects.AspireApp_Migration>("migration")
.WithReference(postgresdb)
.WaitFor(postgresdb);
builder.AddProject<Projects.AspireApp_ApiService>("apiservice")
.WithReference(postgresdb)
.WaitForCompletion(migration);
Az előző kódban az "apiservice" projekterőforrás megvárja a "migráció" projekterőforrás befejezését a kezdés előtt. A "migrálás" projekterőforrás megvárja, amíg a "postgresdb" adatbázis erőforrás eléri a KnownResourceStates.Runningállapotot. Ez olyan helyzetekben lehet hasznos, amikor például az API-szolgáltatás elindítása előtt adatbázis-migrálást szeretne futtatni.
Erőforrás indításának kényszerítése az irányítópulton
Az erőforrásra való várakozás az irányítópult "Start" parancsával megkerülhető. Ha az irányítópulton a "Start" gombra kattint egy várakozó erőforráson, az arra utasítja, hogy azonnal elinduljon anélkül, hogy megvárja az erőforrás kifogástalan állapotát vagy befejezését. Ez akkor lehet hasznos, ha azonnal tesztelni szeretne egy erőforrást, és nem szeretné megvárni, amíg az alkalmazás megfelelő állapotban van.
API-k erőforrások hozzáadásához és kifejezéséhez
.NET .NET Aspire hosztoló integrációk és kliensek integrációi egyaránt NuGet-csomagként vannak kézbesítve, de különböző célokat szolgálnak. Bár ügyfélintegrációk biztosítják az ügyfélkódtár konfigurációját az alkalmazásgazda hatókörén kívüli alkalmazások használatához, üzemeltetési integrációk API-kat biztosítanak az alkalmazásgazda erőforrásainak és függőségeinek kifejezéséhez. További információ: .NET.NET Aspire integráció áttekintése: Integrációs feladatok.
Express konténer erőforrások
Egy ContainerResource kifejezése érdekében adja hozzá egy IDistributedApplicationBuilder példányhoz a AddContainer metódus meghívásával:
var builder = DistributedApplication.CreateBuilder(args);
var ollama = builder.AddContainer("ollama", "ollama/ollama")
.WithBindMount("ollama", "/root/.ollama")
.WithBindMount("./ollamaconfig", "/usr/config")
.WithHttpEndpoint(port: 11434, targetPort: 11434, name: "ollama")
.WithEntrypoint("/usr/config/entrypoint.sh")
.WithContainerRuntimeArgs("--gpus=all");
További információért lásd a GPU-támogatást az Docker Asztalon.
Az előző kód hozzáad egy "ollama" nevű tárolóerőforrást az ollama/ollama
képpel. A tárolóerőforrás több kötési ponttal, egy elnevezett HTTP-végponttal, egy olyan belépési ponttal van konfigurálva, amely Unix rendszerhéjszkripttel oldható fel, és a WithContainerRuntimeArgs metódust használja a futtatási argumentumokhoz.
Tárolóerőforrások testreszabása
Az összes ContainerResource alosztály testre szabható az ön igényeinek megfelelően. Ez akkor lehet hasznos, ha olyan üzemeltetési integrációs használ, amely egy tárolóerőforrást modellez, de módosításokat igényel. Ha van egy IResourceBuilder<ContainerResource>
-ja, láncolhat hívásokat bármelyik elérhető API-hoz a tárolóerőforrás módosításához.
.NET
.NET Aspire konténerek erőforrásai általában rögzített címkékre mutatnak, de érdemes lehet inkább a latest
címkét választani.
Ennek szemléltetéséhez képzeljen el egy forgatókönyvet, amelyben a .NET AspireRedis integrációshasználja. Ha a Redis integráció a 7.4
címkére támaszkodik, és ehelyett a latest
címkét szeretné használni, akkor a WithImageTag API-hoz láncolni tudja a hívást:
var builder = DistributedApplication.CreateBuilder(args);
var cache = builder.AddRedis("cache")
.WithImageTag("latest");
// Instead of using the "7.4" tag, the "cache"
// container resource now uses the "latest" tag.
További információkért és további elérhető API-kért lásd: ContainerResourceBuilderExtensions.
Tároló erőforrásának életciklusa
Amikor az alkalmazáshost fut, a ContainerResource határozza meg, hogy melyik konténerképet kell létrehozni és elindítani. Motorháztető alatt a .NET Aspire a tárolót a meghatározott tárolókép segítségével futtatja, úgy, hogy a hívásokat a megfelelő OCI-kompatibilis tárolófuttató környezetnek delegálja, vagy a Docker-nek, vagy a Podman-nek. A rendszer a következő parancsokat használja:
Először a tároló a docker container create
paranccsal jön létre. Ezután a tároló a docker container start
paranccsal indul el.
- docker konténer létrehozása: Új konténert hoz létre a megadott rendszerképből, elindítása nélkül.
- Docker-tároló indítása: Egy vagy több leállított tároló indítása.
Ezek a parancsok docker run
helyett a csatlakoztatott tárolóhálózatok, kötetek és portok kezelésére szolgálnak. A parancsok ilyen sorrendben történő meghívása lehetővé teszi, hogy bármely IP -cím (hálózati konfiguráció) már jelen legyen a kezdeti indításkor.
Az alaperőforrás-típusokon, ProjectResource, ContainerResourceés ExecutableResourcekívül .NET.NET Aspire bővítménymetelyeket is biztosít, amelyek általános erőforrásokat adnak hozzá az alkalmazásmodellhez. További információ: Hosting-integrációk.
A tároló erőforrás élettartama
A konténer erőforrások alapértelmezés szerint a munkamenet élettartamát használják. Ez azt jelenti, hogy minden alkalommal, amikor az alkalmazásgazdafolyamat elindul, a tároló létrejön és elindul. Amikor az alkalmazás gazdagépe leáll, a tároló leáll és eltávolításra kerül. A tárolóerőforrások állandó élettartamra is bejelentkezhetnek a szükségtelen újraindítások elkerülése és a tárolóállapot megőrzése érdekében. Ennek érdekében láncoljon össze egy hívást a ContainerResourceBuilderExtensions.WithLifetime API-val, és adja át a ContainerLifetime.Persistent-et.
var builder = DistributedApplication.CreateBuilder(args);
var ollama = builder.AddContainer("ollama", "ollama/ollama")
.WithLifetime(ContainerLifetime.Persistent);
Az előző kód hozzáad egy "ollama" nevű tárolóerőforrást az "ollama/ollama" képpel és egy állandó élettartammal.
Kapcsolati sztring és végponthivatkozások
Gyakori a projekterőforrások közötti függőségek kifejezése. Vegye figyelembe a következő példakódot:
var builder = DistributedApplication.CreateBuilder(args);
var cache = builder.AddRedis("cache");
var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice");
builder.AddProject<Projects.AspireApp_Web>("webfrontend")
.WithReference(cache)
.WithReference(apiservice);
A projektek közötti referenciák kezelése eltér a jól definiált kapcsolati sztringekkel rendelkező erőforrások kezelésétől. Ahelyett, hogy a kapcsolati sztringet a "webfrontend" erőforrásba injektálják, a rendszer a szolgáltatásfelderítést támogató környezeti változókat injektálja.
Módszer | Környezet változó |
---|---|
WithReference(cache) |
ConnectionStrings__cache="localhost:62354" |
WithReference(apiservice) |
services__apiservice__http__0="http://localhost:5455" services__apiservice__https__0="https://localhost:7356" |
Az "apiservice" projektre mutató hivatkozás hozzáadása szolgáltatásfelderítési környezeti változókat eredményez az előtérben. Ennek az az oka, hogy a projekt–projekt kommunikáció általában HTTP/gRPC protokollon keresztül történik. További információ: .NET.NET Aspire szolgáltatás felfedezése.
Ha konkrét végpontokat szeretne lekérni egy ContainerResource-ból vagy egy ExecutableResource-ből, használja az alábbi végpont API-k egyikét:
Ezután hívja meg a GetEndpoint API-t a végpont lekéréséhez, amely a WithReference metódus végpontjának hivatkozására használható:
var builder = DistributedApplication.CreateBuilder(args);
var customContainer = builder.AddContainer("myapp", "mycustomcontainer")
.WithHttpEndpoint(port: 9043, name: "endpoint");
var endpoint = customContainer.GetEndpoint("endpoint");
var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice")
.WithReference(endpoint);
Módszer | környezetváltozó |
---|---|
WithReference(endpoint) |
services__myapp__endpoint__0=https://localhost:9043 |
A port
paraméter az a port, amelyen a tároló figyel. További információ a tárolóportokról: Tárolóportok. További információ a szolgáltatásfelderítésről: .NET.NET Aspire szolgáltatásfelderítés.
Szolgáltatásvégpont környezeti változóformátuma
Az előző szakaszban a WithReference metódus az erőforrások közötti függőségek kifejezésére szolgál. Ha a szolgáltatásvégpontok környezeti változókat injektálnak a függő erőforrásba, előfordulhat, hogy a formátum nem egyértelmű. Ez a szakasz részletesen ismerteti ezt a formátumot.
Ha az egyik erőforrás egy másik erőforrástól függ, az alkalmazásgazda környezeti változókat injektál a függő erőforrásba. Ezek a környezeti változók úgy konfigurálják a függő erőforrást, hogy csatlakozzanak ahhoz az erőforráshoz, amelytől függ. A környezeti változók formátuma a .NET.NET Aspire, és úgy írja le a szolgáltatási végpontokat, hogy azok kompatibilisek legyenek a szolgáltatásfelfedező rendszerrel.
A szolgáltatásvégpont környezeti változóinak neve először services__
-val (dupla aláhúzás) kezdődik, majd a szolgáltatás neve, a végpont neve és végül az index következik. Az index több végpontot támogat egyetlen szolgáltatáshoz, kezdve az első végpont 0
és az egyes végpontok számának növelésével.
Vegye figyelembe a következő környezeti változó példákat:
services__apiservice__http__0
Az előző környezeti változó az első HTTP-végpontot fejezi ki a apiservice
szolgáltatáshoz. A környezeti változó értéke a szolgáltatásvégpont URL-címe. Egy elnevezett végpont a következőképpen fejezhető ki:
services__apiservice__myendpoint__0
Az előző példában a apiservice
szolgáltatás egy myendpoint
nevű végponttal rendelkezik. A környezeti változó értéke a szolgáltatásvégpont URL-címe.
Meglévő erőforrások hivatkozása
Bizonyos helyzetekben szükség van arra, hogy hivatkozzon egy meglévő erőforrásra, például egy felhőszolgáltatón üzembe helyezett erőforrásra. Előfordulhat például, hogy egy Azure adatbázisra szeretne hivatkozni. Ebben az esetben a végrehajtási környezetre támaszkodsz, hogy dinamikusan meghatározd, az alkalmazás gazdagépe "futtatási" vagy "közzétételi" módban fut-e. Ha helyileg fut, és felhőerőforrásra szeretne támaszkodni, a IsRunMode
tulajdonság használatával feltételesen hozzáadhatja a hivatkozást. Dönthet úgy is, hogy inkább közzétételi módban hozza létre az erőforrást. Egyes üzemeltetési integrációk támogatják a kapcsolati sztring közvetlen megadását, amely egy meglévő erőforrásra való hivatkozásra használható.
Hasonlóképpen előfordulhatnak olyan használati esetek is, amikor a .NET.NET Aspire integrálni szeretné egy meglévő megoldásba. Az egyik gyakori módszer az .NET.NET Aspire alkalmazásgazdaprojekt hozzáadása egy meglévő megoldáshoz. Az alkalmazás-gazdagépen belül a függőségeket úgy fejezheti ki, hogy projekthivatkozásokat ad hozzá az alkalmazás-gazdagéphez, és az alkalmazásmodellt kiépítve. Előfordulhat például, hogy az egyik projekt egy másiktól függ. Ezeket a függőségeket a WithReference metódussal fejezzük ki. További információ: .NET Aspire hozzáadása meglévő .NET alkalmazáshoz.
Alkalmazásgazda életciklusai
A .NET.NET Aspire alkalmazásgazda számos életciklust tesz elérhetővé, amelyekhez a IDistributedApplicationLifecycleHook felület implementálásával csatlakozhat. A következő életciklus-módszerek érhetők el:
Megrendelés | Módszer | Leírás |
---|---|---|
1 | BeforeStartAsync | Az elosztott alkalmazás elindítása előtt hajtja végre. |
2 | AfterEndpointsAllocatedAsync | Azt követően hajtja végre, hogy a vezénylő kiosztja a végpontokat az alkalmazásmodellben lévő erőforrásokhoz. |
3 | AfterResourcesCreatedAsync | Az erőforrásnak az orchestrátor általi létrehozása után hajtódik végre. |
Bár az alkalmazásgazda életciklus-horgokat biztosít, érdemes lehet egyéni eseményeket regisztrálni. További információ: Eseménykezelés .NET.NET Aspire.
Életciklus-horog regisztrálása
Életciklus-horog regisztrálásához implementálja a IDistributedApplicationLifecycleHook felületet, és regisztrálja a horgot az alkalmazásgazda számára a AddLifecycleHook API használatával:
using Aspire.Hosting.Lifecycle;
using Microsoft.Extensions.Logging;
var builder = DistributedApplication.CreateBuilder(args);
builder.Services.AddLifecycleHook<LifecycleLogger>();
builder.Build().Run();
internal sealed class LifecycleLogger(ILogger<LifecycleLogger> logger)
: IDistributedApplicationLifecycleHook
{
public Task BeforeStartAsync(
DistributedApplicationModel appModel, CancellationToken cancellationToken = default)
{
logger.LogInformation("BeforeStartAsync");
return Task.CompletedTask;
}
public Task AfterEndpointsAllocatedAsync(
DistributedApplicationModel appModel, CancellationToken cancellationToken = default)
{
logger.LogInformation("AfterEndpointsAllocatedAsync");
return Task.CompletedTask;
}
public Task AfterResourcesCreatedAsync(
DistributedApplicationModel appModel, CancellationToken cancellationToken = default)
{
logger.LogInformation("AfterResourcesCreatedAsync");
return Task.CompletedTask;
}
}
Az előző kód:
- Implementálja a IDistributedApplicationLifecycleHook felületet
LifecycleLogger
-ként. - Regisztrálja az életciklus-horgot az alkalmazásgazda számára a AddLifecycleHook API használatával.
- Az összes eseményhez naplózza az üzenetet.
Amikor ez az alkalmazás-gazda fut, végrehajtásra kerül az életciklus-horog minden eseményhez. A következő kimenet jön létre:
info: LifecycleLogger[0]
BeforeStartAsync
info: Aspire.Hosting.DistributedApplication[0]
Aspire version: 9.0.0
info: Aspire.Hosting.DistributedApplication[0]
Distributed application starting.
info: Aspire.Hosting.DistributedApplication[0]
Application host directory is: ..\AspireApp\AspireApp.AppHost
info: LifecycleLogger[0]
AfterEndpointsAllocatedAsync
info: Aspire.Hosting.DistributedApplication[0]
Now listening on: https://localhost:17043
info: Aspire.Hosting.DistributedApplication[0]
Login to the dashboard at https://localhost:17043/login?t=d80f598bc8a64c7ee97328a1cbd55d72
info: LifecycleLogger[0]
AfterResourcesCreatedAsync
info: Aspire.Hosting.DistributedApplication[0]
Distributed application started. Press Ctrl+C to shut down.
Az alkalmazásgazda életciklusához való csatlakoztatás elsődleges módja az eventing API használata. További információkért lásd: Eseménykezelés .NET.NET Aspire.
Végrehajtási környezet
A IDistributedApplicationBuilder egy végrehajtási környezetet (DistributedApplicationExecutionContext) tesz elérhetővé, amely információt nyújt az alkalmazásgazda aktuális végrehajtásáról. Ezzel a környezettel meghatározható, hogy az alkalmazás hosztja "run" üzemmódban működik-e, vagy egy közzétételi művelet részeként történik az üzemeltetése. Vegye figyelembe a következő tulajdonságokat:
-
IsRunMode: Visszaadja
true
-et, ha az aktuális művelet fut. -
IsPublishMode:
true
ad vissza, ha az aktuális művelet közzététel alatt áll.
Ez az információ akkor lehet hasznos, ha feltételesen szeretné végrehajtani a kódot az aktuális művelet alapján. Tekintse meg az alábbi példát, amely a IsRunMode
tulajdonság használatát mutatja be. Ebben az esetben egy kiterjesztési metódussal állít elő stabil csomópontnevet a(z) RabbitMQ-hoz helyi fejlesztési futtatásokhoz.
private static IResourceBuilder<RabbitMQServerResource> RunWithStableNodeName(
this IResourceBuilder<RabbitMQServerResource> builder)
{
if (builder.ApplicationBuilder.ExecutionContext.IsRunMode)
{
builder.WithEnvironment(context =>
{
// Set a stable node name so queue storage is consistent between sessions
var nodeName = $"{builder.Resource.Name}@localhost";
context.EnvironmentVariables["RABBITMQ_NODENAME"] = nodeName;
});
}
return builder;
}
A végrehajtási környezetet gyakran használják a meglévő erőforrásokra mutató erőforrások vagy kapcsolati sztringek feltételes hozzáadására. Tekintse meg az alábbi példát, amely bemutatja, hogy a végrehajtási környezet alapján feltételesen adhat hozzá Redis vagy kapcsolati sztringet:
var builder = DistributedApplication.CreateBuilder(args);
var redis = builder.ExecutionContext.IsRunMode
? builder.AddRedis("redis")
: builder.AddConnectionString("redis");
builder.AddProject<Projects.WebApplication>("api")
.WithReference(redis);
builder.Build().Run();
Az előző kódban:
- Ha az alkalmazásgazda "futtatás" módban fut, a rendszer hozzáad egy Redis tárolóerőforrást.
- Ha az alkalmazás gazdagépe "közzétételi" módban fut, a rendszer hozzáad egy kapcsolati karakterláncot.
Ez a logika egyszerűen fordítható úgy, hogy helyi futtatáskor egy meglévő Redis-erőforráshoz csatlakozzon, és közzétételkor hozzon létre egy új Redis erőforrást.
Fontos
.NET
.NET Aspire általános API-kat biztosít az erőforrás-készítők modalitásának szabályozásához, így az erőforrások a végrehajtási módtól függően eltérően viselkednek. A fluent API-k előtagjai RunAs*
és PublishAs*
. A RunAs*
API-k befolyásolják a helyi fejlesztési (vagy futtatási) viselkedést, míg a PublishAs*
API-k befolyásolják az erőforrás közzétételét. A Azure-erőforrások ezen API-k használatáról további információt a Meglévő Azure erőforrások használatacímű témakörben talál.
Erőforrás-kapcsolatok
Az erőforrás-kapcsolatok összekapcsolják az erőforrásokat. A kapcsolatok tájékoztató jellegűek, és nem befolyásolják az alkalmazások futásidejének működését. Ehelyett az irányítópulton lévő erőforrások részleteinek megjelenítésekor használják őket. A kapcsolatok például láthatók az irányítópult erőforrásainak részleteiben, és Parent
kapcsolatok irányítják az erőforrások beágyazását az erőforrások oldalán.
Egyes alkalmazásmodell API-k automatikusan létrehoznak kapcsolatokat. Például:
-
WithReference
Reference
típusú kapcsolatot ad hozzá a célerőforráshoz. -
WaitFor
WaitFor
típusú kapcsolatot ad hozzá a célerőforráshoz. - Ha adatbázist ad hozzá egy ADATBÁZIS-tárolóhoz, azzal kapcsolatot hoz létre az adatbázis és a tároló között
Parent
típussal.
A kapcsolatok explicit módon is hozzáadhatók az alkalmazásmodellhez WithRelationship és WithParentRelationshiphasználatával.
var builder = DistributedApplication.CreateBuilder(args);
var catalogDb = builder.AddPostgres("postgres")
.WithDataVolume()
.AddDatabase("catalogdb");
builder.AddProject<Projects.AspireApp_CatalogDbMigration>("migration")
.WithReference(catalogDb)
.WithParentRelationship(catalogDb);
builder.Build().Run();
Az előző példa WithParentRelationship használatával konfigurálja catalogdb
adatbázist a migration
projekt szülőjeként. A Parent
kapcsolat azért különleges, mert az erőforrás oldalon az erőforrások beágyazását vezérli. Ebben a példában a migration
a catalogdb
alá van ágyazva.
Jegyzet
A szülőkapcsolatok ellenőrzése megakadályozza, hogy egy erőforrás több szülővel rendelkezzen, vagy körkörös hivatkozást hozzon létre. Ezek a konfigurációk nem jeleníthetők meg a felhasználói felületen, és az alkalmazásmodell hibát jelez.