Azure Container Apps – gyakori kérdések (gyakori kérdések)

Ez a cikk az Azure Container Apps szolgáltatással kapcsolatos gyakori kérdéseket és a kapcsolódó válaszokat sorolja fel.

Régiók

Hol találhatók a legújabb információk a támogatott régiókról az Azure Container Appsben?

A lista az alábbi Azure CLI-parancs futtatásával hozható létre:

  az provider show \
  --namespace Microsoft.App \
  --query "resourceTypes[?resourceType=='managedEnvironments'].locations"

API-k

Az Azure Container Apps közvetlen hozzáférést biztosít a mögöttes Kubernetes API-hoz?

Nem, az Azure Container Apps nem biztosít közvetlen hozzáférést a Kubernetes API-hoz.

Importálhatom az Azure Container Apps API-t az API Management környezetéből?

Igen, importálhat egy Azure Container Apps API-t az API Management környezetéből.

Számlázás

Hogyan történik az Azure Container Apps számlázása?

A számlázás az erőforrás-használaton alapul, beleértve a processzort, a memóriát és a kérések számát. További információkért tekintse meg a számlázási oldalt.

Konfiguráció

Beállíthatom a GitHub Actionst, hogy automatikusan létrehozzam és üzembe helyezhessem a kódot az Azure Container Appsben?

Igen. A GitHub Actionst az Azure CLI vagy az Azure Portal használatával konfigurálhatja:

• Az Azure CLI használatával futtassa az containerapp github-action -h a beállításokat.

• Az Azure Portal használatával lépjen a tárolóalkalmazás "Folyamatos üzembe helyezés" ablakára.

Miért más URL-címet kap az alkalmazás, mint a kérelemben megadott URL-cím?

Az Azure Container Apps dekódolja az URL-címet, hogy megvédje az alkalmazást az URL-zavarásos támadásoktól. A rendszer egy kódolt részeket tartalmazó http://mysite.com/archive/http%3A%2F%2Fmysite.com%2Farchive%2F123kérelem URL-címét küldi el az alkalmazásnak http://mysite.com/archive/http%3A/mysite.com/archive/123.

Csak a használati környezetek támogatják az egyéni, felhasználó által megadott útvonalakat?

A csak használatalapú környezetek korlátozottan támogatják a felhasználó által definiált útvonalakat (UDR-eket). Az ExpressRoute nem támogatott. Korlátozott UDR-támogatás érhető el, ha az alábbiak szerint van konfigurálva:

• Az útvonalat a Azure.<REGION_NAME> Következő ugrás = "Internet" szolgáltatáscímkével kell definiálni.

• A hálózati biztonsági csoport (NSG) szabályait az NSG dokumentációjában leírtak szerint is konfigurálni kell, hogy a környezet megfelelően működjön.

Ezek a korlátozások nem vonatkoznak a számítási feladatok profiljaira, és az UDR és az Express Route teljes körű támogatásához használjon számítási feladatprofil-környezeteket.

Adatkezelés

Hol tárolja az Azure Container Apps az ügyféladatokat?

Az Azure Container Apps nem helyezi át vagy tárolja az ügyféladatokat az üzembe helyezett régióból.

Kvóták

Hogyan kérhetek kvótanövelést?

Kvótanövelés kérése az Azure Portalon a szolgáltatóként kiválasztott Azure Container Appsszel.

A kvótanövelési kérelem beküldésekor vegye figyelembe a következő részleteket:

• Alkalmazások és környezetek skálázása: Számos különböző kvótát lehet növelni. Az alábbi leírások segítenek az igények azonosításában:

  • Alkalmazások és magok növelése környezetenként: Lehetővé teszi több alkalmazás futtatását egy környezetben és/vagy intenzívebb alkalmazásokban. Ajánlott, ha a számítási feladatok ugyanazon a hálózaton és biztonsági határokon belül telepíthetők.
  • Növekvő környezetek: Ajánlott, ha a számítási feladatok hálózati vagy biztonsági határokat igényelnek. Megjegyzés: Részletes üzleti környezetre lehet szükség, ha a kérés környezeti szintű kvóták növelését igényli. Amikor a regionális környezeti kvóta módosítását kéri, a globális környezeti kvótának megfelelő módosítást kell kérnie.

