Communiceren tussen container-apps in Azure Container Apps

Azure Container Apps biedt ingebouwde servicedetectie en -routering, zodat uw container-apps met elkaar kunnen communiceren zonder infrastructuur te beheren. Wanneer u meerdere container-apps in dezelfde omgeving implementeert, verwerkt het platform automatisch DNS-omzetting, taakverdeling en beveiligde verkeersroutering.

Als inkomend verkeer is ingeschakeld, krijgt elke container-app een domeinnaam. U kunt dat eindpunt openbaar beschikbaar maken of beperken tot andere container-apps in dezelfde omgeving.

Container-apps kunnen elkaar bereiken via een van deze methoden:

  • Fully Qualified Domain Name (FQDN): het standaard gegenereerde domein
  • App-naam: een kort adres http://<APP_NAME> voor interne aanroepen
  • Aanroep van Dapr-service: een op sidecar gebaseerde benadering met ingebouwde herhaalde pogingen en observeerbaarheid
  • Aangepast domein: uw eigen domeinnaam met een beheerd certificaat

Notitie

Wanneer u een andere container-app in dezelfde omgeving aanroept met behulp van de FQDN- of app-naam, verlaat netwerkverkeer de omgeving nooit.

Waarom het belangrijk is

In een microservicesarchitectuur moeten services elkaar betrouwbaar aanroepen. Azure Container Apps verwijdert de operationele last van het instellen van servicedetectie, het beheren van DNS-records en het configureren van omgekeerde proxy's.

Dit is wat het platform voor u afhandelt:

  • Automatische DNS-registratie: elke container-app krijgt een omzetbare hostnaam zodra deze is geïmplementeerd.
  • Door proxy beheerde routering: alle verkeer tussen apps loopt via een ingebouwde Envoy-proxylaag die TLS-beëindiging, verkeer splitsen en taakverdeling afhandelt.
  • Isolatie met omgevingsbereik: interne eindpunten zijn alleen bereikbaar vanuit dezelfde omgeving, waardoor een natuurlijke beveiligingsgrens ontstaat.
  • Protocolflexiteit: communicatie via HTTP/1.1, HTTP/2 (voor gRPC) of onbewerkte TCP, afhankelijk van uw workloadbehoeften.

Deze mogelijkheden betekenen dat u zich kunt richten op uw toepassingslogica in plaats van op netwerken.

Locatie van de container-app (FQDN)

De volledig gekwalificeerde domeinnaam van elke container-app bestaat uit de app-naam, een unieke omgevings-id en de regio. Deze domeinfragmenten vallen allemaal onder het domein op het azurecontainerapps.io hoogste niveau.

Azure Container Apps container-app volledig gekwalificeerde domeinnaam.

Externe en interne FQDN's

De zichtbaarheidsinstelling voor inkomend verkeer bepaalt of uw app bereikbaar is van buiten de omgeving:

Zichtbaarheid FQDN-patroon Bereikbaar vanaf
Extern <APP_NAME>.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io Overal (openbaar internet)
Intern <APP_NAME>.internal.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io Alleen dezelfde omgeving

Wanneer u inkomend verkeer instelt op intern, bevat de FQDN een .internal. segment. Andere container-apps in dezelfde omgeving kunnen de app nog steeds bereiken met behulp van dit adres, maar aanvragen van buiten de omgeving ontvangen een 404 reactie van de proxy van de omgeving. De DNS-naam wordt omgezet in het gedeelde IP-adres van de omgeving, maar de proxy weigert de aanvraag omdat de app alleen intern is.

Volledig gekwalificeerde domeinnaam ophalen

De az containerapp show opdracht retourneert de volledig gekwalificeerde domeinnaam van een container-app.

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

Vervang in dit voorbeeld de plaatsaanduidingen tussen <> met uw waarden.

De waarde die door deze opdracht wordt geretourneerd, lijkt op een domeinnaam zoals in het volgende voorbeeld:

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

FQDNs van revisielabels

Wanneer u labels toewijst aan specifieke revisies, krijgt elk label een unieke eigen FQDN met behulp van een scheidingsteken bestaande uit drie streepjes:

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

Voor interne apps bevat het patroon het .internal. segment:

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

Met label-FQDN's kunt u verkeer rechtstreeks naar een specifieke revisie verzenden. Deze procedure is handig voor het testen van nieuwe versies, het uitvoeren van A/B-experimenten of het leveren van stabiele eindpunten voor specifieke revisie-implementaties.

Een container-app op naam aanroepen

