Penyebaran perusahaan menggunakan Azure App Service Environment

Arsitektur referensi ini menunjukkan beban kerja perusahaan umum yang menggunakan Lingkungan App Service versi 3. Ini juga menjelaskan praktik terbaik untuk memperkuat keamanan beban kerja.

Implementasi referensi untuk arsitektur ini tersedia di GitHub.

Arsitektur

Unduh file Visio arsitektur ini.

Alur kerja

App Service Environment versi 3 menyediakan fitur yang berbeda dari versi sebelumnya, dan keuntungan daripada versi tersebut. Untuk informasi selengkapnya, lihat Perbedaan fitur. Anda dapat menyebarkan Lingkungan App Service dengan dua cara:

• Sebagai Lingkungan App Service eksternal dengan alamat IP publik
• Sebagai Lingkungan App Service internal dengan alamat IP internal milik penyeimbang muatan internal (ILB)

Arsitektur referensi ini menyebarkan aplikasi web perusahaan di Lingkungan App Service internal, juga disebut ILB App Service Environment. Gunakan ILB App Service Environment saat skenario Anda mengharuskan Anda untuk:

• Host aplikasi intranet dengan keamanan yang ditingkatkan di cloud, dan akses melalui VPN situs-ke-situs atau Azure ExpressRoute.
• Berikan lapisan perlindungan untuk aplikasi dengan menggunakan firewall aplikasi web (WAF).
• Menghosting aplikasi di cloud yang tidak tercantum di server DNS publik.
• Buat aplikasi back-end yang terisolasi internet, yang dapat diintegrasikan oleh aplikasi front-end Anda dengan cara yang sangat aman.

Lingkungan App Service harus selalu disebarkan di subnetnya sendiri di jaringan virtual perusahaan untuk memungkinkan kontrol ketat terhadap lalu lintas masuk dan keluar. Dalam subnet ini, aplikasi App Service disebarkan dalam satu atau beberapa paket App Service, yang merupakan kumpulan sumber daya fisik yang diperlukan untuk menjalankan aplikasi. Bergantung pada kompleksitas dan persyaratan sumber daya, paket App Service dapat dibagikan di antara beberapa aplikasi. Implementasi referensi ini menyebarkan aplikasi web bernama Voting App, yang berinteraksi dengan API web privat dan fungsi. Itu juga menyebarkan aplikasi web tiruan bernama Aplikasi Pengujian untuk mendemonstrasikan penyebaran multi-aplikasi. Setiap aplikasi App Service dihosting dalam paket App Service-nya sendiri, yang memungkinkan masing-masing untuk diskalakan secara independen jika perlu. Semua sumber daya yang diperlukan oleh aplikasi yang dihosting ini, seperti penyimpanan dan komputasi, serta kebutuhan penskalaan dikelola sepenuhnya oleh infrastruktur Lingkungan App Service.

Aplikasi pemungutan suara sederhana dalam implementasi ini memungkinkan pengguna untuk melihat entri yang ada, membuat entri baru, dan memilih entri yang ada. API web digunakan untuk pembuatan dan pengambilan entri dan suara. Data itu sendiri disimpan dalam database SQL Server. Untuk mendemonstrasikan pembaruan data asinkron, aplikasi web mengantrekan suara yang baru ditambahkan dalam instans Azure Service Bus. Fungsi mengambil suara yang antre dan memperbarui database SQL. Azure Cosmos DB digunakan untuk menyimpan iklan tiruan, yang diambil aplikasi web untuk ditampilkan di browser. Aplikasi menggunakan Azure Cache for Redis untuk manajemen cache. Azure Cache for Redis tingkat Premium digunakan, yang memungkinkan konfigurasi ke jaringan virtual yang sama dengan Lingkungan App Service, di subnetnya sendiri. Ini memberikan peningkatan keamanan dan isolasi ke cache.