• Régiók: A kérelmek növelésének jóváhagyása az Azure-régiókban elérhető számítási kapacitástól függően változik.

• Konkrét számítási követelmények: A platform tárolóalkalmazásonként 4 GB-ot támogat. A memóriakorlátok felülbírálása esetenként történik.

• A skálázás üzleti érvelése: Akkor lehet jogosult a kvótanövelési kérelemre, ha a platformkorlátok blokkolják a számítási feladatokra vonatkozó igényeket. A méretezési korlátok felülbírálása esetenként történik.

A Dapr által üzemeltetett mikroszolgáltatási API-k

Milyen Dapr-funkciók és API-k érhetők el az Azure Container Appsben?

Minden Dapr-képesség alapos értékelésen megy keresztül, hogy pozitív hatással legyen az Azure Container Apps-környezetben mikroszolgáltatásokat futtató ügyfelekre, miközben a lehető legjobb élményt nyújtja.

Támogatottak vagy elérhetők az Alfa Dapr API-k és a 2. rétegbeli összetevők az Azure Container Appsben?

A Dapr alfa API-jainak rendelkezésre állása nem garantált vagy a Microsoft által támogatott.

Míg az 1. rétegbeli összetevők teljes mértékben támogatottak, a 2. rétegbeli összetevők minden erőfeszítést megtesznek. További információ.

Hogyan kérhetek Dapr-funkcióbővítést az Azure Container Appshez?

A szolgáltatáskérést az Azure Container Apps GitHub-adattáron keresztül küldheti el. Ügyeljen arra, hogy a "Dapr" szerepeljen a funkciókérés címében.

Miért jelenik meg a "-msft".<number> verziót a Container App Environmentben?

Ahogy 1.13.6-msft.1 az éles régiókban is megjelenik, előfordulhat, hogy a korábbi verziók is megjelennek (például 1.12.5 vagy 1.12.5-msft.6). Az -msft.<number> utótag az Azure Container Apps felhasználói élmény fokozása érdekében végzett egyéni testreszabásait jelzi.

Milyen gyakran jelennek meg a Dapr-verziók az Azure Container Appshez?

A Dapr-verziók a lehető legjobb erőfeszítéssel frissülnek, a stabilitásra, az alapos tesztelésre és az ügyfelek hatásának minimalizálására összpontosítva. A cél az, hogy a frissítések zökkenőmentesen integrálhatók legyenek anélkül, hogy kompatibilitástörő módosításokat vezetnek be.

Mivel a Dapr verziófrissítései automatikusan kerülnek alkalmazásra, mindig a legbiztonságosabb verziót használhatja. Az Azure Container Apps Dapr szolgáltatása azonban nem követi az új funkciók rögzített kiadási ütemezését. Ehelyett az új Dapr-verziók új funkciókhoz való kiadása a Dapr bináris fájlok rangsorolásától és stabilitásától függ.

A GitHubon található Azure Container Appsben megtalálhatja a Dapr frissítéseit és kiadási közleményeit.

Használhatok egy adott Dapr-verziót a környezetemhez?

Az egyéni verzió kiválasztása nem támogatott. Ehelyett a környezet automatikusan frissül, fenntartva a Dapr teljes mértékben felügyelt és kiszolgáló nélküli ajánlatának integritását az Azure Container Appsben. Az automatikus frissítés vezérléséhez konfigurálja a tervezett karbantartási funkciót a tárolóalkalmazások környezetében.

Dockerless-üzemelő példányok

Mi az a Docker-kevésbé üzemelő példány?

