Vállalati üzembe helyezés Azure-alkalmazás service environment használatával

Ez a referenciaarchitektúra egy általános vállalati számítási feladatot mutat be, amely az App Service Environment 3. verzióját használja. Emellett ismerteti a számítási feladatok biztonságának megerősítésére vonatkozó ajánlott eljárásokat is.

Az architektúra referencia-implementációja elérhető a GitHubon.

Architektúra

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

Munkafolyamat

Az App Service Environment kétféleképpen telepíthető:

• Külső App Service-környezetként nyilvános IP-címmel
• Belső App Service-környezetként a belső terheléselosztóhoz (ILB) tartozó belső IP-címmel

Ez a referenciaarchitektúra egy vállalati webalkalmazást helyez üzembe egy belső App Service-környezetben, más néven ILB App Service-környezetben. Használjon ILB App Service-környezetet, ha a forgatókönyv megköveteli a következőket:

• A felhőben fokozott biztonságot biztosító intranetes alkalmazásokat üzemeltethet, és helyek közötti VPN-en vagy Azure ExpressRoute-on keresztül érheti el őket.
• Biztosítson egy védelmi réteget az alkalmazások számára egy webalkalmazási tűzfal (WAF) használatával.
• A nyilvános DNS-kiszolgálókon nem szereplő alkalmazásokat üzemeltethet a felhőben.
• Internetkapcsolattal rendelkező háttéralkalmazásokat hozhat létre, amelyekkel az előtérbeli alkalmazások rendkívül biztonságos módon integrálhatók.

Az App Service-környezetet mindig a vállalati virtuális hálózat saját alhálózatán kell üzembe helyezni, hogy a bejövő és kimenő forgalom szigorúan szabályozható legyen. Ebben az alhálózatban az App Service-alkalmazások egy vagy több App Service-csomagban vannak üzembe helyezve, amely az alkalmazás futtatásához szükséges fizikai erőforrások gyűjteménye. Az összetettségtől és az erőforrásigénytől függően az App Service-csomag több alkalmazás között is megosztható. Ez a referencia-implementáció egy Voting App nevű webalkalmazást helyez üzembe, amely egy privát webes API-val és egy függvénnyel működik együtt. Emellett egy Tesztalkalmazás nevű, próbaalapú webalkalmazást is üzembe helyez, amely bemutatja a többalkalmazásos üzembe helyezéseket. Minden App Service-alkalmazás saját App Service-csomagban van üzemeltetve, így szükség esetén egymástól függetlenül skálázhatók. A üzemeltetett alkalmazásokhoz szükséges összes erőforrást, például a tárolást és a számítást, valamint a skálázási igényeket teljes mértékben az App Service Environment-infrastruktúra felügyeli.

A megvalósítás egyszerű szavazóalkalmazásával a felhasználók megtekinthetik a meglévő bejegyzéseket, új bejegyzéseket hozhatnak létre, és szavazhatnak a meglévő bejegyzésekre. A webes API-t bejegyzések és szavazatok létrehozására és lekérésére használják. Maga az adatok egy SQL Server-adatbázisban tárolódnak. Az aszinkron adatfrissítések bemutatásához a webalkalmazás az újonnan hozzáadott szavazatokat egy Service Bus-példányban várólistára állítja. A függvény felveszi a várólistára helyezett szavazatokat, és frissíti az SQL-adatbázist. Az Azure Cosmos DB egy makett-hirdetés tárolására szolgál, amelyet a webalkalmazás a böngészőben való megjelenítéshez kér le. Az alkalmazás az Azure Cache for Redist használja a gyorsítótár-kezeléshez. A rendszer prémium szintű Azure Cache for Redis-t használ, amely lehetővé teszi a konfigurációt ugyanazon a virtuális hálózaton, mint az App Service Environment, saját alhálózatán. Ez fokozott biztonságot és elkülönítést biztosít a gyorsítótár számára.

Csak a webalkalmazások érhetők el az internethez az Application Gatewayen keresztül. Az API és a függvény nem érhető el egy internetes ügyfélprogramból. A bejövő forgalmat az Application Gatewayen konfigurált WAF védi.

