Ringkasan peta URL

Load Balancer Aplikasi Google Cloud dan Cloud Service Mesh menggunakan konfigurasi Google Cloud resource 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 mengarahkan permintaan ke tujuan yang berbeda berdasarkan aturan dikonfigurasikan 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 mengarah ke Cloud Storage bucket backend.
  • Permintaan untuk kombinasi host dan jalur lainnya mengarah ke backend default layanan.

Peta URL digunakan dengan produk Google Cloud berikut:

Ada dua jenis resource peta URL yang tersedia: global dan regional. Tujuan yang Anda gunakan tergantung 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 Wilayah, eksternal Layanan backend
Load Balancer Aplikasi internal lintas region INTERNAL_MANAGED Global, internal Layanan backend
Load Balancer Aplikasi internal regional INTERNAL_MANAGED Wilayah, 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. Untuk informasi selengkapnya tentang perbedaan ini, lihat Perbandingan fitur load balancer: Pemilihan rute dan traffic pengelolaan akun. Di beberapa Selain itu, peta URL regional dapat menjadi resource yang ditetapkan sebagai layanan di Pusat Aplikasi, yang berada di pratinjau.

Cara kerja peta URL

Ketika permintaan masuk di load balancer, load balancer akan merutekan permintaan ke layanan backend tertentu atau bucket backend berdasarkan aturan yang ditentukan di peta URL.

Layanan backend mewakili sekumpulan backend, yang merupakan instance dari aplikasi atau microservice Anda. Bucket backend adalah Cloud Storage bucket, yang biasa digunakan untuk menghosting konten statis, seperti gambar.

Untuk Load Balancer Aplikasi eksternal regional, Load Balancer Aplikasi internal, dan Cloud Service Mesh, mungkin tujuan tersebut 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 ditujukan ke alamat IP dan alamat IP yang sama dengan load balancer Jaringan Passthrough Eksternal Regional.
    • Traffic diarahkan ke layanan backend yang berbeda berdasarkan URL permintaan.
  • Dua domain:
    • example.net menghosting video pelatihan.
    • example.org menghosting situs organisasi Anda.
  • Empat set server:
    • Satu menghosting situs organisasi Anda (layanan backend: org-site).
    • Satu menghosting situs video pelatihan secara keseluruhan (layanan backend: video-site).
    • Satu menghosting video pelatihan definisi tinggi (HD) (layanan backend: video-hd).
    • Satu menghosting video pelatihan definisi standar (SD) (layanan backend: video-sd).