A Docker nélküli üzembe helyezés lehetővé teszi az alkalmazás üzembe helyezését anélkül, hogy dockerfile-t határoz meg a kódban. Ehelyett a Container Apps felhőalapú buildelési funkciója a Buildpacks használatával a helyi gépen lévő forráskódot tárolólemezképké alakítja. Ez a beállítás az Azure Container Apps alapértelmezett beállításjegyzékét használja.

A Docker-less alkalmazás telepítése során megjelennek az "ImagePullBackOff on legion", a "Kubernetes error" vagy az "Gateway error" (Átjáróhiba) üzenet, és az alkalmazás nem telepít sikeresen.

Ismert problémát tapasztal a Docker-kevésbé üzemelő példányokkal kapcsolatban. Az újrapróbálkozás megoldhatja a problémát. Ha ez a probléma merül fel, nyisson meg egy GitHub-problémát , hogy csapatunk kivizsgálhassa.

.NET-alkalmazások üzembe helyezése

Mi a teendő, ha a .NET-alkalmazás nem skálázható?

Engedélyeznie kell az adatvédelmet az Azure Container Apps összes .NET-alkalmazásához. Részletekért tekintse meg a ASP.NET Core-alkalmazások üzembe helyezését és skálázását az Azure Container Appsben .

Java-alkalmazások üzembe helyezése

Mely JDK-verziók támogatottak, és hogyan konfigurálhatom a JDK-verziót?

A Container Apps négy LTS JDK-verziót támogat: JDK 8, JDK 11, JDK 17 és JDK 21. A forráskód összeállítása esetén az alapértelmezett verzió a JDK 17. JAR-fájl build esetén a JDK-verzió a META-INF\MANIFEST fájlhelyről lesz beolvasva. MF a JAR-ban, de az alapértelmezett JDK 17-es verzióját használja, ha a megadott verzió nem érhető el.

A JDK-verziót úgy konfigurálhatja, hogy felülbírálja az alapértelmezett verziót a buildkörnyezet változóival.

Mely Java-buildelési eszközök támogatottak?

Az Azure Container Apps jelenleg az Apache Maven-t támogatja Java-buildelési eszközként.

Hogyan szabhatok testre egy Java-rendszerkép-buildet a forráskódból?

A Java-rendszerképek összeállítását a buildkörnyezet változóival szabhatja testre.

Hogyan győződjön meg arról, hogy a Docker-less build buildje és képe ugyanabban a régióban érhető el, mint az alkalmazásom?

containerapp up Docker-less kódbázissal kombinálva használja a paramétert, hogy az --location alkalmazás az USA keleti régiójától eltérő helyen fusson.

Címkézés

Hogyan használhatom a "legújabb" vagy statikus címkét a tárolórendszerképhez?

Kerülje a statikus címkék használatát, például latest tárolólemezképekhez. A statikus címkék használata gyorsítótárazási problémákhoz vezethet, és megnehezítheti az alkalmazás hibaelhárítását. Ehelyett használjon egyedi címkéket minden egyes üzembe helyezéshez, például egy Git-kivonatot vagy dátumot és időt, hogy a frissítések megfelelően legyenek nyomon követve és üzembe helyezve.

OpenTelemetria

Milyen átviteli protokollokat támogat az OpenTelemetry által felügyelt ügynök?

A felügyelt ügynök csak a gRPC-t támogatja.

Ez a cikk az Azure Container Apps szolgáltatással kapcsolatos gyakori kérdéseket és a kapcsolódó válaszokat sorolja fel.

A lista az alábbi Azure CLI-parancs futtatásával hozható létre:

  az provider show \
  --namespace Microsoft.App \
  --query "resourceTypes[?resourceType=='managedEnvironments'].locations"

Nem, az Azure Container Apps nem biztosít közvetlen hozzáférést a Kubernetes API-hoz.

Igen, importálhat egy Azure Container Apps API-t az API Management környezetéből.

A számlázás az erőforrás-használaton alapul, beleértve a processzort, a memóriát és a kérések számát. További információkért tekintse meg a számlázási oldalt.

