Szerkesztés

Megosztás a következőn keresztül:


Azure-alkalmazás konfigurációval kapcsolatos gyakori kérdések

Ez a cikk Azure-alkalmazás konfigurációval kapcsolatos gyakori kérdésekre ad választ.

Miben tér el az App Configuration az Azure Key Vaulttól?

Az alkalmazáskonfiguráció segít a fejlesztőknek az alkalmazásbeállítások kezelésében és a funkciók rendelkezésre állásának szabályozásában. Célja, hogy egyszerűsítse az összetett konfigurációs adatokkal végzett munka számos feladatát.

Az alkalmazáskonfiguráció a következőket támogatja:

  • Hierarchikus névterek
  • Címkézés
  • Kiterjedt lekérdezések
  • Kötegelt lekérés
  • Speciális felügyeleti műveletek
  • Szolgáltatásfelügyeleti felhasználói felület

Az alkalmazáskonfiguráció kiegészíti a Key Vaultot, és a kettőt egymás mellett kell használni a legtöbb alkalmazástelepítésben.

Titkos kulcsokat kell tárolnom az Alkalmazáskonfigurációban?

Bár az alkalmazáskonfiguráció megkeményített biztonságot nyújt, a Key Vault továbbra is a legjobb hely az alkalmazás titkos kulcsainak tárolására. A Key Vault hardverszintű titkosítást, részletes hozzáférési szabályzatokat és felügyeleti műveleteket, például tanúsítványváltást biztosít.

Létrehozhat alkalmazáskonfigurációs kulcsértékeket, amelyek a Key Vaultban tárolt titkos kulcsra hivatkoznak. További információ: Key Vault-hivatkozások használata ASP.NET Core-alkalmazásokban.

Az alkalmazáskonfiguráció titkosítja az adataimat?

Igen. Az alkalmazáskonfiguráció mindig titkosítja az összes átvitt és inaktív adatot. Minden hálózati kommunikáció TLS 1.2 vagy TLS 1.3 protokollon keresztül történik. Az alkalmazáskonfiguráció támogatja a inaktív titkosítást a Microsoft által felügyelt vagy az ügyfél által felügyelt kulcsokkal.

Miben különbözik az alkalmazáskonfiguráció Azure-alkalmazás szolgáltatásbeállításoktól?

Azure-alkalmazás Service lehetővé teszi az egyes App Service-példányok alkalmazásbeállításainak megadását. Ezek a beállítások környezeti változókként lesznek átadva az alkalmazáskódnak. Ha szeretné, hozzárendelhet egy beállítást egy adott üzembehelyezési ponthoz. További információ: Alkalmazásbeállítások konfigurálása.

Ezzel szemben Azure-alkalmazás konfiguráció lehetővé teszi olyan beállítások megadását, amelyek több alkalmazás között megoszthatóak. Ide tartoznak az App Service-ben és más platformokon futó alkalmazások is. Az alkalmazáskód ezeket a beállításokat a .NET és a Java konfigurációs szolgáltatóján, az Azure SDK-on keresztül vagy közvetlenül REST API-kon keresztül éri el.

Az Alkalmazáskonfigurációs adatokra mutató hivatkozásokat az App Service alkalmazásbeállításaiban adhat hozzá. Az App Service és az App Configuration között is importálhat és exportálhat beállításokat . Ezzel a funkcióval gyorsan beállíthat egy új App Configuration Store-t a meglévő App Service-beállítások alapján. A konfigurációt megoszthatja egy meglévő alkalmazással is, amely az App Service-beállításokra támaszkodik.

Vannak méretkorlátozások az alkalmazáskonfigurációban tárolt kulcsokra és értékekre?

Egyetlen kulcsértékre 10 KB-os korlát vonatkozik, beleértve az attribútumokat, például a címkét, a tartalomtípust, a címkéket és az egyéb metaadatokat.

