Ringkasan peta URL

Load Balancer Aplikasi Google Cloud 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 mengarahkan 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 mengarah 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.

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 perutean dan traffic. Selain itu, peta URL regional dapat berupa resource yang ditetapkan sebagai layanan di Pusat Aplikasi, yang berada dalam pratinjau.

Cara kerja peta URL

Saat permintaan masuk di load balancer, load balancer akan merutekan permintaan tersebut 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, tujuan yang memungkinkan 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 diarahkan ke alamat IP dan load balancer yang sama.
  • 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 mengarah ke layanan backend org-site.
• Permintaan ke example.net yang tidak cocok dengan jalur yang lebih spesifik untuk mengarah ke 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, load balancer akan mentransformasi 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 pengalihan 302 ke http://example.net/abc. Sebagian besar klien kemudian bereaksi dengan mengirimkan permintaan ke URL yang ditampilkan oleh load balancer (dalam hal ini, http://example.net/abc). Pengalihan 302 ini tidak dicatat dalam log di Cloud Logging.

Peta URL memungkinkan Anda menyiapkan jenis host dan perutean berbasis 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 URL ke layanan backendatau 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; misalnya, bagian nama host dari URL http://example.net/video/hd adalah example.net.
• Jalur adalah bagian URL setelah 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 dengan satu sama lain.

Anda mengontrol layanan backend atau 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. Setelan default ini mewakili layanan backend atau bucket backend yang menjadi tujuan Google Cloud mengarahkan permintaan untuk 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 yang terkait ke satu pencocok jalur (pathMatchers). Bagian nama host URL sama persis dengan kumpulan nama host yang dikonfigurasi oleh aturan host. Di host peta dan aturan jalur URL, jika Anda menghilangkan host, aturan akan cocok dengan host yang diminta. Guna mengarahkan permintaan untuk http://example.net/video/hd ke pencocok jalur, Anda memerlukan satu aturan host yang setidaknya menyertakan example.net nama host. Aturan host yang sama tersebut juga dapat menangani permintaan untuk nama host lain, tetapi akan mengarahkannya ke pencocok jalur yang sama.

  Jika perlu mengarahkan permintaan ke pencocok jalur yang berbeda, Anda harus menggunakan aturan host 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 * 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 * di aturan host. Anda juga dapat mencocokkan nama host parsial 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 secara berbeda. Dalam kasus Load Balancer Aplikasi internal, Anda dapat menggunakan parameter Aturan host untuk menentukan nomor port. Misalnya, untuk mengarahkan permintaan example.net bagi port 8080, tetapkan aturan host ke example.net:8080. Pada kasus Load Balancer Aplikasi klasik, hanya nama host di URL yang akan 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. Kolom ini 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 setidaknya harus menetapkan layanan backend default atau bucket backend default, tetapi jangan keduanya. Default ini merepresentasikan layanan backend atau bucket backend yang menjadi tujuan Google Cloud mengarahkan permintaan untuk URL yang nama hostnya cocok dengan aturan host yang terkait dengan pencocok jalur, dan yang 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 key-value pair yang memetakan jalur URL ke satu layanan backend atau bucket backend. Bagian berikutnya berisi informasi selengkapnya 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 backendatau bucket backendyang benar, 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 layanan yang Anda tentukan.

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

  • 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 awalannya cocok dengan bagian terpanjang 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 tepat /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 layanan 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.

• 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 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 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 kumpulan aturan jalur yang terbatas. Untuk kasus yang lebih kompleks, Anda perlu melakukan pencocokan ekspresi reguler berbasis jalur di backend.

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 sebagian dan akhiran (ekstensi file), menggunakan sintaksis karakter pengganti. Operator ini dapat berguna saat Anda perlu mengarahkan 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 menyusun ulang dan menghapus komponen URL sebelum permintaan dikirim ke asal 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 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 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 terjadi jika 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 akan dikirim ke user-backend.

Tabel berikut menguraikan sintaksis untuk pola template jalur.

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 encoding persen dinormalisasi. Misalnya, URL dengan karakter garis miring berenkode persen (%2F) tidak didekode ke dalam bentuk yang tidak dienkode.
• Setiap nama variabel, seperti {segment} atau {region}, hanya dapat muncul sekali dalam pola yang sama. Beberapa variabel dengan nama yang sama tidak valid dan akan 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. 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 mengambil jalur. Misalnya, Anda dapat mereferensikan, menyusun ulang, atau menghilangkan 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 asal Anda dengan memeriksa header respons. URL klien asli 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.

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 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 host dan pencocok jalur yang direferensikan.

• Jika menggunakan aturan jalur di pencocok jalur, Anda tidak boleh membuat lebih dari satu aturan jalur untuk jalur yang sama. Misalnya, permintaan untuk /videos/hd tidak boleh 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 Multi-Regional Storage.

  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 kecocokan 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, asalkan proxy HTTP target dan proxy HTTPS target mereferensikan peta URL.

Peta URL paling sederhana

Peta URL paling sederhana hanya memiliki layanan backend default atau bucket backend default. Tidak berisi aturan host dan tidak ada pencocok jalur. Layanan backend default atau bucket backend default (mana pun yang Anda tentukan) akan menangani semua URL yang diminta.

Jika Anda menentukan layanan backend default, Google Cloud akan mengarahkan permintaan ke grup backend instance atau NEG backend-nya sesuai dengan konfigurasi layanan backend.

Contoh alur kerja peta URL dengan Load Balancer Aplikasi eksternal

Contoh berikut menggambarkan urutan operasi untuk peta URL. Contoh ini hanya mengonfigurasi peta URL untuk Load Balancer Aplikasi klasik yang sudah ada. Untuk kemudahan konseptual, metode ini hanya menggunakan layanan backend. Namun, Anda dapat mengganti bucket backend. Untuk mempelajari cara membuat komponen lain dari 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 dokumentasi gcloud compute url-maps create.

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

Tabel berikut menjelaskan pemrosesan permintaan yang ditampilkan dalam diagram sebelumnya.

Pengalihan URL

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

Pengalihan URL default tidak disyaratkan untuk memiliki kecocokan dengan pola tertentu dalam permintaan masuk. Misalnya, Anda dapat menggunakan pengalihan URL default untuk mengalihkan nama host apa pun ke nama host pilihan Anda.

Ada beberapa cara untuk membuat pengalihan URL, seperti yang dijelaskan dalam tabel berikut.

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 merupakan penambahan awalan karena jalur yang cocok selalu /.
• Jika Anda menggunakan urlRedirect dalam aturan rute atau aturan jalur pencocok jalur, prefixRedirect adalah penggantian awalan berdasarkan cara pencocokan jalur yang diminta seperti yang ditentukan dalam aturan jalur atau aturan rute.

Contoh pengalihan

Tabel berikut memberikan beberapa contoh konfigurasi pengalihan. Kolom di sebelah kanan menampilkan konfigurasi API untuk pengalihan URL default.

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
           

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
          

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
              pathRedirect: "/newPath"
           

            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

• Untuk menambahkan, memvalidasi, menguji, mencantumkan, atau menghapus peta URL, lihat Menggunakan peta URL.

• Untuk mengetahui informasi tentang peta aturan pemilihan rute dengan Cloud Service Mesh, lihat ringkasan peta aturan pemilihan rute Cloud Service Mesh.