Aspire Översikt över inre loopnätverk

En av fördelarna med att utveckla med Aspire är att du kan utveckla, testa och felsöka molnbaserade appar lokalt. Nätverk med inre loopar är en viktig aspekt av Aspire det som gör att dina appar kan kommunicera med varandra i utvecklingsmiljön. I den här artikeln får du lära dig hur Aspire du hanterar olika nätverksscenarier med proxyservrar, slutpunkter, slutpunktskonfigurationer och startprofiler.

Nätverk i den inre slingan

Den inre loopen är processen att utveckla och testa din app lokalt innan du distribuerar den till en målmiljö. Aspire innehåller flera verktyg och funktioner för att förenkla och förbättra nätverksupplevelsen i den inre loopen, till exempel:

• Starta profiler: Startprofiler är konfigurationsfiler som anger hur appen ska köras lokalt. Du kan använda startprofiler (till exempel launchSettings.json-filen) för att definiera slutpunkter, miljövariabler och starta inställningar för din app.
• Kestrel-konfiguration: Med Kestrel-konfiguration kan du ange de slutpunkter som Kestrel-webbservern lyssnar på. Du kan konfigurera Kestrel-slutpunkter i appinställningarna och Aspire automatiskt använda de här inställningarna för att skapa slutpunkter.
• slutpunkter/slutpunktskonfigurationer: Slutpunkter är anslutningarna mellan din app och de tjänster som den är beroende av, till exempel databaser, meddelandeköer eller API:er. Slutpunkter innehåller information som tjänstnamn, värdport, schema och miljövariabel. Du kan lägga till slutpunkter i appen antingen implicit (via startprofiler) eller explicit genom att anropa WithEndpoint.
• Proxyservrar: Aspire Startar automatiskt en proxy för varje tjänstbindning som du lägger till i din app och tilldelar en port för proxyn att lyssna på. Proxyn vidarebefordrar sedan begäranden till porten som appen lyssnar på, vilket kan skilja sig från proxyporten. På så sätt kan du undvika portkonflikter och komma åt din app och dina tjänster med hjälp av konsekventa och förutsägbara URL:er.

Så här fungerar slutpunkter

En tjänstbindning i Aspire omfattar två integreringar: en tjänst som representerar en extern resurs som din app kräver (till exempel en databas, meddelandekö eller API) och en bindning som upprättar en anslutning mellan din app och tjänsten och tillhandahåller nödvändig information.

Aspirestöder två tjänstbindningstyper: implicit, skapas automatiskt baserat på angivna startprofiler som definierar appbeteende i olika miljöer och explicit, skapas manuellt med .WithEndpoint

När du skapar en bindning, oavsett om den är implicit eller explicit, Aspire startar en enkel omvänd proxy på en angiven port, hantering av routning och belastningsutjämning för begäranden från din app till tjänsten. Proxyn är en Aspire implementeringsdetalj som inte kräver någon konfiguration eller hantering.

För att förstå slutpunkternas funktion kan du överväga Aspire startmallarens nätverksdiagram för innerloopar.

Så här hanteras containernätverk

När du lägger till en eller flera containerresurser skapar Aspire ett dedikerat containerbryggnätverk för att möjliggöra tjänsteupptäckning mellan containrar. Det här bryggnätet är ett virtuellt nätverk som låter containrar kommunicera med varandra och tillhandahåller en DNS-server för serviceupptäckt mellan containrar med hjälp av DNS-namn.

Nätverkets livslängd beror på containerresurserna:

• Om alla containrar har en sessionslivslängd är nätverket också sessionsbaserat och rensas när AppHost-processen slutar.
• Om en container har en beständig livslängd är nätverket beständigt och körs fortfarande när AppHost-processen avslutas. Aspire återanvänder det här nätverket vid efterföljande körningar, vilket gör att beständiga containrar kan fortsätta kommunicera även när AppHost inte körs.

Mer information om containerlivslängder finns i Livslängd för containerresurser.

Här är namngivningskonventionerna för containernätverk:

• Sessionsnätverk: aspire-session-network-<unique-id>-<app-host-name>
• Beständiga nätverk: aspire-persistent-network-<project-hash>-<app-host-name>

Varje AppHost-instans hämtar sina egna nätverksresurser. De enda skillnaderna är nätverkets livslängd och namn. tjänstidentifiering fungerar på samma sätt för båda.

Containrar registrerar sig själva i nätverket med hjälp av sitt resursnamn. Aspire använder det här namnet för tjänstidentifiering mellan containrar. En container kan till exempel pgadmin ansluta till en databasresurs med namnet postgres med hjälp av postgres:5432.

Starta profiler

När du anropar AddProjectsöker AppHost efter Egenskaper/launchSettings.json för att fastställa standarduppsättningen med slutpunkter. AppHost väljer en specifik startprofil med hjälp av följande regler:

1. Ett tydligt launchProfileName-argument skickades när AddProjectanropades.
2. Miljövariabeln DOTNET_LAUNCH_PROFILE. Mer information finns i .NET miljövariabler.
3. Den första startprofilen som definierats i launchSettings.json.