Ennek a korlátnak elegendőnek kell lennie egyetlen beállításhoz a legtöbb alkalmazásban. Ha úgy találja, hogy a beállítás nagyobb ennél a korlátnál, megfontolhatja az adatok máshol való tárolását, és hozzáadhatja az adatok hivatkozását az Alkalmazáskonfigurációban.

További információ: Azure-előfizetés és szolgáltatáskorlátok.

Hogyan tárolhatom több környezet konfigurációit (tesztelés, előkészítés, éles környezet stb.)?

Szabályozhatja, hogy ki férhet hozzá az alkalmazáskonfigurációhoz üzletenként. Minden olyan környezethez használjon külön tárolót, amelyhez eltérő engedélyek szükségesek. Ez a megközelítés biztosítja a legjobb biztonsági elkülönítést.

Ha nincs szüksége a környezetek közötti biztonsági elkülönítésre, címkék használatával megkülönböztetheti a konfigurációs értékeket. A különböző környezetek különböző konfigurációinak engedélyezéséhez címkék használatával teljes példát mutatunk be.

Mik az alkalmazáskonfiguráció használatának ajánlott módjai?

Tekintse meg az ajánlott eljárásokat.

Mennyibe kerül az alkalmazáskonfiguráció?

Két tarifacsomag létezik:

  • Ingyenes szint
  • Standard csomag

Ha a Standard szint bevezetése előtt létrehozott egy áruházat, az általános rendelkezésre állás esetén automatikusan átkerült az ingyenes szintre. Dönthet úgy, hogy a Standard szintre frissít, vagy az ingyenes szinten marad.

A standard szintről az ingyenes szintre nem lehet leminősíteni egy áruházat. Létrehozhat egy új tárolót az ingyenes szinten, majd importálhatja a konfigurációs adatokat az adott tárolóba.

Melyik alkalmazáskonfigurációs szintet érdemes használni?

Mindkét alkalmazáskonfigurációs szint alapvető funkciókat kínál, beleértve a konfigurációs beállításokat, a funkciójelzőket, a Key Vault-hivatkozásokat, a konfigurációs pillanatképeket, az alapvető felügyeleti műveleteket, a metrikákat és a naplókat.

Az alábbiakban a szint kiválasztásával kapcsolatos szempontokat vesszük figyelembe.

  • Előfizetésenkénti erőforrások: Az erőforrások egyetlen konfigurációs tárból állnak. Minden előfizetés régiónként egy konfigurációs tárra korlátozódik az ingyenes szinten. Az előfizetések korlátlan számú konfigurációs tárolóval rendelkezhetnek a standard szinten.

  • Erőforrásonkénti tárolás: Az ingyenes szinten minden konfigurációs tárterület 10 MB normál tárterületre és 10 MB pillanatképtárra korlátozódik. A standard szinten minden konfigurációs tár legfeljebb 1 GB normál tárterületet és további 1 GB pillanatkép-tárterületet használhat.

  • Korrektúraelőzmények: Az alkalmazáskonfiguráció tárolja a kulcsok módosításainak előzményeit. Az ingyenes szinten ezt az előzményt hét napig tárolja a rendszer. A standard szinten ezt az előzményt 30 napig tárolja a rendszer.

  • Kérelmek kvótája: Az ingyenes szintű áruházak napi 1000 kérésre korlátozódnak. Amikor egy áruház eléri az 1000 kérést, a 429-ben megadott HTTP-állapotkódot adja vissza az összes kéréshez utc éjfélig.

    A standard szintű áruházak óránként legfeljebb 30 000 kérést igényelnek. Ha az óránkénti kvóta kimerült, a kérések a 429-ben megadott HTTP-állapotkódot adhatják vissza, amely túl sok kérést jelez az óra végéig. Mivel több, kvótát meghaladó kérést küld a rendszer, nagyobb százalékuk a 429-as állapotkódot adja vissza.

  • Szolgáltatásiszint-szerződés: A standard szint SLA-ja 99,9%-os rendelkezésre állással és 99,95%-os rendelkezésre állással rendelkezik, ha engedélyezve van a georeplikációs szolgáltatás. Az ingyenes szint nem rendelkezik SLA-val.

  • Funkciók: Mindkét szint tartalmazza a funkciókat, beleértve a Microsoft által felügyelt kulcsokkal való titkosítást, a hozzáférési kulcson vagy a Microsoft Entra-azonosítón keresztüli hitelesítést, az Azure szerepköralapú hozzáférés-vezérlését (RBAC), a felügyelt identitást, a szolgáltatáscímkéket és a rendelkezésre állási zóna redundanciát. A Standard szint további funkciókat kínál, beleértve a Private Link támogatását, az ügyfél által felügyelt kulcsokkal való titkosítást, a helyreállítható törlési védelmet és a georeplikációs képességet.

  • Költség: A standard szintű áruházak napi használati díjjal rendelkeznek. A napi díj tartalmazza az első 200 000 kérést. A napi kiosztáson túli kérésekért túlhasználati díjat is fizetni kell. Az ingyenes szintű áruház használata nem jár költséggel.