Igen. A GitHub Actionst az Azure CLI vagy az Azure Portal használatával konfigurálhatja:

• Az Azure CLI használatával futtassa az containerapp github-action -h a beállításokat.

• Az Azure Portal használatával lépjen a tárolóalkalmazás "Folyamatos üzembe helyezés" ablakára.

Az Azure Container Apps dekódolja az URL-címet, hogy megvédje az alkalmazást az URL-zavarásos támadásoktól. A rendszer egy kódolt részeket tartalmazó http://mysite.com/archive/http%3A%2F%2Fmysite.com%2Farchive%2F123kérelem URL-címét küldi el az alkalmazásnak http://mysite.com/archive/http%3A/mysite.com/archive/123.

A csak használatalapú környezetek korlátozottan támogatják a felhasználó által definiált útvonalakat (UDR-eket). Az ExpressRoute nem támogatott. Korlátozott UDR-támogatás érhető el, ha az alábbiak szerint van konfigurálva:

• Az útvonalat a Azure.<REGION_NAME> Következő ugrás = "Internet" szolgáltatáscímkével kell definiálni.

• A hálózati biztonsági csoport (NSG) szabályait az NSG dokumentációjában leírtak szerint is konfigurálni kell, hogy a környezet megfelelően működjön.

Ezek a korlátozások nem vonatkoznak a számítási feladatok profiljaira, és az UDR és az Express Route teljes körű támogatásához használjon számítási feladatprofil-környezeteket.

Az Azure Container Apps nem helyezi át vagy tárolja az ügyféladatokat az üzembe helyezett régióból.

Kvótanövelés kérése az Azure Portalon a szolgáltatóként kiválasztott Azure Container Appsszel.

A kvótanövelési kérelem beküldésekor vegye figyelembe a következő részleteket:

• Alkalmazások és környezetek skálázása: Számos különböző kvótát lehet növelni. Az alábbi leírások segítenek az igények azonosításában:

  • Alkalmazások és magok növelése környezetenként: Lehetővé teszi több alkalmazás futtatását egy környezetben és/vagy intenzívebb alkalmazásokban. Ajánlott, ha a számítási feladatok ugyanazon a hálózaton és biztonsági határokon belül telepíthetők.
  • Növekvő környezetek: Ajánlott, ha a számítási feladatok hálózati vagy biztonsági határokat igényelnek. Megjegyzés: Részletes üzleti környezetre lehet szükség, ha a kérés környezeti szintű kvóták növelését igényli. Amikor a regionális környezeti kvóta módosítását kéri, a globális környezeti kvótának megfelelő módosítást kell kérnie.

• Régiók: A kérelmek növelésének jóváhagyása az Azure-régiókban elérhető számítási kapacitástól függően változik.

• Konkrét számítási követelmények: A platform tárolóalkalmazásonként 4 GB-ot támogat. A memóriakorlátok felülbírálása esetenként történik.

• A skálázás üzleti érvelése: Akkor lehet jogosult a kvótanövelési kérelemre, ha a platformkorlátok blokkolják a számítási feladatokra vonatkozó igényeket. A méretezési korlátok felülbírálása esetenként történik.

Minden Dapr-képesség alapos értékelésen megy keresztül, hogy pozitív hatással legyen az Azure Container Apps-környezetben mikroszolgáltatásokat futtató ügyfelekre, miközben a lehető legjobb élményt nyújtja.

A Dapr alfa API-jainak rendelkezésre állása nem garantált vagy a Microsoft által támogatott.

Míg az 1. rétegbeli összetevők teljes mértékben támogatottak, a 2. rétegbeli összetevők minden erőfeszítést megtesznek. További információ.

A szolgáltatáskérést az Azure Container Apps GitHub-adattáron keresztül küldheti el. Ügyeljen arra, hogy a "Dapr" szerepeljen a funkciókérés címében.

