Megosztás:

Alapszintű webalkalmazás

Azure App Service
Azure Monitor
Azure SQL Database

Ez a cikk egy egyszerű architektúrát tartalmaz, amely a webalkalmazások Azure-alkalmazás szolgáltatásban való futtatásának megismerésére szolgál egyetlen régióban.

Fontos

Ez az architektúra nem éles alkalmazásokhoz használható. Ez egy bevezető architektúra, amelyet a tanulás és a koncepció igazolása (POC) céljából használhat. Az éles Azure-alkalmazás szolgáltatásalkalmazás tervezésekor tekintse meg az Alapterv magas rendelkezésre állású zónaredundáns webalkalmazást.

Fontos

GitHub-embléma Az útmutatót egy példa implementáció is alátámasztja, amely bemutatja ezt az alapszintű App Service-implementációt az Azure-ban. Ez az implementáció a POC alapjaként használható a Azure-alkalmazás Szolgáltatással való munkához.

Architektúra

Egy alapszintű App Service-architektúrát bemutató diagram.

1. ábra: Alapszintű Azure-alkalmazás szolgáltatásarchitektúra

Töltse le az architektúra Visio-fájlját.

Workflow

  1. A felhasználó HTTPS-kérést küld az App Service alapértelmezett tartományának.azurewebsites.net Ez a tartomány automatikusan az App Service beépített nyilvános IP-címére mutat. A TLS-kapcsolat közvetlenül az ügyfél és az App Service között jön létre. A tanúsítványt az Azure teljes mértékben felügyeli.
  2. Az Easy Auth, a Azure-alkalmazás szolgáltatás egyik funkciója biztosítja, hogy a webhelyet elérő felhasználó a Microsoft Entra-azonosítóval legyen hitelesítve.
  3. Az App Service-ben üzembe helyezett alkalmazáskód kezeli a kérést. Előfordulhat például, hogy a kód egy Azure SQL Database-példányhoz csatlakozik egy alkalmazásbeállításként konfigurált App Service-ben konfigurált kapcsolati sztring használatával.
  4. Az App Service-nek küldött eredeti kéréssel és az Azure SQL Database hívásával kapcsolatos információk az Application Insightsban lesznek naplózva.

Összetevők

  • A Microsoft Entra ID egy felhőalapú identitás- és hozzáférés-kezelési szolgáltatás, amely hitelesítési és engedélyezési képességeket biztosít. Ebben az architektúrában az App Service-vel az Easy Auth használatával integrálva biztosítja a webalkalmazáshoz hozzáférő felhasználók hitelesítését. Ez leegyszerűsíti a hitelesítési folyamatot anélkül, hogy jelentős kódmódosításokat kellene végrehajtania.
  • Az App Service egy felügyelt platform webalkalmazások létrehozására, üzembe helyezésére és skálázására. Ebben az architektúrában üzemelteti a webalkalmazás kódját, kezeli az alapértelmezett azurewebsites.net tartomány HTTPS-kéréseit, és konfigurált kapcsolati sztringeken keresztül csatlakozik az Azure SQL Database-hez.
  • Az Azure Monitor egy monitorozási szolgáltatás, amely felhőbeli és helyszíni környezetekből származó telemetriai adatokat gyűjt, elemez és használ. Ebben az architektúrában az App Service-nek küldött kérelmekről és az SQL Database-hez intézett hívásokról az Application Insights-integráción keresztül rögzíti és tárolja az információkat.
  • Az SQL Database egy felügyelt relációsadatbázis-szolgáltatás, amely SQL Server-képességeket biztosít a felhőben. Ebben az architektúrában az App Service-alkalmazás által az alkalmazásbeállításokként konfigurált kapcsolati sztringeken keresztül csatlakozik adattárolási rétegként.

Megfontolások

Ezek a szempontok implementálják az Azure Well-Architected Framework alappilléreit, amely a számítási feladatok minőségének javítására használható vezérelvek halmaza. További információ: Microsoft Azure Well-Architected Framework.

Az ebben az architektúrában felsorolt összetevők az Azure Well-Architected szolgáltatás útmutatóira hivatkoznak. A szolgáltatás útmutatói részletesen ismertetik az adott szolgáltatásokra vonatkozó javaslatokat és szempontokat. Ez a szakasz kiterjeszti ezt az útmutatást az Azure Well-Architected Framework főbb ajánlásainak és szempontjainak kiemelésével, amelyek az architektúrára vonatkoznak. További információ: Microsoft Azure Well-Architected Framework.

