Google Cloud Application Load Balancer dan Cloud Service Mesh menggunakan resource konfigurasi Google Cloud yang disebut peta URL untuk merutekan permintaan HTTP(S) ke layanan backend atau bucket backend.
Misalnya, dengan Load Balancer Aplikasi eksternal, Anda dapat menggunakan satu peta URL untuk merutekan permintaan ke berbagai tujuan berdasarkan aturan yang dikonfigurasi di peta URL:
- Permintaan untuk
https://example.com/video
mengarah ke satu layanan backend. - Permintaan untuk
https://example.com/audio
mengarah ke layanan backend yang berbeda.
- Permintaan untuk
https://example.com/images
akan diarahkan ke bucket backend Cloud Storage.
- Permintaan untuk kombinasi host dan jalur lainnya mengarah ke layanan backend default.
Peta URL digunakan dengan produk Google Cloud berikut:
- Load Balancer Aplikasi Eksternal (mode global, regional, dan klasik)
- Load Balancer Aplikasi Internal (mode lintas region dan regional)
- Cloud Service Mesh, saat Cloud Service Mesh di-deploy dengan API load balancing
Ada dua jenis resource peta URL yang tersedia: global dan regional. Jenis resource yang Anda gunakan bergantung pada skema load balancing produk.
Produk | Skema load balancing | Jenis resource peta URL | Tujuan yang didukung |
---|---|---|---|
Load Balancer Aplikasi eksternal global | EXTERNAL_MANAGED |
Global, eksternal | Layanan backend, bucket backend |
Load Balancer Aplikasi Klasik | EXTERNAL |
Global, eksternal | Layanan backend, bucket backend |
Load Balancer Aplikasi eksternal regional | EXTERNAL_MANAGED |
Regional, eksternal | Layanan backend |
Load Balancer Aplikasi internal lintas region | INTERNAL_MANAGED |
Global, internal | Layanan backend |
Load Balancer Aplikasi internal regional | INTERNAL_MANAGED |
Regional, internal | Layanan backend |
Mesh Layanan Cloud | INTERNAL_SELF_MANAGED |
Global, internal | Layanan backend |
Tidak semua fitur peta URL tersedia untuk semua produk. Peta URL yang digunakan dengan Load Balancer Aplikasi eksternal global, Load Balancer Aplikasi eksternal regional, Load Balancer Aplikasi internal, dan Cloud Service Mesh juga mendukung beberapa fitur pengelolaan traffic lanjutan. Untuk mengetahui informasi selengkapnya tentang perbedaan ini, lihat Perbandingan fitur load balancer: Pengelolaan rute dan traffic. Selain itu, peta URL regional dapat berupa resource yang ditetapkan sebagai layanan di App Hub, yang dalam pratinjau.
Cara kerja peta URL
Saat permintaan tiba di load balancer, load balancer akan merutekan permintaan ke layanan backend tertentuatau bucket backend berdasarkan aturan yang ditentukan dalam peta URL.
Layanan backend mewakili kumpulan backend, yang merupakan instance aplikasi atau microservice. Bucket backend adalah bucket Cloud Storage, yang biasanya digunakan untuk menghosting konten statis, seperti gambar.
Untuk Load Balancer Aplikasi eksternal regional, Load Balancer Aplikasi internal, dan Cloud Service Mesh, kemungkinan tujuannya adalah sebagai berikut:
- Layanan backend default
- Layanan backend non-default
Selain itu, Load Balancer Aplikasi eksternal global mendukung hal berikut:
- Bucket backend default
- Bucket backend non-default
Misalnya, asumsikan Anda memiliki penyiapan berikut:
- Satu alamat IP:
- Semua permintaan ke organisasi Anda akan diarahkan ke alamat IP yang sama dan load balancer yang sama.
- Traffic diarahkan ke berbagai layanan backend berdasarkan URL permintaan.
- Dua domain:
example.net
menghosting video pelatihan.example.org
menghosting situs organisasi Anda.
- Empat kumpulan server:
- Satu host situs organisasi Anda (layanan backend:
org-site
). - Satu server menghosting situs video pelatihan secara keseluruhan (layanan backend:
video-site
). - Satu host video pelatihan definisi tinggi (HD) (layanan backend:
video-hd
). - Satu host video pelatihan definisi standar (SD) (layanan backend:
video-sd
).
- Satu host situs organisasi Anda (layanan backend:
Anda ingin hal berikut terjadi:
- Permintaan ke
example.org
(atau domain apa pun selainexample.net
) untuk membuka layanan backendorg-site
. - Permintaan ke
example.net
yang tidak cocok dengan jalur yang lebih spesifik untuk membuka layanan backendvideo-site
. - Permintaan ke
example.net/video/hd/*
untuk membuka layanan backendvideo-hd
. - Permintaan ke
example.net/video/sd/*
untuk membuka layanan backendvideo-sd
.
--path-rule
untuk /video/*
cocok dengan URI seperti /video/test1
dan /video/test2
. Namun, aturan jalur ini tidak cocok dengan jalur
/video
.
Jika load balancer menerima permintaan dengan /../
di URL, load
balancer akan mengubah URL dengan menghapus segmen jalur sebelum ..
, dan
merespons dengan URL yang diubah. Misalnya, saat permintaan dikirim untuk
http://example.net/video/../abc
, load balancer akan merespons dengan pengalihan
302 ke http://example.net/abc
. Sebagian besar klien kemudian bereaksi dengan mengeluarkan
permintaan ke URL yang ditampilkan oleh load balancer (dalam hal ini,
http://example.net/abc
). Pengalihan 302 ini tidak dicatat ke dalam log di Cloud Logging.
Peta URL memungkinkan Anda menyiapkan jenis perutean berbasis host dan jalur ini.
Penamaan
Setiap peta URL memiliki nama. Saat Anda membuat load balancer berbasis HTTP(S) menggunakan konsol Google Cloud, peta URL akan diberi nama. Nama ini sama dengan nama load balancer di Konsol Google Cloud. Jika menggunakan Google Cloud CLI atau API, Anda dapat menentukan nama kustom untuk peta URL.
Komponen peta URL
Peta URL adalah kumpulan resource konfigurasi Google Cloud yang mengarahkan permintaan untuk URL ke layanan backendatau bucket backend. Peta URL melakukannya dengan menggunakan bagian hostname dan path untuk setiap URL yang diprosesnya:
- Nama host adalah bagian nama domain dari URL; misalnya, bagian nama host dari URL
http://example.net/video/hd
adalahexample.net
. - Jalur adalah bagian dari URL yang mengikuti nama host dan nomor port opsional; misalnya, bagian jalur URL
http://example.net/video/hd
adalah/video/hd
.
Diagram ini menunjukkan struktur objek konfigurasi load balancing dalam kaitannya satu sama lain.
Anda mengontrol layanan backendatau bucket backend yang menerima permintaan masuk menggunakan parameter konfigurasi peta URL berikut:
- Layanan backend default atau bucket backend default. Saat membuat peta URL, Anda harus menentukan layanan backend default atau bucket backend default, tetapi tidak keduanya. Default ini mewakili layanan backend atau bucket backend yang dituju Google Cloud untuk permintaan URL dengan nama host apa pun, kecuali jika ada aturan host yang berlaku.
Aturan host (
hostRules
). Aturan host mengarahkan permintaan yang dikirim ke satu atau beberapa nama host terkait ke satu pencocok jalur (pathMatchers
). Bagian nama host dari URL dicocokkan persis dengan kumpulan nama host yang dikonfigurasi oleh aturan host. Dalam aturan host dan jalur peta URL, jika Anda menghapus host, aturan akan cocok dengan host yang diminta. Untuk mengarahkan permintaanhttp://example.net/video/hd
ke pencocok jalur, Anda memerlukan satu aturan host yang setidaknya menyertakan nama hostexample.net
. Aturan host yang sama juga dapat menangani permintaan untuk nama host lain, tetapi akan mengarahkan permintaan tersebut ke pencocok jalur yang sama.Jika perlu mengarahkan permintaan ke pencocok jalur yang berbeda, Anda harus menggunakan aturan host yang berbeda. Dua aturan host dalam peta URL tidak boleh menyertakan nama host yang sama.
Anda dapat mencocokkan semua nama host dengan menentukan karakter pengganti
*
dalam aturan host. Misalnya, untuk URLhttp://example.org
,http://example.net/video/hd
, danhttp://example.com/audio
, ketiga nama hostexample.org
,example.net
, danexample.com
dapat dicocokkan dengan menentukan*
dalam aturan host. Anda juga dapat mencocokkan nama host sebagian dengan menentukan karakter pengganti*
. Misalnya, aturan host*.example.net
dicocokkan dengan nama hostnews.example.net
danfinance.example.net
.- Nomor port. Load Balancer Aplikasi yang berbeda menangani nomor port dengan cara yang berbeda. Untuk Load Balancer Aplikasi internal, Anda dapat
menggunakan parameter Host rule untuk menentukan nomor port. Misalnya, untuk
mengarahkan permintaan
example.net
untuk port 8080, tetapkan aturan host keexample.net:8080
. Untuk Load Balancer Aplikasi klasik, hanya nama host di URL yang dipertimbangkan saat mencocokkan aturan host. Misalnya, permintaanexample.net
untuk port 8080 dan port 80 cocok dengan aturan hostexample.net
.
- Nomor port. Load Balancer Aplikasi yang berbeda menangani nomor port dengan cara yang berbeda. Untuk Load Balancer Aplikasi internal, Anda dapat
menggunakan parameter Host rule untuk menentukan nomor port. Misalnya, untuk
mengarahkan permintaan
Pencocok jalur (
pathMatchers
). Pencocok jalur adalah parameter konfigurasi yang dirujuk oleh aturan host. Peta URL menentukan hubungan antara bagian jalur URL dan layanan backend atau bucket backend yang harus menayangkan permintaan. Pencocok jalur terdiri dari dua elemen:Layanan backend default pencocok jalur atau bucket backend default pencocok jalur. Untuk setiap pencocok jalur, Anda harus setidaknya menentukan layanan backend default atau bucket backend default, tetapi tidak keduanya. Default ini mewakili layanan backend atau bucket backend yang diarahkan Google Cloud untuk permintaan URL yang nama host-nya cocok dengan aturan host yang terkait dengan pencocok jalur, dan jalur URL-nya tidak cocok dengan aturan jalur apa pun di pencocok jalur.
Aturan jalur. Untuk setiap pencocok jalur, Anda dapat menentukan satu atau beberapa aturan jalur, yang merupakan pasangan nilai kunci yang memetakan jalur URL ke satu layanan backend atau bucket backend. Bagian berikutnya berisi informasi selengkapnya tentang cara kerja aturan jalur.
Urutan operasi
Untuk nama host dan jalur tertentu di URL yang diminta, Google Cloud menggunakan prosedur berikut untuk mengarahkan permintaan ke layanan backend yang benar atau bucket backend, seperti yang dikonfigurasi di peta URL Anda:
Jika peta URL tidak berisi aturan host untuk nama host URL, Google Cloud akan mengarahkan permintaan ke layanan backend default peta URLatau bucket backend default, bergantung pada mana yang Anda tentukan.
Jika peta URL berisi aturan host yang menyertakan nama host URL, pencocok jalur yang dirujuk oleh aturan host tersebut akan dikonsultasikan:
Jika pencocok jalur berisi aturan jalur yang sama persis dengan jalur URL, Google Cloud akan mengarahkan permintaan ke layanan backend atau bucket backend untuk aturan jalur tersebut.
Jika pencocok jalur tidak berisi aturan jalur yang sama persis dengan jalur URL, tetapi berisi aturan jalur yang diakhiri dengan
/*
yang awalan -nya cocok dengan bagian terpanjang dari jalur URL, Google Cloud akan mengarahkan permintaan ke layanan backend atau bucket backend untuk aturan jalur tersebut. Misalnya, untuk peta URL yang berisi dua aturan pencocok jalur/video/hd/movie1
dan/video/hd/*
, jika URL berisi jalur yang sama/video/hd/movie1
, URL tersebut akan dicocokkan dengan aturan jalur tersebut.Jika tidak ada kondisi sebelumnya yang benar, Google Cloud akan mengarahkan permintaan ke layanan backend default pencocok jalur atau bucket backend default, bergantung pada mana yang Anda tentukan.
Batasan pencocok jalur
Nama host, pencocok jalur, dan aturan jalur memiliki batasan.
Karakter pengganti, ekspresi reguler, dan URL dinamis dalam aturan jalur
Aturan jalur hanya dapat menyertakan karakter pengganti (
*
) setelah karakter garis miring (/
). Misalnya,/videos/*
dan/videos/hd/*
valid untuk aturan jalur, tetapi/videos*
dan/videos/hd*
tidak valid.Aturan jalur tidak menggunakan ekspresi reguler atau pencocokan substring. PathTemplateMatch dapat menggunakan operator pencocokan jalur yang disederhanakan. Misalnya, aturan jalur untuk
/videos/hd
atau/videos/hd/*
tidak berlaku untuk URL dengan jalur/video/hd-abcd
. Namun, aturan jalur untuk/video/*
berlaku untuk jalur tersebut.Pencocok jalur (dan peta URL secara umum) tidak menawarkan fitur yang berfungsi seperti perintah
LocationMatch
Apache. Jika Anda memiliki aplikasi yang membuat jalur URL dinamis yang memiliki awalan umum, seperti/videos/hd-abcd
dan/videos/hd-pqrs
, dan Anda perlu mengirim permintaan yang dibuat ke jalur tersebut ke layanan backend yang berbeda, Anda mungkin tidak dapat melakukannya dengan peta URL. Untuk kasus yang hanya berisi beberapa kemungkinan URL dinamis, Anda mungkin dapat membuat pencocok jalur dengan serangkaian aturan jalur yang terbatas. Untuk kasus yang lebih kompleks, Anda perlu melakukan pencocokan ekspresi reguler berbasis jalur di backend.
Karakter pengganti dan operator pencocokan pola dalam template jalur untuk aturan rute
Operator pencocokan pola yang fleksibel memungkinkan Anda mencocokkan beberapa bagian jalur URL, termasuk URL parsial dan akhiran (ekstensi file), dengan menggunakan sintaksis karakter pengganti. Operator ini dapat membantu saat Anda perlu merutekan traffic dan menjalankan penulisan ulang berdasarkan jalur URL yang kompleks. Anda juga dapat mengaitkan satu atau beberapa komponen jalur dengan variabel bernama, lalu merujuk ke variabel tersebut saat menulis ulang URL. Dengan variabel bernama, Anda dapat mengurutkan ulang dan menghapus komponen URL sebelum permintaan dikirim ke origin.
Pencocokan pola dengan karakter pengganti hanya didukung untuk produk berikut:
- Load Balancer Aplikasi eksternal global
- Load Balancer Aplikasi eksternal regional
- Load Balancer Aplikasi internal regional
- Load Balancer Aplikasi internal lintas region
- Mesh Layanan Cloud
Contoh berikut merutekan traffic untuk aplikasi e-Commerce yang memiliki
layanan terpisah untuk informasi keranjang dan informasi pengguna.
Anda dapat mengonfigurasi routeRules
dengan operator pencocokan pola yang fleksibel dan
variabel bernama untuk mengirim ID unik pengguna ke halaman detail akun pengguna
dan informasi keranjang pengguna ke layanan pemrosesan keranjang setelah
menulis ulang URL.
pathMatchers:
- name: cart-matcher
routeRules:
- description: CartService
matchRules:
- pathTemplateMatch: '/xyzwebservices/v2/xyz/users/{username=*}/carts/{cartid=**}'
service: cart-backend
priority: 1
routeAction:
urlRewrite:
pathTemplateRewrite: '/{username}-{cartid}/'
- name: user-matcher
routeRules:
- description: UserService
matchRules:
- pathTemplateMatch: '/xyzwebservices/v2/xyz/users/*/accountinfo/*'
service: user-backend
priority: 1
Berikut ini yang terjadi saat klien meminta
/xyzwebservices/v2/xyz/users/abc@xyz.com/carts/FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB
,
yang memiliki informasi pengguna dan informasi keranjang:
- Jalur permintaan cocok dengan
pathTemplateMatch
dalam pathMatchercart-matcher
. Variabel{username=*}
cocok denganabc@xyz.com
dan variabel{cartid=**}
cocok denganFL0001090004/entries/SJFI38u3401nms
. - Parameter kueri dipisahkan dari jalur, jalur ditulis ulang
berdasarkan
pathTemplateRewrite
, dan parameter kueri ditambahkan ke jalur yang ditulis ulang. Kita hanya boleh menggunakan variabel yang sama dengan yang digunakan untuk menentukanpathTemplateMatch
dipathTemplateRewrite
. - Permintaan yang ditulis ulang dikirim ke
cart-backend
dengan jalur URL yang ditulis ulang:/abc@xyz.com-FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB
.
Hal berikut akan terjadi saat klien meminta
/xyzwebservices/v2/xyz/users/abc%40xyz.com/accountinfo/abc-1234
,
yang hanya memiliki informasi pengguna dan akun:
- Jalur permintaan cocok dengan
pathTemplateMatch
dalam pathMatcheruser-matcher
.*
pertama cocok denganabc%40xyz.com
dan*
kedua cocok denganabc-1234
. - Permintaan dikirim ke
user-backend
.
Tabel berikut menguraikan sintaksis untuk pola template jalur.
Operator | Mencocokkan dengan |
---|---|
* |
Satu segmen jalur, tidak termasuk karakter pemisah jalur
/ di sekitarnya. |
** |
Mencocokkan nol karakter atau lebih, termasuk karakter pemisah jalur
/ di antara beberapa segmen jalur. Jika operator lain
disertakan, operator ** harus berupa operator terakhir. |
{name} atau {name=*} |
Variabel bernama yang cocok dengan satu segmen jalur. Mencocokkan satu segmen
jalur, tidak termasuk karakter pemisah jalur /
di sekitarnya. |
{name=news/*} |
Variabel bernama yang secara eksplisit cocok dengan dua segmen jalur:
news dan segmen karakter pengganti * . |
{name=*/news/*} |
Variabel bernama yang cocok dengan tiga segmen jalur. |
{name=**} |
Variabel bernama yang cocok dengan nol atau beberapa karakter. Jika ada, harus berupa operator terakhir. |
Saat Anda menggunakan operator ini untuk pencocokan pola yang fleksibel, perhatikan pertimbangan berikut:
- Beberapa operator dapat digabungkan dalam satu pola.
- Parameter kueri dipisahkan dari jalur, jalur ditulis ulang
berdasarkan
pathTemplateRewrite
, dan parameter kueri ditambahkan ke jalur yang ditulis ulang. - Permintaan tidak dinormalisasi encoding persen. Misalnya, URL dengan karakter garis miring yang dienkode persen (%2F) tidak didekode menjadi bentuk yang tidak dienkode.
- Setiap nama variabel, seperti
{segment}
atau{region}
, hanya dapat muncul satu kali dalam pola yang sama. Beberapa variabel dengan nama yang sama tidak valid dan ditolak. - Nama variabel peka huruf besar/kecil dan harus berupa ID yang valid. Untuk memeriksa apakah
nama variabel valid, pastikan nama tersebut cocok dengan ekspresi reguler
^[a-zA-Z][a-zA-Z0-9_]*$
.{API}
,{api}
, dan{api_v1}
adalah ID yang valid. Laporan ini mengidentifikasi tiga variabel yang berbeda.{1}
,{_api}
, dan{10alpha}
bukan ID yang valid.
- Batas operator per pola template adalah lima.
Untuk menjalankan penulisan ulang URL opsional sebelum permintaan dikirim ke origin,
Anda dapat menggunakan variabel yang sama dengan yang Anda tentukan untuk mengambil jalur.
Misalnya, Anda dapat mereferensikan, mengurutkan ulang, atau menghapus variabel di
kolom pathTemplateRewrite
saat menentukan urlRewrite
.
Saat Anda menggunakan variabel dan operator untuk pencocokan pola yang fleksibel untuk penulisan ulang URL, perhatikan pertimbangan berikut:
- Saat menulis ulang URL, Anda dapat menghilangkan variabel jika tidak diperlukan sebagai bagian dari URL yang ditulis ulang.
- Sebelum penulisan ulang, Anda dapat mengidentifikasi URL yang dikirim oleh klien
di origin dengan memeriksa header respons. URL klien asli diisi
dengan header
x-client-request-url
dan headerx-envoy-original-path
.
Hubungan nama host dan aturan host
Nama host hanya dapat mereferensikan satu aturan host.
Satu aturan host dapat memproses beberapa nama host.
Hubungan aturan host dan pencocok jalur
Beberapa aturan host dapat mereferensikan satu pencocok jalur.
Aturan host hanya dapat mereferensikan satu pencocok jalur.
Diagram berikut menggambarkan poin-poin ini.
Hubungan URL dan backend
Setiap URL unik hanya diarahkan ke satu layanan backend atau bucket backend. Akibatnya:
Google Cloud menggunakan bagian nama host URL untuk memilih satu aturan host dan pencocok jalur yang dirujuknya.
Saat menggunakan aturan jalur di pencocok jalur, Anda tidak dapat membuat lebih dari satu aturan jalur untuk jalur yang sama. Misalnya, permintaan untuk
/videos/hd
tidak dapat diarahkan ke lebih dari satu layanan backend atau bucket backend. Layanan backend dapat memiliki grup instance backend atau grup endpoint jaringan backend (NEG) di zona dan region yang berbeda, dan Anda dapat membuat bucket backend yang menggunakan class Penyimpanan Multi-Regional.Untuk mengarahkan traffic untuk URL unik ke beberapa layanan, Anda dapat menggunakan aturan rute, bukan aturan jalur. Jika Anda mengonfigurasi pencocok jalur dengan aturan rute untuk pencocokan header atau parameter, URL unik dapat diarahkan ke lebih dari satu layanan backend atau bucket, berdasarkan konten header atau parameter kueri di URL.
Demikian pula untuk Load Balancer Aplikasi eksternal regional dan Cloud Service Mesh, layanan backend berbobot pada tindakan rute dapat mengarahkan URL yang sama ke beberapa layanan backend atau bucket, bergantung pada bobot yang ditetapkan pada layanan backend berbobot.
Peta dan protokol URL
Anda dapat menggunakan peta URL, aturan host, dan pencocok jalur yang sama untuk memproses permintaan HTTP dan HTTPS yang dikirimkan oleh klien, selama proxy HTTP target dan proxy HTTPS target mereferensikan peta URL.
Peta URL paling sederhana
Peta URL yang paling sederhana hanya memiliki layanan backend default atau bucket backend default. Aturan ini tidak berisi aturan host dan pencocok jalur. Layanan backend default atau bucket backend default (mana saja yang Anda tentukan) menangani semua URL yang diminta.
Jika Anda menentukan layanan backend default, Google Cloud akan mengarahkan permintaan ke grup instance backend atau NEG backend sesuai dengan konfigurasi layanan backend.
Contoh alur kerja peta URL dengan Load Balancer Aplikasi eksternal
Contoh berikut mengilustrasikan urutan operasi untuk peta URL. Contoh ini hanya mengonfigurasi peta URL untuk Load Balancer Aplikasi klasik yang ada. Untuk kesederhanaan konseptual, bucket ini hanya menggunakan layanan backend; tetapi, Anda dapat mengganti bucket backend. Untuk mempelajari cara membuat komponen load balancer lainnya, lihat Membuat Load Balancer Aplikasi klasik.
Untuk informasi selengkapnya tentang cara membuat dan mengonfigurasi peta URL dengan pencocok jalur dan aturan host, lihat dokumentasi gcloud compute url-maps create
.
Buat peta URL untuk load balancer dan tentukan layanan backend default. Contoh ini membuat peta URL bernama
video-org-url-map
yang mereferensikan layanan backend yang ada bernamaorg-site
.gcloud compute url-maps create video-org-url-map \ --default-service=org-site
Buat pencocok jalur bernama
video-matcher
dengan karakteristik berikut:- Layanan backend default adalah
video-site
, layanan backend yang ada. - Tambahkan aturan jalur yang mengarahkan permintaan untuk jalur URL yang tepat
/video/hd
atau awalan jalur URL/video/hd/*
ke layanan backend yang ada bernamavideo-hd
. - Tambahkan aturan jalur yang mengarahkan permintaan untuk jalur URL yang tepat
/video/sd
atau awalan jalur URL/video/sd/*
ke layanan backend yang ada bernamavideo-sd
.
gcloud compute url-maps add-path-matcher video-org-url-map \ --path-matcher-name=video-matcher \ --default-service=video-site \ --path-rules=/video/hd=video-hd,/video/hd/*=video-hd,/video/sd=video-sd,/video/sd/*=video-sd
- Layanan backend default adalah
Buat aturan host untuk nama host
example.net
yang mereferensikan pencocok jalurvideo-matcher
.gcloud compute url-maps add-host-rule video-org-url-map \ --hosts=example.net \ --path-matcher-name=video-matcher
Peta URL video-org-url-map
akan terlihat seperti ini:
gcloud compute url-maps describe video-org-url-map
creationTimestamp: '2021-03-05T13:34:15.833-08:00' defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/org-site fingerprint: mfyJIT7Zurs= hostRules: - hosts: - '*' pathMatcher: video-matcher - hosts: - example.net pathMatcher: video-matcher id: '8886405179645041976' kind: compute#urlMap name: video-org-url-map pathMatchers: - defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-site name: video-matcher pathRules: - paths: - /video/hd - /video/hd/* service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-hd - paths: - /video/sd - /video/sd/* service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-sd selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps/video-org-url-map
Peta URL video-org-url-map
mengarahkan URL yang diminta ke backend dengan cara berikut.
Tabel berikut menjelaskan pemrosesan permintaan yang ditampilkan dalam diagram sebelumnya.
Hostname | Jalur URL | Layanan backend yang dipilih | Alasan pemilihan |
---|---|---|---|
Nama host:example.org dan semua nama host lainnya
berbeda denganexample.net |
semua jalur | org-site |
Nama host tidak ada dalam aturan host peta URL, sehingga permintaan diarahkan ke layanan backend default peta URL. |
Nama host:example.net |
/video /video/examples |
video-site |
Permintaan akan diarahkan ke layanan backend default karena tidak ada
aturan jalur untuk /video/ atau /video/* . Aturan host untuk example.net mereferensikan pencocok jalur, tetapi pencocok jalur tersebut tidak memiliki aturan jalur yang akan berlaku untuk jalur ini.
|
Nama host:example.net |
/video/hd /video/hd/movie1 /video/hd/movies/movie2 URL lain yang diawali dengan /video/hd/* |
video-hd |
Aturan host untuk example.net mereferensikan pencocok jalur yang aturan jalurnya mengarahkan permintaan untuk jalur URL yang sama persis dengan /video/hd atau yang diawali dengan /video/hd/* ke layanan backend video-hd . |
Nama host:example.net |
/video/sd /video/sd/show1 /video/sd/shows/show2 URL lain yang diawali dengan /video/sd/* |
video-sd |
Aturan host untuk example.net mereferensikan pencocok jalur yang aturan jalurnya mengarahkan permintaan untuk jalur URL yang sama persis dengan /video/sd atau yang diawali dengan /video/sd/* ke layanan backend video-sd . |
Pengalihan URL
Pengalihan URL mengalihkan pengunjung domain Anda dari satu URL ke URL lain.
Pengalihan URL default tidak dikondisikan untuk mencocokkan pola tertentu dalam permintaan masuk. Misalnya, Anda mungkin ingin menggunakan pengalihan URL default untuk mengalihkan nama host mana pun ke nama host pilihan Anda.
Ada beberapa cara untuk membuat pengalihan URL, seperti yang diuraikan dalam tabel berikut.
Metode | Konfigurasi |
---|---|
Pengalihan URL default peta URL | defaultUrlRedirect tingkat teratas |
Pengalihan URL default pencocok jalur | pathMatchers[].defaultUrlRedirect[] |
Pengalihan URL aturan jalur pencocok jalur | pathMatchers[].pathRules[].urlRedirect |
Pengalihan URL aturan rute pencocok jalur | pathMatchers[].routeRules[].urlRedirect |
Di dalam defaultUrlRedirect
atau urlRedirect
, pathRedirect
selalu berfungsi
sebagai berikut:
- Seluruh jalur permintaan diganti dengan jalur yang Anda tentukan.
Di dalam defaultUrlRedirect
atau urlRedirect
, cara kerjaprefixRedirect
bergantung pada cara Anda menggunakannya:
- Jika Anda menggunakan
defaultUrlRedirect
,prefixRedirect
secara efektif merupakan awalan awalan karena jalur yang cocok selalu/
. - Jika Anda menggunakan
urlRedirect
dalam aturan rute atau aturan jalur pencocok jalur,prefixRedirect
adalah penggantian awalan berdasarkan cara jalur yang diminta dikococokkan seperti yang ditentukan dalam aturan jalur atau aturan rute.
Contoh pengalihan
Tabel berikut memberikan beberapa contoh konfigurasi pengalihan. Kolom kanan menampilkan konfigurasi API untuk pengalihan URL default.
Anda ingin | Dilakukan menggunakan pengalihan URL default |
---|---|
Pengalihan HTTP-ke-HTTPS Alihkan http://host.name/path ke https://host.name/path |
kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True |
HTTP-ke-HTTPS + Pengalihan host Alihkan http://nama-host-apa-saja/jalur ke https://www.example.com/jalur |
kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" |
HTTP-ke-HTTPS + Pengalihan host + Pengalihan jalur lengkap Alihkan http://nama-host-apa pun/jalur ke https://www.example.com/newPath |
kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" pathRedirect: "/newPath" |
HTTP-ke-HTTPS + Pengalihan host + Pengalihan awalan Alihkan http://nama-host-mana-saja/jalur-asli ke https://www.example.com/awalan-baru/jalur-asli |
kind: compute#urlMap name: web-map-http defaultUrlRedirect: httpsRedirect: True hostRedirect: "www.example.com" prefixRedirect: "/newPrefix" |
Cuplikan sebagian berikut menganotasi setiap resource API:
defaultUrlRedirect: redirectResponseCode: MOVED_PERMANENTLY_DEFAULT httpsRedirect: True # True if you want https://, false if you want http:// hostRedirect: "new-host-name.com" # Omit to keep the requested host pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect stripQuery: False # True to omit everything in the URL after ? ...
Langkah selanjutnya
Untuk menambahkan, memvalidasi, menguji, mencantumkan, atau menghapus peta URL, lihat Menggunakan peta URL.
Untuk informasi tentang peta aturan pemilihan rute dengan Cloud Service Mesh, lihat ringkasan peta aturan pemilihan rute Cloud Service Mesh.