Kommunikáció tárolóalkalmazások között az Azure Container Apps-ben

Azure Container Apps beépített szolgáltatásfelderítést és útválasztást biztosít, hogy a tárolóalkalmazások infrastruktúra kezelése nélkül kommunikálhassanak egymással. Ha több tárolóalkalmazást helyez üzembe ugyanabban a környezetben, a platform automatikusan kezeli a DNS-feloldásokat, a terheléselosztást és a biztonságos forgalomirányítást.

Ha a bejövő forgalom engedélyezve van, minden tárolóalkalmazás kap egy tartománynevet. Ezt a végpontot nyilvánosan elérhetővé teheti, vagy korlátozhatja más tárolóalkalmazásokra ugyanabban a környezetben.

A tárolóalkalmazások az alábbi módszerek bármelyikével elérhetik egymást:

  • Teljes tartománynév (FQDN): az alapértelmezett generált tartomány
  • Alkalmazás neve: rövid cím belső hívásokhoz http://<APP_NAME>
  • Dapr szolgáltatáshívás: oldalkocsi-alapú megközelítés beépített újrapróbálkozással és megfigyelhetőséggel
  • Egyéni tartomány: saját tartományneve felügyelt tanúsítvánnyal

Feljegyzés

Ha egy másik tárolóalkalmazást hív meg ugyanabban a környezetben a teljes tartománynév vagy az alkalmazásnév használatával, a hálózati forgalom soha nem hagyja el a környezetet.

Miért fontos?

A mikroszolgáltatás-architektúra esetében a szolgáltatásoknak megbízhatóan kell egymást hívniuk. Azure Container Apps megszünteti a szolgáltatásfelderítés beállításának, a DNS-rekordok kezelésének és a fordított proxyk konfigurálásának működési terheit.

A platform az alábbiakat kezeli:

  • Automatikus DNS-regisztráció: Az üzembe helyezés után minden tárolóalkalmazás kap egy feloldható állomásnevet.
  • Proxy által felügyelt útválasztás: Minden alkalmazásközi forgalom egy beépített megbízott proxyrétegen halad át, amely kezeli a TLS-lezárást, a forgalom felosztását és a terheléselosztást.
  • Környezeti hatókörű elkülönítés: A belső végpontok csak ugyanazon a környezetben érhetők el, és természetes biztonsági határt hoznak létre.
  • Protokollrugalmasság: HTTP/1.1, HTTP/2 (gRPC esetén) vagy nyers TCP-kapcsolaton keresztüli kommunikáció a számítási feladat igényeitől függően.

Ezek a képességek azt jelentik, hogy a hálózatkezelés helyett az alkalmazáslogikára összpontosíthat.

Tárolóalkalmazás helye (FQDN)

Minden tárolóalkalmazás teljes tartományneve az alkalmazás nevéből, egy egyedi környezeti azonosítóból és a régióból áll. Ezek a tartománytöredékek mind a azurecontainerapps.io legfelső szintű tartomány alá tartoznak.

Azure Container Apps tárolóalkalmazás teljes tartományneve.

Külső és belső FQDN-ek

A bejövő forgalom láthatósági beállítása szabályozza, hogy az alkalmazás elérhető-e a környezeten kívülről:

Láthatóság FQDN (teljes tartománynév) mintája Elérhető innen:
külső <APP_NAME>.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io Bárhol (nyilvános internet)
Belső <APP_NAME>.internal.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io Csak ugyanaz a környezet

Ha az ingress értékét belső értékre állítja, a teljes tartománynév egy .internal. szegmenst tartalmaz. Az ugyanabban a környezetben lévő többi tárolóalkalmazás továbbra is elérheti az alkalmazást ezzel a címmel, de a környezeten kívüli kérések választ kapnak 404 a környezet proxyjától. A DNS-név feloldódik a környezet megosztott IP-címére, de a proxy elutasítja a kérést, mert az alkalmazás csak belső használatra van.