Összetevők

Az alábbi szolgáltatások kulcsfontosságúak az App Service-környezet zárolásához ebben az architektúrában:

• Az Azure Virtual Network egy privát Azure-felhőhálózat, amely egy vállalat tulajdonában van. Fokozott hálózati biztonságot és elkülönítést biztosít. Az App Service Environment egy App Service-telepítés a vállalati tulajdonú virtuális hálózat alhálózatán. Lehetővé teszi a vállalat számára, hogy szigorúan szabályozza a hálózati területet és az általa elért erőforrásokat hálózati biztonsági csoportok és privát végpontok használatával.

• Az Application Gateway egy alkalmazásszintű webes forgalom terheléselosztója TLS/SSL-kiszervezéssel és WAF-sel. Figyeli a nyilvános IP-címet, és átirányítja a forgalmat az alkalmazásvégpontra az ILB App Service-környezetben. Mivel ez alkalmazásszintű útválasztás, több alkalmazáshoz is irányíthatja a forgalmat ugyanabban az ILB App Service-környezetben. További információ: Application Gateway multiple site hosting.

• Az Azure Firewall a webalkalmazás kimenő forgalmának korlátozására szolgál. A kimenő forgalom, amely nem halad át a privát végpontcsatornákon, és az App Service Environment által megkövetelt útvonaltáblát a tűzfal alhálózatára irányítja a rendszer. Az egyszerűség kedvéért ez az architektúra a szolgáltatások alhálózatán konfigurálja az összes privát végpontot.

• A Microsoft Entra ID vagy a Microsoft Entra ID hozzáférési jogosultságokat és engedélyeket biztosít az Azure-erőforrásokhoz és -szolgáltatásokhoz. A felügyelt identitások a Microsoft Entra ID által automatikusan felügyelt szolgáltatásokhoz és alkalmazásokhoz rendelik az identitásokat. Ezek az identitások a Microsoft Entra hitelesítést támogató szolgáltatások hitelesítésére használhatók. Így nem szükséges explicit módon konfigurálni a hitelesítő adatokat ezekhez az alkalmazásokhoz. Ez az architektúra hozzárendel egy felügyelt identitást a webalkalmazáshoz.

• Az Azure Key Vault tárolja az alkalmazások által igényelt titkos kulcsokat és hitelesítő adatokat. Ezzel a beállítással közvetlenül az alkalmazásban tárolhatja a titkos kulcsokat.

• A GitHub Actions folyamatos integrációs és folyamatos üzembe helyezési képességeket biztosít ebben az architektúrában. Mivel az App Service-környezet a virtuális hálózatban található, a virtuális hálózaton belül egy virtuális gépet használnak jumpboxként, hogy alkalmazásokat telepítsenek az App Service-csomagokban. A művelet létrehozza az alkalmazásokat a virtuális hálózaton kívül. A fokozott biztonság és a zökkenőmentes RDP/SSH-kapcsolat érdekében fontolja meg az Azure Bastion használatát a jumpboxhoz.

Többhelyes konfiguráció

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

A belső App Service-környezet számos webalkalmazást és API-t üzemeltethet HTTP-végpontokkal. Ezek az alkalmazások le vannak zárva a nyilvános internetről, mivel az ILB IP-cím csak a virtuális hálózatról érhető el. Az Application Gateway használatával szelektíven teheti elérhetővé ezeket az alkalmazásokat az interneten. Az App Service-környezet minden App Service-alkalmazáshoz hozzárendel egy alapértelmezett URL-címet.<default-appName>.<app-service-environment-domain>.appserviceenvironment.net Létrejön egy privát DNS-zóna , amely leképozza az App Service Environment tartománynevét az App Service Environment ILB IP-címére. Így elkerülhető, hogy egyéni DNS-t használjon a virtuális hálózaton belüli alkalmazások eléréséhez.