Aplikasi web adalah satu-satunya komponen yang dapat diakses oleh internet melalui Application Gateway. API dan fungsinya tidak dapat diakses dari klien internet. Lalu lintas masuk dilindungi oleh WAF yang dikonfigurasi di Application Gateway.

Komponen

Layanan berikut adalah kunci untuk mengunci Lingkungan App Service dalam arsitektur ini:

• Azure Virtual Network adalah jaringan cloud Azure privat yang dimiliki oleh perusahaan. Ini menyediakan keamanan dan isolasi berbasis jaringan yang ditingkatkan. Lingkungan App Service adalah penyebaran App Service ke subnet jaringan virtual milik perusahaan. Ini memungkinkan perusahaan untuk mengontrol ruang jaringan dan sumber daya yang diaksesnya dengan menggunakan grup keamanan jaringan dan titik akhir privat.

• Application Gateway adalah penyeimbang beban lalu lintas web tingkat aplikasi dengan offloading TLS/SSL dan WAF. Ini mendengarkan alamat IP publik dan merutekan lalu lintas ke titik akhir aplikasi di ILB App Service Environment. Karena ini adalah perutean tingkat aplikasi, ini dapat merutekan lalu lintas ke beberapa aplikasi dalam ILB App Service Environment yang sama. Untuk info selengkapnya, lihat Hosting Application Gateway beberapa situs.

• Azure Firewall digunakan untuk membatasi lalu lintas keluar dari aplikasi web. Lalu lintas keluar yang tidak melalui saluran titik akhir privat dan tabel rute yang diperlukan oleh Lingkungan App Service diarahkan ke subnet firewall. Demi kesederhanaan, arsitektur ini mengonfigurasi semua titik akhir privat pada subnet layanan.

• ID Microsoft Entra atau ID Microsoft Entra menyediakan hak akses dan manajemen izin ke sumber daya dan layanan Azure. Identitas Terkelola menetapkan identitas ke layanan dan aplikasi, yang dikelola secara otomatis oleh ID Microsoft Entra. Identitas ini dapat digunakan untuk mengautentikasi ke layanan apa pun yang mendukung autentikasi Microsoft Entra. Ini menghilangkan kebutuhan untuk mengonfigurasi info masuk secara eksplisit untuk aplikasi ini. Arsitektur ini menetapkan identitas terkelola ke aplikasi web.

• Azure Key Vault menyimpan rahasia dan kredensial apa pun yang diperlukan oleh aplikasi. Gunakan opsi ini untuk menyimpan rahasia langsung dalam aplikasi.

• GitHub Actions menyediakan kemampuan integrasi berkelanjutan dan penyebaran berkelanjutan dalam arsitektur ini. Karena Lingkungan App Service berada di jaringan virtual, komputer virtual digunakan sebagai jumpbox di dalam jaringan virtual untuk menyebarkan aplikasi dalam paket App Service. Tindakan ini membangun aplikasi di luar jaringan virtual. Untuk keamanan yang ditingkatkan dan konektivitas RDP/SSH yang mulus, pertimbangkan untuk menggunakan Azure Bastion untuk jumpbox.

Konfigurasi multi-situs

Unduh file Visio arsitektur ini.

Lingkungan App Service Internal dapat menghosting beberapa aplikasi web dan API dengan titik akhir HTTP. Aplikasi ini dikunci dari internet publik karena IP ILB hanya dapat diakses dari dalam Virtual Network. Application Gateway digunakan untuk mengekspos aplikasi ini secara selektif ke internet. Lingkungan App Service menetapkan URL default ke setiap aplikasi App Service sebagai <default-appName>.<app-service-environment-domain>.appserviceenvironment.net. Zona DNS privat dibuat yang memetakan nama domain Lingkungan App Service ke alamat IP ILB Lingkungan App Service. Ini menghindari penggunaan DNS kustom untuk mengakses aplikasi dalam jaringan virtual.