Anda ingin hal berikut terjadi:

  • Permintaan ke example.org (atau domain selain example.net) untuk diarahkan layanan backend org-site.
  • Permintaan ke example.net yang tidak cocok dengan jalur yang lebih spesifik untuk menuju Layanan backend video-site.
  • Permintaan ke example.net/video/hd/* untuk menuju layanan backend video-hd.
  • Permintaan ke example.net/video/sd/* untuk menuju 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, berarti load balancer balancer mengubah URL dengan menghapus segmen jalur sebelum .., dan merespons dengan URL yang telah diubah. Misalnya, saat permintaan dikirim untuk http://example.net/video/../abc, load balancer akan merespons dengan respons 302 mengalihkan ke http://example.net/abc. Sebagian besar klien kemudian merespons dengan mengeluarkan ke URL yang ditampilkan oleh load balancer (dalam kasus ini, http://example.net/abc). Pengalihan 302 ini tidak login Cloud Logging.

Peta URL memungkinkan Anda menyiapkan jenis host dan perutean berbasis 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) dengan menggunakan konsol Google Cloud, peta URL akan diberi nama. Nama ini sama dengan nama load balancer di Konsol Google Cloud. Jika Anda menggunakan Google Cloud CLI atau API, Anda dapat menentukan nama kustom untuk peta URL.

Komponen peta URL

Peta URL adalah serangkaian konfigurasi Google Cloud resource yang mengarahkan permintaan untuk URL ke layanan backend atau bucket backend. Peta URL melakukannya dengan menggunakan bagian nama host dan jalur untuk setiap URL yang diproses:

  • Nama host adalah bagian nama domain dari URL; untuk contoh, bagian nama host dari URL http://example.net/video/hd adalah example.net.
  • Jalur adalah bagian dari URL setelah nama host dan port opsional nomor; misalnya, bagian jalur dari 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 backend mana atau bucket backend menerima permintaan masuk dengan menggunakan parameter konfigurasi peta URL berikut:

  • Layanan backend default atau bucket backend default. Saat Anda membuat Peta URL, Anda harus menentukan layanan backend default atau backend default bucket, tetapi bukan keduanya. Default ini mewakili layanan backend atau backend bucket tempat Google Cloud mengarahkan permintaan untuk URL dengan nama host apa pun, kecuali ada aturan host yang berlaku.

  • Aturan host (hostRules). Aturan host mengarahkan permintaan yang dikirim ke satu atau beberapa nama host yang terkait ke satu pencocok jalur (pathMatchers). Nama host URL sama persis dengan kumpulan aturan host nama host yang dikonfigurasi. Di host peta dan aturan jalur URL, jika Anda menghilangkan {i>host<i}, aturan sesuai dengan {i>host<i} apa pun yang diminta. Untuk mengarahkan permintaan http://example.net/video/hd ke pencocok jalur, Anda memerlukan satu host aturan yang setidaknya menyertakan nama host example.net. {i>Host<i} yang sama juga dapat menangani permintaan untuk nama {i>host<i} lain, tetapi akan mengarahkan mereka ke pencocok jalur yang sama.

    Jika perlu mengarahkan permintaan ke pencocok jalur yang berbeda, Anda harus menggunakan aturan {i>host<i} yang berbeda. Dua aturan host di peta URL tidak dapat menyertakan nama host yang sama.

    Anda dapat mencocokkan semua nama host dengan menentukan karakter pengganti * di aturan host. Misalnya, untuk URL http://example.org, http://example.net/video/hd, dan http://example.com/audio, ketiganya nama host example.org, example.net, dan example.com dapat dicocokkan dengan menentukan * dalam aturan host. Dimungkinkan juga untuk mencocokkan nama host 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 port angka secara berbeda. Dalam kasus Load Balancer Aplikasi internal, Anda dapat gunakan parameter Host rule untuk menentukan nomor port. Misalnya, untuk permintaan example.net langsung untuk port 8080, tetapkan aturan host ke example.net:8080. Dalam kasus Load Balancer Aplikasi klasik, hanya nama host di URL akan dipertimbangkan saat mencocokkan host aturan. Misalnya, permintaan example.net untuk port 8080 dan port 80 cocok aturan host example.net.

  • Pencocok jalur (pathMatchers). Pencocok jalur adalah konfigurasi yang direferensikan oleh aturan host. Mendefinisikan hubungan antara bagian jalur URL dan layanan backend atau bucket backend yang harus melayani permintaan. Pencocok jalur terdiri dari dua elemen:

    • Layanan backend default pencocok jalur atau backend default pencocok jalur bucket. Untuk setiap pencocok jalur, Anda setidaknya harus menetapkan layanan backend atau bucket backend default, tetapi bukan keduanya. Default ini mewakili layanan backend atau bucket backend yang mengarahkan permintaan untuk URL yang nama hostnya cocok dengan aturan host yang dengan pencocok jalur, dan jalur URL yang tidak cocok dengan jalur mana pun di pencocok jalur.

    • Aturan jalur. Untuk setiap pencocok jalur, Anda dapat menentukan satu atau beberapa jalur aturan, yang merupakan pasangan nilai kunci yang memetakan jalur URL ke backend tunggal layanan atau bucket backend. Bagian berikutnya berisi informasi lebih lanjut tentang cara kerja aturan jalur.

Urutan operasi ({i>Order of operations<i})

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:

  • Jika peta URL tidak berisi aturan host untuk nama host URL, Google Cloud mengarahkan permintaan ke layanan backend default peta URL atau bucket backend default, bergantung pada bucket yang Anda tentukan.

  • Jika peta URL berisi aturan host yang menyertakan nama host URL, pencocok jalur yang dirujuk oleh aturan host tersebut diminta:

    • Jika pencocok jalur berisi aturan jalur yang sama persis dengan Jalur URL, Google Cloud mengarahkan permintaan ke backend bucket layanan atau backend untuk aturan jalur tersebut.

    • Jika pencocok jalur tidak berisi aturan jalur yang sama persis jalur URL, tetapi berisi aturan jalur yang diakhiri dengan /* yang awalannya cocok dengan bagian terpanjang jalur URL, maka Google Cloud mengarahkan permintaan ke layanan backend atau bucket backend untuk jalur tersebut aturan. Misalnya, untuk peta URL yang berisi dua aturan pencocok jalur /video/hd/movie1 dan /video/hd/*, jika URL berisi jalur yang tepat /video/hd/movie1, kolom ini dicocokkan dengan aturan jalur tersebut.

    • Jika tidak satu pun kondisi sebelumnya yang terpenuhi, Google Cloud mengarahkan permintaan ke layanan backend default pencocok jalur atau default bucket backend, bergantung pada bucket 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.

  • Aturan jalur tidak menggunakan ekspresi reguler atau pencocokan substring. PathTemplateMatch dapat menggunakan jalur yang disederhanakan dan operator yang cocok. 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 Apache LocationMatch. Jika Anda memiliki aplikasi yang menghasilkan 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 untuk 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 kumpulan aturan jalur yang terbatas. Untuk kasus yang lebih kompleks, Anda perlu melakukan ekspresi reguler berbasis jalur pencocokan pada backend Anda.

Operator pencocokan pola dan karakter pengganti di 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 berguna saat Anda perlu merutekan lalu lintas dan mengeksekusi penulisan ulang berdasarkan jalur URL yang kompleks. Anda juga dapat mengaitkan satu atau beberapa jalur komponen dengan variabel bernama kemudian merujuk ke variabel tersebut saat menulis ulang URL. Dengan variabel bernama, Anda dapat menyusun ulang dan menghapus komponen URL sebelum permintaan dikirim ke origin Anda.

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

Inilah yang terjadi ketika 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 cart-matcher pathMatcher. 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 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 terjadi saat klien meminta Sebagai gantinya, /xyzwebservices/v2/xyz/users/abc%40xyz.com/accountinfo/abc-1234 yang hanya memiliki informasi pengguna dan akun:

  1. Jalur permintaan cocok dengan pathTemplateMatch dalam user-matcher pathMatcher. * pertama cocok dengan abc%40xyz.com dan * kedua cocok abc-1234.
  2. Permintaan akan dikirim ke user-backend.

Tabel berikut menguraikan sintaksis untuk pola template jalur.

Operator Mencocokkan dengan
* Segmen jalur tunggal, tidak termasuk jalur di sekitarnya pemisah / karakter.
** Mencocokkan nol karakter atau lebih, termasuk pemisah jalur apa pun / karakter di antara beberapa segmen jalur. Jika operator lain disertakan, operator ** harus menjadi operator terakhir.
{name} atau {name=*} Variabel bernama yang cocok dengan satu segmen jalur. Cocok dengan satu jalur segmen, tidak termasuk pemisah jalur di sekitarnya / karakter.
{name=news/*} Variabel bernama yang secara eksplisit cocok dengan dua segmen jalur: Segmen karakter pengganti news dan *.
{name=*/news/*} Variabel bernama yang cocok dengan tiga segmen jalur.
{name=**} Variabel bernama yang cocok dengan nol karakter atau lebih. Jika ada, harus menjadi operator terakhir.

Bila Anda menggunakan operator ini untuk pencocokan pola yang fleksibel, pertahankan pertimbangan:

  • Beberapa operator dapat digabungkan dalam satu pola.
  • Parameter kueri dipisah dari jalur, jalur ditulis ulang berdasarkan pathTemplateRewrite, dan parameter kueri ditambahkan ke jalur yang ditulis ulang.
  • Permintaan tidak encoding persen dinormalisasi. Misalnya, URL dengan karakter garis miring yang dienkode dengan persen (%2F) tidak didekode ke dalam bentuk yang tidak dienkode.
  • Setiap nama variabel, seperti {segment} atau {region}, hanya dapat muncul sekali di 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 bahwa nama tersebut cocok dengan ekspresi reguler ^[a-zA-Z][a-zA-Z0-9_]*$.
    • {API}, {api}, dan {api_v1} adalah ID yang valid. Mereka mengidentifikasi tiga variabel yang berbeda.
    • {1}, {_api}, dan {10alpha} bukan ID yang valid.
  • Ada batas lima operator per pola template.

Untuk menjalankan penulisan ulang URL opsional sebelum permintaan dikirim ke asal, Anda dapat menggunakan variabel yang sama yang Anda tetapkan untuk merekam jalur. Misalnya, Anda dapat mereferensikan, menyusun ulang, atau menghilangkan variabel dalam Kolom pathTemplateRewrite saat menentukan urlRewrite.

Saat Anda menggunakan variabel dan operator untuk pencocokan pola yang fleksibel untuk URL penulisan ulang, ingatlah pertimbangan berikut:

  • Saat menulis ulang URL, Anda dapat menghilangkan variabel jika tidak diperlukan sebagai bagian dari URL yang ditulis ulang.
  • Sebelum menulis ulang, Anda dapat mengidentifikasi URL yang dikirim oleh klien di asal Anda dengan memeriksa header respons. URL klien asli telah diisi dengan header x-client-request-url dan header x-envoy-original-path.

Hubungan aturan host dan host

  • Nama host hanya dapat merujuk pada 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).

Aturan host dan hubungan pencocok jalur

  • Beberapa aturan host dapat mereferensikan satu pencocok jalur.

  • Aturan host hanya dapat mereferensikan satu pencocok jalur.

Diagram berikut mengilustrasikan 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. Oleh karena itu:

  • Google Cloud menggunakan bagian nama host URL untuk memilih satu aturan {i>host<i} dan pencocok jalurnya.

  • Jika 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 backend grup instance atau grup endpoint jaringan backend (NEG) di zona berbeda dan region, serta Anda dapat membuat bucket backend yang menggunakan Multi-Regional Kelas penyimpanan.

    Untuk mengarahkan traffic untuk URL unik ke beberapa layanan, Anda dapat menggunakan rute aturan alih-alih aturan jalur. Jika Anda mengonfigurasi pencocok jalur dengan rute untuk pencocokan header atau parameter, URL unik dapat diarahkan ke dari satu layanan backend atau bucket, berdasarkan isi header atau parameter kueri di URL.

    Demikian pula untuk Load Balancer Aplikasi eksternal regional dan Cloud Service Mesh, dengan pembobotan layanan backend pada tindakan rute dapat mengarahkan URL yang sama ke beberapa layanan backend atau bucket, bergantung pada bobot yang ditetapkan pada layanan backend.

Peta dan protokol URL

Anda bisa menggunakan peta URL, aturan host, dan pencocok jalur yang sama untuk memproses dan permintaan HTTPS yang dikirimkan klien, selama baik proxy HTTP target maupun proxy HTTPS target mereferensikan peta URL.

Peta URL paling sederhana

Peta URL paling sederhana hanya memiliki layanan backend default atau backend default bucket. Tidak berisi aturan host dan tidak ada pencocok jalur. Opsi default-nya layanan backend atau bucket backend default (mana pun 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-nya sesuai dengan konfigurasi Anda.

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 menggambarkan urutan operasi untuk URL peta. Contoh ini hanya mengonfigurasi peta URL untuk konfigurasi Load Balancer Aplikasi klasik. Untuk kesederhanaan konseptual, ini hanya menggunakan backend layanan; Namun, Anda dapat mengganti bucket backend. Untuk mempelajari cara untuk membuat komponen lain di load balancer, lihat Membuat Load Balancer Aplikasi klasik.

Untuk mengetahui informasi selengkapnya tentang cara membuat dan mengonfigurasi peta URL dengan pencocok jalur dan aturan host, lihat gcloud compute url-maps create dokumentasi.

  1. Membuat peta URL untuk load balancer dan menentukan layanan backend default. Contoh ini akan membuat peta URL bernama video-org-url-map yang merujuk ke sebuah 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 hal berikut karakteristik:

    • Layanan backend default adalah video-site, layanan backend yang sudah ada.
    • Tambahkan aturan jalur yang mengarahkan permintaan untuk jalur URL yang sama persis /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 sama persis /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 di seperti berikut ini.

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 dari
example.net		 semua jalur org-site Nama host tidak ada dalam aturan host peta URL mana pun, jadi permintaan diarahkan ke layanan backend default peta URL.
Nama host:
example.net		 /video
/video/examples		 video-site Permintaan menuju ke layanan backend default karena tidak ada aturan jalur untuk /video/ atau /video/*. Host aturan untuk example.net merujuk ke pencocok jalur, tetapi pencocok jalur itu tidak memiliki aturan jalur yang akan diterapkan ke 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 /video/hd atau yang diawali dengan /video/hd/* hingga 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 /video/sd atau yang diawali dengan /video/sd/* hingga layanan backend video-sd.

Pengalihan URL

Pengalihan URL mengalihkan pengunjung domain Anda dari satu URL ke URL lainnya.

Pengalihan URL default tidak ditentukan jika cocok dengan pola tertentu dalam permintaan masuk. Misalnya, Anda mungkin ingin menggunakan URL default mengalihkan untuk mengalihkan nama host apa pun ke nama host pilihan Anda.

Ada beberapa cara untuk membuat pengalihan URL, seperti yang dijelaskan di bawah ini tabel sementara.

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 kerja prefixRedirect bergantung pada cara Anda menggunakannya:

  • Jika Anda menggunakan defaultUrlRedirect, prefixRedirect secara efektif adalah tambahkan awalan karena jalur yang cocok selalu /.
  • Jika Anda menggunakan urlRedirect dalam aturan rute atau jalur pencocok jalur aturan, prefixRedirect adalah penggantian awalan berdasarkan cara permintaan jalur dicocokkan sebagaimana yang ditentukan dalam aturan jalur atau aturan rute.

Contoh pengalihan

Tabel berikut memberikan beberapa contoh konfigurasi pengalihan. Tujuan di sebelah kanan menunjukkan 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-to-HTTPS + Pengalihan host

Alihkan
http://any-host-name/path
ke
https://www.example.com/path 
            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
HTTP-to-HTTPS + Pengalihan host + Pengalihan jalur lengkap

Alihkan
http://any-host-name/path
ke
https://www.example.com/newPath 
            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
              pathRedirect: "/newPath"
HTTP-to-HTTPS + Pengalihan host + Pengalihan awalan

Alihkan
http://any-host-name/originalPath
ke
https://www.example.com/newPrefix/originalPath 
            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
              prefixRedirect: "/newPrefix"

Cuplikan parsial 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