Frissíthetem az áruházat az ingyenes szintről a Standard szintre? Le lehet sorolni egy áruházat a Standard szintről az ingyenes szintre?

Az ingyenes szintről bármikor frissíthet a Standard szintre.

A standard szintről az ingyenes szintre nem lehet leminősíteni egy áruházat. Létrehozhat egy új tárolót az ingyenes szinten, majd importálhatja a konfigurációs adatokat az adott tárolóba.

Hol találhatók az Alkalmazáskonfigurációban tárolt adatok?

Az Alkalmazáskonfigurációban tárolt ügyféladatok abban a régióban találhatók, ahol az ügyfél Alkalmazáskonfigurációs áruháza létrejött. Az ügyféladatok csak akkor lesznek replikálva egy másik régióba, ha az ügyfél engedélyezi az adott régió georeplikálását . Ez az összes elérhető régióra vonatkozik. Az ügyfelek globálisan bármilyen helyről áthelyezhetik, másolhatják vagy elérhetik az adataikat.

Hogyan biztosítja az alkalmazáskonfiguráció a magas adatok rendelkezésre állását?

Azure-alkalmazás Konfiguráció támogatja a földrajzi replikációt a regionális kimaradásokkal szembeni fokozott rugalmasság érdekében.

Azure-alkalmazás Konfiguráció támogatja az Azure rendelkezésre állási zónáit, hogy megvédje az alkalmazást és az adatokat az egyetlen adatközpont hibáitól. Az összes rendelkezésre állási zóna számára engedélyezett régió legalább 3 rendelkezésre állási zónából áll, amelyek mindegyike fizikailag független adatközpont. A rugalmasság érdekében ez az alkalmazáskonfiguráció támogatása minden ügyfél számára ingyenesen engedélyezve van. Az alábbiakban azokat a régiókat követjük, amelyekben az Alkalmazáskonfiguráció engedélyezte a rendelkezésre állási zónák támogatását. További információ: Régiók és rendelkezésre állási zónák az Azure-ban.

Az alábbiakban azokat a régiókat követjük, ahol az alkalmazáskonfiguráció engedélyezte a rendelkezésre állási zónák támogatását.

Észak-, Dél- és Közép-Amerika Európa Közel-Kelet Afrika Ázsia és a Csendes-óceáni térség
Dél-Brazília Közép-Franciaország Közép-Katar Kelet-Ausztrália
Közép-Kanada Észak-Olaszország Egyesült Arab Emírségek északi régiója Közép-India
Az USA középső régiója Középnyugat-Németország Izrael középső régiója Kelet-Japán
USA keleti régiója Észak-Európa Dél-Korea középső régiója
USA 2. keleti régiója Kelet-Norvégia Délkelet-Ázsia
USA déli középső régiója Az Egyesült Királyság déli régiója Kelet-Ázsia
USA-beli államigazgatás – Virginia Nyugat-Európa Észak-Kína 3. régiója
USA 2. nyugati régiója Közép-Svédország
USA 3. nyugati régiója Észak-Svájc
Mexikó középső régiója Közép-Lengyelország
Közép-Spanyolország