Az Application Gateway úgy van konfigurálva, hogy a figyelő a HTTPS-porton figyeli az átjáró IP-címére irányuló kérelmeket. Az egyszerűség kedvéért ez a megvalósítás nem használ nyilvános DNS-névregisztrációt. Ehhez módosítania kell a localhost fájlt a számítógépen, hogy egy tetszőlegesen kiválasztott URL-címet mutasson az Application Gateway IP-címére. Az egyszerűség kedvéért a figyelő önaláírt tanúsítványt használ a kérések feldolgozásához. Az Application Gateway háttérkészletekkel rendelkezik az egyes App Service-alkalmazások alapértelmezett URL-címéhez. Az útválasztási szabály úgy van konfigurálva, hogy a figyelőt a háttérkészlethez csatlakoztassa. HTTP-beállítások jönnek létre, amelyek meghatározzák, hogy az átjáró és az App Service-környezet közötti kapcsolat titkosítva lesz-e. Ezekkel a beállításokkal felülbírálhatja a bejövő HTTP-gazdagépfejlécet a háttérkészletből kiválasztott gazdagépnévvel. Ez az implementáció az alapértelmezett App Service Environment alkalmazás URL-címekhez létrehozott alapértelmezett tanúsítványokat használja, amelyeket az átjáró megbízhatónak minősít. A rendszer átirányítja a kérést a megfelelő alkalmazás alapértelmezett URL-címére. A virtuális hálózathoz társított privát DNS továbbítja ezt a kérést az ILB IP-címre. Az App Service Environment ezután továbbítja ezt a kért app service-nek. Az App Service Environment-alkalmazásokon belüli HTTP-kommunikáció a privát DNS-t használja. Vegye figyelembe, hogy a figyelőt, a háttérkészletet, az útválasztási szabályt és a HTTP-beállításokat az alkalmazásátjárón kell konfigurálni minden App Service Environment-alkalmazáshoz.

Tekintse át az appgw.bicep és a dns.bicep webhelyet, és ismerje meg, hogyan készülnek ezek a konfigurációk több webhely engedélyezéséhez. A névvel ellátott testapp webalkalmazás egy üres alkalmazás, amely ezt a konfigurációt szemlélteti. Ezek a JSON-fájlok a commands_std.azcli üzembehelyezési szkriptből érhetők el. Ezekhez a commands_ha.azcli is hozzáfér, amely magas rendelkezésre állású többhelyes App Service-környezet üzembe helyezéséhez használatos.

Forgatókönyv részletei

A Azure-alkalmazás Szolgáltatás egy PaaS-szolgáltatás, amellyel különféle alkalmazásokat üzemeltethet az Azure-ban: webalkalmazásokat, API-alkalmazásokat, függvényeket és mobilalkalmazásokat. Az App Service Environment lehetővé teszi a vállalatok számára, hogy app Service-alkalmazásaikat egy alhálózaton helyezzék üzembe a saját Azure-beli virtuális hálózatukban, elkülönített, nagy mértékben skálázható és dedikált környezetet biztosítva a felhőbeli számítási feladataikhoz.

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.

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ó: A biztonsági pillér áttekintése.

App Service Environment

Egy belső App Service-környezet van üzembe helyezve a vállalati virtuális hálózaton, elrejtve a nyilvános internet elől. Lehetővé teszi a vállalat számára, hogy hálózati szinten zárolja a háttérszolgáltatásait, például a webes API-kat és függvényeket. Bármely HTTP-végponttal rendelkező App Service Environment-alkalmazás elérhető az ILB-ben, a virtuális hálózaton belülről. Az Application Gateway úgy van konfigurálva, hogy a kérelmeket az ILB-ben keresztül továbbítsa a webalkalmazásnak. Maga a webalkalmazás az ILB-ben keresztül éri el az API-t. A kritikus háttérösszetevők, vagyis az API és a függvény gyakorlatilag elérhetetlenek a nyilvános internetről.

Az app service-környezet által hozzárendelt alapértelmezett tartománynévhez az egyes app service-szolgáltatások alapértelmezett tanúsítványai jönnek létre. Ez a tanúsítvány megszigoríthatja az átjáró és az alkalmazás közötti forgalom biztonságát, és bizonyos esetekben szükség lehet erre. Ezek a tanúsítványok nem láthatók az ügyfélböngészőn keresztül. Csak az Application Gatewayen konfigurált tanúsítványokra tud válaszolni.