Application Gateway dikonfigurasi sembarang sehingga pendengar mendengarkan di port HTTPS untuk permintaan ke alamat IP gateway. Demi kesederhanaan, implementasi ini tidak menggunakan pendaftaran nama DNS publik. Ini mengharuskan Anda memodifikasi file localhost di komputer Anda untuk mengarahkan URL yang dipilih secara arbitrase ke IP Application Gateway. Untuk kesederhanaan, pendengar menggunakan sertifikat yang ditandatangani sendiri untuk memproses permintaan ini. Application Gateway memiliki kumpulan backend untuk setiap URL default aplikasi App Service. Aturan perutean dikonfigurasi untuk menyambungkan pendengar ke kumpulan backend. Pengaturan HTTP dibuat yang menentukan apakah koneksi antara gateway dan Lingkungan App Service akan dienkripsi. Pengaturan ini juga digunakan untuk mengganti header host HTTP yang masuk dengan nama host yang diambil dari kumpulan backend. Implementasi ini menggunakan sertifikat default yang dibuat untuk URL aplikasi App Service Environment default, yang dipercaya oleh gateway. Permintaan dialihkan ke URL default aplikasi yang sesuai. DNS privat yang ditautkan ke jaringan virtual meneruskan permintaan ini ke IP ILB. App Service Environment kemudian meneruskan ini ke layanan aplikasi yang diminta. Setiap komunikasi HTTP dalam aplikasi App Service Environment melewati DNS privat. Perhatikan bahwa pendengar, kumpulan backend, aturan perutean, dan pengaturan HTTP perlu dikonfigurasi pada gateway aplikasi untuk setiap aplikasi App Service Environment.

Tinjau appgw.bicep dan dns.bicep untuk mempelajari bagaimana konfigurasi ini dibuat untuk mengizinkan beberapa situs. Aplikasi web bernama testapp adalah aplikasi kosong yang dibuat untuk mendemonstrasikan konfigurasi ini. File JSON ini diakses dari skrip penyebaran commands_std.azcli. Ini juga diakses oleh commands_ha.azcli, yang digunakan untuk penyebaran App Service Environment multi-situs ketersediaan tinggi.

Detail skenario

Azure App Service adalah layanan PaaS yang digunakan untuk menghosting berbagai aplikasi di Azure: aplikasi web, aplikasi API, fungsi, dan aplikasi ponsel. App Service Environment memungkinkan perusahaan untuk menyebarkan aplikasi App Service mereka di subnet di Azure Virtual Network mereka sendiri, menyediakan lingkungan yang terisolasi, sangat dapat diskalakan, dan khusus untuk beban kerja cloud mereka.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Keamanan

Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keamanan.

Lingkungan App Service

Lingkungan App Service internal disebarkan di jaringan virtual perusahaan, tersembunyi dari internet publik. Hal ini memungkinkan perusahaan untuk mengunci layanan backend mereka, seperti API dan fungsi web, di tingkat jaringan. Aplikasi App Service Environment apa pun dengan titik akhir HTTP, dapat diakses melalui ILB, dari dalam jaringan virtual. Application Gateway dikonfigurasi untuk meneruskan permintaan ke aplikasi web melalui ILB. Aplikasi web itu sendiri melalui ILB untuk mengakses API. Komponen backend penting, yaitu API dan fungsinya, secara efektif tidak dapat diakses dari internet publik.

Sertifikat default dibuat untuk setiap layanan aplikasi untuk nama domain default yang ditetapkan oleh Lingkungan App Service. Sertifikat ini dapat memperketat keamanan lalu lintas antara gateway dan aplikasi, dan mungkin diperlukan dalam skenario tertentu. Sertifikat ini tidak terlihat melalui browser klien. Ini hanya dapat merespons sertifikat yang dikonfigurasi di Application Gateway.

Application Gateway

Implementasi referensi mengonfigurasi Application Gateway secara terprogram di appgw.bicep. File commands_std.azcli menggunakan konfigurasi ini saat menyebarkan gateway:

az deployment group create --resource-group $RGNAME --template-file templates/appgw.bicep --parameters vnetName=$VNET_NAME appgwSubnetAddressPrefix=$APPGW_PREFIX appgwApplications=@appgwApps.parameters.json
APPGW_PUBLIC_IP=$(az deployment group show -g $RGNAME -n appgw --query properties.outputs.appGwPublicIpAddress.value -o tsv)

Enkripsi

Seperti yang dijelaskan dalam Gambaran Umum penghentian TLS dan TLS ujung ke ujung dengan Application Gateway, Application Gateway dapat menggunakan Keamanan Lapisan Transportasi (TLS)/Secure Sockets Layer (SSL) untuk mengenkripsi dan melindungi semua lalu lintas dari browser web. Enkripsi dapat dikonfigurasi dengan cara berikut:

• Enkripsi dihentikan di gateway. Kumpulan backend dalam hal ini dikonfigurasi untuk HTTP. Enkripsi berhenti di gateway, dan lalu lintas antara gateway dan layanan aplikasi tidak terenkripsi. Karena enkripsi membutuhkan banyak CPU, lalu lintas tidak terenkripsi di backend meningkatkan performa dan memungkinkan pengelolaan sertifikat yang lebih sederhana. Ini memberikan tingkat keamanan yang wajar karena backend diamankan berdasarkan konfigurasi jaringan.

• Enkripsi end-to-end. Dalam beberapa skenario, seperti persyaratan keamanan atau kepatuhan tertentu, lalu lintas mungkin perlu dienkripsi antara gateway dan aplikasi. Ini dicapai menggunakan koneksi HTTPS, dan mengonfigurasi sertifikat di kumpulan backend.

Implementasi referensi ini menggunakan sertifikat yang ditandatangani sendiri untuk Application Gateway. Untuk kode produksi, sertifikat yang dikeluarkan oleh Otoritas Sertifikat harus digunakan. Untuk daftar jenis sertifikat yang didukung, lihat Sertifikat yang didukung untuk penghentian TLS. Baca Mengonfigurasi gateway aplikasi dengan penghentian TLS menggunakan portal Azure untuk mempelajari cara membuat enkripsi yang diakhiri Gateway. Baris kode berikut di appgw.bicep mengonfigurasi ini secara terprogram:

          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
          }
        }]

Implementasi referensi menunjukkan enkripsi end-to-end untuk lalu lintas antara Application Gateway dan aplikasi web di Lingkungan App Service. Sertifikat SSL default digunakan. Kumpulan backend dalam penerapan ini dikonfigurasikan untuk mengalihkan lalu lintas HTTPS dengan nama host diganti dengan nama domain default yang terkait dengan aplikasi web. Application Gateway mempercayai sertifikat SSL default karena dikeluarkan oleh Microsoft. Lihat Mengonfigurasi App Service dengan Application Gateway untuk informasi tentang bagaimana konfigurasi ini dibuat. Kode berikut dari appgw.bicep menunjukkan bagaimana ini dikonfigurasi dalam implementasi referensi:

        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}'
          }
        }
      }]

Web Application Firewall

Web Application Firewall (WAF) di Application Gateway melindungi aplikasi web dari serangan berbahaya, seperti injeksi SQL. Itu juga terintegrasi dengan Azure Monitor, untuk memantau serangan menggunakan log real time. WAF harus diaktifkan di gateway, seperti yang dijelaskan dalam Membuat gateway aplikasi dengan Web Application Firewall menggunakan portal Azure. Implementasi referensi memungkinkan WAF secara terprogram dalam file appgw.bicep dengan cuplikan berikut:

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

Virtual Network