Ez az alapvető architektúra nem éles környezetekhez készült. Az architektúra az egyszerűséget és a költséghatékonyságot részesíti előnyben a funkciókkal szemben, így kiértékelheti és megismerheti Azure-alkalmazás szolgáltatást. Az alábbi szakaszok az alapvető architektúra néhány hiányosságát, valamint a javaslatokat és szempontokat ismertetik.

Megbízhatóság

A megbízhatóság biztosítja, hogy az alkalmazás megfeleljen az ügyfelek felé vállalt kötelezettségeknek. További információkért tekintse meg a Megbízhatósági terv felülvizsgálati ellenőrzőlistát.

Mivel ez az architektúra nem éles üzemelő példányokhoz készült, az alábbi ábra az architektúra által kihagyott kritikus megbízhatósági funkciókat ismerteti:

  • Az App Service-csomag a szinthez van konfigurálva, amely nem támogatja az Standard Azure rendelkezésre állási zónáját. Az App Service elérhetetlenné válik a példány, az állvány vagy a példányt üzemeltető adatközpont bármilyen problémája esetén.
  • Az Azure SQL Database a réteghez van konfigurálva, amely nem támogatja a Basic zónaredundanciát. Ez azt jelenti, hogy az adatok nem replikálódnak az Azure rendelkezésre állási zónáiban, így megszakadás esetén a véglegesített adatok elvesznek.
  • Az architektúra üzemelő példányai állásidőt eredményezhetnek az alkalmazástelepítések esetében, mivel a legtöbb üzembehelyezési technika megköveteli az összes futó példány újraindítását. A felhasználók 503-at tapasztalhatnak a folyamat során. Ez az üzembe helyezési állásidő az alaparchitektúra üzembehelyezési pontokon keresztül. Az egyidejű ponttelepítés támogatásához gondos alkalmazástervezésre, sémakezelésre és alkalmazáskonfiguráció-kezelésre van szükség. Ezzel a POC-sel megtervezheti és érvényesítheti a pontalapú éles üzembe helyezési megközelítést.
  • Ebben az alapszintű architektúrában az automatikus skálázás nincs engedélyezve. A rendelkezésre álló számítási erőforrások hiánya miatti megbízhatósági problémák elkerülése érdekében túlterjeszkednie kell ahhoz, hogy mindig elegendő számítási kapacitással fusson a maximális egyidejű kapacitás kezeléséhez.

Az Alapkonfiguráció magas rendelkezésre állású zónaredundáns webalkalmazás megbízhatósági szakaszában megtudhatja, hogyan háríthatja el ezeket a megbízhatósági problémákat.

Ha ez a számítási feladat végül többrégiós aktív-aktív vagy aktív-passzív architektúrát igényel, tekintse meg a következő erőforrást:

Biztonság

A biztonság biztosítékokat nyújt a szándékos támadások és az értékes adatokkal és rendszerekkel való visszaélés ellen. További információkért lásd a Biztonsági terv felülvizsgálati ellenőrzőlistát.

