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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Iratkozzon fel a GitHub-közlemények adattárára.

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

• Tudnivalók a Azure-alkalmazás konfigurációjáról