Korlátozva van az alkalmazáskonfigurációra irányuló kérések száma?

Az ingyenes csomag konfigurációs tárolói naponta legfeljebb 1000 kérést igényelnek. A Standard szinten lévő konfigurációs tárolók átmeneti szabályozást tapasztalhatnak, ha a kérések száma meghaladja az óránkénti 30 000 kérést.

Ha egy áruház eléri a korlátot a standard szinten, az óra végéig küldött egyes kérések esetében a 429-et is visszaadhatja. A retry-after-ms válasz fejléce javasolt várakozási időt ad (ezredmásodpercben) a kérés újrapróbálkozása előtt.

Ha az alkalmazás rendszeresen tapasztal 429-es HTTP-állapotkódot, fontolja meg újratervezését, hogy csökkentse a kérések számát. További információkért tekintse meg , hogyan csökkentheti az alkalmazáskonfigurációra irányuló kérelmeket.

Az alkalmazás 429-ben kap HTTP-állapotkódot. Miért?

Ilyen körülmények között 429-ben kap EGY HTTP-állapotkódot:

  • Az ingyenes szinten lévő áruház napi kérési korlátjának túllépése.
  • Túllépi a standard szinten lévő tárolók óránkénti kérési korlátját.
  • Pillanatnyi szabályozás a kérések nagy száma miatt†.
  • Pillanatnyi szabályozás a túlzott sávszélesség-használat miatt†.
  • Kulcs létrehozása vagy módosítása a tárkvóta túllépésekor.

Ellenőrizze a 429-válasz törzsét, hogy a kérés miért nem sikerült.

†A konfigurációs tároló pillanatnyi szabályozást tapasztalhat, ha nagy mennyiségű kérést kap, vagy túlzott mennyiségű adatot továbbít. Az alkalmazáskonfigurációs ügyfelek, például az Azure SDK, a konfigurációszolgáltatói kódtárak és az Azure Pipelines-feladatok automatikusan újrapróbálkoznak a szabályozott kérelmeken. Minden olyan alkalmazás esetében, amely ezen ügyfelek egyikét használja, vagy egy olyan egyéni ügyfél esetében, amely újrapróbálkozott a szabályozott kérelmeken, ezt a pillanatnyi szabályozást észrevétlenül kell szabályozni, ha ez történik.

Hogyan megbecsülni az alkalmazás által az Alkalmazáskonfigurációnak küldött kérelmek számát?

Vegyünk egy példát, és tegyük fel, hogy 1000 konfigurációs beállítással rendelkező alkalmazással rendelkezik. Az alkalmazás indításkor betölti ezeket a beállításokat az Alkalmazáskonfigurációból. Ezt követően 30 másodpercenként ellenőrzi, hogy van-e sentinel kulcs a konfigurációs módosításokhoz. Akár Kubernetesen, App Service-en vagy virtuális gépeken fut, tegyük fel, hogy az alkalmazás 50 példánya fut egyszerre.

Először is becsüljük meg a konfigurációfigyelési kérelmeket. Az alkalmazás minden példánya 30 másodpercenként küld egy kérést a sentinel kulcsról az Alkalmazáskonfigurációnak, így egy óra alatt 120 (=3600/30) kérést küld. Mivel az alkalmazás 50 példánya van, az alkalmazás óránként 6000 (=120x50) kérést küld a konfigurációfigyeléshez. Vegye figyelembe, hogy mivel a sentinelkulcs-kérelmek gyakoriak és többnyire változatlanok, a legtöbbjük nem számít bele az áruház óránkénti kvótakorlátjaiba†.