Mivel ez az architektúra nem éles környezetekhez lett tervezve, az alábbi ábra az architektúra által kihagyott kritikus biztonsági funkciókat, valamint egyéb megbízhatósági javaslatokat és szempontokat vázol fel:

  • Ez az alapvető architektúra nem valósítja meg a hálózati adatvédelmet. Az erőforrások, például a Azure-alkalmazás szolgáltatás és az Azure SQL Server adat- és felügyeleti síkjai a nyilvános interneten keresztül érhetők el. A privát hálózatkezelés kihagyása jelentősen növeli az architektúra támadási felületét. Ha meg szeretné tudni, hogyan biztosítja a privát hálózatkezelés a következő biztonsági funkciókat, tekintse meg az Alapterv magas rendelkezésre állású zónaredundáns webalkalmazás hálózatkezelési szakaszát:

    • Egyetlen biztonságos belépési pont az ügyfélforgalomhoz
    • A hálózati forgalom a csomag szintjén és a DDoS szintjén is szűrve van.
    • Az adatkiszivárgás minimalizálható az Azure-ban a Private Link használatával történő forgalom megtartásával
    • A hálózati erőforrások logikailag vannak csoportosítva és elkülönítve egymástól a hálózat szegmentálásán keresztül.

  • Ez az alapvető architektúra nem tartalmazza az Azure Web Application Firewall üzembe helyezését. A webalkalmazás nem védett a gyakori biztonsági résekkel és biztonsági résekkel szemben. Tekintse meg az alapkonfigurációt, amelyből megtudhatja, hogyan implementálható a webalkalmazási tűzfal Azure-alkalmazás Átjáróval egy Azure-alkalmazás Services-architektúrában.

  • Ez az alapvető architektúra olyan titkos kulcsokat tárol, mint például az Azure SQL Server kapcsolati sztring az Alkalmazásbeállításokban. Amíg az alkalmazásbeállítások titkosítva vannak, éles környezetbe való áttéréskor érdemes lehet titkos kulcsokat tárolni az Azure Key Vaultban a nagyobb szabályozás érdekében. Még jobb megoldás, ha felügyelt identitást használ a hitelesítéshez, és nem tárol titkos kulcsokat a kapcsolati sztring.

  • A távoli hibakeresés és a Kudu-végpontok engedélyezése a fejlesztés során vagy a megvalósíthatósági fázis igazolása rendben van. Amikor éles környezetbe lép, le kell tiltania a szükségtelen vezérlősíkot, üzembe helyezést vagy távelérést.

  • Az FTP- és SCM-helytelepítések helyi hitelesítési módszereinek engedélyezése a fejlesztési vagy a megvalósíthatósági fázisban is rendben van. Amikor éles környezetbe lép, le kell tiltania a helyi hitelesítést ezeken a végpontokon.

  • Nem kell engedélyeznie a Microsoft Defender for App Service-t a megvalósíthatósági vizsgálat fázisában. Éles környezetbe való áttéréskor engedélyeznie kell a Defender for App Service-t, hogy biztonsági javaslatokat hozzon létre, amelyek a biztonsági helyzet növeléséhez és az App Service-t fenyegető fenyegetések észleléséhez implementálandóak.

  • Azure-alkalmazás szolgáltatás tartalmaz egy SSL-végpontot egy altartományonazurewebsites.net, külön költség nélkül. A HTTP-kérések alapértelmezés szerint a HTTPS-végpontra lesznek átirányítva. Éles üzemelő példányok esetén általában az App Service üzembe helyezése előtt az Application Gatewayhez vagy AZ API-kezeléshez társított egyéni tartományt kell használnia.

  • Használja az App Service ("EasyAuth") integrált hitelesítési mechanizmusát. Az EasyAuth leegyszerűsíti az identitásszolgáltatók webalkalmazásba való integrálásának folyamatát. A webalkalmazáson kívüli hitelesítést kezeli, így nem kell jelentős kódmódosításokat végrehajtania.

  • Felügyelt identitás használata számítási feladatok identitásaihoz. A felügyelt identitás szükségtelenné teszi a fejlesztők számára a hitelesítési hitelesítő adatok kezelését. Az alapvető architektúra jelszóval hitelesíti az SQL Servert egy kapcsolati sztring. Fontolja meg a felügyelt identitás használatát az Azure SQL Serveren való hitelesítéshez.

További biztonsági szempontokat az alkalmazás biztonságossá tételét Azure-alkalmazás Service-ben című témakörben talál.

Költségoptimalizálás

A költségoptimalizálás a szükségtelen kiadások csökkentésének és a működési hatékonyság javításának módjairól szól. További információ: Költségoptimalizálásitervezési felülvizsgálati ellenőrzőlistája.

Ez az architektúra a Well-Architected-keretrendszer egyéb pilléreivel való számos kompromisszum révén optimalizálja a költségeket, különösen az architektúra tanulási és megvalósíthatósági céljainak megfelelően. A költségmegtakarítás egy éles üzemre kész architektúrához képest, például a Alapkonfigurációban magas rendelkezésre állású zónaredundáns webalkalmazás, főként az alábbi lehetőségekből származik.

  • Egyetlen App Service-példány, automatikus skálázás engedélyezése nélkül
  • Standard tarifacsomag az Azure App Service-hez
  • Nincs egyéni TLS-tanúsítvány vagy statikus IP-cím
  • Nincs webalkalmazási tűzfal (WAF)
  • Nincs dedikált tárfiók az alkalmazás üzembe helyezéséhez
  • Alapszintű tarifacsomag az Azure SQL Database-hez biztonsági mentési megőrzési szabályzatok nélkül
  • Nincs Microsoft Defender for Cloud-összetevő
  • Nincs hálózati forgalomforgalom-vezérlés tűzfalon keresztül
  • Nincsenek privát végpontok
  • Minimális naplók és naplómegőrzési időszak a Log Analyticsben