Ahogy 1.13.6-msft.1 az éles régiókban is megjelenik, előfordulhat, hogy a korábbi verziók is megjelennek (például 1.12.5 vagy 1.12.5-msft.6). Az -msft.<number> utótag az Azure Container Apps felhasználói élmény fokozása érdekében végzett egyéni testreszabásait jelzi.

A Dapr-verziók a lehető legjobb erőfeszítéssel frissülnek, a stabilitásra, az alapos tesztelésre és az ügyfelek hatásának minimalizálására összpontosítva. A cél az, hogy a frissítések zökkenőmentesen integrálhatók legyenek anélkül, hogy kompatibilitástörő módosításokat vezetnek be.

Mivel a Dapr verziófrissítései automatikusan kerülnek alkalmazásra, mindig a legbiztonságosabb verziót használhatja. Az Azure Container Apps Dapr szolgáltatása azonban nem követi az új funkciók rögzített kiadási ütemezését. Ehelyett az új Dapr-verziók új funkciókhoz való kiadása a Dapr bináris fájlok rangsorolásától és stabilitásától függ.

A GitHubon található Azure Container Appsben megtalálhatja a Dapr frissítéseit és kiadási közleményeit.

Az egyéni verzió kiválasztása nem támogatott. Ehelyett a környezet automatikusan frissül, fenntartva a Dapr teljes mértékben felügyelt és kiszolgáló nélküli ajánlatának integritását az Azure Container Appsben. Az automatikus frissítés vezérléséhez konfigurálja a tervezett karbantartási funkciót a tárolóalkalmazások környezetében.

A Docker nélküli üzembe helyezés lehetővé teszi az alkalmazás üzembe helyezését anélkül, hogy dockerfile-t határoz meg a kódban. Ehelyett a Container Apps felhőalapú buildelési funkciója a Buildpacks használatával a helyi gépen lévő forráskódot tárolólemezképké alakítja. Ez a beállítás az Azure Container Apps alapértelmezett beállításjegyzékét használja.

Ismert problémát tapasztal a Docker-kevésbé üzemelő példányokkal kapcsolatban. Az újrapróbálkozás megoldhatja a problémát. Ha ez a probléma merül fel, nyisson meg egy GitHub-problémát , hogy csapatunk kivizsgálhassa.

Engedélyeznie kell az adatvédelmet az Azure Container Apps összes .NET-alkalmazásához. Részletekért tekintse meg a ASP.NET Core-alkalmazások üzembe helyezését és skálázását az Azure Container Appsben .

A Container Apps négy LTS JDK-verziót támogat: JDK 8, JDK 11, JDK 17 és JDK 21. A forráskód összeállítása esetén az alapértelmezett verzió a JDK 17. JAR-fájl build esetén a JDK-verzió a META-INF\MANIFEST fájlhelyről lesz beolvasva. MF a JAR-ban, de az alapértelmezett JDK 17-es verzióját használja, ha a megadott verzió nem érhető el.

A JDK-verziót úgy konfigurálhatja, hogy felülbírálja az alapértelmezett verziót a buildkörnyezet változóival.

Az Azure Container Apps jelenleg az Apache Maven-t támogatja Java-buildelési eszközként.

A Java-rendszerképek összeállítását a buildkörnyezet változóival szabhatja testre.

containerapp up Docker-less kódbázissal kombinálva használja a paramétert, hogy az --location alkalmazás az USA keleti régiójától eltérő helyen fusson.

Kerülje a statikus címkék használatát, például latest tárolólemezképekhez. A statikus címkék használata gyorsítótárazási problémákhoz vezethet, és megnehezítheti az alkalmazás hibaelhárítását. Ehelyett használjon egyedi címkéket minden egyes üzembe helyezéshez, például egy Git-kivonatot vagy dátumot és időt, hogy a frissítések megfelelően legyenek nyomon követve és üzembe helyezve.

A felügyelt ügynök csak a gRPC-t támogatja.