De eenvoudigste manier om een andere container-app vanuit dezelfde omgeving aan te roepen, is op naam. Verzend een aanvraag naar http://<CONTAINER_APP_NAME>en de ingebouwde DNS van de omgeving zet de naam automatisch om.

http://my-backend-api

Hoe DNS-omzetting werkt

Achter de schermen gebruikt Azure Container Apps een aangepaste DNS-configuratie waarmee container-app-namen worden omgezet in routeerbare adressen. Wanneer uw app een aanvraag indient naar de naam of FQDN van een andere app:

  1. De DNS-server van de omgeving zet de hostnaam om in het adres van de Envoy-proxyservice.
  2. De Envoy-proxy identificeert de doel-app van de oorspronkelijke hostnaam.
  3. De proxy stuurt de aanvraag naar de juiste revisie(s) op basis van uw verkeersconfiguratie.

Deze architectuur betekent dat container-apps nooit rechtstreeks met elkaars pods communiceren. Al het verkeer passeert de proxylaag, die TLS-beëindiging, taakverdeling en verkeer splitsen biedt.

Aanbeveling

Gebruik de korte app-naam (http://<APP_NAME>) voor aanroepen tussen container-apps in dezelfde omgeving. Het is eenvoudiger dan de volledige FQDN en werkt op dezelfde manier omdat de DNS beide patronen via dezelfde proxy oplost.

Transportprotocollen

Container-apps ondersteunen drie transportmodi voor inkomend verkeer, geconfigureerd via de transport eigenschap:

Vervoer Gebruiksituatie Details
Automatisch (standaard) Standaardweb-API's en -services Onderhandelt automatisch over HTTP/1.1 en HTTP/2
HTTP/2 gRPC services Hiermee schakelt u end-to-end HTTP/2 in, vereist voor gRPC
TCP Niet-HTTP-protocollen (databases, aangepaste protocollen) Onbewerkte TCP-verbindingen met poorttoewijzing

Notitie

Voor extern TCP-inkomend verkeer is een aangepast VNet vereist. Als u een externe TCP-app probeert te maken zonder een aangepast VNet, krijgt u een ContainerAppTcpRequiresVnet foutmelding. Intern TCP-inkomend verkeer werkt zonder een aangepast VNet.

Wanneer u TCP-transport gebruikt, kunt u ook extra poorten beschikbaar maken buiten de primaire ingangspoort. Elke extra poort maakt een afzonderlijk TCP-eindpunt waarmee andere apps in de omgeving verbinding kunnen maken.

Verkeerssplitsing en revisieroutering

Azure Container Apps ondersteunt drie revisiemodi die van invloed zijn op de manier waarop verkeer wordt gedistribueerd tussen container-apps:

Mode Gedrag
enkele Al het verkeer gaat naar de meest recente actieve revisie.
Meerdere Verkeer wordt verdeeld over revisies per percentage, op basis van uw verkeersregels.
Labels Elke gelabelde revisie krijgt een unieke FQDN voor directe toegang.

Wanneer in meerdere modus een andere container-app de FQDN van uw app aanroept, distribueert de proxy automatisch aanvragen over revisies op basis van uw geconfigureerde gewichten. In de labelsmodus kunnen oproepers zich richten op een specifieke revisie met behulp van de label FQDN.

Zie Revisions in Azure Container Apps voor meer informatie.

Aanroep van dapr-service

Dapr (Distributed Application Runtime) biedt een sidecar-benadering voor communicatie tussen apps. Door Dapr in te schakelen, krijgen uw container-apps ingebouwde service-aanroep met wederzijdse TLS, automatische nieuwe pogingen en gedistribueerde tracering via Azure Application Insights.

Diagram dat de locatie van de Azure Container Apps container-app met Dapr toont.

Hoe Dapr-aanroep werkt

Elke container-app met Dapr-functionaliteit voert een sidecar-proces uit naast uw toepassing. Als u een andere dapr-app wilt aanroepen, moet u een lokale HTTP-aanvraag indienen bij de Dapr-sidecar, waarmee servicedetectie en -routering wordt verwerkt:

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

Als u bijvoorbeeld de catalog methode voor een app wilt aanroepen met een Dapr-app-id van order-processor:

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

De sidecar zet de doel-app om via een toegewezen DNS-domein en stuurt de aanvraag door via de envoy-proxylaag. Dit is dezelfde infrastructuur die FQDN-routering verwerkt.

Notitie

Dapr maakt gebruik van een eigen DNS-omzettingspad (het .dapr domein) gescheiden van de standaard FQDN-resolutie. Beide paden worden gerouteerd via de proxy-infrastructuur van de omgeving.

Dapr App ID

De Dapr-app-id is de identiteit die andere apps gebruiken om uw service aan te roepen. Als u geen expliciete app-id instelt, wordt de Dapr-runtime standaard ingesteld op de naam van de container-app. De ARM-API wordt weergegeven appId: null wanneer u geen aangepaste id configureert, maar de runtime past de naam van de app automatisch toe. Stel een aangepaste app-id in uw Dapr-configuratie in als u een andere id nodig hebt.

Dapr-app-id's moeten uniek zijn binnen een omgeving. Als u een container-app probeert te implementeren met een Dapr-app-id die al wordt gebruikt door een andere app, wordt de container-app-resource gemaakt, maar faalt de revisie om te provisioneren (provisioningState: Failed). Het foutbericht identificeert de conflicterende app-id en de app die eigenaar is van de app.

Dapr-only apps (geen HTTP-inkomend verkeer)

U kunt Dapr inschakelen voor een container-app zonder HTTP-inkomend verkeer te configureren. In dit geval is de app niet bereikbaar via een FQDN- of app-naam, maar andere Dapr-apps kunnen deze nog steeds aanroepen via dapr-serviceaanroepen. Dit patroon is handig voor achtergrondwerkers of gebeurtenisprocessors die alleen oproepen van andere services in de mesh hoeven te ontvangen.

Aanbeveling

Wanneer u een app zonder inkomend verkeer maakt met de Azure CLI, laat u zowel de vlaggen --ingress als --target-port weg. Het opnemen van --target-port zonder --ingress leidt tot een gebruiksfout.

Dapr sidecar-configuratie

U configureert de Dapr-sidecar via de eigenschappen van uw container-app. Belangrijke instellingen zijn onder andere:

Configuratie Beschrijving
appId De Dapr-app-id (standaard ingesteld op de naam van de container-app)
appPort De poort waarop uw app luistert (valt terug naar de ingress-doelpoort)
appProtocol Protocol voor communicatie tussen Dapr-apps (bijvoorbeeld , httpgrpc)
logLevel Uitgebreidheid van Dapr Sidecar-logboek
enableApiLogging Moeten Dapr API-aanroepen worden vastgelegd?
httpMaxRequestSize Maximale grootte van aanvraagbody in MB voor de HTTP-server van Dapr
httpReadBufferSize Maximale grootte van de HTTP-leesbuffer in KB

Zie Dapr-integratie met Azure Container Apps voor meer informatie over het configureren van Dapr met Azure Container Apps.

Beveiliging voor communicatie tussen apps

Azure Container Apps bevat verschillende beveiligingsfuncties die van invloed zijn op de communicatie tussen container-apps:

  • TLS standaard: al het verkeer tussen container-apps wordt gerouteerd via de Envoy-proxy, die TLS-beëindiging afhandelt. Ingesteld allowInsecure op false (de standaardinstelling) om HTTPS-omleidingen af te dwingen.
  • Clientcertificaatmodus (mTLS):configureer wederzijdse TLS door de clientcertificaatmodus in te stellen op require, acceptof ignore.
  • IP-beperkingen: definieer regels voor toestaan of weigeren om te beperken welke IP-adressen uw app kunnen bereiken.
  • CORS-beleid: regels voor het delen van cross-origin-resources configureren voor browserclients die uw container-apps aanroepen.

Notitie

Wanneer u Dapr-serviceaanroepen gebruikt, worden de Dapr-sidecars tussen services automatisch beveiligd met wederzijdse TLS-communicatie. U hoeft mTLS niet afzonderlijk te configureren voor Dapr-naar-Dapr-aanroepen.

Zie Ingress in Azure Container Apps voor meer informatie.

Aangepaste domeinen

U kunt uw eigen domeinnamen toewijzen aan een container-app door aangepaste domeinen te configureren in de instellingen voor inkomend verkeer. Elk aangepast domein kan verwijzen naar een beheerd of geüpload TLS-certificaat.

Aangepaste domeinen worden geregistreerd naast de standaard-FQDN, zodat uw app op beide adressen reageert. Wanneer andere container-apps in de omgeving uw app moeten bereiken, kunnen ze de standaard-FQDN, de app-naam of uw aangepaste domein gebruiken.

Zie Custom-domeinen in Azure Container Apps voor meer informatie.

Voorbeeldoplossing

Een voorbeeld waarin wordt getoond hoe u tussen containers aanroept met zowel de FQDN als Dapr, is beschikbaar op Azure Samples.

Informatie over communicatie tussen apps in Azure Container Apps maakt verbinding met verschillende gerelateerde onderwerpen:

Volgende stap

Ingang configureren voor uw containerapp

  • Last updated on