Alkalmazási átjáró

A TLS megszüntetésének és végpontok közötti TLS-nek az Application Gateway használatával történő áttekintésében leírtak szerint az Application Gateway a Transport Layer Security (TLS)/Secure Sockets Layer (SSL) használatával titkosíthatja és védheti a webböngészőktől érkező összes forgalmat. A titkosítás a következő módokon konfigurálható:

• A titkosítás leállt az átjárónál. Ebben az esetben a háttérkészletek HTTP-hez vannak konfigurálva. A titkosítás leáll az átjárónál, és az átjáró és az app service közötti forgalom titkosítatlan. Mivel a titkosítás processzorigényes, a háttérrendszer titkosítatlan forgalma javítja a teljesítményt, és egyszerűbb tanúsítványkezelést tesz lehetővé. Ez ésszerű biztonsági szintet biztosít, mivel a háttérrendszert a hálózati konfiguráció biztosítja.

• Végpontok közötti titkosítás. Bizonyos esetekben, például bizonyos biztonsági vagy megfelelőségi követelmények esetén előfordulhat, hogy a forgalmat titkosítani kell az átjáró és az alkalmazás között. Ez HTTPS-kapcsolattal és a háttérkészlet tanúsítványainak konfigurálásával érhető el.

Ez a referencia-implementáció önaláírt tanúsítványokat használ az Application Gatewayhez. Éles kód esetén a hitelesítésszolgáltató által kiadott tanúsítványt kell használni. A támogatott tanúsítványtípusok listáját a TLS-lezáráshoz támogatott tanúsítványok című témakörben találja. Olvassa el az Application Gateway TLS-leállítással való konfigurálását az Azure Portal használatával, és ismerje meg, hogyan hozhat létre átjáróval végződő titkosítást. Az appgw.bicep következő kódsorai programozott módon konfigurálják ezt:

httpListeners: [for item in appgwApplications: {
name: '${appgwListenerName}${item.name}'
properties: {
  frontendIPConfiguration: {
    id: '${appgwId}/frontendIPConfigurations/${appgwFrontendName}'
  }
  frontendPort: {
    id: '${appgwId}/frontendPorts/port_443'
  }
  protocol: 'Https'
  sslCertificate: {
    id: '${appgwId}/sslCertificates/${appgwSslCertificateName}${item.name}'
  }
  hostName: item.hostName
  requireServerNameIndication: true
}
}]

A referencia-implementáció az Application Gateway és az App Service-környezet webalkalmazásai közötti forgalom végpontok közötti titkosítását mutatja be. A rendszer az alapértelmezett SSL-tanúsítványokat használja. Az implementáció háttérkészletei úgy vannak konfigurálva, hogy a https-forgalmat a webalkalmazásokhoz társított alapértelmezett tartománynevek felülírják a gazdagépnév felülírásával. Az Application Gateway megbízik az alapértelmezett SSL-tanúsítványokban, mert a Microsoft állítja ki őket. A konfigurációkról további információt az App Service konfigurálása az Application Gateway használatával című témakörben talál. Az appgw.bicep következő kódja bemutatja, hogyan van konfigurálva ez a referencia-implementációban:

backendHttpSettingsCollection: [for item in appgwApplications: {
name: '${appgwHttpSettingsName}${item.name}'
properties: {
  port: 443
  protocol: 'Https'
  cookieBasedAffinity: 'Disabled'
  pickHostNameFromBackendAddress: true
  requestTimeout: 20
  probe: {
    id: '${appgwId}/probes/${appgwHealthProbeName}${item.name}'
  }
}
}]

Webalkalmazási tűzfal

Az Application Gateway webalkalmazási tűzfala (WAF) védi a webalkalmazásokat a rosszindulatú támadásoktól, például az SQL-injektálástól. Emellett integrálva van az Azure Monitorral, hogy valós idejű naplóval monitorozza a támadásokat. A WAF-et engedélyezni kell az átjárón, az Azure Portal használatával az Application Gateway létrehozása webalkalmazási tűzfallal című cikkben leírtak szerint. A referencia-implementáció lehetővé teszi a WAF programozott használatát az appgw.bicep fájlban az alábbi kódrészlettel:

webApplicationFirewallConfiguration: {
  enabled: true
  firewallMode: 'Detection'
  ruleSetType: 'OWASP'
  ruleSetVersion: '3.2'
}

Virtual Network

A hálózati biztonsági csoportok a virtuális hálózat egy vagy több alhálózatához társíthatók. Ezek olyan biztonsági szabályok, amelyek engedélyezik vagy letiltják a forgalom áramlását a különböző Azure-erőforrások között. Ez az architektúra minden alhálózathoz külön hálózati biztonsági csoportot társít. Ez lehetővé teszi ezeknek a szabályoknak az alhálózatonkénti finomhangolását az alhálózatban található szolgáltatásoknak megfelelően. Lásd például az App Service Environment alhálózat hálózati biztonsági csoportjának ase.bicep fájljának konfigurációját"type": "Microsoft.Network/networkSecurityGroups", az Application Gateway alhálózatának hálózati biztonsági csoportjához tartozó appgw.bicep fájlt.

A privát végpontok fokozott biztonsági privát kapcsolatot tesznek lehetővé az ügyfelek és az Azure-szolgáltatások között egy privát hálózaton keresztül. Privátan elérhető IP-címet biztosítanak az Azure-szolgáltatáshoz, amely fokozott biztonsági forgalmat tesz lehetővé egy Azure Private Link-erőforrás felé. A platform ellenőrzi a hálózati kapcsolatokat, így csak azokat engedélyezi, amelyek a megadott Privát kapcsolat erőforráshoz csatlakoznak. A privát végpontok olyan hálózati házirendeket támogatnak, mint a hálózati biztonsági csoportok, a felhasználó által megadott útvonalak és az alkalmazásbiztonsági csoportok. A biztonság javítása érdekében engedélyeznie kell a privát végpontokat minden olyan Azure-szolgáltatáshoz, amely támogatja őket. Ezután javíthatja a szolgáltatás biztonságát a virtuális hálózatban a nyilvános hozzáférés letiltásával, amely hatékonyan blokkolja a nyilvános internetről való hozzáférést. Ez az architektúra privát végpontokat konfigurál az azt támogató szolgáltatásokhoz: Azure Service Bus, SQL Server, Key Vault és Azure Cosmos DB. A konfigurációt a privatendpoints.bicep fájlban tekintheti meg.

A privát végpontok engedélyezéséhez privát DNS-zónákat is konfigurálnia kell. További információ: Azure-beli privát végpont DNS-konfigurálása.

Firewall

Az Azure Firewall és a privát végpontok kiegészítik egymást. A privát végpontok segítenek megvédeni az erőforrásokat azáltal, hogy csak a virtuális hálózatból származó forgalmat engedélyezik. Az Azure Firewall lehetővé teszi az alkalmazások kimenő forgalmának korlátozását. Javasoljuk, hogy minden kimenő forgalom áthaladjon a tűzfal alhálózatán, beleértve a privát végpont forgalmát is. Ez lehetővé teszi a kimenő forgalom jobb monitorozását. Az egyszerűség kedvéért ez a referenciaarchitektúra a szolgáltatás alhálózatán konfigurálja az összes privát végpontot a tűzfal alhálózata helyett.

Az Azure Firewall és az App Service Environment integrálásának megismeréséhez tekintse meg az Azure Firewall App Service-környezettel való konfigurálását ismertető témakört. Minden olyan forgalmat, amely nem halad át a privát végpontokon és a virtuális hálózati útvonaltáblán, a tűzfal figyeli és irányítja.

Microsoft Entra ID

A Microsoft Entra ID biztonsági funkciókat biztosít az alkalmazások hitelesítéséhez és az erőforrásokhoz való hozzáférés engedélyezéséhez. Ez a referenciaarchitektúra a Microsoft Entra-azonosító két fő funkcióját használja: a felügyelt identitásokat és az Azure szerepköralapú hozzáférés-vezérlést.