Az architektúra becsült költségének megtekintéséhez tekintse meg a díjkalkulátor becslését az architektúra összetevőinek használatával. Az architektúra költsége általában tovább csökkenthető egy Azure Dev/Test-előfizetéshasználatával, amely ideális előfizetési típus az ilyen fogalmak igazolásához.

Működési kiválóság

Az Operational Excellence azokat az üzemeltetési folyamatokat fedi le, amelyek üzembe helyeznek egy alkalmazást, és éles környezetben tartják azt. További információ: Az operatív kiválóság tervezési felülvizsgálati ellenőrzőlistája.

Az alábbi szakaszok útmutatást nyújtanak az App Service-alkalmazás konfigurálásának, monitorozásának és üzembe helyezésének.

Alkalmazáskonfigurációk

Mivel az alaparchitektúra nem éles környezetben készült, az App Service-konfigurációval tárolja a konfigurációs értékeket és titkos kulcsokat. A titkos kódok tárolása az App Service-konfigurációban a PoC-fázishoz megfelelő. Nem használ valódi titkos kulcsokat, és nem követeli meg az éles számítási feladatok által megkövetelt titkos kulcsok szabályozását.

A konfigurációs javaslatok és szempontok a következők:

  • Első lépésként használja az App Service-konfigurációt a konfigurációs értékek és kapcsolati sztring tárolására a koncepciótelepítések igazolása során. Az alkalmazásbeállítások és kapcsolati sztring titkosítása és visszafejtése még azelőtt történik, hogy az alkalmazásba injektálva lenne az indításkor.
  • Amikor éles fázisba lép, a titkos kulcsokat az Azure Key Vaultban tárolhatja. Az Azure Key Vault használata kétféleképpen javítja a titkos kódok szabályozását:
    • A titkos kulcsok Azure Key Vaultba való kihelyezésével központosíthatja a titkos kulcsok tárolását. Van egy hely, ahol titkos kulcsokat kezelhet.
    • Az Azure Key Vault használatával naplózhatja a titkos kódokkal folytatott minden interakciót, beleértve a titkos kulcsok elérésének minden egyes időpontját is.
  • Az éles környezetbe való áttéréskor a Key Vault-hivatkozások használatával fenntarthatja az Azure Key Vault és az App Service konfigurációját is.

Containers

Az alaparchitektúra használható a támogatott kód központi telepítéséhez közvetlenül Windows vagy Linux-példányokon. Alternatív megoldásként az App Service egy tároló-üzemeltetési platform is a tárolóalapú webalkalmazás futtatásához. Az App Service különböző beépített tárolókat kínál. Ha egyéni vagy többtárolós alkalmazásokat használ a futtatókörnyezet további finomhangolásához, vagy egy natívan nem támogatott kódnyelv támogatásához, be kell vezetnie egy tárolóregisztrációs adatbázist.

Vezérlősík

A POC-fázis során kényelmesen megismerkedhet Azure-alkalmazás szolgáltatás vezérlősíkjával a Kudu szolgáltatáson keresztül. Ez a szolgáltatás általános üzembehelyezési API-kat tesz elérhetővé, például ZIP-telepítéseket, nyers naplókat és környezeti változókat tesz elérhetővé.

Tárolók használata esetén mindenképpen ismerje meg, hogy a Kudu képes-e SSH-munkamenetet megnyitni egy tárolón a speciális hibakeresési képességek támogatásához.

Diagnosztika és figyelés