Másodszor, becsüljük meg a konfiguráció betöltésére/újratöltésére vonatkozó kéréseket. Az alkalmazás az indításkor vagy a sentinel kulcsváltozás észlelésekor betölti az összes beállítást. Az alkalmazáskonfiguráció minden kérése legfeljebb 100 kulcsértéket tud lekérni, ezért az összes beállítás betöltéséhez 10 (=1000/100) kérelemre lesz szükség. Mivel 50 alkalmazáspéldánya van, összesen 500 (=10x50) kérést küld, amikor az alkalmazás újraindul vagy újra betölti annak konfigurációját.

Végül rakjuk össze. Feltéve, hogy egy órán belül kétszer frissítette a sentinel kulcsot, az Alkalmazáskonfigurációs áruház 7000 (=6000+500x2) kérést fog kapni az adott órára vonatkozóan. Vegye figyelembe, hogy ezen kérések közül csak körülbelül 1000 (=500x2) kérelem használja a rendelkezésre álló óránkénti kvótát. Frissítse a példában szereplő számokat úgy, hogy az megfeleljen az adott beállításnak és kialakításnak, hogy elegendő pufferrel rendelkezzen az óránkénti szabályozási korláthoz. További információkért tekintse meg , hogyan csökkentheti az alkalmazáskonfigurációra irányuló kérelmeket.

† Az ingyenes szintű tárolók nem rendelkeznek gyakori, ismétlődő kérésekkel, amelyeket kizárnak a napi korlátjukból.

Miért nem tudok olyan alkalmazáskonfigurációs áruházat létrehozni, amelynek a neve megegyezik az imént törölt névvel?

A standard szint összes alkalmazáskonfigurációs áruháza automatikusan engedélyezte a helyreállítható törlés funkciót. A standard szintű Alkalmazáskonfigurációs áruház törlésekor a rendszer fenntartja a nevét a megőrzési időszakra. Ha a megőrzési időszak lejárta előtt újra létre szeretne hozni egy azonos nevű tárolót, először törölnie kell a helyreállíthatóan törölt tárolót , feltéve, hogy az áruházban nincs engedélyezve a törlés elleni védelem. Ha a törlés elleni védelem engedélyezve van, meg kell várnia, amíg a megőrzési időszak el nem telik. Használja a kiürítési függvényt, vagy adjon meg rövidebb megőrzési időt, ha gyakran kell újra létrehoznia egy azonos nevű tárolót. Azoknak a munkafolyamatoknak, amelyek egy azonos nevű tároló újraépítését igénylik, egy órát kell engedélyezni a konfigurációs tár kiürítése és az azt követő létrehozás végrehajtása között. Ez a javaslat azért van érvényben, mert a törlés kérése után a konfigurációs tár erőforrásainak tényleges törlése aszinkron módon történik, ami hosszabb időt igényel a véglegesítéshez. A várakozás elkerülése érdekében a rövid élettartamú konfigurációs tárolókat létrehozó munkafolyamatoknak ajánlott egyedi neveket használniuk.

Hogyan állíthatom vissza a tévesen törölt alkalmazáskonfigurációs áruházat?

A standard szinten található összes alkalmazáskonfigurációs tároló támogatja a helyreállítható törlés funkciót, amely nem tiltható le. A törölt tárolót a megőrzési időn belül helyreállíthatja. Kövesse az alábbi utasításokat egy tévesen törölt alkalmazáskonfigurációs áruház helyreállításához.

Létrehozhatok és frissíthetek funkciójelzőket vagy Key Vault-hivatkozásokat programozott módon?

Igen. Bár az Alkalmazáskonfiguráció funkciójelzőit és Key Vault-hivatkozásait az Azure Portalon vagy a PARANCSSOR-on keresztül kezelheti, az alkalmazáskonfigurációs SDK-k használatával programozott módon is létrehozhatja és frissítheti őket. Ezért megírhatja a testreszabott felügyeleti portált, vagy programozott módon kezelheti őket a CI/CD-ben. A funkciójelző és a Key Vault referencia API-k az összes támogatott nyelv SDK-jában elérhetők. Tekintse meg a mintahivatkozásokat az egyes támogatott nyelvek példáihoz.

