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. A kulcsok és címkék száma nincs korlátozva, amíg a teljes méretük nem éri el a tárterületkorlátot.

Ennek a kulcs-érték 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.

A korlátok teljes listájáért tekintse meg az Azure-előfizetések és -szolgáltatások korlátait.

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.

Három tarifacsomag érhető el: Ingyenes, Standard és Prémium. Részletes díjszabási információkért tekintse meg az Alkalmazáskonfiguráció díjszabási oldalát.

Minden 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.

• Cél: Az ingyenes szint tökéletes a szolgáltatás nem éles környezetekben történő értékeléséhez, így díjmentesen felfedezheti funkcióit. A Standard szint a közepes volumenű termelési használati esetekre van szabva, ami a teljesítmény és a költséghatékonyság egyensúlyát biztosítja. A nagy volumenű vagy nagyvállalati szintű termelési igények esetén a Prémium szint a legmagasabb szintű teljesítményt és méretezhetőséget biztosítja, így az alkalmazások nagy terhelés esetén is zökkenőmentesen futnak.

• 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 és a Premium szinteken.

• Erőforrásonkénti tárolás: Az ingyenes szinten minden konfigurációs tárterület legfeljebb 10 MB normál tárterületre és 10 MB pillanatképtárra korlátozódik. A Standard szinten minden konfigurációs tároló legfeljebb 1 GB normál tárterületet és további 1 GB pillanatkép-tárterületet használhat. A Prémium szinten minden konfigurációs tár legfeljebb 4 GB normál tárterületet és további 4 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 ez az előzmények hét napig lesznek tárolva. A Standard és a Premium szinteken ez az előzmény 30 napig van tárolva.

• 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. Az óránkénti kvóta kimerülése után a további kérések az óra végéig egy 429-ben megadott HTTP-állapotkódot adhatnak vissza, amely túl sok kérést jelez. 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.

  A prémium szintű áruházak nem rendelkeznek kvótakorlátokkal a kérelmekre vonatkozóan, biztosítva, hogy az áruházhoz való hozzáférés soha ne legyen letiltva.

• Átviteli sebesség: Az alkalmazáskonfigurációs áruházak minden szinten rendelkeznek átviteli sebességgel. A kedvezményt meghaladó kérelmek 429-ben kapnak HTTP-állapotkódot. Az ingyenes szinten lévő üzletek nem rendelkeznek garantált átviteli sebességgel.

  A Standard szinten lévő tárolók a futtatási arányt teszik lehetővé† másodpercenként legfeljebb 300 kérést (RPS) az olvasási kérelmekhez, és legfeljebb 60 RPS-t az írási kérelmekhez.

  A Prémium szintű tárolók a futtatási arányt teszik lehetővé† olvasási kérelmek esetén legfeljebb 450 RPS, írási kérelmek esetén pedig legfeljebb 100 RPS.

  †A futtatási sebesség általában az alkalmazáskonfigurációs áruház által kezelt kérelmek átlagos száma, amely nem szabályozható egy adott időszakban.

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

• Funkciók: Minden 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 és prémium szintű szintek további funkciókat kínálnak, 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: Ingyenes szintű áruház használata nem jár költséggel.

  A standard szintű áruházak napi használati díjat számolnak fel, amely naponta az első 200 000 kérést tartalmazza. A napi foglaláson túli kérések túlhasználati díjat vonnak maga után.

  A prémium szintű áruházak napi használati díjjal is rendelkeznek, és replikát is tartalmaznak. A forrásra vonatkozó első 800 000 kérelem és a replikára vonatkozó első 800 000 kérelem minden nap a napi díj részét képezi. A napi foglalást meghaladó kérelmek túlhasználati díjat vonnak maga után.

Az Alkalmazáskonfigurációs áruházat bármikor frissítheti, például az ingyenes szintről a Standard vagy a Prémium szintre, vagy a Standard szintről a Prémium szintre.

Az alkalmazáskonfigurációs áruházak nem válthatók le például a Prémium szintről a Standard szintre, illetve a Standard szintről az ingyenes szintre. Létrehozhat azonban egy új tárolót a kívánt 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 három 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 alkalmazáskonfigurációs áruházak különböző kéréskvótákkal rendelkeznek a szintjük alapján. Az ingyenes szintű áruházak legfeljebb napi 1000 kérést, a standard szintű áruházakat óránként 30 000 kérésre, a prémium szintű áruházak pedig nem rendelkeznek kérelemkorlátokkal, biztosítva a folyamatos hozzáférést.