Kelompok keamanan jaringan dapat dikaitkan dengan satu atau beberapa subnet di jaringan virtual. Ini adalah aturan keamanan yang mengizinkan atau menolak lalu lintas mengalir di antara berbagai sumber daya Azure. Arsitektur ini mengaitkan grup keamanan jaringan terpisah untuk setiap subnet. Ini memungkinkan penyempurnaan aturan ini per subnet, sesuai layanan yang terkandung dalam subnet tersebut. Misalnya, lihat konfigurasi untuk "type": "Microsoft.Network/networkSecurityGroups" dalam file ase.bicep untuk grup keamanan jaringan untuk subnet Lingkungan App Service, dan dalam file appgw.bicep untuk grup keamanan jaringan untuk subnet Application Gateway.

Titik akhir privat memungkinkan konektivitas privat keamanan yang ditingkatkan antara klien dan layanan Azure melalui jaringan privat. Mereka menyediakan alamat IP yang dapat diakses secara privat untuk layanan Azure, memungkinkan lalu lintas keamanan yang ditingkatkan ke sumber daya Azure Private Link. Platform memvalidasi koneksi jaringan, hanya memungkinkan mereka yang terhubung ke sumber daya Private Link yang ditentukan. Titik akhir privat mendukung kebijakan jaringan seperti grup keamanan jaringan, rute yang ditentukan pengguna, dan grup keamanan aplikasi. Untuk meningkatkan keamanan, Anda harus mengaktifkan titik akhir privat untuk layanan Azure apa pun yang mendukungnya. Anda kemudian dapat meningkatkan keamanan untuk layanan di jaringan virtual dengan menonaktifkan akses publik, secara efektif memblokir akses apa pun dari internet publik. Arsitektur ini mengonfigurasi titik akhir privat untuk layanan yang mendukungnya: Azure Bus Layanan, SQL Server, Key Vault, dan Azure Cosmos DB. Anda dapat melihat konfigurasi di privatendpoints.bicep.

Untuk mengaktifkan titik akhir privat, Anda juga perlu mengonfigurasi zona DNS privat. Untuk informasi selengkapnya, lihat Konfigurasi DNS Azure Private Endpoint.

Firewall

Azure Firewall dan titik akhir privat saling melengkapi. Titik akhir privat membantu melindungi sumber daya dengan hanya mengizinkan lalu lintas yang berasal dari jaringan virtual Anda. Azure Firewall memungkinkan Anda membatasi lalu lintas keluar dari aplikasi Anda. Kami menyarankan agar Anda mengizinkan semua lalu lintas keluar untuk melewati subnet firewall, termasuk lalu lintas titik akhir privat. Ini memungkinkan pemantauan lalu lintas keluar yang lebih baik. Demi kesederhanaan, arsitektur referensi ini mengonfigurasi semua titik akhir privat pada subnet layanan alih-alih pada subnet firewall.

Untuk mempelajari bagaimana Azure Firewall terintegrasi dengan App Service Environment, lihat Mengonfigurasi Azure Firewall dengan Lingkungan App Service Anda. Lalu lintas apa pun yang tidak melintasi titik akhir privat dan tabel rute jaringan virtual dipantau dan dijaga oleh firewall.

Microsoft Entra ID

MICROSOFT Entra ID menyediakan fitur keamanan untuk mengautentikasi aplikasi dan mengotorisasi akses ke sumber daya. Arsitektur referensi ini menggunakan dua fitur utama ID Microsoft Entra: identitas terkelola, dan kontrol akses berbasis peran Azure.

Pada aplikasi cloud, kredensial yang diperlukan untuk mengautentikasi ke layanan cloud harus diamankan. Idealnya, info masuk tidak boleh muncul di stasiun kerja pengembang atau diperiksa ke kontrol sumber. Azure Key Vault menyediakan cara untuk menyimpan info masuk dan rahasia dengan aman, tetapi aplikasi masih harus mengautentikasi ke Key Vault untuk mengambilnya. Identitas Terkelola untuk sumber daya Azure menyediakan layanan Azure dengan identitas yang dikelola secara otomatis di ID Microsoft Entra. Identitas ini dapat digunakan untuk mengautentikasi ke layanan apa pun yang mendukung autentikasi Microsoft Entra, termasuk Key Vault, tanpa kredensial apa pun dalam aplikasi.

