Mengonfigurasi Azure Application Gateway
Application Gateway memiliki serangkaian komponen yang digabungkan untuk merutekan permintaan ke kumpulan server web dan untuk memeriksa kesehatan server web ini.
Konfigurasi frontend
Anda dapat mengonfigurasi application gateway untuk memiliki alamat IP publik, alamat IP privat, atau keduanya. Alamat IP publik diperlukan saat Anda menghosting back end yang harus diakses klien melalui internet melalui IP virtual akses internet.
Konfigurasi backend
Kumpulan backend digunakan untuk merutekan permintaan ke server backend yang melayani permintaan. Kumpulan backend dapat terdiri dari NIC, set skala komputer virtual, alamat IP publik, alamat IP internal, nama domain yang sepenuhnya memenuhi syarat (FQDN), dan back-end multi-penyewa seperti Azure App Service. Anda dapat membuat kumpulan backend kosong dengan gateway aplikasi Anda, lalu menambahkan target backend ke kumpulan backend.
Mengonfigurasi pemeriksaan kesehatan
Azure Application Gateway secara default memantau kesehatan semua sumber daya di kumpulan ujung belakangnya dan secara otomatis menghapus sumber daya apa pun yang dianggap tidak sehat dari kumpulan. Application Gateway terus memantau instans yang tidak sehat dan menambahkannya kembali ke kumpulan back-end yang sehat setelah tersedia dan merespons pemeriksaan kesehatan. Secara default, Application gateway mengirimkan pemeriksaan kesehatan dengan port yang sama yang ditentukan dalam pengaturan HTTP ujung belakang. Port pemeriksaan kustom dapat dikonfigurasikan menggunakan pemeriksaan kesehatan kustom.
Alamat IP sumber yang digunakan Application Gateway untuk pemeriksaan kesehatan bergantung pada kumpulan backend:
- Jika alamat server di kumpulan ujung belakang adalah titik akhir publik, maka alamat sumber adalah alamat IP publik ujung depan gateway aplikasi.
- Jika alamat server di kumpulan ujung belakang adalah titik akhir privat, maka alamat IP sumber berasal dari ruang alamat IP pribadi subnet gateway aplikasi.
Pemeriksaan kesehatan default
Gateway aplikasi otomatis mengonfigurasi pemeriksaan kesehatan default jika Anda tidak menyiapkan konfigurasi pemeriksaan kustom apa pun. Perilaku pemantauan bekerja dengan membuat permintaan HTTP GET ke alamat IP atau FQDN yang dikonfigurasi di kumpulan ujung belakang. Untuk pemeriksaan default jika pengaturan http ujung belakang dikonfigurasi untuk HTTPS, pemeriksaan menggunakan HTTPS untuk menguji kesehatan server ujung belakang.
Misalnya: Anda mengonfigurasi gateway aplikasi untuk menggunakan server ujung belakang A, B, dan C untuk menerima lalu lintas jaringan HTTP di port 80. Pemantauan kesehatan default menguji tiga server setiap 30 detik untuk respons HTTP yang sehat dengan batas waktu 30 detik untuk setiap permintaan. Respons HTTP yang sehat memiliki kode status antara 200 dan 399. Dalam hal ini, permintaan HTTP GET untuk pemeriksaan kesehatan terlihat seperti http://127.0.0.1/.
Jika pemantauan pemeriksaan default gagal untuk server A, gateway aplikasi berhenti meneruskan permintaan ke server ini. Pemeriksaan default akan terus memeriksa server A setiap 30 detik. Ketika server A berhasil merespons satu permintaan dari pemeriksaan kesehatan default, gateway aplikasi mulai meneruskan permintaan ke server lagi.
Pengaturan pemeriksaan kesehatan default
Tabel berikut mencantumkan pengaturan pemeriksaan kesehatan default:
| Properti pemeriksaan | Nilai | Keterangan |
|---|---|---|
| URL Pemeriksaan | <protocol>://127.0.0.1:<port>/ |
Protokol dan port diwarisi dari pengaturan HTTP ujung belakang yang dikaitkan dengan pemeriksaan |
| Interval | 30 | Jumlah waktu dalam hitungan detik untuk menunggu sebelum pemeriksaan kesehatan berikutnya dikirim. |
| Waktu habis | 30 | Jumlah waktu dalam detik gateway aplikasi menunggu respons pemeriksaan sebelum menandai pemeriksaan tersebut sebagai tidak sehat. Jika pemeriksaan kembali sebagai sehat, ujung belakang yang sesuai segera ditandai sebagai sehat. |
| Ambang tidak sehat | 3 | Mengatur berapa banyak pemeriksaan untuk dikirim jika ada kegagalan pemeriksaan kesehatan biasa. Dalam SKU v1, pemeriksaan kesehatan tambahan ini dikirim secara cepat berturut-turut untuk menentukan kesehatan ujung belakang dengan cepat dan tidak menunggu jeda pemeriksaan. Dalam kasus SKU v2 pemeriksaan kesehatan menunggu jeda. Server ujung belakang ditandai ke bawah setelah jumlah kegagalan pemeriksaan berurutan mencapai ambang buruk. |
Interval pemeriksaan
Semua instans Application Gateway menyelidiki ujung belakang independen satu sama lain. Konfigurasi pemeriksaan yang sama berlaku untuk setiap instans Application Gateway. Misalnya, jika konfigurasi pemeriksaan adalah mengirim pemeriksaan kesehatan setiap 30 detik dan gateway aplikasi memiliki dua instans, maka kedua instans mengirim pemeriksaan kesehatan setiap 30 detik.
Jika ada beberapa listener, setiap listener akan memeriksa backend secara terpisah satu sama lain.
Pemeriksaan kesehatan kustom
Pemeriksaan kustom memberi Anda memiliki kontrol yang lebih terperinci atas pemantauan kesehatan. Saat menggunakan pemeriksaan kustom, Anda dapat mengonfigurasi nama host kustom, jalur URL, jeda pemeriksaan, dan berapa banyak respons yang gagal diterima sebelum menandai instans kumpulan ujung belakang sebagai tidak sehat, dll.
Pengaturan pemeriksaan kesehatan kustom
Tabel berikut ini menyediakan definisi untuk properti pemeriksaan kesehatan kustom.
| Properti pemeriksaan | Keterangan |
|---|---|
| Nama | Nama pemeriksaan. Nama ini digunakan untuk mengidentifikasi dan merujuk ke pemeriksaan di pengaturan HTTP ujung belakang. |
| Protokol | Protokol yang digunakan untuk mengirim pemeriksaan. Properti ini harus cocok dengan protokol yang ditentukan dalam pengaturan HTTP back-end yang terkait dengannya |
| Host | Nama host untuk mengirimkan pemeriksaan. Di SKU v1, nilai ini hanya digunakan untuk header host permintaan pemeriksaan. Dalam SKU v2, digunakan sebagai header host dan SNI |
| Jalur | Jalur relatif dari pemeriksaan. Jalur yang valid dimulai dengan '/' |
| Port | Jika didefinisikan, properti ini digunakan sebagai port tujuan. Jika tidak, ia menggunakan port yang sama dengan pengaturan HTTP yang dikaitkan dengannya. Properti ini hanya tersedia di SKU v2 |
| Interval | Jeda pemeriksaan dalam hitungan detik. Nilai ini adalah jeda waktu antara dua pemeriksaan berurutan |
| Waktu habis | Menyelidiki waktu habis dalam hitungan detik. Jika respons yang valid tidak diterima dalam periode waktu habis ini, pemeriksaan ditandai sebagai gagal |
| Ambang tidak sehat | Menyelidiki jumlah percobaan kembali. Server ujung belakang ditandai ke bawah setelah jumlah kegagalan pemeriksaan berurutan mencapai ambang tidak sehat |
Pencocokan pemeriksaan
Secara default, respons HTTP dengan kode status antara 200 dan 399 dianggap sehat. Pemeriksaan kesehatan kustom juga mendukung dua kriteria yang cocok. Kriteria pencocokan dapat digunakan untuk secara opsional mengubah interpretasi default dari apa yang membuat respons yang sehat.
Berikut ini adalah kriteria yang cocok:
- Kecocokan kode status respons HTTP - Kriteria pencocokan pemeriksaan untuk menerima kode respons http yang ditentukan pengguna atau rentang kode respons. Kode status respons individual yang dipisahkan koma atau rentang kode status didukung.
- Kecocokan badan respons HTTP - Kriteria pencocokan pemeriksaan yang melihat badan respons HTTP dan cocok dengan string yang ditentukan pengguna. Kecocokan hanya mencari kehadiran string yang ditentukan pengguna dalam isi respons dan bukan kecocokan ekspresi reguler penuh.
Kriteria pencocokan dapat ditentukan menggunakan cmdlet New-AzApplicationGatewayProbeHealthResponseMatch.
Mengonfigurasi listener
Listener adalah entitas logis yang memeriksa permintaan koneksi masuk dengan menggunakan port, protokol, host, dan alamat IP. Saat mengonfigurasi listener, Anda harus memasukkan nilai yang cocok dengan masing-masing nilai dalam permintaan masuk di gateway.
Saat Anda membuat app gateway dengan menggunakan portal Microsoft Azure, Anda juga membuat listener default dengan memilih protokol dan port untuk listener. Anda bisa memilih apakah akan mengaktifkan dukungan HTTP2 pada listener. Setelah Anda membuat app gateway, Anda bisa mengedit pengaturan listener default tersebut (appGatewayHttpListener) atau membuat listener baru.
Tipe listener
Saat membuat listener baru, Anda harus memilih antara dasar dan multi-situs.
- Dasar: Semua permintaan untuk domain apa pun akan diterima dan diteruskan ke kumpulan backend.
- Multi-situs: Meneruskan permintaan ke kumpulan backend yang berbeda berdasarkan header host atau nama host. Anda harus menentukan nama host yang cocok dengan permintaan masuk. Hal ini karena App Gateway bergantung pada header host HTTP 1.1 untuk hosting lebih dari satu situs web pada port dan alamat IP publik yang sama.
Urutan pemrosesan listener
Untuk SKU v1, permintaan dicocokkan sesuai dengan urutan aturan dan jenis listener. Jika aturan dengan pendengar dasar lebih dulu dalam urutan, aturan diproses terlebih dahulu dan menerima permintaan apa pun untuk kombinasi port dan IP tersebut. Untuk menghindari hal ini, konfigurasikan aturan dengan listener multi-situs terlebih dahulu dan dorong aturan dengan listener dasar ke yang terakhir dalam daftar.
Untuk SKU v2, listener multi-situs diproses sebelum listener dasar.
Alamat IP front-end
Pilih alamat IP front-end yang anda rencanakan untuk diasosiasikan dengan listener ini. listener akan mendengarkan permintaan masuk pada IP ini.
Port front-end
Pilih port front-end. Pilih port yang sudah ada atau buat yang baru. Pilih nilai apa pun dari rentang port yang diizinkan. Anda bisa menggunakan tidak hanya port terkenal, seperti 80 dan 443, tetapi port kustom yang diizinkan yang cocok. Port bisa digunakan untuk listener umum atau listener pribadi.
Protokol
Pilih HTTP atau HTTPS:
- HTTP: lalu lintas antara klien dan gateway aplikasi tidak dienkripsi.
- HTTPS: memungkinkan penghentian TLS atau enkripsi TLS end-to-end. Koneksi TLS berakhir di gateway aplikasi. Lalu lintas antara klien dan gateway aplikasi dienkripsi. Jika Anda ingin enkripsi TLS end-to-end, Anda harus memilih HTTPS dan mengonfigurasi pengaturan HTTP back-end. Ini memastikan bahwa lalu lintas dienkripsi ulang ketika bepergian dari app gateway ke ujung belakang.
Untuk mengonfigurasi penghentian TLS dan enkripsi TLS end-to-end, Anda harus menambahkan sertifikat ke listener untuk mengaktifkan app gateway untuk memperoleh kunci konten. Kunci konten digunakan untuk mengenkripsi dan mendekripsi lalu lintas yang dikirim ke gateway. Sertifikat gateway harus dalam format Pertukaran Informasi Pribadi (PFX). Format ini memungkinkan Anda mengekspor kunci privat yang digunakan gateway untuk mengenkripsi dan mendekripsi lalu lintas.
Ringkasan pengalihan
Anda dapat menggunakan aplikasi gateway untuk mengalihkan lalu lintas. Ini memiliki mekanisme pengalihan generik yang memungkinkan untuk mengalihkan lalu lintas yang diterima pada satu listener ke listener lain atau ke situs eksternal. Hal ini mempermudah konfigurasi aplikasi, mengoptimalkan penggunaan sumber daya, dan mendukung skenario pengalihan baru, termasuk pengalihan global dan pengalihan berbasis jalur.
Skenario pengalihan umum untuk banyak aplikasi web mendukung pengalihan otomatis HTTP ke HTTPS untuk memastikan semua komunikasi antara aplikasi dan penggunanya terjalin melalui jalur yang terenkripsi. Dulu, Anda mungkin menggunakan teknik seperti pembuatan kumpulan ujung belakang khusus yang tujuan tunggalnya adalah untuk mengalihkan permintaan yang diterimanya di HTTP ke HTTPS. Dengan dukungan pengalihan di Application Gateway, Anda dapat melakukan tindakan ini cukup dengan menambahkan konfigurasi pengalihan baru ke aturan perutean dan menentukan listener lain dengan protokol HTTPS sebagai listener target.
Jenis pengalihan berikut ini didukung:
- 301 Pengalihan Permanen
- 302 Ditemukan
- 303 Lihat Lainnya
- 307 Pengalihan Sementara
Dukungan pengalihan Application Gateway menawarkan kemampuan berikut:
- Pengalihan global: Mengalihkan dari satu listener ke listener lain di gateway. Ini memungkinkan pengalihan HTTP ke HTTPS pada situs.
- Pengalihan berbasis jalur: Mengaktifkan pengalihan HTTP ke HTTPS hanya di area situs tertentu, misalnya area keranjang belanja yang ditandai dengan /cart/*.
- Pengalihan ke situs eksternal: Memerlukan objek konfigurasi pengalihan baru, yang menentukan listener target atau situs eksternal tujuan pengalihan. Elemen konfigurasi juga mendukung opsi untuk mengaktifkan penambahan jalur URI dan string kueri ke URL yang dialihkan. Konfigurasi pengalihan dilampirkan ke listener sumber melalui aturan baru.
Untuk informasi selengkapnya tentang mengonfigurasi pengalihan di Application Gateway, lihat Pengalihan berbasis jalur URL menggunakan PowerShell - Azure Application Gateway | Microsoft Docs.
Aturan perutean permintaan Application Gateway
Saat Anda membuat gateway aplikasi menggunakan portal Microsoft Azure, Anda membuat aturan default(aturan1). Aturan ini mengikat listener default (appGatewayHttpListener) dengan kumpulan ujung-belakang default (appGatewayBackendPool) dan pengaturan HTTP ujung-belakang default (appGatewayBackendHttpSettings). Setelah membuat gateway, Anda dapat mengedit pengaturan aturan default atau membuat aturan baru.
Jenis aturan:
- Aturan dasar meneruskan semua permintaan di listener terkait (misalnya, blog.contoso.com/*) ke kumpulan back-end tunggal.
- Aturan berbasis jalur merutekan permintaan dari jalur URL tertentu ke kumpulan back-end tertentu.
Urutan aturan pemrosesan
Untuk SKU v1 dan v2, pencocokan pola permintaan masuk diproses dalam urutan jalur yang tercantum dalam peta jalur URL aturan berbasis jalur. Jika permintaan sesuai dengan pola dalam dua jalur atau lebih pada peta jalur, maka jalur yang dicantumkan terlebih dahulu akan dicocokkan. Dan permintaan diteruskan ke back-end yang terkait dengan jalur tersebut.
Pendengar terkait
Kaitkan pendengar ke aturan tersebut, sehingga aturan perutean-permintaan yang terkait dengan pendengar dievaluasi untuk menentukan kumpulan ujung belakang yang akan dirutekan permintaannya.
Kumpulan ujung belakang terkait
Kaitkan dengan aturan kumpulan ujung belakang yang berisi target ujung belakang yang melayani permintaan yang diterima pendengar.
Untuk aturan dasar, hanya satu kumpulan back-end yang diizinkan. Semua permintaan pendengar terkait diteruskan menuju kumpulan back-end tersebut.
Untuk aturan berbasis jalur, tambahkan beberapa kumpulan ujung belakang yang sesuai dengan setiap jalur URL. Permintaan yang cocok dengan jalur URL yang dimasukkan akan diteruskan ke kumpulan ujung belakang yang sesuai. Selain itu, tambahkan kumpulan ujung belakang default. Permintaan yang tidak cocok dengan jalur URL apa pun dalam aturan akan diteruskan ke kumpulan tersebut.
Pengaturan HTTP ujung belakang terkait
Menambahkan pengaturan HTTP ujung belakang untuk setiap aturan. Permintaan dirutekan dari gateway aplikasi ke target ujung belakang dengan menggunakan nomor port, protokol, dan informasi lain yang ditentukan dalam pengaturan ini.
Untuk aturan dasar, hanya satu pengaturan HTTP back-end yang diizinkan. Semua permintaan pada pendengar terkait diteruskan ke target ujung belakang yang sesuai dengan menggunakan pengaturan HTTP ini.
Untuk aturan berbasis jalur, tambahkan beberapa pengaturan HTTP back-end yang sesuai dengan setiap jalur URL. Permintaan yang cocok dengan jalur URL dalam pengaturan ini diteruskan ke target back-end menggunakan pengaturan HTTP yang sesuai dengan setiap jalur URL. Selain itu, tambahkan pengaturan HTTP default. Permintaan yang tidak cocok dengan jalur URL apa pun dalam aturan ini diteruskan ke kumpulan ujung belakang default dengan menggunakan pengaturan HTTP default.
Pengaturan pengalihan
Jika pengalihan dikonfigurasi untuk aturan dasar, semua permintaan pendengar terkait dialihkan ke target. Ini adalah pengalihan global. Jika pengalihan dikonfigurasi untuk aturan berbasis jalur, hanya permintaan di area situs tertentu yang dialihkan. Contohnya adalah area keranjang belanja yang ditandai dengan /cart/*. Ini adalah pengalihan berbasis jalur.
Jenis pengalihan
Pilih jenis pengalihan yang diperlukan: Permanen(301), Sementara(307), Ditemukan(302), atau Lihat lainnya(303).
Target pengalihan
Pilih pendengar lain atau situs eksternal sebagai target pengalihan.
Listener
Pilih pendengar sebagai target pengalihan untuk mengalihkan lalu lintas dari satu pendengar ke pendengar lainnya di dalam gateway.
Situseksternal
Pilih situs eksternal jika Anda ingin mengalihkan lalu lintas pada pendengar yang terkait dengan aturan ini ke situs eksternal. Anda dapat memilih untuk menyertakan untai (karakter) kueri dari permintaan asli dalam permintaan yang diteruskan ke target pengalihan. Anda tidak dapat meneruskan jalur ke situs eksternal yang ada di permintaan asli.
Regenerasi header HTTP dan URL
Dengan menggunakan aturan regenerasi, Anda dapat menambahkan, menghapus, atau memperbarui permintaan HTTP(S) dan header respons serta jalur URL dan parameter string kueri saat paket permintaan dan respons berpindah antara klien dengan kumpulan ujung belakang melalui gateway aplikasi.
Parameter header dan URL dapat diatur ke nilai statik atau ke header dan variabel server lainnya. Hal tersebut membantu kasus penggunaan penting, seperti mengekstrak alamat IP klien, menghapus informasi sensitif tentang back-end, meningkatkan keamanan yang lebih banyak, dan sebagainya.
Mengonfigurasi perutean berbasis URL
Perutean Berbasis Jalur URL memungkinkan Anda merutekan lalu lintas ke kumpulan server backend berdasarkan Jalur URL permintaan. Salah satu kasus penggunaan adalah merutekan permintaan untuk berbagai jenis konten ke kumpulan server backend yang berbeda.
Untuk v1 SKU, aturan diproses sesuai urutan yang tercantum di portal. Jika pendengar dasar dicantumkan terlebih dahulu dan cocok dengan permintaan masuk, maka akan diproses oleh pendengar tersebut. Untuk v2 SKU, kecocokan persis memiliki prioritas yang lebih tinggi. Namun, sangat disarankan untuk mengonfigurasi listener multi-situs terlebih dahulu sebelum mengonfigurasi listener dasar. Ini memastikan bahwa lalu lintas dirutekan ke ujung belakang kanan.
Elemen konfigurasi urlPathMap
Elemen urlPathMap digunakan untuk menentukan pola Path ke pemetaan kumpulan server back-end. Contoh kode berikut adalah cuplikan elemen urlPathMap dari file templat.
"urlPathMaps": [{
"name": "{urlpathMapName}",
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/urlPathMaps/{urlpathMapName}",
"properties": {
"defaultBackendAddressPool": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendAddressPools/{poolName1}"
},
"defaultBackendHttpSettings": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendHttpSettingsList/{settingname1}"
},
"pathRules": [{
"name": "{pathRuleName}",
"properties": {
"paths": [
"{pathPattern}"
],
"backendAddressPool": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendAddressPools/{poolName2}"
},
"backendHttpsettings": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendHttpsettingsList/{settingName2}"
}
}
}]
}
}]
PathPattern
PathPattern adalah daftar pola jalur yang cocok. Masing-masing harus dimulai dengan / dan satu-satunya tempat "*" diizinkan adalah di akhir mengikuti "/." String yang disalurkan ke pencocok jalur tidak menyertakan teks apa pun setelah yang pertama? atau #, dan karakter tersebut tidak diizinkan di sini. Karakter apa pun yang diizinkan di URL juga diperbolehkan di PathPattern. Pola yang didukung bergantung pada apakah Anda menyebarkan Application Gateway v1 atau v2.
Aturan PathBasedRouting
RequestRoutingRule tipe PathBasedRouting digunakan untuk mengikat listener ke urlPathMap. Semua permintaan yang diterima untuk listener ini dirutekan berdasarkan kebijakan yang ditentukan di dalam urlPathMap.
Mengonfigurasi kebijakan regenerasi di Application Gateway
Application Gateway memungkinkan Anda meregenerasi konten permintaan dan respons yang dipilih. Dengan fitur ini, Anda dapat menerjemahkan URL, parameter untai kueri, serta mengubah header permintaan dan respons. Fitur ini juga memungkinkan Anda untuk menambahkan kondisi untuk memastikan bahwa URL atau header akan dapat diregenerasi ketika kondisi tertentu terpenuhi. Kondisi tersebut didasarkan pada informasi permintaan dan respons.
Fitur regenerasi header HTTP dan URL hanya tersedia untuk SKU Application Gateway v2.
Jenis regenerasi yang didukung
Application Gateway mendukung beberapa jenis regenerasi.
Header permintaan dan respons
Header HTTP memungkinkan klien dan server untuk meneruskan informasi tambahan dengan permintaan atau respons. Dengan menulis ulang header ini, Anda dapat menyelesaikan tugas-tugas penting, seperti menambahkan bidang header terkait keamanan seperti HSTS/ X-XSS-Protection, menghapus bidang header respons yang mungkin mengungkapkan informasi sensitif, dan menghapus informasi port dari header X-Forwarded-For.
Application Gateway memungkinkan Anda untuk menambah, menghapus, atau memperbarui permintaan HTTP dan header respons saat paket permintaan dan respons berpindah antara klien dan kumpulan ujung belakang.
Jalur URL dan string kueri
Dengan kemampuan regenerasi URL di Application Gateway, Anda dapat:
- Meregenerasi nama host, jalur, dan string kueri URL permintaan
- Pilih untuk meregenerasi URL dari semua permintaan pada seorang pendengar atau hanya permintaan yang cocok dengan satu atau beberapa kondisi yang Anda tetapkan. Kondisi ini didasarkan pada properti permintaan dan respons (permintaan, header, header respons, dan variabel server).
- Pilih untuk merutekan permintaan (pilih kumpulan backend) berdasarkan URL asli atau URL yang diregenerasi.
Tindakan menulis ulang
Anda menggunakan tindakan regenerasi untuk menentukan URL, header permintaan, atau header respons yang ingin Anda regenerasi dan nilai baru tempat Anda ingin melakukan regenerasi. Nilai URL atau header baru atau yang sudah ada dapat diatur ke jenis nilai berikut:
- Teks
- Header permintaan. Untuk menentukan header permintaan, Anda perlu menggunakan sintaks {http_req_headerName}
- Header respons. Untuk menentukan header respons, Anda perlu menggunakan sintaks {http_resp_headerName}
- Variabel server. Untuk menentukan variabel server, anda perlu menggunakan sintaks {var_serverVariable}. Lihat daftar variabel server yang didukung
Kombinasi teks, header permintaan, header respons, dan variabel server.
Kondisi regenerasi
Anda dapat menggunakan kondisi regenerasi, konfigurasi opsional, untuk mengevaluasi konten permintaan dan respons HTTP dan melakukan regenerasi hanya ketika satu atau beberapa kondisi terpenuhi. Gateway aplikasi menggunakan jenis variabel berikut untuk mengevaluasi konten permintaan dan respons:
- Header HTTP dalam permintaan
- Header HTTP dalam respons
- Variabel server Application Gateway
Anda dapat menggunakan kondisi untuk mengevaluasi apakah variabel tertentu ada, apakah variabel yang ditentukan cocok dengan nilai tertentu, atau dengan pola tertentu.
Konfigurasi Penulisan Ulang
Untuk mengonfigurasi aturan regenerasi, Anda perlu membuat seperangkat aturan regenerasi dan menambahkan konfigurasi aturan regenerasi di dalamnya.
Seperangkat aturan regenerasi berisi:
Meminta asosiasi aturan perutean: Konfigurasi regenerasi dikaitkan dengan pendengar sumber melalui aturan perutean. Ketika Anda menggunakan aturan perutean dasar, konfigurasi regenerasi dihubungkan dengan pendengar sumber dan merupakan regenerasi header global. Ketika Anda menggunakan aturan perutean berbasis jalur, konfigurasi regenerasi ditentukan pada peta jalur URL. Dalam hal ini, aturan hanya berlaku untuk area jalur tertentu dari sebuah situs. Anda dapat membuat beberapa set regenerasi dan menerapkan tiap set regenerasi ke beberapa pendengar. Tetapi Anda hanya dapat menerapkan satu set penulisan ulang ke listener tertentu.
Kondisi Regenerasi: Konfigurasi ini bersifat opsional. Kondisi Penulisan Ulang mengevaluasi konten permintaan dan respons dari HTTP. Tindakan penulisan ulang akan terjadi jika permintaan atau respons dari HTTP cocok dengan kondisi tulis ulang. Jika anda menghubungkan lebih dari satu kondisi dengan sebuah tindakan, tindakan tersebut hanya terjadi ketika semua kondisi terpenuhi. Dengan kata lain, ini adalah operasi AND logis.
Jenis penulisan ulang: Ada tiga jenis penulisan ulang yang tersedia:
Meregenerasi header permintaan
Meregenerasi header respons
Meregenerasi komponen URL
- Jalur URL: Nilai tempat jalur akan diregenerasi.
- String Kueri URL: Nilai tempat string kueri akan diregenerasi.
- Evaluasi ulang peta jalur: Digunakan untuk menentukan apakah peta jalur URL akan dievaluasi ulang atau tidak. Jika disimpan tanpa dicentang, jalur URL asli akan digunakan untuk mencocokkan pola jalur di peta jalur URL. Jika diatur ke true, peta jalur URL akan dievaluasi kembali untuk memeriksa kecocokan dengan jalur yang diregenerasi. Mengaktifkan tombol ini membantu dalam merutekan permintaan ke regenerasi pos kumpulan ujung belakang.
Untuk informasi selengkapnya tentang Mengonfigurasi regenerasi di Application Gateway, lihat Meregenerasi header HTTP dan HTTP dengan Azure Application Gateway | Microsoft Docs.