Az alkalmazáskonfigurációs áruházak a szintjük alapján rendelkeznek átviteli sebességgel. Az ingyenes szintű áruházak nem rendelkeznek garantált átviteli sebességgel. A standard szintű tárolók másodpercenként legfeljebb 300 kérelem (RPS) futtatását támogatják olvasási műveletekhez, írási műveletek esetén pedig legfeljebb 60 RPS-et. A prémium szintű tárolók legfeljebb 450 RPS-et támogatnak olvasási műveletekhez, írási műveletek esetén pedig legfeljebb 100 RPS-et.

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 egy kérést küld a sentinel kulcsra 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érések gyakoriak és többnyire változatlanok, a legtöbbjük nem számít bele az áruház óránkénti kvótakorlátjaiba† standard szintű tárolók esetében.

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 10 (=1000/100) kérés szükséges az összes beállítás betöltéséhez. 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 standard szintű tárolókhoz rendelkezésre álló óránkénti kvótát. Frissítse a példában szereplő számokat úgy, hogy azok megfeleljenek az adott beállításnak és kialakításnak, így elegendő pufferrel rendelkezik az óránkénti kvótakorláthoz.

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

Az alkalmazás a következő körülmények között 429-ben kaphat HTTP-állapotkódot:

• Az ingyenes szinten lévő áruház napi kéréskvóta túllépése.
• Túllépi az óránkénti kérelemkvótát egy standard szintű tárolóhoz.
• Bármely szinten túllépi az áruház átviteli sebességét.
• Bármely szinten túllépi egy áruház sávszélesség-keretét.
• Kulcsérték 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. Az Alkalmazáskonfigurációs áruház naplóit az Azure Monitorban is gyűjtheti, és riasztásokat állíthat be a kérelemkvóta-használati metrikához.

A pillanatnyi HTTP-állapotkód 429-ben történő fogadása általában nem okoz kárt, mivel az alkalmazáskonfigurációs ügyfelek kecsesen kezelik őket. Ha azonban az alkalmazás rendszeresen 429-ben kapott HTTP-állapotkódot tapasztal, vegye figyelembe a következő lehetőségeket:

• Frissítse az áruházat a prémium szintre: Ez a szint nem korlátozza a kérelmek kvótakorlátját, és megnövelte a tárterületkvótát és a nagyobb átviteli sebességet.
• Alkalmazáskonfigurációs szolgáltatók használata: A szolgáltatók beépített újrapróbálkozási és gyorsítótárazási képességekkel, valamint számos más rugalmassági funkcióval rendelkeznek. Mindenképpen frissítsen a szolgáltató legújabb verziójára az összes legújabb fejlesztéshez.
• Alkalmazáskonfigurációs SDK-k használata, ha az alkalmazásnak írási kéréseket kell küldenie. Bár az SDK-k nem olyan funkciókban gazdagok, mint a szolgáltatók, automatikusan újrapróbálkoznak a HTTP-állapotkód 429-re adott válaszaival és egyéb átmeneti hibáival.
• Ha nem tudja használni az alkalmazáskonfigurációs szolgáltatókat vagy SDK-kat, próbálkozzon újra az egyéni ügyfelekkel . A retry-after-ms válasz fejléce javasolt várakozási időt (ezredmásodpercben) biztosít a kérés újrapróbálkozása előtt.
• Kérelmek elosztása több ügyfélpéldány között: Ez segít elérni az Alkalmazáskonfigurációs áruház maximális átviteli sebességét.
• Az alkalmazáskonfigurációra irányuló kérések csökkentése: Kövesse az útmutatást a kérések számának minimalizálásához.
• Az alkalmazás rugalmasságának javítása: Fontolja meg a georeplikáció integrálását a feladatátvétel és a terheléselosztás engedélyezéséhez. Tekintse meg a rendkívül rugalmas alkalmazások készítésének ajánlott eljárásait.

A Standard és a Prémium szintű alkalmazáskonfigurációs áruházak automatikusan engedélyezték a helyreállítható törlés funkciót. Egy standard vagy prémium 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 és a Prémium szintű alkalmazáskonfigurációs áruházak támogatják 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) () címkéivel,${spring.profiles.active} 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.message Hello from dev. Ha a Spring-profil értéke proda következő lesz: config.message Hello 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 megadott címkével(ek)et tartalmazó kulcsértékeket.

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 IHttpContextAccessor minta 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