Kontrol akses berbasis peran Azure (Azure RBAC) mengelola akses ke sumber daya Azure. Drive ini termasuk:

• Entitas mana yang memiliki akses: pengguna, identitas terkelola, prinsip keamanan.
• Jenis akses apa yang dimilikinya: pemilik, kontributor, pembaca, admin.
• Cakupan akses: sumber daya, grup sumber daya, langganan, atau grup manajemen.

Anda dapat mengunci akses ke aplikasi App Service Environment dengan mengontrol peran yang diperlukan dan jenis akses untuk setiap aplikasi. Dengan cara ini, beberapa aplikasi dapat disebarkan di Lingkungan App Service yang sama dari tim pengembangan yang berbeda. Misalnya, frontend mungkin ditangani oleh satu tim, dan backend oleh yang lain. Azure RBAC dapat digunakan untuk membatasi akses setiap tim ke aplikasi yang sedang dikerjakannya. Jelajahi Peran kustom Azure untuk membuat peran yang sesuai dengan organisasi Anda.

Key Vault

Beberapa layanan mendukung identitas terkelola tetapi menggunakan Azure RBAC untuk menyiapkan izin untuk aplikasi. Misalnya, lihat peran Bus Layanan bawaan dan Azure RBAC di Azure Cosmos DB. Akses Pemilik ke langganan diperlukan untuk memberikan izin ini, meskipun personel dengan akses Kontributor dapat menyebarkan layanan ini. Agar tim pengembang yang lebih luas dapat menjalankan skrip penyebaran, opsi terbaik berikutnya adalah menggunakan kebijakan kontrol akses asli layanan:

• Untuk Bus Layanan, ini adalah tanda tangan akses bersama.
• Untuk Azure Cosmos DB, ini adalah kunci.

String koneksi untuk kebijakan kontrol akses ini kemudian disimpan di Key Vault. Vault itu sendiri diakses melalui identitas terkelola, yang memerlukan Azure RBAC. Atur kebijakan akses untuk string koneksi ini dengan tepat. Misalnya, baca-saja untuk backend, tulis-saja untuk frontend, dan seterusnya, daripada menggunakan kebijakan akses akar default.