A felhőalkalmazások esetében a felhőszolgáltatások hitelesítéséhez szükséges hitelesítő adatokat biztonságossá kell tenni. Ideális esetben a hitelesítő adatoknak soha nem szabad megjelennie a fejlesztői munkaállomásokon, vagy be kell jelentkeznie a forráskövetésbe. Az Azure Key Vault lehetővé teszi a hitelesítő adatok és titkos kódok biztonságos tárolását, de az alkalmazásnak továbbra is hitelesítenie kell őket a Key Vaultban. Az Azure-erőforrások felügyelt identitásai automatikusan felügyelt identitást biztosítanak az Azure-szolgáltatások számára a Microsoft Entra ID-ban. Ez az identitás bármely olyan szolgáltatásban használható hitelesítésre, amely támogatja a Microsoft Entra-hitelesítést, beleértve a Key Vaultot is, és nem tartalmaz hitelesítő adatokat az alkalmazásban.

Az Azure szerepköralapú hozzáférés-vezérlése (Azure RBAC) felügyeli az Azure-erőforrásokhoz való hozzáférést. Ide tartoznak az alábbiak:

• Melyik entitás rendelkezik hozzáféréssel: felhasználó, felügyelt identitás, biztonsági tag.
• Milyen típusú hozzáféréssel rendelkezik: tulajdonos, közreműködő, olvasó, rendszergazda.
• A hozzáférés hatóköre: erőforrás, erőforráscsoport, előfizetés vagy felügyeleti csoport.

Az App Service Environment-alkalmazásokhoz való hozzáférés zárolásához szigorúan szabályozhatja az egyes alkalmazásokhoz szükséges szerepkört és a hozzáférés típusát. Így több alkalmazás is üzembe helyezhető ugyanazon az App Service-környezetben különböző fejlesztői csapatoktól. Előfordulhat például, hogy az előtérben az egyik csapat, a háttérrendszert pedig egy másik kezeli. Az Azure RBAC használatával korlátozhatja az egyes csapatok hozzáférését az általa használt alkalmazás(ok)hoz. Az Egyéni Azure-szerepkörök megismerése a szervezetnek megfelelő szerepkörök létrehozásához.

Key Vault

Egyes szolgáltatások támogatják a felügyelt identitásokat, és az Azure RBAC használatával beállítják az alkalmazás engedélyeit. Lásd például a beépített Service Bus-szerepköröket és az Azure RBAC-t az Azure Cosmos DB-ben. Ezeknek az engedélyeknek a megadásához felhasználói hozzáférés-rendszergazdai hozzáférés szükséges az előfizetéshez, annak ellenére, hogy a közreműködői hozzáféréssel rendelkező személyzet üzembe helyezheti ezeket a szolgáltatásokat. Annak érdekében, hogy a fejlesztők szélesebb csoportja futtathassa az üzembehelyezési szkripteket, az alternatív megoldás a szolgáltatások által biztosított natív hozzáférés-vezérlés használata:

• A Service Bus esetében közös hozzáférésű jogosultságkódok.
• Az Azure Cosmos DB-hez ez a kulcsok.

Ha a számítási feladatnak szolgáltatásalapú hozzáférésre van szüksége, akkor ezeket az előre megosztott titkos kulcsokat a Key Vaultban kell tárolni. Magát a tárolót a webalkalmazás felügyelt identitásán keresztül kell elérni.

A Key Vaultban tárolt titkos kulcsokat az alkalmazások érik el, amelyek a Key Vault kulcs-érték párjára hivatkoznak. Ez a sites.bicep fájlban történik, ahogy a Szavazóalkalmazás következő kódja mutatja:

properties: {
  enabled: true
  hostingEnvironmentProfile: {
    id: aseId
  }
  serverFarmId: votingWebPlanName.id
  siteConfig: {
    appSettings: [
      {
        name: 'ASecret'
        value: '@Microsoft.KeyVault(SecretUri=${applicationKeyVault::secretName.secretUriWithVersion})'
      }
    ]
  }
}

Méretezhetőség

Méretezhető alkalmazások tervezése

Az ebben a referenciaarchitektúrában található alkalmazás úgy van strukturálva, hogy az egyes összetevők méretezhető legyen a használat alapján. Minden webalkalmazás, API és függvény saját App Service-csomagban van üzembe helyezve. Az egyes alkalmazásokat figyelheti a teljesítmény szűk keresztmetszetei miatt, majd szükség esetén felskálázhatja .

