Ringkasan peta URL

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:

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:

Selain itu, Load Balancer Aplikasi eksternal global mendukung hal berikut:

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).

Anda ingin hal berikut terjadi:

  • Permintaan ke example.org (atau domain apa pun selain example.net) untuk membuka layanan backend org-site.
  • Permintaan ke example.net yang tidak cocok dengan jalur yang lebih spesifik untuk membuka layanan backend video-site.
  • Permintaan ke example.net/video/hd/* untuk membuka layanan backend video-hd.
  • Permintaan ke example.net/video/sd/* untuk membuka layanan backend video-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.

Contoh penyiapan layanan backend.
Contoh penyiapan layanan backend (klik untuk memperbesar).

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 adalah example.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.
Konfigurasi load balancer dengan peta URL dasar.
Konfigurasi load balancer dengan peta URL dasar (klik untuk memperbesar).

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 permintaan http://example.net/video/hd ke pencocok jalur, Anda memerlukan satu aturan host yang setidaknya menyertakan nama host example.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 URL http://example.org, http://example.net/video/hd, dan http://example.com/audio, ketiga nama host example.org, example.net, dan example.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 host news.example.net dan finance.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 ke example.net:8080. Untuk Load Balancer Aplikasi klasik, hanya nama host di URL yang dipertimbangkan saat mencocokkan aturan host. Misalnya, permintaan example.net untuk port 8080 dan port 80 cocok dengan aturan host example.net.
  • 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:

  1. Jalur permintaan cocok dengan pathTemplateMatch dalam pathMatcher cart-matcher. Variabel {username=*} cocok dengan abc@xyz.com dan variabel {cartid=**} cocok dengan FL0001090004/entries/SJFI38u3401nms.
  2. 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 menentukan pathTemplateMatch di pathTemplateRewrite.
  3. 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:

  1. Jalur permintaan cocok dengan pathTemplateMatch dalam pathMatcher user-matcher. * pertama cocok dengan abc%40xyz.com dan * kedua cocok dengan abc-1234.
  2. 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 header x-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 antara nama host dan aturan host.
Hubungan antara nama host dan aturan host (klik untuk memperbesar).

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 antara aturan host dan pencocok jalur.
Hubungan antara aturan host dan pencocok jalur (klik untuk memperbesar).

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.

Peta URL tanpa aturan kecuali default.
Peta URL tanpa aturan kecuali default (klik untuk memperbesar).

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.

  1. 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 bernama org-site.

    gcloud compute url-maps create video-org-url-map \
        --default-service=org-site
    
  2. 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 bernama video-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 bernama video-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
    
  3. Buat aturan host untuk nama host example.net yang mereferensikan pencocok jalur video-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.

Peta URL dengan aturan jalur, pencocok jalur, dan aturan host.
Peta URL dengan aturan jalur, pencocok jalur, dan aturan host (klik untuk memperbesar).

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 dengan
example.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