Kode berikut dalam services.bicep menunjukkan konfigurasi Key Vault untuk layanan ini:

      resource keyVaultName_CosmosKey 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'CosmosKey'
      properties: {
        value: cosmosName.listKeys().primaryMasterKey 
      }
    }

      resource keyVaultName_ServiceBusListenerConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusListenerConnectionString'
      properties: {
        value: listKeys(serviceBusName_ListenerSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

      resource keyVaultName_ServiceBusSenderConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusSenderConnectionString'
      properties: {
        value: listKeys(serviceBusName_SenderSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

Nilai string koneksi ini diakses oleh aplikasi, yang mereferensikan pasangan kunci/nilai Key Vault. Ini dilakukan dalam file sites.bicep , seperti yang ditunjukkan kode berikut untuk Aplikasi Pemungutan Suara:

  properties: {
    enabled: true
    hostingEnvironmentProfile: {
      id:aseId
    }
    serverFarmId: votingWebPlanName.id
    siteConfig: {
      appSettings: [
        {
          name: 'ConnectionStrings:sbConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, serviceBusSenderConnectionStringSecretName), '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:RedisConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(keyVaultName_redisSecretName.id, '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:CosmosKey'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, cosmosKeySecretName), '2022-07-01').secretUriWithVersion})'
        }
      ]
    }
  }

Fungsi ini juga mengakses string koneksi pendengar Azure Service Bus dengan cara yang sama.

Skalabilitas

Merancang aplikasi yang dapat diskalakan

Aplikasi dalam arsitektur referensi ini disusun sehingga masing-masing komponen dapat diskalakan berdasarkan penggunaan. Setiap aplikasi web, API, dan fungsi disebarkan dalam paket App Service-nya sendiri. Anda dapat memantau setiap aplikasi untuk mencari hambatan performa, lalu meningkatkan skalanya jika diperlukan.

Autoscaling Application Gateway

Penskalaan Otomatis dapat diaktifkan di Azure Application Gateway V2. Ini memungkinkan Application Gateway untuk meningkatkan atau menurunkan skala berdasarkan pola beban lalu lintas. Arsitektur referensi ini mengonfigurasi dalam file appgw.bicep untuk menskalakan autoscaleConfiguration antara nol dan 10 instans tambahan. Lihat Penskalaan Application Gateway dan WAF v2 untuk detail selengkapnya.

Penyebaran

Skrip penyebaran dalam arsitektur referensi ini digunakan untuk menyebarkan Lingkungan App Service, layanan lain, dan aplikasi di dalam Lingkungan App Service. Setelah aplikasi ini disebarkan, perusahaan mungkin ingin memiliki rencana untuk integrasi berkelanjutan dan penyebaran untuk pemeliharaan dan peningkatan aplikasi. Bagian ini menunjukkan beberapa cara umum yang digunakan pengembang untuk CI/CD aplikasi App Service Environment.

Aplikasi hanya dapat disebarkan ke Lingkungan App Service internal dari dalam jaringan virtual. Tiga metode berikut banyak digunakan untuk menyebarkan aplikasi App Service Environment:

• Secara manual di dalam Virtual Network: Buat komputer virtual di dalam jaringan virtual App Service Environment dengan alat yang diperlukan untuk penyebaran. Buka koneksi RDP ke VM menggunakan konfigurasi NSG. Salin artefak kode Anda ke VM, buat, dan sebarkan ke subnet App Service Environment. Ini adalah cara sederhana untuk menyiapkan lingkungan pengembangan awal dan pengujian. Namun tidak disarankan untuk lingkungan produksi karena tidak dapat menskalakan throughput penyebaran yang diperlukan.

• Koneksi titik ke situs dari stasiun kerja lokal: Ini memungkinkan Anda memperluas jaringan virtual Lingkungan App Service ke komputer pengembangan Anda, dan menyebarkan dari sana. Ini adalah cara lain untuk menyiapkan lingkungan pengembang awal, dan tidak direkomendasikan untuk produksi.

• Melalui Azure Pipelines: Ini mengimplementasikan alur CI/CD lengkap, berakhiran agen yang terletak di dalam jaringan virtual. Ini sangat ideal untuk lingkungan produksi yang membutuhkan throughput penyebaran yang tinggi. Alur build tetap sepenuhnya di luar jaringan virtual. Alur penyebaran menyalin objek bawaan ke agen build di dalam jaringan virtual, lalu menyebarkan ke subnet Lingkungan App Service. Untuk informasi selengkapnya, baca diskusi ini tentang agen build yang dihost sendiri antara Alur dan jaringan virtual Lingkungan App Service.

Sebaiknya menggunakan Azure Pipelines untuk lingkungan produksi. Membuat skrip CI/CD dengan bantuan skema Azure Pipelines YAML membantu mengotomatiskan proses pembuatan dan penyebaran. Azure-pipelines.yml menerapkan pipa CI/CD semacam itu untuk aplikasi web dalam penerapan referensi ini. Ada skrip CI/CD serupa untuk API web serta fungsi. Baca Menggunakan Azure Pipelines untuk mempelajari bagaimana ini digunakan untuk mengotomatisasi CI/CD untuk setiap aplikasi.

Beberapa perusahaan mungkin tidak ingin mempertahankan agen build permanen di dalam jaringan virtual. Dalam hal ini, Anda dapat memilih untuk membuat agen build di dalam alur DevOps, dan menonaktifkannya setelah penyebaran selesai. Ini menambahkan langkah lain dalam DevOps, namun menurunkan kompleksitas pemeliharaan VM. Anda bahkan dapat mempertimbangkan untuk menggunakan kontainer sebagai agen build, bukan VM. Agen build juga dapat sepenuhnya dihindari dengan menyebarkan dari file zip yang ditempatkan di luar jaringan virtual, biasanya di akun penyimpanan. Akun penyimpanan harus dapat diakses dari Lingkungan App Service. Alur harus dapat mengakses penyimpanan. Pada akhir alur rilis, file zip dapat dihilangkan ke penyimpanan blob. Lingkungan App Service kemudian dapat mengambilnya dan menyebarkannya. Berhati-hatilah pada keterbatasan berikut dari pendekatan ini:

• Ada pemutusan koneksi antara DevOps dan proses penyebaran yang sebenarnya, yang menyebabkan kesulitan dalam memantau dan melacak masalah penyebaran apa pun.
• Dalam lingkungan terkunci dengan lalu lintas aman, Anda mungkin perlu mengubah aturan untuk mengakses file zip di penyimpanan.
• Anda harus menginstal ekstensi dan alat tertentu di Lingkungan App Service untuk dapat menyebarkan dari zip.

Untuk mengetahui beberapa cara lain aplikasi dapat disebarkan ke paket App Service, baca artikel App Service yang berfokus pada strategi penyebaran.

Pengoptimalan biaya

Gunakan kalkulator harga Azure untuk memperkirakan biaya. Pertimbangan lainnya dijelaskan di bagian Biaya di Microsoft Azure Well-Architected Framework. Reservasi Azure membantu Anda berhemat dengan menerapkan paket satu tahun atau tiga tahun untuk banyak sumber daya Azure. Baca selengkapnya di artikel Beli reservasi.

Berikut adalah beberapa poin yang perlu dipertimbangkan untuk beberapa layanan utama yang digunakan dalam arsitektur ini.

Lingkungan App Service v3

Ada berbagai opsi harga yang tersedia untuk App Service. Lingkungan App Service disebarkan menggunakan Paket Layanan v2 Terisolasi. Dalam paket ini, ada beberapa opsi untuk ukuran CPU, dari I1v2 hingga I6v2. Implementasi referensi ini menggunakan tiga I1v2 per instans.

Application Gateway

Harga Application Gateway menyediakan berbagai opsi harga. Implementasi ini menggunakan Application Gateway Standard v2 dan WAF v2 SKU, yang mendukung penskalaan otomatis dan redundansi zona. Lihat Penskalaan Application Gateway v2 dan WAF v2 untuk informasi selengkapnya tentang model harga yang digunakan untuk SKU ini.

Azure Cache untuk Redis

Harga Azure Cache for Redis menyediakan berbagai opsi harga untuk layanan ini. Arsitektur ini menggunakan SKU Premium, untuk dukungan jaringan virtual.

Berikut ini adalah halaman harga untuk layanan lain yang digunakan untuk mengunci Lingkungan App Service:

• Harga Azure Firewall

• Harga Key Vault

• Harga Microsoft Entra

Menyebarkan skenario ini

Untuk menyebarkan penerapan referensi untuk arsitektur ini, lihat readme GitHub, dan ikuti skrip untuk penyebaran standar.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

• Dhanashri Kshirsagar | PM Konten Senior

Kontributor lain:

• Deep Bhattacharya | Arsitek Solusi Cloud
• Suhas Rao | Arsitek Solusi Cloud

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

• Menjalankan aplikasi Anda di Azure App Service langsung dari paket ZIP
• Skema YAML Azure Pipelines
• Mendapatkan alamat manajemen Anda dari API
• Azure Key Vault
• Alur Azure

Sumber daya terkait

Untuk mempelajari cara memperluas arsitektur ini untuk mendukung ketersediaan tinggi, baca Penyebaran aplikasi ketersediaan tinggi menggunakan Lingkungan App Services.