A megvalósíthatósági fázis során fontos tisztában lenni azzal, hogy milyen naplók és metrikák rögzíthetők. Az alábbiakban javaslatokat és szempontokat javaslatokat és szempontokat kell figyelembe venni a koncepció igazolási fázisában történő monitorozáshoz:

  • A diagnosztikai naplózás engedélyezése az összes elemnapló-forráshoz. Az összes diagnosztikai beállítás használatának konfigurálásával megértheti, hogy milyen naplók és metrikák vannak megadva a dobozon kívül, valamint azokat a hiányosságokat, amelyeket be kell zárnia egy naplózási keretrendszer használatával az alkalmazáskódban. Az éles környezetbe való áttéréskor meg kell szüntetnie azokat a naplóforrásokat, amelyek nem adnak hozzá értéket, és zajt és költséget adnak hozzá a számítási feladat naplófájl-fogadójához.
  • A naplózás konfigurálása az Azure Log Analytics használatára. Az Azure Log Analytics skálázható platformot biztosít a naplózás központosításához, amely könnyen lekérdezhető.
  • Az Application Insights vagy egy másik Alkalmazásteljesítmény-kezelési (APM) eszközzel telemetriát és naplókat bocsáthat ki az alkalmazás teljesítményének figyeléséhez.

Telepítés

Az alábbi lista útmutatást nyújt az App Service-alkalmazás üzembe helyezéséhez.

  • Az alkalmazás üzembe helyezésének automatizálásához kövesse a CI/CD for Azure Web Apps és az Azure Pipelines útmutatását. Kezdje el az üzembehelyezési logika kiépítését a PoC-fázisban. A CI/CD implementálása a fejlesztési folyamat korai szakaszában lehetővé teszi, hogy gyorsan és biztonságosan iterálja az alkalmazást az éles környezet felé haladva.
  • Arm-sablonok használatával üzembe helyezheti az Azure-erőforrásokat és azok függőségeit. Fontos, hogy ezt a folyamatot a PoC fázisban indítsa el. Az éles környezet felé haladva szeretné automatikusan üzembe helyezni az infrastruktúrát.
  • Használjon különböző ARM-sablonokat, és integrálja őket az Azure DevOps-szolgáltatásokkal. Ezzel a beállítással különböző környezeteket hozhat létre. Az éles környezetekhez hasonló forgatókönyveket vagy terheléstesztelési környezeteket például csak szükség esetén replikálhatja, és költségmegtakarítást érhet el.

További információt az Azure Well-Architected Framework DevOps szakaszában talál.

Teljesítményhatékonyság

A teljesítményhatékonyság az a képesség, hogy a számítási feladat hatékonyan kielégítse a felhasználók által támasztott igényeket. További információt a Teljesítményhatékonyság tervezési felülvizsgálati ellenőrzőlistájában talál.

Mivel ez az architektúra nem éles környezetekhez készült, az alábbi ábra az architektúra által kihagyott kritikus teljesítményhatékonysági funkciókat, valamint egyéb javaslatokat és szempontokat vázol fel.

A koncepció igazolásának olyan termékváltozat-kiválasztásnak kell lennie, amely a számítási feladathoz megfelelő. A számítási feladatot úgy kell megtervezni, hogy horizontális skálázással hatékonyan kielégítse az igényeket az App Service-csomagban üzembe helyezett számítási példányok számának módosításával. Ne tervezzen úgy a rendszert, hogy a számítási termékváltozatot az igényeknek megfelelően módosítsa.

  • Ebben az alaparchitektúrában az App Service nem rendelkezik automatikus skálázással. A szolgáltatás nem skálázható fel dinamikusan, és nem igazodik hatékonyan az igényekhez.
    • A Standard szint támogatja az automatikus méretezési beállításokat , hogy lehetővé tegye a szabályalapú automatikus skálázás konfigurálását. A POC-folyamat részeként hatékony automatikus skálázási beállításokat kell létrehoznia az alkalmazáskód erőforrásigénye és a várt használati jellemzők alapján.
    • Éles környezetekben vegye figyelembe az automatikus skálázást támogató prémium szintű csomagokat, ahol a platform automatikusan kezeli a skálázási döntéseket.
  • Kövesse az útmutatást az egyes adatbázisok alkalmazás-állásidő nélküli vertikális felskálázásához, ha magasabb szolgáltatási szintre vagy teljesítményszintre van szüksége az SQL Database-hez.

A forgatókönyv üzembe helyezése

Az útmutatót egy példa implementáció is alátámasztja, amely egy alapszintű App Service-implementációt mutat be az Azure-ban.

Következő lépések

Alapkonfiguráció magas rendelkezésre állású zónaredundáns webalkalmazás

Termékdokumentáció:

Microsoft Learn-modulok: