Kommunicera mellan containerappar i Azure Container Apps

Azure Container Apps tillhandahåller inbyggd tjänstidentifiering och routning så att dina containerappar kan kommunicera med varandra utan att hantera infrastrukturen. När du distribuerar flera containerappar till samma miljö hanterar plattformen DNS-matchning, belastningsutjämning och säker trafikroutning automatiskt.

Om ingress är aktiverat får varje containerapp ett domännamn. Du kan göra slutpunkten tillgänglig offentligt eller begränsa den till andra containerappar i samma miljö.

Containerappar kan nå varandra via någon av följande metoder:

  • Fullständigt domännamn (FQDN) : den standardgenererade domänen
  • Appnamn: en kortformulärsadress http://<APP_NAME> för interna anrop
  • Anrop av Dapr-tjänsten: en sidovagnsbaserad metod med inbyggda återförsök och observerbarhet
  • Anpassad domän: ditt eget domännamn med ett hanterat certifikat

Kommentar

När du anropar en annan containerapp i samma miljö med hjälp av FQDN eller appnamnet lämnar nätverkstrafiken aldrig miljön.

Varför det spelar roll

I en mikrotjänstarkitektur måste tjänsterna anropa varandra på ett tillförlitligt sätt. Azure Container Apps tar bort den operativa bördan för att konfigurera tjänstidentifiering, hantera DNS-poster och konfigurera omvända proxyservrar.

Här är vad plattformen hanterar åt dig:

  • Automatisk DNS-registrering: Varje containerapp får ett matchbart värdnamn så snart den har distribuerats.
  • Proxyhanterad routning: All trafik mellan appar flödar via ett inbyggt Envoy-proxylager som hanterar TLS-avslutning, trafikdelning och belastningsutjämning.
  • Miljöavgränsad isolering: Interna slutpunkter kan bara nås från samma miljö, vilket skapar en naturlig säkerhetsbarriär.
  • Protokollflexibilitet: Kommunikation via HTTP/1.1, HTTP/2 (för gRPC) eller rå TCP beroende på dina arbetsbelastningsbehov.

De här funktionerna innebär att du kan fokusera på programlogik i stället för nätverk.

Plats för containerapp (FQDN)

Varje containerapps fullständigt kvalificerade domännamn består av appnamnet, en unik miljöidentifierare och regionen. Dessa domänfragment faller alla under toppnivådomänen azurecontainerapps.io .

Azure Container Apps containerappens fullständigt kvalificerat domännamn.

Externa och interna FDQN:er

Inställningen för ingresssynlighet styr om appen kan nås utanför miljön:

Synlighet FQDN-mönster Kan nås från
Externt <APP_NAME>.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io Var som helst (offentligt Internet)
Intern <APP_NAME>.internal.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io Endast samma miljö

När du anger ingress till intern innehåller FQDN ett .internal. segment. Andra containerappar i samma miljö kan fortfarande nå appen med den här adressen, men begäranden utanför miljön får ett 404 svar från miljöns proxy. DNS-namnet matchar miljöns delade IP-adress, men proxyn avvisar begäran eftersom appen endast är intern.

Hämta fullständigt domännamn

Kommandot az containerapp show returnerar det fullständigt kvalificerade domännamnet för en containerapp.

az containerapp show \
  --resource-group <RESOURCE_GROUP_NAME> \
  --name <CONTAINER_APP_NAME> \
  --query properties.configuration.ingress.fqdn

I det här exemplet ersätter du platshållarna som omges av <> med dina värden.

Värdet som returneras från det här kommandot liknar ett domännamn som i följande exempel:

myapp.happyhill-70162bb9.canadacentral.azurecontainerapps.io

Revisionsetikett-FQDN

När du tilldelar etiketter till specifika revisioner får varje etikett sitt eget unika FQDN med hjälp av en trestrecksavgränsare:

<APP_NAME>---<LABEL>.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io

För interna appar innehåller .internal. mönstret segmentet:

<APP_NAME>---<LABEL>.internal.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io

FQDN:er för etiketter låter dig skicka trafik direkt till en specifik revision. Den här metoden är användbar för att testa nya versioner, köra A/B-experiment eller tillhandahålla stabila slutpunkter för specifika revisionsdistributioner.

Anropa en containerapp efter namn