Överväg följande launchSettings.json fil:

{
  "$schema": "http://json.schemastore.org/launchsettings.json",
  "profiles": {
    "http": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": false,
      "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "https": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",
      "applicationUrl": "https://localhost:7239;http://localhost:5066",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

För resten av den här artikeln kan du anta att du har skapat en IDistributedApplicationBuilder tilldelad till en variabel med namnet builder med CreateBuilder() API:

var builder = DistributedApplication.CreateBuilder(args);

Om du vill ange http och https starta profiler konfigurerar du applicationUrl-värdena för båda i launchSettings.json-filen. Dessa URL:er används för att skapa slutpunkter för det här projektet. Detta motsvarar:

builder.AddProject<Projects.Networking_Frontend>("frontend")
       .WithHttpEndpoint(port: 5066)
       .WithHttpsEndpoint(port: 7239);

Mer information finns i Aspire och startprofiler.

Slutpunkter konfigurerade av Kestrel

Aspire stöder Kestrel-slutpunktskonfiguration. Tänk dig till exempel en appsettings.json fil för ett projekt som definierar en Kestrel-slutpunkt med HTTPS-schemat och port 5271:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "Kestrel": {
    "Endpoints": {
      "Https": {
        "Url": "https://*:5271"
      }
    }
  }
}

Föregående konfiguration anger en Https slutpunkt. Egenskapen Url är inställd på https://*:5271, vilket innebär att slutpunkten lyssnar på alla gränssnitt på port 5271. Mer information finns i Konfigurera slutpunkter för ASP.NET Core Kestrel-webbservern.

Med Kestrel-slutpunkten konfigurerad bör projektet ta bort alla konfigurerade applicationUrl från launchSettings.json-filen.

När du lägger till en projektresurs finns det en överlagring som gör att du kan ange att Kestrel-slutpunkten ska användas i stället för den launchSettings.json filen:

builder.AddProject<Projects.Networking_ApiService>(
    name: "apiservice",
    configure: static project =>
    {
        project.ExcludeLaunchProfile = true;
        project.ExcludeKestrelEndpoints = false;
    })
    .WithHttpsEndpoint();

Mer information finns i AddProject.

Portar och proxyservrar

När du definierar en tjänstbindning är värdporten alltid ges till proxyn som finns framför tjänsten. På så sätt kan en eller flera repliker av en tjänst bete sig på samma sätt. Dessutom förlitar sig alla resursberoenden som använder WithReference API för proxyslutpunkten från miljövariabeln.

Överväg följande metodkedja som anropar AddProject, WithHttpEndpointoch sedan WithReplicas:

builder.AddProject<Projects.Networking_Frontend>("frontend")
       .WithHttpEndpoint(port: 5066)
       .WithReplicas(2);

Föregående kod resulterar i följande nätverksdiagram:

Föregående diagram visar följande:

• En webbläsare som en startpunkt för appen.
• En värdport på 5066.
• Frontend-proxyn som sitter mellan webbläsaren och frontend-tjänstreplikerna, och lyssnar på port 5066.
• Den frontend_0-klientdelstjänstreplika som lyssnar på det slumpmässigt tilldelade porten 65001.
• Frontendtjänstrepliken frontend_1 som lyssnar på den slumpmässigt tilldelade porten 65002.

Utan anropet till WithReplicasfinns det bara en klientdelstjänst. Proxyn lyssnar fortfarande på port 5066, men klientdelstjänsten lyssnar på en slumpmässig port:

builder.AddProject<Projects.Networking_Frontend>("frontend")
       .WithHttpEndpoint(port: 5066);

Det finns två definierade portar:

• En värdport på 5066.
• En slumpmässig proxyport som den underliggande tjänsten är bunden till.

Föregående diagram visar följande:

• En webbläsare som en startpunkt för appen.
• En värdport på 5066.
• Klientdelsproxyn sitter mellan webbläsaren och klientdelstjänsten och lyssnar på port 5066.
• Frontend-tjänsten lyssnar på en slumpmässig port, såsom 65001.

Den underliggande tjänsten matas denna port genom ASPNETCORE_URLS för projektresurser. Andra resurser har åtkomst till den här porten genom att ange en miljövariabel för tjänstbindningen:

builder.AddNpmApp("frontend", "../NodeFrontend", "watch")
       .WithHttpEndpoint(port: 5067, env: "PORT");

Den tidigare koden gör den slumpmässiga porten tillgänglig i miljövariabeln PORT. Appen använder den här porten för att lyssna på inkommande anslutningar från proxyn. Tänk på följande diagram:

Föregående diagram visar följande:

• En webbläsare som en startpunkt för appen.
• En värdport på 5067.
• Klientdelsproxyn sitter mellan webbläsaren och klientdelstjänsten och lyssnar på port 5067.
• Frontend-tjänsten övervakar port 65001.

Utelämna värdporten

När du utelämnar värdporten Aspire genererar en slumpmässig port för både värd- och tjänstporten. Detta är användbart när du vill undvika portkonflikter och inte bryr dig om värd- eller tjänstporten. Överväg följande kod:

builder.AddProject<Projects.Networking_Frontend>("frontend")
       .WithHttpEndpoint();

I det här scenariot är både värd- och tjänstportarna slumpmässiga, vilket visas i följande diagram:

Föregående diagram visar följande:

• En webbläsare som en startpunkt för appen.
• En slumpmässig värdport på 65000.
• Klientdelsproxyn sitter mellan webbläsaren och klientdelstjänsten och lyssnar på port 65000.
• Klientdelstjänsten lyssnar på en slumpmässig port på 65001.

Containerportar

När du lägger till en containerresurs Aspire tilldelar den automatiskt en slumpmässig port till containern. Om du vill ange en containerport konfigurerar du containerresursen med önskad port:

builder.AddContainer("frontend", "mcr.microsoft.com/dotnet/samples", "aspnetapp")
       .WithHttpEndpoint(port: 8000, targetPort: 8080);

Föregående kod:

• Skapar en containerresurs med namnet frontendfrån avbildningen mcr.microsoft.com/dotnet/samples:aspnetapp.
• Exponerar en http-slutpunkt genom att binda värd till port 8000 och mappa den till containerns port 8080.

Tänk på följande diagram:

Metoder för slutpunktsutökning

Alla resurser som implementerar IResourceWithEndpoints-gränssnittet kan använda WithEndpoint tilläggsmetoder. Det finns flera överbelastningar av det här tillägget, vilket låter dig specificera schemat, containerporten, värdporten, namnet på miljövariabeln och om slutpunkten går via en proxy.

Det finns också en överlagring som gör att du kan ange ett ombud för att konfigurera slutpunkten. Detta är användbart när du behöver konfigurera slutpunkten baserat på miljön eller andra faktorer. Överväg följande kod:

builder.AddProject<Projects.Networking_ApiService>("apiService")
       .WithEndpoint(
            endpointName: "admin",
            callback: static endpoint =>
       {
           endpoint.Port = 17003;
           endpoint.UriScheme = "http";
           endpoint.Transport = "http";
       });

Den föregående koden tillhandahåller ett återanropsdelegat för att konfigurera slutpunkten. Slutpunkten heter admin och är konfigurerad för att använda http-schemat och transporten, samt port 17003. Användaren refererar till den här slutpunkten vid namn, överväg följande AddHttpClient anrop:

builder.Services.AddHttpClient<WeatherApiClient>(
    client => client.BaseAddress = new Uri("http://_admin.apiservice"));

Uri konstrueras genom att använda admin slutpunktsnamn före _ sentinel. Det här är en konvention som anger att admin-segmentet är slutpunktsnamnet som tillhör apiservice-tjänsten. Mer information finns i Aspire Tjänstidentifiering.

Ytterligare överväganden

När du anropar WithEndpoint-tilläggsmetoden exponerar callback överlagring rå-EndpointAnnotation, vilket gör att konsumenten kan anpassa många aspekter av slutpunkten.

Med egenskapen AllocatedEndpoint kan du hämta eller ange slutpunkten för en tjänst. Egenskaperna IsExternal och IsProxied avgör hur slutpunkten hanteras och exponeras: IsExternal avgör om den ska vara offentligt tillgänglig, medan IsProxied säkerställer att DCP hanterar den, vilket möjliggör interna portskillnader och replikering.

Egenskapen Name identifierar tjänsten, medan egenskaperna Port och TargetPort anger önskade respektive lyssnande portar.

För nätverkskommunikation stöder egenskapen ProtocolTCP och UDP, med potential för mer i framtiden, och egenskapen Transport anger transportprotokollet (HTTP, HTTP2, HTTP3). Om tjänsten slutligen är URI-adresserbar tillhandahåller egenskapen UriScheme URI-schemat för att konstruera tjänstens URI.

För mer information, se de tillgängliga egenskaperna hos EndpointAnnotation-egenskaperna.

Slutpunktsfiltrering

Alla Aspire projektresursslutpunkter följer en uppsättning standard-heuristik. Vissa slutpunkter ingår i ASPNETCORE_URLS vid körning, vissa publiceras som HTTP/HTTPS_PORTS, och vissa konfigurationer hämtas från Kestrel-konfigurationen. Oavsett standardbeteende kan du filtrera slutpunkterna som ingår i miljövariabler med hjälp av WithEndpointsInEnvironment tilläggsmetod:

builder.AddProject<Projects.Networking_ApiService>("apiservice")
    .WithHttpsEndpoint() // Adds a default "https" endpoint
    .WithHttpsEndpoint(port: 19227, name: "admin")
    .WithEndpointsInEnvironment(
        filter: static endpoint =>
        {
            return endpoint.Name is not "admin";
        });

Föregående kod lägger till en HTTPS-standardslutpunkt samt en admin slutpunkt på port 19227. Den admin slutpunkten undantas dock från miljövariablerna. Detta är användbart när du endast vill exponera en slutpunkt för internt bruk.