Az Application Gateway automatikus skálázása

Az automatikus skálázás engedélyezhető Azure-alkalmazás Gateway V2-n. Ez lehetővé teszi, hogy az Application Gateway a forgalmi terhelési minták alapján vertikálisan fel- vagy leskálázható legyen. Ez a referenciaarchitektúra autoscaleConfiguration úgy van konfigurálva az appgw.bicep fájlban, hogy nulla és 10 további példány között skálázható legyen. További részletekért lásd : Application Gateway és WAF v2 skálázása.

Telepítés

A referenciaarchitektúra üzembehelyezési szkriptjei az App Service Environment, más szolgáltatások és az App Service-környezeten belüli alkalmazások üzembe helyezésére szolgálnak. Az alkalmazások üzembe helyezése után előfordulhat, hogy a vállalatoknak rendelkezniük kell egy tervvel az alkalmazáskarbantartáshoz és -frissítésekhez való folyamatos integrációhoz és üzembe helyezéshez. Ez a szakasz az App Service Environment-alkalmazások CI/CD-hez való használatának néhány gyakori módját mutatja be.

Az alkalmazások csak a virtuális hálózaton belül helyezhetők üzembe egy belső App Service-környezetben. Az App Service Environment-alkalmazások üzembe helyezéséhez széles körben az alábbi három módszert használják:

• Manuálisan a virtuális hálózaton belül: Hozzon létre egy virtuális gépet az App Service Environment virtuális hálózaton belül az üzembe helyezéshez szükséges eszközökkel. Nyissa meg az RDP-kapcsolatot a virtuális géphez egy NSG-konfigurációval. Másolja a kódösszetevőket a virtuális gépre, hozza létre és helyezze üzembe az App Service Environment alhálózatán. Ez egy egyszerű módszer egy kezdeti buildelési és tesztelési környezet beállítására. Éles környezetben azonban nem ajánlott, mivel nem tudja skálázni a szükséges üzembe helyezési átviteli sebességet.

• Pont–hely kapcsolat helyi munkaállomásról: Ez lehetővé teszi, hogy kiterjesztse az App Service Environment virtuális hálózatát a fejlesztői gépre, és onnan telepítse. Ez egy másik módszer a kezdeti fejlesztői környezet beállítására, és nem ajánlott éles környezetben.

• Azure Pipelineson keresztül: Ez egy teljes CI/CD-folyamatot valósít meg, amely a virtuális hálózaton belül található ügynökkel végződik. Ez ideális olyan éles környezetekhez, amelyek nagy átviteli sebességet igényelnek. A buildelési folyamat teljes egészében a virtuális hálózaton kívül marad. Az üzembe helyezési folyamat átmásolja a beépített objektumokat a virtuális hálózaton belüli buildügynökbe, majd telepíti az App Service Environment alhálózatra. További információkért olvassa el ezt a beszélgetést a pipelines és az App Service Environment virtuális hálózat közötti saját üzemeltetésű buildügynökről.

Az Azure Pipelines használata éles környezetekhez ajánlott. A CI/CD szkriptelése az Azure Pipelines YAML-séma segítségével segít automatizálni a buildelési és üzembehelyezési folyamatokat. A azure-pipelines.yml egy ilyen CI/CD-folyamatot implementál a webalkalmazáshoz ebben a referencia-implementációban. A webes API-hoz és a függvényhez hasonló CI-/CD-szkriptek is léteznek. Olvassa el az Azure Pipelines használata című cikket, amelyből megtudhatja, hogyan automatizálja ezeket a CI/CD az egyes alkalmazásokhoz.