Teljesen minősített tartománynév megszerzése

A az containerapp show parancs egy tárolóalkalmazás teljes tartománynevét adja vissza.

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

Ebben a példában cserélje le a <> helyőrzőket az Ön értékeire.

A parancsból visszaadott érték hasonlít egy tartománynévre, mint az alábbi példa:

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

Változatcímke teljes tartománynevei

Ha címkéket rendel hozzá adott változatokhoz, mindegyik címke saját egyedi teljes tartománynevet kap egy háromkötőjeles elválasztó használatával:

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

A belső alkalmazások esetében a minta a szegmenst .internal. tartalmazza:

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

A Label FQDN-ek lehetővé teszik, hogy a forgalmat közvetlenül egy adott verzióra küldje. Ez a gyakorlat hasznos új verziók teszteléséhez, A/B-kísérletek futtatásához vagy stabil végpontok biztosításához adott változattelepítésekhez.

Tárolóalkalmazás meghívása név szerint

Egy másik tárolóalkalmazás ugyanolyan környezetben történő meghívásának legegyszerűbb módja a neve. Küldjön egy kérést http://<CONTAINER_APP_NAME>, és a környezet beépített DNS-e automatikusan feloldja a nevet.

http://my-backend-api

A DNS-feloldás működése

A színfalak mögött Azure Container Apps egy egyéni DNS-konfigurációt használ, amely a tárolóalkalmazások nevét fordítja le irányítható címekre. Amikor az alkalmazás kérést küld egy másik alkalmazás nevére vagy teljes tartománynevére:

  1. A környezet DNS-kiszolgálója feloldja a gazdagépnevet az Envoy proxy szolgáltatás címére.
  2. Az Envoy proxy azonosítja a célalkalmazást az eredeti gazdagépnévből.
  3. A proxy a forgalomkonfiguráció alapján a megfelelő változat(ok)ra irányítja a kérelmet.

Ez az architektúra azt jelenti, hogy a tárolóalkalmazások soha nem kommunikálnak közvetlenül egymás podjaival. Minden forgalom áthalad a proxyrétegen, amely TLS-lezárást, terheléselosztást és forgalomeloszlást biztosít.

Jótanács