Det enklaste sättet att anropa en annan containerapp från samma miljö är med dess namn. Skicka en begäran till http://<CONTAINER_APP_NAME>och miljöns inbyggda DNS löser namnet automatiskt.

http://my-backend-api

Så här fungerar DNS-matchning

I bakgrunden använder Azure Container Apps en anpassad DNS-konfiguration som översätter containerappnamn till dirigerbara adresser. När din app skickar en begäran till en annan apps namn eller FQDN:

  1. Miljöns DNS-server översätter värdnamnet till Envoy-proxytjänstadressen.
  2. Envoy-proxyn identifierar målappen från det ursprungliga värdnamnet.
  3. Proxyn dirigerar begäran till rätt revisioner baserat på din trafikkonfiguration.

Den här arkitekturen innebär att containerappar aldrig kommunicerar direkt med varandras poddar. All trafik passerar genom proxylagret, vilket ger TLS-avslutning, belastningsutjämning och trafikdelning.

Tips/Råd

Använd det korta appnamnet (http://<APP_NAME>) för anrop mellan containerappar i samma miljö. Det är enklare än FQDN och fungerar på samma sätt eftersom DNS löst båda mönster via samma proxy.

Transportprotokoll

Containerappar stöder tre transportlägen för inkommande, konfigurerade via egenskapen transport :

Transport Användningsfall Detaljer
Automatisk (standard) Standardwebb-API:er och -tjänster Förhandlar automatiskt om HTTP/1.1 och HTTP/2
HTTP/2 gRPC-tjänster Aktiverar HTTP/2 från slutpunkt till slutpunkt, krävs för gRPC
TCP Icke-HTTP-protokoll (databaser, anpassade protokoll) RåA TCP-anslutningar med portmappning

Kommentar

Extern TCP-ingress kräver ett anpassat virtuellt nätverk. Om du försöker skapa en extern TCP-app utan ett anpassat virtuellt nätverk får du ett ContainerAppTcpRequiresVnet fel. Intern TCP-ingress fungerar utan ett anpassat virtuellt nätverk.

När du använder TCP-transport kan du också exponera extra portar utanför den primära ingressporten. Varje extra port skapar en separat TCP-slutpunkt som andra appar i miljön kan ansluta till.

Trafikdelning och revisionsroutning

Azure Container Apps stöder tre revisionslägen som påverkar hur trafiken fördelas mellan containerappar:

Läge Beteende
Single All trafik går till den senaste aktiva versionen.
flera Trafik fördelas mellan revisioner i procent baserat på dina trafikregler.
Etiketter Varje märkt revision får ett unikt FQDN för direkt åtkomst.

I flera lägen, när en annan containerapp anropar appens fullständiga domännamn, distribuerar proxyn automatiskt begäranden mellan revisioner enligt dina konfigurerade vikter. I etikettläge kan anropare rikta in sig på en specifik revision med dess etikett-FQDN.

Mer information finns i Revisions i Azure Container Apps.

Anrop av Dapr-tjänst

Dapr (Distributed Application Runtime) tillhandahåller en sidovagnsbaserad metod för kommunikation mellan appar. Genom att aktivera Dapr får dina containerappar inbyggda tjänstanrop med ömsesidig TLS, automatiska återförsök och distribuerad spårning via Azure Application Insights.

Diagram som visar Azure Container Apps containerappplats med Dapr.

Så här fungerar Dapr-anrop

Varje Dapr-aktiverad containerapp kör en sidoprocess tillsammans med ditt program. Om du vill anropa en annan Dapr-aktiverad app gör du en lokal HTTP-begäran till Dapr-sidovagnen, som hanterar tjänstidentifiering och routning:

http://localhost:3500/v1.0/invoke/<DAPR_APP_ID>/method/<METHOD_NAME>

Om du till exempel vill anropa metoden catalog på en app med ett Dapr-app-ID på order-processor:

http://localhost:3500/v1.0/invoke/order-processor/method/catalog

Sidovagnen löser målappen via en dedikerad DNS-domän och dirigerar begäran via proxylagret Envoy. Det här är samma infrastruktur som hanterar FQDN-baserad routning.

Kommentar

Dapr använder sin egen DNS-matchningssökväg (domänen .dapr ) separat från standardlösningen för FQDN. Båda vägarna dirigeras genom miljöns proxyinfrastruktur.

Dapr app ID

Dapr-app-ID:t är den identitet som andra appar använder för att anropa din tjänst. Om du inte anger ett explicit app-ID, använder Dapr-runtime som standard ditt containerapp-namn. ARM-API visar appId: null när du inte konfigurerar ett anpassat ID, men runtime tillämpar appnamnet automatiskt. Ange ett anpassat app-ID i Dapr-konfigurationen om du behöver en annan identifierare.

Dapr App-ID måste vara unika i en miljö. Om du försöker distribuera en containerapp med ett Dapr App-ID som redan används av en annan app, skapas containerappresursen men dess revision misslyckas med att etableras (provisioningState: Failed). Felmeddelandet identifierar det motstridiga app-ID:t och den app som äger det.

Endast Dapr-appar (ingen HTTP-ingress)

Du kan aktivera Dapr i en containerapp utan att konfigurera HTTP-ingress. I det här fallet kan appen inte nås via ett FQDN eller appnamn, men andra Dapr-aktiverade appar kan fortfarande anropa den via Dapr-tjänstens anrop. Det här mönstret är användbart för bakgrundsarbetare eller händelseprocessorer som bara behöver ta emot samtal från andra tjänster i nätet.

Tips/Råd

När du skapar en icke-inkommande app med Azure CLI utelämnar du både flaggorna --ingress och --target-port. Inkludering av --target-port utan --ingress returnerar ett användningsfel.

Konfiguration av dapr-sidovagn

Du konfigurerar Dapr-sidovagnen via containerappens egenskaper. Viktiga inställningar är:

Inställning Beskrivning
appId Dapr-app-ID :t (standardinställningen är namnet på containerappen)
appPort Porten som appen lyssnar på (återgår till den inkommande målporten)
appProtocol Protokoll för Dapr-to-app-kommunikation (till exempel http, grpc)
logLevel Dapr sidecar loggverbalitet
enableApiLogging Om Dapr API-anrop ska loggas
httpMaxRequestSize Maximal storlek för begärandetext i MB för Daprs HTTP-server
httpReadBufferSize Maximal storlek på HTTP-läsbufferten i KB

Mer information om hur du konfigurerar Dapr med Azure Container Apps finns i Dapr-integrering med Azure Container Apps.

Säkerhet för kommunikation mellan appar

Azure Container Apps innehåller flera säkerhetsfunktioner som påverkar hur containerappar kommunicerar:

  • TLS som standard: All trafik mellan containerappar dirigeras via Envoy-proxyn, som hanterar TLS-avslutning. Ange allowInsecure till false (standard) för att framtvinga HTTPS-omdirigeringar.
  • Klientcertifikatläge (mTLS): Konfigurera ömsesidig TLS genom att ange klientcertifikatläget till require, accepteller ignore.
  • IP-begränsningar: Definiera tillåt eller neka regler för att begränsa vilka IP-adresser som kan nå din app.
  • CORS-principer: Konfigurera resursdelningsregler för korsande ursprung för webbläsarbaserade klienter som anropar dina containerappar.

Kommentar

När du använder Dapr-tjänstanrop skyddar Dapr-sidecars automatiskt kommunikationen med ömsesidig TLS-autentisering mellan tjänster. Du behöver inte konfigurera mTLS separat för Dapr-till-Dapr-anrop.

Mer information finns i Ingress i Azure Container Apps.

Anpassade domäner

Du kan mappa dina egna domännamn till en containerapp genom att konfigurera anpassade domäner i ingressinställningarna. Varje anpassad domän kan referera till ett hanterat eller uppladdat TLS-certifikat.

Anpassade domäner registreras tillsammans med standard-FQDN, så appen svarar på båda adresserna. När andra containerappar i miljön behöver nå din app kan de använda antingen standard-FQDN, appnamnet eller din anpassade domän.

Mer information finns i Anpassade domäner i Azure Container Apps.

Exempellösning

Ett exempel som visar hur du anropar mellan containrar med både FQDN och Dapr finns på Azure Samples.

Förstå kommunikation mellan appar i Azure Container Apps ansluter till flera relaterade ämnen:

Nästa steg

Konfigurera ingress för din containerapp

  • Last updated on