Előfordulhat, hogy egyes vállalatok nem szeretnének állandó buildügynököt fenntartani a virtuális hálózaton belül. Ebben az esetben létrehozhat egy buildügynököt a DevOps-folyamaton belül, és az üzembe helyezés befejezése után lebonthatja azt. Ez hozzáad egy újabb lépést a DevOpshoz, de csökkenti a virtuális gép karbantartásának összetettségét. Virtuális gépek helyett akár tárolókat is használhat buildügynökként. A buildelési ügynököket a virtuális hálózaton kívül elhelyezett tömörített fájlból, általában egy tárfiókban történő üzembe helyezéssel is teljesen elkerülheti. A tárfióknak elérhetőnek kell lennie az App Service-környezetből. A folyamatnak hozzá kell férnie a tárolóhoz. A kiadási folyamat végén egy tömörített fájl dobható a blobtárolóba. Az App Service-környezet ezután felveheti és üzembe helyezheti azt. Vegye figyelembe ennek a megközelítésnek a következő korlátait:

• A DevOps és a tényleges üzembehelyezési folyamat közötti kapcsolat megszakad, ami nehézségeket okoz az üzembehelyezési problémák monitorozásában és nyomon követésében.
• Biztonságos forgalommal rendelkező zárolt környezetben előfordulhat, hogy módosítania kell a szabályokat a tároló tömörített fájljának eléréséhez.
• A zip-ről való üzembe helyezéshez telepítenie kell bizonyos bővítményeket és eszközöket az App Service-környezetben.

Ha többet szeretne tudni az alkalmazások App Service-csomagokban való üzembe helyezéséről, olvassa el az App Service üzembehelyezési stratégiákra vonatkozó cikkeit.

Költségoptimalizálás

Az Azure díjkalkulátorával megbecsülheti költségeit. Egyéb szempontokat a Microsoft Azure Well-Architected Framework Költség szakaszában ismertetünk. Az Azure Reservationsszel csökkentheti költségeit, ha több Azure-erőforrásra egy vagy három évre előre kötelezettséget vállal. További információt a Foglalás vásárlása című cikkben talál.

Az alábbi szempontokat érdemes figyelembe venni az architektúra néhány kulcsfontosságú szolgáltatásához.

App Service-környezet v3

Az App Service-hez különböző díjszabási lehetőségek érhetők el. Az App Service-környezet az Izolált v2 szolgáltatáscsomag használatával van üzembe helyezve. Ebben a csomagban több lehetőség is van a cpu-méretekre, az I1v2-től az I6v2-esig. Ez a referencia-implementáció példányonként három I1v2-t használ.

Alkalmazási átjáró

Az Application Gateway díjszabása különböző díjszabási lehetőségeket kínál. Ez az implementáció az Application Gateway Standard v2 és WAF v2 termékváltozatot használja, amely támogatja az automatikus skálázást és a zónaredundanciát. A termékváltozathoz használt díjszabási modellről további információt az Application Gateway v2 és WAF v2 skálázása című témakörben talál.

Azure Cache for Redis

Az Azure Cache for Redis díjszabása biztosítja a szolgáltatás különböző díjszabási lehetőségeit. Ez az architektúra a Prémium termékváltozatot használja a virtuális hálózat támogatásához.

Az alábbiakban az App Service-környezet zárolásához használt egyéb szolgáltatások díjszabási oldalai találhatók:

• Az Azure Firewall díjszabása

• A Key Vault díjszabása

• A Microsoft Entra díjszabása

A forgatókönyv üzembe helyezése

Az architektúra referencia-implementációjának üzembe helyezéséhez tekintse meg a GitHub-olvasót, és kövesse a szabványos üzembe helyezéshez szükséges szkriptet.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

• Dhanashri Kshirsagar | Vezető tartalom pm

Egyéb közreműködők:

• Mély Bhattacharya | Felhőmegoldás-tervező
• Suhas Rao | Felhőmegoldás-tervező

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Következő lépések

• Az alkalmazás futtatása közvetlenül egy ZIP-csomagból Azure-alkalmazás Service-ben
• Azure Pipelines YAML-séma
• Felügyeleti címek lekérése az API-ból
• Azure Key Vault
• Azure Pipelines

Kapcsolódó erőforrások

Ha meg szeretné tudni, hogyan terjesztheti ki ezt az architektúrát a magas rendelkezésre állás támogatására, olvassa el a magas rendelkezésre állású alkalmazás üzembe helyezését az App Services-környezettel.