Használja a rövid alkalmazásnevet (http://<APP_NAME>) a tárolóalkalmazások közötti hívásokhoz ugyanabban a környezetben. Ez egyszerűbb, mint a teljes teljes tartománynév, és ugyanúgy működik, mivel a DNS mindkét mintát ugyanazzal a proxyval oldja fel.

Szállítási protokollok

A tárolóalkalmazások három átviteli módot támogatnak a bejövő forgalomhoz, amelyek a transport tulajdonságon keresztül konfigurálhatók:

Szállítás Felhasználási eset Részletek
Automatikus (alapértelmezett) Standard webes API-k és -szolgáltatások A HTTP/1.1 és a HTTP/2 automatikus egyeztetése
HTTP/2 gRPC-szolgáltatások A gRPC-hez szükséges HTTP/2 protokoll teljes körű engedélyezése
TCP Nem HTTP protokollok (adatbázisok, egyéni protokollok) Nyers TCP-kapcsolatok portleképezéssel

Feljegyzés

A külső TCP-bejövő forgalomhoz egyéni virtuális hálózat szükséges. Ha egyéni virtuális hálózat nélkül próbál külső TCP-alkalmazást létrehozni, hibaüzenet jelenik ContainerAppTcpRequiresVnet meg. A belső TCP-bejövő forgalom egyéni virtuális hálózat nélkül működik.

TCP-átvitel használatakor az elsődleges bejövő porton kívül további portokat is elérhetővé tehet. Minden további port külön TCP-végpontot hoz létre, amelyhez a környezet más alkalmazásai is csatlakozhatnak.

Forgalom felosztása és revízió-útválasztás

Azure Container Apps három változatmódot támogat, amelyek befolyásolják a forgalom tárolóalkalmazások közötti elosztását:

Mód Magatartás
Single Minden forgalom a legújabb aktív változatra kerül.
több A forgalom az Ön forgalmi szabályai alapján százalékosan oszlik meg a különböző verziók között.
Címkék Minden címkézett változat egyedi teljes tartománynevet kap a közvetlen hozzáféréshez.

Több módban, amikor egy másik tárolóalkalmazás meghívja az alkalmazás teljes tartománynevét, a proxy automatikusan elosztja a kéréseket a változatok között a konfigurált súlyok alapján. Címkék módban a hívók egy adott változatot a címke FQDN használatával célozhatnak meg.

További információ: Revisions in Azure Container Apps.

Dapr szolgáltatáshívás

A Dapr (Distributed Application Runtime) oldalkocsialapú megközelítést biztosít az alkalmazások közötti kommunikációhoz. A Dapr engedélyezésével a tárolóalkalmazások beépített szolgáltatáshívást kapnak kölcsönös TLS-sel, az automatikus újrapróbálkozással és az Azure-alkalmazás Insights-on keresztüli elosztott nyomkövetéssel.

Diagram, amely az Azure Container Apps tárolóalkalmazás helyét mutatja be a Dapr mellett.

A Dapr-hívás működése

Minden Dapr-kompatibilis tárolóalkalmazás egy sidecar folyamatot futtat a fő alkalmazással együtt. Egy másik Dapr-kompatibilis alkalmazás meghívásához hozzon létre egy helyi HTTP-kérést a Dapr oldalkocsihoz, amely kezeli a szolgáltatásfelderítést és -útválasztást:

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

Például a catalog metódus meghívásához egy alkalmazáson, amelynek Dapr-alkalmazásazonosítója: order-processor:

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

A sidecar egy dedikált DNS-tartományon keresztül oldja fel a célalkalmazást, és átirányítja a kérést az Envoy proxyrétegen keresztül. Ez ugyanaz az infrastruktúra, amely az FQDN-alapú útválasztást kezeli.

Feljegyzés

A Dapr a saját DNS-feloldási útvonalát (a .dapr tartományt) használja, amely elkülönül a standard teljes tartománynév (FQDN) feloldástól. Mindkét útvonal a környezet proxyinfrastruktúráján halad át.

Dapr-alkalmazás azonosítója

A Dapr-alkalmazás azonosítója az az identitás, amelyet más alkalmazások használnak a szolgáltatás meghívásához. Ha nem állít be explicit alkalmazásazonosítót, a Dapr-futtatókörnyezet alapértelmezésként a tárolóalkalmazás nevét használja. Az ARM API akkor jelenik meg appId: null , ha nem konfigurál egyéni azonosítót, de a futtatókörnyezet automatikusan alkalmazza az alkalmazás nevét. Ha más azonosítóra van szüksége, állítson be egy egyéni alkalmazásazonosítót a Dapr-konfigurációban.

A Dapr-alkalmazásazonosítóknak egyedinek kell lenniük egy környezetben. Ha egy másik alkalmazás által már használatban lévő Dapr alkalmazásazonosítóval rendelkező tárolóalkalmazást próbál üzembe helyezni, a tárolóalkalmazás-erőforrás létrejön, de a változat telepítése nem sikerül (provisioningState: Failed). A hibaüzenet azonosítja az ütköző alkalmazásazonosítót és a tulajdonában lévő alkalmazást.

Csak dapr-alkalmazások (http-bejövő forgalom nélkül)

A Dapr http-bejövő forgalom konfigurálása nélkül is engedélyezhető egy tárolóalkalmazásban. Ebben az esetben az alkalmazás nem érhető el teljes tartománynévvel vagy alkalmazásnévvel, de más Dapr-kompatibilis alkalmazások továbbra is elérhetik Dapr szolgáltatáshívással. Ez a minta olyan háttérmunkások vagy eseményfeldolgozók számára hasznos, amelyeknek csak a háló más szolgáltatásaitól kell hívásokat fogadniuk.

Jótanács

Amikor bejárat nélküli alkalmazást hoz létre az Azure CLI-vel, hagyja ki a --ingress és --target-port jelzőket. Ha --target-port--ingress nélkül szerepel, az használati hibát eredményez.

Dapr oldalkocsi konfigurációja

A Dapr oldalkocsit a tárolóalkalmazás tulajdonságain keresztül konfigurálhatja. A kulcsbeállítások a következők:

Setting Leírás
appId A Dapr-alkalmazás azonosítója (alapértelmezés szerint a tárolóalkalmazás neve)
appPort Az alkalmazás által figyelt port (visszaesik a bemeneti célportra)
appProtocol Protokoll a Dapr-to-app kommunikációhoz (például http, grpc)
logLevel Dapr oldalkocsi napló részletessége
enableApiLogging Dapr API-hívások naplózása
httpMaxRequestSize A kérelem törzsének maximális mérete MB-ban a Dapr HTTP-kiszolgálója számára
httpReadBufferSize A HTTP olvasási puffer maximális mérete a KB-ban

További információ a Dapr Azure Container Apps-szel való konfigurálásáról a Dapr integrációja az Azure Container Apps-szel című témakörben található.

Alkalmazásközi kommunikáció biztonsága

Azure Container Apps számos olyan biztonsági funkciót tartalmaz, amelyek befolyásolják a tárolóalkalmazások kommunikációját:

  • TLS alapértelmezés szerint: A tárolóalkalmazások közötti összes forgalom az envoy proxyn keresztül halad át, amely kezeli a TLS-leállítást. allowInsecure A false HTTPS-átirányítások kényszerítéséhez állítsa (alapértelmezett) értékre.
  • Ügyféltanúsítvány-mód (mTLS): Az ügyféltanúsítvány mód beállításával konfigurálja a kölcsönös TLS-t a következőre require: , acceptvagy ignore.
  • IP-korlátozások: Olyan engedélyezési vagy megtagadási szabályok definiálása, amelyek korlátozzák, hogy mely IP-címek érhetik el az alkalmazást.
  • CORS-szabályzatok: A tárolóalkalmazásokat hívó böngészőalapú ügyfelek forrásközi erőforrás-megosztási szabályainak konfigurálása.

Feljegyzés

A Dapr szolgáltatáshívás használatakor a Dapr oldalkocsik automatikusan biztosítják a szolgáltatások közötti kölcsönös TLS-kapcsolattal való kommunikációt. Nem kell külön konfigurálnia az mTLS-t a Dapr-to-Dapr hívásokhoz.

További információ: Ingress in Azure Container Apps.

Egyedi domainek

Saját tartományneveit egy tárolóalkalmazáshoz rendelheti, ha egyéni tartományokat konfigurál a bemeneti beállításokon. Minden egyéni tartomány hivatkozhat felügyelt vagy feltöltött TLS-tanúsítványra.

Az egyéni tartományok az alapértelmezett teljes tartománynév mellett vannak regisztrálva, így az alkalmazás mindkét címre válaszol. Ha a környezet többi tárolóalkalmazásának el kell érnie az alkalmazást, használhatják az alapértelmezett teljes tartománynevet, az alkalmazásnevet vagy az egyéni tartományt.

További információért nézze meg az Egyéni tartományok az Azure Container Appsben dokumentációt.

Mintamegoldás

Egy minta található az Azure Minták oldalon, amely bemutatja, hogyan lehet hívást kezdeményezni a tárolók között az FQDN és a Dapr használatával.

Az alkalmazások közötti kommunikáció megértése Azure Container Apps több kapcsolódó témakörhöz kapcsolódik:

Következő lépés

Bejövő forgalom konfigurálása a tárolóalkalmazáshoz

  • Last updated on