Azure App Service adalah layanan PaaS yang digunakan untuk menghosting berbagai aplikasi di Azure: aplikasi web, aplikasi API, fungsi, dan aplikasi ponsel. Lingkungan App Service atau ASE memungkinkan perusahaan untuk menerapkan aplikasi App Service mereka di subnet di Azure Virtual Network mereka sendiri, menyediakan lingkungan yang terisolasi, sangat skalabel, dan berdedikasi untuk beban kerja cloud mereka.
Arsitektur referensi ini menunjukkan beban kerja perusahaan yang umum menggunakan ASE, dan praktik terbaik untuk memperketat keamanan beban kerja ini.
Implementasi referensi untuk arsitektur ini tersedia di GitHub.
Arsitektur
Alur kerja
Komponen utama arsitektur ini adalah lingkungan App Service. ASE dapat digunakan sebagai ASE eksternal dengan alamat IP publik, atau sebagai ASE internal, dengan alamat IP internal milik Internal Load Balancer (ILB). Arsitektur referensi ini menyebarkan aplikasi web perusahaan dalam ASE internal, juga disebut ILB ASE. Gunakan ILB ASE saat skenario Anda mengharuskan Anda untuk:
- Menghosting aplikasi intranet dengan aman di cloud, yang Anda akses melalui situs ke situs atau ExpressRoute.
- Melindungi aplikasi dengan perangkat WAF.
- Menghosting aplikasi di cloud yang tidak tercantum di server DNS publik.
- Membuat aplikasi ujung-belakang yang terisolasi internet, yang dapat diintegrasikan dengan aman oleh aplikasi ujung-depan Anda.
Sebuah ASE harus selalu disebarkan di subnetnya sendiri dalam jaringan virtual perusahaan, memungkinkan kontrol yang ketat dari 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. Penerapan referensi ini menyebarkan aplikasi web bernama Aplikasi Pemungutan Suara, yang berinteraksi dengan API web privat dan sebuah 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 penerapan ini, memungkinkan pengguna untuk melihat entri yang ada atau membuat entri baru, serta memberikan suara pada 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. CosmosDB digunakan untuk menyimpan iklan tiruan, yang diambil oleh 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 ASE, di subnetnya sendiri. Ini memberikan peningkatan keamanan dan isolasi ke cache.
Aplikasi web adalah satu-satunya komponen yang dapat diakses oleh internet melalui App Gateway. API dan fungsinya tidak dapat diakses dari klien internet. Lalu lintas masuk dilindungi oleh Web Application Firewall yang dikonfigurasi pada App Gateway.
Komponen
Layanan berikut adalah kunci untuk mengunci ASE dalam arsitektur ini:
Azure Virtual Network atau VNet adalah jaringan cloud Azure privat yang dimiliki oleh perusahaan. Ini memberikan keamanan dan isolasi berbasis jaringan. ASE adalah penyebaran App Service ke subnet VNet milik perusahaan. Hal ini memungkinkan perusahaan untuk mengontrol dengan ketat ruang jaringan dan sumber daya yang diaksesnya, menggunakan grup Keamanan Jaringan dan Titik Akhir Layanan.
Application Gateway adalah penyeimbang beban lalu lintas web tingkat aplikasi, dengan pemindahan TLS/SSL, dan perlindungan firewall aplikasi web (WAF). Application Gateway mendengarkan pada alamat IP publik dan mengarahkan lalu lintas ke titik akhir aplikasi di ILB ASE. Karena ini adalah perutean tingkat aplikasi, maka dapat merutekan lalu lintas ke beberapa aplikasi dalam ILB ASE yang sama. Lihat Application Gateway beberapa situs hosting untuk mempelajari bagaimana App Gateway mendukung beberapa situs.
Azure Firewall digunakan untuk membatasi lalu lintas keluar dari aplikasi web. Lalu lintas keluar yang tidak melalui saluran titik akhir layanan dan tabel rute yang diperlukan oleh ASE, diarahkan ke subnet firewall. Meskipun disarankan agar titik akhir layanan dikonfigurasikan pada subnet firewall untuk keterlacakan, hal itu mungkin tidak selalu layak. Misalnya, beberapa titik akhir layanan diperlukan oleh infrastruktur ASE untuk berada di subnet ASE. Untuk kesederhanaan, arsitektur ini mengonfigurasi semua titik akhir layanan pada subnet ASE.
Azure Active Directory atau Azure AD memberikan hak akses dan manajemen izin ke sumber daya dan layanan Azure. Identitas Terkelola menetapkan identitas ke layanan dan aplikasi, yang dikelola secara otomatis oleh Azure AD. Identitas ini dapat digunakan untuk mengautentikasi ke layanan apa pun yang mendukung autentikasi Azure AD. Ini menghilangkan kebutuhan untuk mengonfigurasi info masuk secara eksplisit untuk aplikasi ini. Arsitektur ini menetapkan identitas terkelola ke aplikasi web.
Key Vault menyimpan rahasia dan info masuk apa pun yang diperlukan oleh aplikasi. Gunakan opsi ini untuk menyimpan rahasia langsung dalam aplikasi.
Azure Pipelines menyediakan kemampuan Continuous Integration dan Continuous Deployment dalam arsitektur ini. Karena ASE bersifat internal ke jaringan virtual, mesin virtual digunakan sebagai jumpbox di dalam VNet untuk menyebarkan aplikasi dalam paket App Service. Alur tersebut membangun aplikasi di luar VNet. Untuk keamanan yang ditingkatkan dan konektivitas RDP/SSH yang mulus, pertimbangkan untuk menggunakan Azure Bastion yang baru dirilis sebagai jumpbox.
Konfigurasi multi-situs
ASE 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. ASE menetapkan URL default ke setiap aplikasi App Service sebagai <default-appName>.<ASE-domain>.appserviceenvironment.net. Zona DNS privat dibuat yang memetakan nama domain ASE ke alamat IP ASE ILB. Ini menghindari penggunaan DNS kustom untuk mengakses aplikasi di dalam VNet.
App Gateway dikonfigurasi sedemikian rupa sehingga pendengar mendengarkan di port HTTPS untuk permintaan ke alamat IP Gateway. Untuk kesederhanaan, penerapan ini tidak menggunakan pendaftaran nama DNS publik, dan mengharuskan Anda untuk memodifikasi file localhost di komputer Anda untuk mengarahkan URL yang dipilih secara sewenang-wenang ke IP App Gateway. Untuk kesederhanaan, pendengar menggunakan sertifikat yang ditandatangani sendiri untuk memproses permintaan ini. App Gateway memiliki kumpulan backend untuk URL default setiap aplikasi App Service. Aturan perutean dikonfigurasi untuk menyambungkan pendengar ke kumpulan backend. Pengaturan HTTP dibuat yang menentukan apakah koneksi antara gateway dan ASE akan dienkripsi. Pengaturan ini juga digunakan untuk mengganti header host HTTP yang masuk dengan nama host yang diambil dari kumpulan backend. Penerapan ini menggunakan sertifikat default yang dibuat untuk URL aplikasi ASE default, yang dipercaya oleh gateway. Permintaan dialihkan ke URL default aplikasi yang sesuai. DNS privat yang ditautkan ke VNet meneruskan permintaan ini ke IP ILB. ASE kemudian meneruskan ini ke layanan Aplikasi yang diminta. Komunikasi HTTP apa pun dalam aplikasi ASE, melalui DNS privat. Perhatikan bahwa pendengar, kumpulan backend, aturan perutean, dan pengaturan HTTP perlu dikonfigurasi di App Gateway untuk setiap aplikasi ASE.
Jelajahi appgw.json dan dns.json untuk memahami bagaimana konfigurasi ini dibuat untuk memungkinkan beberapa situs. Aplikasi web bernama testapp adalah aplikasi kosong yang dibuat untuk mendemonstrasikan konfigurasi ini. File JSON ini diakses dari skrip penyebaran deploy_std.sh. Ini juga diakses oleh deploy_ha.sh, yang digunakan untuk penyebaran ASE multi-situs dengan ketersediaan tinggi.
Pertimbangan
Keamanan
Lingkungan App Service
ASE 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. Setiap aplikasi ASE dengan titik akhir HTTP, dapat diakses melalui ILB, dari dalam jaringan virtual. App 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 ASE. Sertifikat ini dapat memperketat keamanan lalu lintas antara gateway dan aplikasi, dan mungkin diperlukan dalam skenario tertentu. Sertifikat ini tidak akan terlihat oleh browser klien, hanya dapat merespons sertifikat yang dikonfigurasi di App Gateway.
App Gateway
Penerapan referensi mengonfigurasi App Gateway secara terprogram di appgw.json. File deploy_std.sh menggunakan konfigurasi ini saat menyebarkan gateway:
az deployment group create --resource-group $RGNAME --template-file templates/appgw.json --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 Ringkasan penghentian TLS dan TLS secara menyeluruh dengan Application Gateway, App Gateway dapat menggunakan Transport Layer Security (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 secara menyeluruh. 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.
Penerapan referensi ini menggunakan sertifikat yang ditandatangani sendiri untuk App Gateway. Untuk kode produksi, sertifikat yang dikeluarkan oleh Otoritas Sertifikat harus digunakan. Untuk daftar jenis sertifikat yang didukung, baca 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.json mengonfigurasi ini secara terprogram:
{
"name": "httpListeners",
"count": "[length(parameters('appgwApplications'))]",
"input": {
"name": "[concat(variables('appgwListenerName'), parameters('appgwApplications')[copyIndex('httpListeners')].name)]",
"properties": {
"frontendIPConfiguration": {
"id": "[concat(variables('appgwId'), '/frontendIPConfigurations/', variables('appgwFrontendName'))]"
},
"frontendPort": {
"id": "[concat(variables('appgwId'), '/frontendPorts/port_443')]"
},
"protocol": "Https",
"sslCertificate": {
"id": "[concat(variables('appgwId'), '/sslCertificates/', variables('appgwSslCertificateName'), parameters('appgwApplications')[copyIndex('httpListeners')].name)]"
},
"hostName": "[parameters('appgwApplications')[copyIndex('httpListeners')].hostName]",
"requireServerNameIndication": true
}
}
},
Untuk lalu lintas antara aplikasi web di ASE dan gateway, 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. App Gateway mempercayai sertifikat SSL default karena dikeluarkan oleh Microsoft. Baca Mengonfigurasi App Service dengan Application Gateway untuk mengetahui bagaimana konfigurasi ini dibuat. Baris berikut di appgw.json menunjukkan bagaimana ini dikonfigurasi dalam penerapan referensi:
{
"name": "backendHttpSettingsCollection",
"count": "[length(parameters('appgwApplications'))]",
"input": {
"name": "[concat(variables('appgwHttpSettingsName'), parameters('appgwApplications')[copyIndex('backendHttpSettingsCollection')].name)]",
"properties": {
"Port": 443,
"Protocol": "Https",
"cookieBasedAffinity": "Disabled",
"pickHostNameFromBackendAddress": true,
"requestTimeout": 20,
"probe": {
"id": "[concat(variables('appgwId'), '/probes/', variables('appgwHealthProbeName'), parameters('appgwApplications')[copyIndex('backendHttpSettingsCollection')].name)]"
}
}
}
},
Web Application Firewall
Web Application Firewall (WAF) pada 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. Penerapan referensi memungkinkan WAF secara terprogram dalam file appgw.json dengan cuplikan berikut:
"webApplicationFirewallConfiguration": {
"enabled": true,
"firewallMode": "Detection",
"ruleSetType": "OWASP",
"ruleSetVersion": "3.0"
},
Virtual Network
Grup keamanan jaringan dapat dikaitkan dengan satu atau beberapa subnet di VNet. Ini adalah aturan keamanan yang mengizinkan atau menolak lalu lintas mengalir di antara berbagai sumber daya Azure. Arsitektur ini mengaitkan NSG terpisah untuk setiap subnet. Hal ini memungkinkan penyempurnaan aturan ini per subnet, sesuai dengan layanan yang terdapat dalam subnet tersebut. Misalnya, jelajahi konfigurasi untuk "type": "Microsoft.Network/networkSecurityGroups" dalam file ase.json untuk NSG untuk subnet ASE, dan dalam file appgw.json untuk NSG untuk subnet App Gateway.
Titik akhir layanan memperluas ruang alamat dan identitas privat VNet Anda untuk mendukung layanan Azure, membatasi akses ke layanan ini hanya untuk VNet Anda. Untuk meningkatkan keamanan, titik akhir layanan harus diaktifkan pada subnet ASE untuk layanan Azure apa pun yang mendukungnya. Layanan tersebut kemudian dapat diamankan ke VNet perusahaan dengan menetapkan aturan jaringan virtual pada layanan, yang secara efektif memblokir akses dari internet publik. Infrastruktur ASE menyiapkan titik akhir layanan untuk Event Hub, SQL Server, dan Storage, untuk manajemennya sendiri, meskipun arsitektur itu sendiri mungkin tidak menggunakannya, seperti yang disebutkan di bagian Arsitektur Sistem di artikel ini. Arsitektur ini mengonfigurasi titik akhir layanan untuk layanan yang digunakan, yang mendukung ini: Azure Service Bus, SQL Server, Key Vault, dan CosmosDB. Jelajahi konfigurasi ini di ase.json, sebagai "type": "Microsoft.Network/virtualNetworks/subnets" -->"properties" -->"serviceEndpoints".
Mengaktifkan titik akhir layanan pada subnet adalah proses dua langkah. Sumber daya itu sendiri perlu dikonfigurasi untuk menerima lalu lintas di titik akhir layanan dari jaringan virtual ini. Untuk informasi selengkapnya, baca Membatasi akses jaringan ke sumber daya .
Firewall
Azure Firewall dan titik akhir layanan saling melengkapi. Sementara titik akhir layanan melindungi sumber daya dengan membatasi lalu lintas masuk yang berasal dari jaringan virtual Anda, Azure Firewall memungkinkan Anda membatasi lalu lintas keluar dari aplikasi Anda. Sebaiknya membiarkan semua lalu lintas keluar melewati subnet firewall, termasuk lalu lintas titik akhir layanan. Hal ini memungkinkan pemantauan lalu lintas keluar yang lebih baik. Namun, infrastruktur ASE memerlukan titik akhir layanan untuk SQL Server, Storage, dan Azure Event Hubs untuk dikonfigurasi pada subnet ASE. Lihat Mengunci Lingkungan App Service untuk diskusi tentang integrasi firewall. Selain itu, penerapan ini menggunakan CosmosDB dalam mode koneksi langsung, yang memerlukan berbagai port untuk dibuka. Ini dapat memperumit konfigurasi firewall. Untuk kesederhanaan, arsitektur referensi ini mengonfigurasi semua titik akhir layanan pada subnet ASE, bukan subnet firewall. Ini termasuk titik akhir untuk Azure Service Bus, CosmosDB, dan Key Vault, selain yang diperlukan oleh infrastruktur ASE.
Lihat Mengonfigurasi Azure Firewall dengan ASE Anda untuk mempelajari bagaimana firewall terintegrasi dengan ASE. Setiap lalu lintas yang tidak melewati titik akhir layanan dan tabel rute jaringan virtual, akan dipantau dan dijaga oleh firewall. Kebutuhan untuk tabel rute dijelaskan di bagian berikut.
IP Manajemen ASE
Lalu lintas manajemen ASE mengalir melalui jaringan virtual perusahaan. Lalu lintas ini harus diarahkan langsung ke alamat IP khusus di luar jaringan virtual, menghindari firewall. Ini dicapai dengan membuat tabel rute jaringan virtual yang ditentukan pengguna. Artikel Alamat manajemen Lingkungan App Service mencantumkan alamat IP ini. Daftar ini bisa menjadi terlalu panjang untuk dikonfigurasi di firewall secara manual. Penerapan ini menunjukkan bagaimana ini dapat diisi secara terprogram. Baris berikut di deploy_std.sh memperoleh daftar ini menggunakan Azure CLI dan jq, parser JSON baris perintah:
ENDPOINTS_LIST=$(az rest --method get --uri $ASE_ID/inboundnetworkdependenciesendpoints?api-version=2016-09-01 | jq '.value[0].endpoints | join(", ")' -j)
Ini setara dengan metode terdokumentasi untuk mendapatkan alamat manajemen dari API.
Perintah berikut di deploy_std.sh membuat jaringan virtual bersama dengan tabel rute, seperti yang dikonfigurasi di network.json:
VNET_NAME=$(az network vnet list -g $RGNAME --query "[?contains(addressSpace.addressPrefixes, '${NET_PREFIX}')]" --query [0].name -o tsv)
az deployment group create --resource-group $RGNAME --template-file templates/network.json --parameters existentVnetName=$VNET_NAME vnetAddressPrefix=$NET_PREFIX
VNET_NAME=$(az deployment group show -g $RGNAME -n network --query properties.outputs.vnetName.value -o tsv)
VNET_ROUTE_NAME=$(az deployment group show -g $RGNAME -n network --query properties.outputs.vnetRouteName.value -o tsv)
Saat subnet ASE dibuat, tabel rute dikaitkan dengannya:
az deployment group create --resource-group $RGNAME --template-file templates/ase.json -n ase --parameters vnetName=$VNET_NAME vnetRouteName=$VNET_ROUTE_NAME aseSubnetAddressPrefix=$ASE_PREFIX
Saat firewall dibuat, file konfigurasi firewall.json memperbarui tabel rute ini dengan IP manajemen ASE, diikuti dengan IP firewall. Ini mendorong lalu lintas yang tersisa melalui IP firewall:
"variables": {
"firewallSubnetName": "AzureFirewallSubnet",
"firewallPublicIpName": "[concat('firewallIp', '-', uniqueString(resourceGroup().id))]",
"firewallName": "[concat('firewall', '-', uniqueString(resourceGroup().id))]",
"aseManagementEndpoints": "[split(replace(parameters('aseManagementEndpointsList') ,' ', ''), ',')]",
"copy": [
{
"name": "aseManagementIpRoutes",
"count": "[length(variables('aseManagementEndpoints'))]",
"input": {
"name": "[replace(variables('aseManagementEndpoints')[copyIndex('aseManagementIpRoutes')], '/', '-')]",
"properties": {
"addressPrefix": "[variables('aseManagementEndpoints')[copyIndex('aseManagementIpRoutes')]]",
"nextHopType": "Internet"
}
}
}
]
},
"resources": [
{
"type": "Microsoft.Network/routeTables",
"apiVersion": "2019-11-01",
"name": "[parameters('vnetRouteName')]",
"location": "[parameters('location')]",
"tags": {
"displayName": "UDR - Subnet"
},
"dependsOn": [
"[resourceId('Microsoft.Network/azureFirewalls', variables('firewallName'))]"
],
"properties": {
"routes": "[concat(variables('aseManagementIpRoutes'), array(json(concat('{ \"name\": \"Firewall\", \"properties\": { \"addressPrefix\": \"0.0.0.0/0\", \"nextHopType\": \"VirtualAppliance\", \"nextHopIpAddress\": \"', reference(concat('Microsoft.Network/azureFirewalls/', variables('firewallName')),'2019-09-01','Full').properties.ipConfigurations[0].properties.privateIPAddress, '\" } }'))))]"
}
},
Daftar IP manajemen dapat berubah setelah tabel rute disebarkan, dalam hal ini tabel rute ini perlu disebarkan ulang.
Azure Active Directory
Azure Active Directory menyediakan fitur keamanan untuk mengautentikasi aplikasi dan mengotorisasi akses ke sumber daya. Arsitektur referensi ini menggunakan dua fitur utama Azure Active Directory: identitas terkelola, dan kontrol akses berbasis peran Azure.
Saat membangun aplikasi cloud, info masuk 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 Azure AD. Identitas ini dapat digunakan untuk mengautentikasi ke layanan apa pun yang mendukung autentikasi Azure AD, termasuk Key Vault, tanpa info masuk 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, perwakilan 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 ASE dengan mengontrol secara ketat peran yang diperlukan dan jenis akses untuk setiap aplikasi. Dengan cara ini, beberapa aplikasi dapat digunakan pada ASE 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, namun layanan tersebut menggunakan Azure RBAC untuk menyiapkan izin aplikasi. Misalnya, lihat peran bawaan Azure Service Bus, serta 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 Azure Service Bus, ini adalah Tanda Tangan Akses Bersama,
- Untuk CosmosDB, ini adalah Kunci Master.
String koneksi untuk kebijakan kontrol akses ini kemudian disimpan di Key Vault. Vault itu sendiri diakses melalui identitas terkelola, yang tidak 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.
Cuplikan berikut di services.json menunjukkan konfigurasi KeyVault untuk layanan ini:
{
"type": "Microsoft.KeyVault/vaults/secrets",
"name": "[concat(variables('keyVaultName'), '/CosmosKey')]",
"apiVersion": "2015-06-01",
"dependsOn": [
"[resourceId('Microsoft.KeyVault/vaults', variables('keyVaultName'))]",
"[resourceId('Microsoft.DocumentDB/databaseAccounts', variables('cosmosName'))]"
],
"properties": {
"value": "[listKeys(resourceId('Microsoft.DocumentDB/databaseAccounts',variables('cosmosName')),'2015-04-08').primaryMasterKey]"
}
},
{
"type": "Microsoft.KeyVault/vaults/secrets",
"name": "[concat(variables('keyVaultName'), '/ServiceBusListenerConnectionString')]",
"apiVersion": "2015-06-01",
"dependsOn": [
"[resourceId('Microsoft.KeyVault/vaults', variables('keyVaultName'))]",
"[resourceId('Microsoft.ServiceBus/namespaces/AuthorizationRules', variables('serviceBusName'), 'ListenerSharedAccessKey')]"
],
"properties": {
"value": "[listKeys(resourceId('Microsoft.ServiceBus/namespaces/AuthorizationRules',variables('serviceBusName'),'ListenerSharedAccessKey'),'2015-08-01').primaryConnectionString]"
}
},
{
"type": "Microsoft.KeyVault/vaults/secrets",
"name": "[concat(variables('keyVaultName'), '/ServiceBusSenderConnectionString')]",
"apiVersion": "2015-06-01",
"dependsOn": [
"[resourceId('Microsoft.KeyVault/vaults', variables('keyVaultName'))]",
"[resourceId('Microsoft.ServiceBus/namespaces/AuthorizationRules', variables('serviceBusName'), 'SenderSharedAccessKey')]"
],
"properties": {
"value": "[listKeys(resourceId('Microsoft.ServiceBus/namespaces/AuthorizationRules',variables('serviceBusName'),'SenderSharedAccessKey'),'2015-08-01').primaryConnectionString]"
}
},
Nilai string koneksi ini diakses oleh aplikasi, dengan merujuk pasangan kunci/nilai Key Vault. Ini dilakukan di file sites.json seperti yang ditunjukkan cuplikan berikut untuk Aplikasi Pemungutan Suara:
"properties": {
"enabled": true,
"name": "[variables('votingWebName')]",
"hostingEnvironment": "[variables('aseId')]",
"serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('votingWebPlanName'))]",
"siteConfig": {
"appSettings": [
{
...
...
...
{
"name": "ConnectionStrings:sbConnectionString",
"value": "[concat('@Microsoft.KeyVault(SecretUri=', reference(resourceId('Microsoft.KeyVault/vaults/secrets', parameters('keyVaultName'), variables('serviceBusSenderConnectionStringSecretName')), '2016-10-01').secretUriWithVersion, ')')]"
},
...
...
{
"name": "ConnectionStrings:RedisConnectionString",
"value": "[concat('@Microsoft.KeyVault(SecretUri=', reference(resourceId('Microsoft.KeyVault/vaults/secrets', parameters('keyVaultName'), variables('redisSecretName')), '2016-10-01').secretUriWithVersion, ')')]"
},
...
...
{
"name": "ConnectionStrings:CosmosKey",
"value": "[concat('@Microsoft.KeyVault(SecretUri=', reference(resourceId('Microsoft.KeyVault/vaults/secrets', parameters('keyVaultName'), variables('cosmosKeySecretName')), '2016-10-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. Baca Meningkatkan skalabilitas dalam aplikasi web Azure untuk mempelajari cara mendesain aplikasi web yang skalabel menggunakan Azure App Service.
App Gateway Penskalaan Otomatis
Penskalaan Otomatis dapat diaktifkan di Azure Application Gateway V2. Hal ini memungkinkan App Gateway untuk meningkatkan atau menurunkan berdasarkan pola beban lalu lintas. Arsitektur referensi ini mengonfigurasi autoscaleConfiguration dalam file appgw.json untuk menskalakan 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 ASE, layanan lain, dan aplikasi di dalam ASE. 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 ASE.
Aplikasi dapat digunakan ke ASE internal hanya dari dalam jaringan virtual. Tiga metode berikut banyak digunakan untuk menyebarkan aplikasi ASE:
Secara manual di dalam Virtual Network: Buat mesin virtual di dalam ASE VNet dengan alat yang diperlukan untuk penyebaran. Buka koneksi RDP ke VM menggunakan konfigurasi NSG. Salin artefak kode Anda ke VM, bangun, dan sebarkan ke subnet ASE. 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 untuk memperluas ASE VNet ke mesin pengembangan Anda, dan menyebarkan dari sana. Ini adalah cara lain untuk menyiapkan lingkungan pengembang awal, dan tidak direkomendasikan untuk produksi.
Melalui Azure Pipelines: Ini menerapkan alur CI/CD lengkap, yang diakhiri dengan agen yang terletak di dalam VNet. Ini sangat ideal untuk lingkungan produksi yang membutuhkan throughput penyebaran yang tinggi. Alur build tetap sepenuhnya berada di luar VNet. Alur penyebaran menyalin objek yang dibangun ke agen build di dalam VNet, dan kemudian disebarkan ke subnet ASE. Untuk informasi selengkapnya, baca diskusi ini tentang agen build yang dihost sendiri antara Alur dan ASE VNet.
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 VNet. 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 VNet, biasanya di akun penyimpanan. Akun penyimpanan harus dapat diakses dari ASE. Alur harus dapat mengakses penyimpanan. Pada akhir alur rilis, file zip dapat dihilangkan ke penyimpanan blob. ASE 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 perlu menginstal ekstensi dan alat khusus pada ASE untuk dapat digunakan 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
Ada berbagai opsi harga yang tersedia untuk App Service. Lingkungan App Service disebarkan menggunakan Paket Layanan Terisolasi. Dalam paket ini, ada tiga opsi untuk ukuran CPU - I1, I2, dan I3. Penerapan referensi ini menggunakan tiga I1 per instans.
Application Gateway
Harga Application Gateway menyediakan berbagai opsi harga untuk App Gateway. Kami menggunakan Application Gateway Standard_v2 dan WAF_v2 SKU, yang mendukung penskalaan otomatis dan redundansi zona. Baca artikel ini untuk mengetahui lebih lanjut tentang model penetapan 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 ASE:
Menyebarkan skenario ini
Untuk menyebarkan penerapan referensi untuk arsitektur ini, lihat readme GitHub, dan ikuti skrip untuk penyebaran standar.
Langkah berikutnya
- Menjalankan aplikasi Anda di Azure App Service langsung dari paket ZIP
- Skema YAML Azure Pipelines
- Mendapatkan alamat manajemen Anda dari API
Sumber daya terkait
Untuk mempelajari cara memperluas arsitektur ini untuk mendukung ketersediaan tinggi, baca Penyebaran aplikasi ketersediaan tinggi menggunakan Lingkungan App Services.