Az alkalmazás funkciójelzőinek kiértékeléséhez és használatához az alkalmazáskonfigurációs szolgáltatóra és a .NET-ben és a Java Springben elérhető szolgáltatásfelügyeleti kódtárakra van szükség. További információért tekintse meg a Funkciókezelés szakaszt a Rövid útmutatók és oktatóanyagok szakaszban.

Java Spring-profilok használata az Alkalmazáskonfigurációban

A spring-profilok lehetővé teszik az alkalmazás részeinek elkülönítését, beleértve a konfigurációt is, és csak bizonyos környezetekben vagy adott kódtárak használatakor teszik elérhetővé.

Javasoljuk, hogy állítsa be a kulcsértékek címkéjét úgy, hogy megfeleljen a Spring-profiloknak. Alapértelmezés szerint az Alkalmazáskonfiguráció spring szolgáltatói kódtára betölti a kulcsértékeket az aktuális aktív Spring-profil(ok)nak () megfelelő címkével(${spring.profiles.active}ek), ha a címkeszűrő nincs explicit módon beállítva. Ha nincs aktív Spring-profilkészlet, a rendszer betölti a "nincs címke" értékű kulcsértékeket.

Például profilokkal dev , és prodennek megfelelően hozhat létre kulcsértékeket az alábbi címkékkel.

Kulcs Felirat Érték
/application/config.message Dev Hello from dev
/application/config.message döfköd Hello from prod

Ha a Spring-profil értéke deva következő lesz: config.messageHello from dev. Ha a Spring-profil értéke proda következő lesz: config.messageHello from prod.

Ez az alapértelmezett viselkedés felülbírálható a címkeszűrő beállításával a bootstrap-fájlban. A Spring-szolgáltató kódtára az aktív Spring-profiltól függetlenül betölti a kulcsértékeket a megadott címkével(ek) együtt.

spring.cloud.azure.appconfiguration.stores[0].selects[0].label-filter: my-label

Más címkék és a Spring-profil(ok) kiválasztásához használhat egy címkeszűrőt, például ',${spring.profiles.active}', amely kijelöli az összes címkével nem rendelkező és a Spring-profilnak megfelelő kulcsot. A jobb szélső címke(ok) elsőbbséget élveznek az ismétlődő kulcsok megtalálásakor.

Szolgáltatáskezelés engedélyezése Blazor-alkalmazásokban vagy hatókörön belüli szolgáltatásokként a .NET-alkalmazásokban?

A 3.1.0-s verziótól kezdve a Microsoft.FeatureManagement kódtár lehetővé teszi a szolgáltatásfelügyeleti szolgáltatások, köztük a funkciószűrők futtatását hatóköralapú szolgáltatásokként a függőséginjektálási alapú .NET-alkalmazásokban. A funkció előnyeinek kihasználásához egyszerűen cserélje le a AddFeatureManagement kódban AddScopedFeatureManagementlévő hívást a következő kódrészletben látható módon:

services.AddScopedFeatureManagement();

A funkciószűrők egy HTTP-kérés tulajdonságai alapján értékelhetnek ki egy funkciójelzőt. Ezt általában az egyszeri IHttpContextAccessorminta vizsgálatával HttpContext hajtják végre. Ez a minta azonban nem működik a Blazor-kiszolgálóalkalmazások esetében, ahol a hatókörön belüli szolgáltatásokat kell használni. Ebben az esetben a AddScopedFeatureManagement metódust kell használni.

Hogyan kaphatok bejelentéseket az új kiadásokról és az alkalmazáskonfigurációval kapcsolatos egyéb információkról?

Hogyan jelenthetek problémát, vagy adhatok javaslatot?

Közvetlenül a GitHubon érhet el minket.

Következő lépések