Halaman ini menunjukkan cara membuat Load Balancer Aplikasi eksternal untuk mengarahkan permintaan ke backend serverless. Di sini, istilah serverless mengacu pada produk komputasi serverless berikut:
- App Engine
- Cloud Functions
- Cloud Run
Integrasi Load Balancer Aplikasi eksternal dengan Gateway API memungkinkan backend serverless memanfaatkan semua fitur yang disediakan oleh Cloud Load Balancing. Untuk mengonfigurasi Load Balancer Aplikasi eksternal guna mengarahkan traffic ke Gateway API, baca artikel Memulai Load Balancer Aplikasi eksternal untuk Gateway API. Dukungan Load Balancer Aplikasi Eksternal untuk Gateway API berada di Pratinjau.
NEG Serverless memungkinkan Anda menggunakan aplikasi serverless Google Cloud dengan Load Balancer Aplikasi eksternal. Setelah Anda mengonfigurasi load balancer dengan backend NEG serverless, permintaan ke load balancer akan dirutekan ke backend aplikasi serverless.
Untuk mempelajari NEG serverless lebih lanjut, baca Ringkasan NEG Tanpa Server.
Jika Anda adalah pengguna Load Balancer Aplikasi klasik yang sudah ada, pastikan Anda meninjau Merencanakan migrasi ke Load Balancer Aplikasi eksternal global saat merencanakan deployment baru dengan Load Balancer Aplikasi eksternal global.Sebelum memulai
- Deploy layanan App Engine, Cloud Functions, atau Cloud Run.
- Instal Google Cloud CLI jika Anda belum melakukannya.
- Mengonfigurasi izin.
- Tambahkan resource sertifikat SSL.
Men-deploy layanan App Engine, Cloud Functions, atau Cloud Run
Petunjuk di halaman ini mengasumsikan bahwa Anda sudah menjalankan layanan Cloud Run, Cloud Functions, atau App Engine.
Untuk contoh di halaman ini, kami telah menggunakan panduan memulai Cloud Run Python untuk men-deploy layanan Cloud Run di region us-central1
. Bagian selanjutnya dari halaman ini akan menunjukkan cara menyiapkan Load Balancer Aplikasi eksternal yang menggunakan backend NEG serverless untuk mengarahkan permintaan ke layanan ini.
Jika Anda belum men-deploy aplikasi serverless, atau jika ingin mencoba NEG serverless dengan aplikasi contoh, gunakan salah satu panduan memulai berikut. Anda dapat membuat aplikasi serverless di region mana pun, tetapi Anda harus menggunakan region yang sama nanti untuk membuat NEG serverless dan load balancer.
Cloud Run
Untuk membuat aplikasi Halo Dunia sederhana, kemas ke dalam image container, lalu deploy image container ke Cloud Run. Lihat Panduan Memulai: Mem-build dan Men-deploy.
Jika Anda sudah mengupload container contoh ke Container Registry, lihat Panduan Memulai: Men-deploy Container Contoh Bawaan.
Cloud Functions
Lihat Panduan Memulai Cloud Functions: Python.
App Engine
Lihat panduan memulai App Engine berikut untuk Python 3:
Menginstal Google Cloud CLI.
Instal Google Cloud CLI. Lihat Ringkasan gcloud untuk mengetahui informasi konseptual dan penginstalan tentang alat ini.
Jika Anda belum menjalankan gcloud CLI sebelumnya, jalankan gcloud init
terlebih dahulu untuk melakukan inisialisasi direktori gcloud Anda.
Konfigurasikan izin
Untuk mengikuti panduan ini, Anda perlu membuat NEG serverless dan membuat load balancer HTTP(S) eksternal di sebuah project. Anda harus menjadi pemilik atau editor project, atau Anda harus memiliki peran IAM Compute Engine berikut:
Tugas | Peran yang Diperlukan |
---|---|
Membuat komponen jaringan dan load balancer | Admin Jaringan |
Membuat dan mengubah NEG | Compute Instance Admin |
Membuat dan mengubah sertifikat SSL | Security Admin |
Mencadangkan alamat IP eksternal
Setelah layanan Anda aktif dan berjalan, siapkan alamat IP eksternal statis global yang digunakan pelanggan untuk menjangkau load balancer Anda.
Konsol
Di konsol Google Cloud, buka halaman External IP addresses.
Klik Reserve external static IP address.
Untuk Name, masukkan
example-ip
.Untuk Tingkat layanan jaringan, pilih Premium.
Untuk IP version, pilih IPv4.
Untuk Jenis, pilih Global.
Klik Reserve.
gcloud
gcloud compute addresses create example-ip \ --network-tier=PREMIUM \ --ip-version=IPV4 \ --global
Perhatikan alamat IPv4 yang dicadangkan:
gcloud compute addresses describe example-ip \ --format="get(address)" \ --global
Membuat resource sertifikat SSL
Untuk membuat load balancer HTTPS, Anda harus menambahkan resource sertifikat SSL ke front end load balancer. Buat resource sertifikat SSL menggunakan sertifikat SSL yang dikelola Google atau sertifikat SSL yang dikelola sendiri.
Sertifikat yang dikelola Google. Sebaiknya gunakan sertifikat yang dikelola Google karena Google Cloud mendapatkan, mengelola, dan memperpanjang sertifikat ini secara otomatis. Untuk membuat sertifikat yang dikelola Google, Anda harus memiliki domain dan data DNS untuk domain tersebut agar sertifikat dapat disediakan. Jika belum memiliki domain, Anda bisa mendapatkannya dari Google Domains. Untuk mengetahui informasi selengkapnya, lihat Memulai Google Domains. Selain itu, Anda perlu memperbarui data A DNS domain agar mengarah ke alamat IP load balancer yang dibuat di langkah sebelumnya (
example-ip
). Untuk petunjuk mendetail, lihat Menggunakan sertifikat yang dikelola Google.Sertifikat yang ditandatangani sendiri. Jika saat ini Anda tidak ingin menyiapkan domain, Anda dapat menggunakan sertifikat SSL yang ditandatangani sendiri untuk melakukan pengujian.
Contoh ini mengasumsikan bahwa Anda telah membuat resource sertifikat SSL.
Jika ingin menguji proses ini tanpa membuat resource sertifikat SSL (atau domain seperti yang diwajibkan oleh sertifikat yang dikelola Google), Anda tetap dapat menggunakan petunjuk di halaman ini untuk menyiapkan load balancer HTTP.
Membuat load balancer
Dalam diagram berikut, load balancer menggunakan backend NEG serverless untuk mengarahkan permintaan ke layanan Cloud Run serverless. Untuk contoh ini, kami telah menggunakan panduan memulai Cloud Run Python untuk men-deploy layanan Cloud Run.
Karena health check tidak didukung untuk layanan backend dengan backend NEG serverless, Anda tidak perlu membuat aturan firewall yang mengizinkan health check jika load balancer hanya memiliki backend NEG serverless.
Konsol
Memulai konfigurasi Anda
Di Konsol Google Cloud, buka halaman Load balancing.
- Klik Create load balancer.
- Untuk Type of load balancer, pilih Application Load Balancer (HTTP/HTTPS) lalu klik Next.
- Untuk Public facing or internal, pilih Public facing (eksternal), lalu klik Next.
- Untuk Global or single region deployment, pilih Best for global Workload, lalu klik Next.
- Untuk Load balancer Generation, pilih Global external Application Load Balancer, lalu klik Next.
- Klik Konfigurasikan.
Konfigurasi dasar
- Untuk nama load balancer, masukkan
serverless-lb
. - Biarkan jendela tetap terbuka untuk melanjutkan.
Konfigurasi frontend
- Klik Frontend configuration.
- Untuk Name, masukkan nama.
-
Untuk membuat load balancer HTTPS, Anda harus memiliki sertifikat SSL (
gcloud compute ssl-certificates list
).Sebaiknya gunakan sertifikat yang dikelola Google seperti yang dijelaskan sebelumnya.
- Klik Done.
Untuk mengonfigurasi Load Balancer Aplikasi eksternal, isi kolom sebagai berikut.
Pastikan opsi berikut dikonfigurasi dengan nilai ini:
Properti | Nilai (ketik nilai atau pilih opsi yang ditentukan) |
---|---|
Protokol | HTTPS |
Network Service Tier | Premium |
IP version | IPv4 |
Alamat IP | example-ip |
Port | 443 |
Opsional: Waktu tunggu keepalive HTTP | Masukkan nilai waktu tunggu dari 5 hingga 1200 detik. Nilai defaultnya adalah 610 detik. |
Certificate | Pilih sertifikat SSL yang ada atau buat sertifikat baru. Untuk membuat load balancer HTTPS, Anda harus memiliki resource sertifikat SSL untuk digunakan di proxy HTTPS. Anda dapat membuat resource sertifikat SSL menggunakan sertifikat SSL yang dikelola Google atau sertifikat SSL yang dikelola sendiri. Untuk membuat sertifikat yang dikelola Google, Anda harus memiliki domain. Data A domain harus di-resolve ke alamat IP load balancer (dalam contoh ini, example-ip). Direkomendasikan untuk menggunakan sertifikat yang dikelola Google karena Google Cloud akan mendapatkan, mengelola, dan memperpanjang sertifikat ini secara otomatis. Jika tidak memiliki domain, Anda dapat menggunakan sertifikat SSL yang ditandatangani sendiri untuk pengujian. |
Opsional: Mengaktifkan Pengalihan HTTP ke HTTPS |
Gunakan kotak centang ini untuk mengaktifkan pengalihan HTTP ke HTTPS.
Jika kotak ini dicentang, load balancer HTTP sebagian tambahan akan menggunakan alamat IP yang sama dengan load balancer HTTPS dan akan mengalihkan permintaan HTTP ke frontend HTTPS load balancer. Kotak centang ini hanya dapat dipilih jika protokol HTTPS dipilih dan alamat IP yang dicadangkan digunakan. |
Jika ingin menguji proses ini tanpa menyiapkan resource sertifikat SSL (atau domain seperti yang diwajibkan oleh sertifikat yang dikelola Google), Anda dapat menyiapkan load balancer HTTP.
Untuk membuat load balancer HTTP, pastikan opsi berikut dikonfigurasi dengan nilai ini:
Properti | Nilai (ketik nilai atau pilih opsi yang ditentukan) |
---|---|
Protokol | HTTP |
Network Service Tier | Premium |
IP version | IPv4 |
Alamat IP | example-ip |
Port | 80 |
Opsional: Waktu tunggu keepalive HTTP | Masukkan nilai waktu tunggu dari 5 hingga 1200 detik. Nilai defaultnya adalah 610 detik. |
Konfigurasi backend
- Klik Backend configuration.
- Dalam daftar Backend services & backend buckets, klik Create a backend service.
- Untuk Name, masukkan nama.
- Di Backend type, pilih Serverless network endpoint group.
- Jangan ubah Protocol. Parameter ini diabaikan.
- Di bagian Backends, untuk New backend, pilih Create Serverless network endpoint group.
- Untuk Name, masukkan nama.
- Di Region, pilih us-central1, lalu pilih Cloud Run.
- Pilih Pilih nama layanan.
- Dalam daftar Service, pilih layanan Cloud Run yang ingin Anda buatkan load balancernya.
- Klik Create.
- Di bagian New backend, klik Done.
- Klik Create.
Aturan perutean
Aturan pemilihan rute menentukan cara traffic Anda diarahkan. Untuk mengonfigurasi perutean, Anda akan menyiapkan aturan host dan pencocok jalur, yang merupakan komponen konfigurasi dari peta URL Load Balancer Aplikasi eksternal.
Klik Routing rules.
- Pertahankan host dan jalur default. Untuk contoh ini, semua permintaan mengarah ke layanan backend yang dibuat di langkah sebelumnya.
Meninjau konfigurasi
- Klik Review and finalize.
- Tinjau semua setelan.
- Opsional: Klik Equivalent Code untuk melihat permintaan REST API yang akan digunakan untuk membuat load balancer.
- Klik Create.
- Tunggu load balancer dibuat.
- Klik nama load balancer (serverless-lb).
- Catat alamat IP load balancer untuk tugas berikutnya. Nama ini
disebut sebagai
IP_ADDRESS
.
gcloud
- Buat NEG serverless untuk aplikasi serverless Anda.
Untuk membuat NEG serverless dengan layanan Cloud Run:
gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME \ --region=us-central1 \ --network-endpoint-type=serverless \ --cloud-run-service=CLOUD_RUN_SERVICE_NAME
Untuk opsi lainnya, lihat panduan referensigcloud
untukgcloud compute network-endpoint-groups create
. - Buat layanan backend.
gcloud compute backend-services create BACKEND_SERVICE_NAME \ --load-balancing-scheme=EXTERNAL_MANAGED \ --global
- Tambahkan NEG serverless sebagai backend ke layanan backend:
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \ --global \ --network-endpoint-group=SERVERLESS_NEG_NAME \ --network-endpoint-group-region=us-central1
- Buat peta URL untuk mengarahkan permintaan masuk ke layanan backend:
gcloud compute url-maps create URL_MAP_NAME \ --default-service BACKEND_SERVICE_NAME
Contoh peta URL ini hanya menargetkan satu layanan backend yang mewakili satu aplikasi serverless, sehingga kita tidak perlu menyiapkan aturan host atau pencocok jalur. Jika memiliki lebih dari satu layanan backend, Anda dapat menggunakan aturan host untuk mengarahkan permintaan ke layanan yang berbeda berdasarkan nama host, dan Anda juga dapat menyiapkan pencocok jalur untuk mengarahkan permintaan ke berbagai layanan berdasarkan jalur permintaan.
-
Untuk membuat load balancer HTTPS, Anda harus memiliki
resource sertifikat
SSL untuk digunakan di proxy target HTTPS.
Anda dapat membuat resource sertifikat SSL menggunakan sertifikat SSL yang dikelola Google atau sertifikat SSL yang dikelola sendiri. Sebaiknya gunakan sertifikat yang dikelola Google
karena Google Cloud mendapatkan, mengelola, dan memperpanjang
sertifikat ini secara otomatis.
Untuk membuat sertifikat yang dikelola Google, Anda harus memiliki domain. Jika tidak memiliki domain, Anda dapat menggunakan sertifikat SSL yang ditandatangani sendiri untuk pengujian.
Untuk membuat resource sertifikat SSL yang dikelola Google:gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \ --domains DOMAIN
Untuk membuat resource sertifikat SSL yang dikelola sendiri:gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \ --certificate CRT_FILE_PATH \ --private-key KEY_FILE_PATH
-
Buat proxy HTTP(S) target untuk merutekan permintaan ke peta URL Anda.
Untuk load balancer HTTP, buat proxy target HTTP:
gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \ --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \ --url-map=URL_MAP_NAME
Untuk load balancer HTTPS, buat proxy target HTTPS. Proxy adalah bagian dari load balancer yang menyimpan sertifikat SSL untuk Load Balancing HTTPS, sehingga Anda juga memuat sertifikat pada langkah ini.
gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \ --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \ --ssl-certificates=SSL_CERTIFICATE_NAME \ --url-map=URL_MAP_NAME
Ganti kode berikut:
TARGET_HTTP_PROXY_NAME
: nama proxy HTTP target.TARGET_HTTPS_PROXY_NAME
: nama proxy HTTPS target.HTTP_KEEP_ALIVE_TIMEOUT_SEC
: kolom opsional yang digunakan untuk menentukan waktu tunggu keepalive HTTP klien. Nilai waktu tunggu harus antara 5 hingga 1200 detik. Nilai defaultnya adalah 610 detik.SSL_CERTIFICATE_NAME
: nama sertifikat SSL.URL_MAP_NAME
: nama peta URL.
- Buat aturan penerusan untuk mengarahkan permintaan masuk ke proxy.
Untuk load balancer HTTP:
gcloud compute forwarding-rules create HTTP_FORWARDING_RULE_NAME \ --load-balancing-scheme=EXTERNAL_MANAGED \ --network-tier=PREMIUM \ --address=example-ip \ --target-http-proxy=TARGET_HTTP_PROXY_NAME \ --global \ --ports=80
Untuk load balancer HTTPS:
gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \ --load-balancing-scheme=EXTERNAL_MANAGED \ --network-tier=PREMIUM \ --address=example-ip \ --target-https-proxy=TARGET_HTTPS_PROXY_NAME \ --global \ --ports=443
Menghubungkan domain ke load balancer
Setelah load balancer dibuat, catat alamat IP yang terkait dengan load balancer, misalnya, 30.90.80.100
. Untuk mengarahkan domain ke load balancer, buat data A
menggunakan layanan pendaftaran domain. Jika
Anda menambahkan beberapa domain ke sertifikat SSL, Anda harus menambahkan data A
untuk setiap domain, yang semuanya mengarah ke alamat IP load balancer. Misalnya, untuk
membuat data A
bagi www.example.com
dan example.com
, gunakan string berikut:
NAME TYPE DATA www A 30.90.80.100 @ A 30.90.80.100
Jika Anda menggunakan Cloud DNS sebagai penyedia DNS, lihat Menambahkan, mengubah, dan menghapus data.
Menguji load balancer
Setelah mengonfigurasi load balancer, Anda dapat mulai mengirim traffic ke alamat IP load balancer. Jika mengonfigurasi domain, Anda juga dapat mengirim traffic ke nama domain. Namun, penerapan DNS dapat memerlukan waktu untuk menyelesaikan pengujian sehingga Anda dapat memulai dengan menggunakan alamat IP untuk pengujian.
Di Konsol Google Cloud, buka halaman Load balancing.
Klik load balancer yang baru saja dibuat.
Catat alamat IP load balancer internal.
Untuk load balancer HTTP, Anda dapat menguji load balancer menggunakan browser web dengan membuka
http://IP_ADDRESS
. GantiIP_ADDRESS
dengan alamat IP load balancer. Anda akan diarahkan ke halaman beranda layananhelloworld
.
Untuk load balancer HTTPS, Anda dapat menguji load balancer menggunakan browser web dengan membuka
https://IP_ADDRESS
. GantiIP_ADDRESS
dengan alamat IP load balancer. Anda akan diarahkan ke halaman beranda layananhelloworld
.
Jika tidak berhasil dan Anda menggunakan sertifikat yang dikelola Google, konfirmasi bahwa status resource sertifikat Anda AKTIF. Untuk mengetahui informasi selengkapnya, lihat Status resource sertifikat SSL yang dikelola Google.
Jika Anda menggunakan sertifikat yang ditandatangani sendiri untuk pengujian, browser akan menampilkan peringatan. Anda harus secara eksplisit memerintahkan browser untuk menerima sertifikat yang ditandatangani sendiri. Klik peringatan untuk melihat halaman sebenarnya.
Opsi konfigurasi tambahan
Bagian ini memperluas contoh konfigurasi untuk memberikan opsi konfigurasi alternatif dan tambahan. Semua tugas bersifat opsional. Anda dapat melakukannya dalam urutan apa pun.
Menyiapkan load balancing multi-region
Pada contoh yang dijelaskan sebelumnya di halaman ini, kita hanya memiliki satu layanan Cloud Run yang berfungsi sebagai backend di region us-central1
. Karena NEG serverless hanya dapat mengarah ke satu endpoint dalam satu waktu, load balancing tidak dilakukan di beberapa region. Load Balancer Aplikasi eksternal hanya berfungsi sebagai frontend, dan menjadi proxy traffic ke endpoint aplikasi helloworld
yang ditentukan. Namun, Anda mungkin ingin menyalurkan aplikasi Cloud Run dari lebih dari satu region untuk mengurangi latensi pengguna akhir.
Jika layanan backend memiliki beberapa NEG serverless yang terpasang padanya, load balancer akan menyeimbangkan traffic dengan meneruskan permintaan ke NEG serverless di region terdekat yang tersedia. Namun, layanan backend hanya dapat berisi satu NEG serverless per region. Agar layanan Cloud Run tersedia dari beberapa region, Anda perlu menyiapkan perutean lintas region. Anda dapat menggunakan satu skema URL yang berfungsi di mana saja di seluruh dunia, tetapi melayani permintaan pengguna dari region yang paling dekat dengan pengguna.
Untuk menyiapkan penyaluran multi-region, Anda harus menggunakan tingkat jaringan Premium untuk memastikan bahwa semua deployment Cloud Run regional kompatibel dan siap untuk menyalurkan traffic dari region mana pun.
Untuk menyiapkan load balancer multi-region:
- Siapkan dua layanan Cloud Run di region yang berbeda. Anggaplah Anda telah men-deploy dua layanan Cloud Run: satu ke region di AS, dan satu lagi ke region di Eropa.
- Buat Load Balancer Aplikasi eksternal dengan penyiapan berikut:
- Siapkan layanan backend global dengan dua NEG serverless:
- Buat NEG pertama di region yang sama dengan layanan Cloud Run yang di-deploy di AS.
- Buat NEG kedua di region yang sama dengan layanan Cloud Run yang di-deploy di Eropa.
- Siapkan konfigurasi frontend Anda dengan Paket Layanan Jaringan Premium.
- Siapkan layanan backend global dengan dua NEG serverless:
Penyiapan yang dihasilkan ditampilkan dalam diagram berikut.
Bagian ini dibuat berdasarkan penyiapan load balancer yang dijelaskan sebelumnya di halaman ini,
tempat Anda membuat satu NEG serverless di region us-central1
yang mengarah
ke layanan Cloud Run di region yang sama. Contoh ini juga mengasumsikan bahwa Anda telah membuat layanan Cloud Run kedua di region europe-west1
. NEG serverless kedua yang Anda buat akan mengarah ke layanan Cloud Run ini di region europe-west1
.
Dalam contoh ini, Anda akan menyelesaikan langkah-langkah berikut:
- Buat NEG serverless kedua di region
europe-west1
. - Lampirkan NEG serverless kedua ke layanan backend.
Untuk menambahkan NEG serverless kedua ke layanan backend yang ada, ikuti langkah-langkah berikut.
Konsol
Di konsol Google Cloud, buka halaman Load balancing.
Klik nama load balancer yang layanan backend-nya ingin Anda edit.
Di halaman Load balancer details, klik
Edit.Di halaman Edit global external Application Load Balancer, klik Backend configuration.
Di halaman Backend configuration, klik
Edit untuk layanan backend yang ingin diubah.Di bagian Backends, klik Add a backend.
Dalam daftar Serverless network endpoint groups, pilih Create Serverless network endpoint group.
Masukkan nama untuk NEG serverless.
Untuk Region, pilih
europe-west1
.Untuk Serverless network endpoint group type, pilih Cloud Run, lalu lakukan hal berikut:
- Pilih opsi Pilih Layanan.
- Dalam daftar Service, pilih layanan Cloud Run yang ingin Anda buatkan load balancernya.
Klik Create.
Di halaman New backend, klik Done.
Klik Save.
Untuk mengupdate layanan backend, klik Update.
Untuk memperbarui load balancer, di halaman Edit global external Application Load Balancer, klik Update.
gcloud
Buat NEG serverless kedua di region yang sama tempat layanan Cloud Run di-deploy.
gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME_2 \ --region=europe-west1 \ --network-endpoint-type=SERVERLESS \ --cloud-run-service=CLOUD_RUN_SERVICE_2
Ganti kode berikut:
SERVERLESS_NEG_NAME_2
: nama NEG serverless keduaCLOUD_RUN_SERVICE_2
: nama layanan Cloud Run
Tambahkan NEG serverless kedua sebagai backend ke layanan backend.
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \ --global \ --network-endpoint-group=SERVERLESS_NEG_NAME_2 \ --network-endpoint-group-region=europe-west1
Ganti kode berikut:
BACKEND_SERVICE_NAME
: nama layanan backendSERVERLESS_NEG_NAME_2
: nama NEG serverless kedua
Menggunakan langganan push Pub/Sub terautentikasi dengan deployment Cloud Run multi-region
Untuk permintaan push terautentikasi, Cloud Run mengharapkan kolom audiens khusus region secara default. Dalam kasus deployment Cloud Run multi-region, jika permintaan push dirutekan ke layanan Cloud Run di region yang berbeda, verifikasi token JWT akan gagal karena ketidakcocokan audience.
Untuk mengatasi pembatasan spesifik per wilayah ini:
- Konfigurasikan audiens kustom yang sama untuk deployment layanan di berbagai region.
- Konfigurasikan pesan push Pub/Sub untuk menggunakan audiens kustom sebagai audience dalam token JWT.
Menyiapkan pemilihan rute regional
Alasan umum untuk menayangkan aplikasi dari beberapa region adalah untuk memenuhi persyaratan lokalitas data. Misalnya, Anda mungkin ingin memastikan bahwa permintaan yang dibuat oleh pengguna Eropa selalu disalurkan dari region yang berlokasi di Eropa. Untuk menyiapkannya, Anda memerlukan skema URL dengan URL terpisah untuk pengguna Uni Eropa dan non-Uni Eropa, dan mengarahkan pengguna Uni Eropa Anda ke URL Uni Eropa.
Dalam skenario seperti ini, Anda akan menggunakan peta URL untuk merutekan permintaan dari URL tertentu ke wilayah yang sesuai. Dengan penyiapan seperti itu, permintaan yang ditujukan untuk satu region tidak akan pernah dikirim ke region lain. Hal ini menyediakan isolasi antar-region. Di sisi lain, saat suatu region gagal, permintaan tidak dirutekan ke region lain. Jadi, pengaturan ini tidak meningkatkan ketersediaan layanan Anda.
Untuk menyiapkan perutean regional, Anda harus menggunakan tingkat jaringan Premium agar dapat menggabungkan region yang berbeda dalam satu aturan penerusan.
Untuk menyiapkan load balancer dengan perutean regional:
- Siapkan dua layanan Cloud Run di region yang berbeda. Anggaplah Anda telah men-deploy dua layanan Cloud Run: hello-world-eu ke region di Eropa, dan hello-world-us ke region di AS.
- Buat Load Balancer Aplikasi eksternal dengan penyiapan berikut:
- Siapkan layanan backend dengan NEG serverless di Eropa. NEG serverless harus dibuat di region yang sama dengan layanan Cloud Run yang di-deploy di Eropa.
- Siapkan layanan backend kedua dengan NEG serverless lain di AS. NEG serverless ini harus dibuat di region yang sama dengan layanan Cloud Run yang di-deploy di AS.
- Siapkan peta URL dengan aturan host dan jalur yang sesuai agar satu kumpulan URL dirutekan ke layanan backend Eropa sementara semua permintaan dirutekan ke layanan backend AS.
- Siapkan konfigurasi frontend Anda dengan tingkat jaringan Premium.
Penyiapan lainnya mungkin sama seperti yang dijelaskan sebelumnya. Konfigurasi yang dihasilkan akan terlihat seperti ini:
Menggunakan mask URL
Saat membuat NEG serverless, daripada memilih layanan Cloud Run tertentu, Anda dapat menggunakan URL mask untuk mengarah ke beberapa layanan yang ditayangkan di domain yang sama. Masker URL adalah template skema URL Anda. NEG serverless akan menggunakan template ini untuk mengekstrak nama layanan dari URL permintaan masuk dan memetakan permintaan ke layanan yang sesuai.
Masker URL sangat berguna jika layanan Anda dipetakan ke domain kustom, bukan alamat default yang disediakan Google Cloud untuk layanan yang di-deploy. Dengan URL mask, Anda dapat menargetkan beberapa layanan dan versi dengan satu aturan meskipun aplikasi Anda menggunakan pola URL kustom.
Jika Anda belum melakukannya, pastikan Anda membaca Ringkasan NEG Tanpa Server: Masker URL.
Membuat mask URL
Untuk membuat mask URL bagi load balancer, mulailah dengan URL layanan
Anda. Untuk contoh ini, kita akan menggunakan contoh aplikasi serverless yang berjalan di https://example.com/login
. Ini adalah URL tempat layanan login
aplikasi
akan ditayangkan.
- Hapus
http
atauhttps
dari URL. Anda memilikiexample.com/login
. - Ganti nama layanan dengan placeholder untuk URL mask.
- Cloud Run: Ganti nama layanan Cloud Run dengan placeholder
<service>
. Jika layanan Cloud Run memiliki tag yang terkait dengannya, ganti nama tag dengan placeholder<tag>
. Dalam contoh ini, mask URL yang tersisa adalahexample.com/<service>
. - Cloud Functions: Ganti nama fungsi dengan placeholder
<function>
. Dalam contoh ini, mask URL yang tersisa adalahexample.com/<function>
. - App Engine: Ganti nama layanan dengan placeholder
<service>
. Jika layanan memiliki versi yang terkait dengannya, ganti versi dengan placeholder<version>
. Dalam contoh ini, mask URL yang tersisa adalahexample.com/<service>
. - Gateway API: Ganti nama gateway dengan placeholder
<gateway>
. Dalam contoh ini, mask URL yang tersisa adalahexample.com/<gateway>
.
- Cloud Run: Ganti nama layanan Cloud Run dengan placeholder
(Opsional) Jika nama layanan (atau fungsi, versi, atau tag) dapat diekstrak dari bagian jalur URL,domain dapat dihilangkan. Bagian jalur mask URL dibedakan berdasarkan karakter
/
pertama. Jika/
tidak ada dalam mask URL, mask akan dianggap mewakili host saja. Oleh karena itu, untuk contoh ini, mask URL dapat dikurangi menjadi/<service>
,/<gateway>
, atau/<function>
.Demikian pula, jika nama layanan dapat diekstrak dari bagian host URL, Anda dapat menghilangkan seluruh jalur dari mask URL.
Anda juga dapat menghilangkan komponen host atau subdomain yang muncul sebelum placeholder pertama dan komponen jalur apa pun yang muncul setelah placeholder terakhir. Dalam kasus tersebut, placeholder mencatat informasi yang diperlukan untuk komponen.
Berikut adalah beberapa contoh lain yang menunjukkan aturan tersebut:
Cloud Run
Tabel ini mengasumsikan bahwa Anda memiliki domain kustom bernama example.com
dan semua layanan Cloud Run Anda sedang dipetakan ke domain ini menggunakan Load Balancer Aplikasi eksternal.
Layanan, Nama tag | URL domain kustom | Masker URL |
---|---|---|
layanan: login | https://login-home.example.com/web | <layanan>-home.example.com |
layanan: login | https://example.com/login/web | example.com/<service> atau /<service> |
service: login, tag: uji | https://test.login.example.com/web | <tag>.<layanan>.example.com |
service: login, tag: uji | https://example.com/home/login/test | example.com/home/<service>/<tag> atau /home/<service>/<tag> |
service: login, tag: uji | https://test.example.com/home/login/web | <tag>.example.com/home/<layanan> |
Cloud Functions
Tabel ini mengasumsikan bahwa Anda memiliki domain kustom bernama example.com
dan semua layanan Cloud Functions Anda sedang dipetakan ke domain ini.
Nama Fungsi | URL domain kustom | Penyamaran URL |
---|---|---|
login | https://example.com/login | /<function> |
login | https://example.com/home/login | /home/<function> |
login | https://login.example.com | <function>.example.com |
login | https://login.home.example.com | <function>.home.example.com |
App Engine
Tabel ini mengasumsikan bahwa Anda memiliki domain kustom bernama example.com
dan semua layanan App Engine Anda sedang dipetakan ke domain ini.
Nama layanan, versi | URL domain kustom | Masker URL |
---|---|---|
layanan: login | https://login.example.com/web | <layanan>.example.com |
layanan: login | https://example.com/home/login/web | example.com/home/<service>, atau /home/<service> |
service: login, versi: uji coba | https://test.example.com/login/web | <versi>.example.com/<layanan> |
service: login, versi: uji coba | https://example.com/login/test | example.com/<layanan>/<versi> |
Gateway API
Tabel ini mengasumsikan bahwa Anda memiliki domain kustom bernama example.com
dan semua layanan Gateway API Anda dipetakan ke domain ini.
Gateway name | URL domain kustom(Pratinjau) Gateway API | Masker URL |
---|---|---|
login | https://example.com/login | /<gateway> |
login | https://example.com/home/login | /home/<gateway> |
login | https://login.example.com | <gateway>.example.com |
login | https://login.home.example.com | <gateway>.home.example.com |
Membuat NEG serverless dengan mask URL
Konsol
Untuk load balancer baru, Anda dapat menggunakan proses menyeluruh yang sama seperti yang dijelaskan sebelumnya dalam topik ini. Saat mengonfigurasi layanan backend, masukkan mask URL, bukan memilih layanan tertentu.
Jika sudah memiliki load balancer, Anda dapat mengedit konfigurasi backend dan mengarahkan NEG serverless ke URL mask, bukan layanan tertentu.
Untuk menambahkan NEG tanpa server berbasis mask URL ke layanan backend yang ada:
- Buka halaman Load balancing di Konsol Google Cloud.
Buka halaman Load balancing - Klik nama load balancer yang layanan backend-nya ingin Anda edit.
- Di halaman Load balancer details, klik Edit .
- Di halaman Edit global external Application Load Balancer, klik Backend configuration.
- Di halaman Backend configuration, klik Edit untuk layanan backend yang ingin diubah.
- Klik Add backend.
- Pilih Create Serverless network endpoint group.
- Untuk Name, masukkan
helloworld-serverless-neg
. - Di bagian Region, pilih us-central1.
- Di bagian Serverless network endpoint group type, pilih platform tempat pembuatan aplikasi (atau layanan atau fungsi) serverless Anda.
- Pilih Gunakan Masker URL.
- Masukkan mask URL. Untuk petunjuk cara membuat mask URL, lihat Membuat mask URL.
- Klik Create.
- Untuk Name, masukkan
- Di bagian New backend, klik Done.
- Klik Perbarui.
gcloud: Cloud Run
Untuk membuat NEG Tanpa Server dengan contoh URL mask example.com/<service>
:
gcloud compute network-endpoint-groups create helloworld-neg-mask \ --region=us-central1 \ --network-endpoint-type=serverless \ --cloud-run-url-mask="example.com/<service>"
gcloud: Cloud Functions
Untuk membuat NEG Tanpa Server dengan contoh URL mask example.com/<service>
:
gcloud compute network-endpoint-groups create helloworld-neg-mask \ --region=us-central1 \ --network-endpoint-type=serverless \ --cloud-function-url-mask="example.com/<service>"
gcloud: App Engine
Untuk membuat NEG Tanpa Server dengan contoh mask URL example.com/<service>
:
gcloud compute network-endpoint-groups create helloworld-neg-mask \ --region=us-central1 \ --network-endpoint-type=serverless \ --app-engine-url-mask="example.com/<service>"
gcloud: Gateway API
Untuk membuat NEG Tanpa Server dengan contoh mask URL example.com/<gateway>
:
gcloud beta compute network-endpoint-groups create helloworld-neg-mask \ --region=us-central1 \ --network-endpoint-type=serverless \ --serverless-deployment-platform=apigateway.googleapis.com \ --serverless-deployment-resource=my-gateway \ --serverless-deployment-url-mask="example.com/<gateway>"
Untuk mempelajari cara load balancer menangani masalah ketidakcocokan mask URL, lihat Memecahkan masalah terkait NEG serverless.
Memindahkan domain kustom Anda untuk ditayangkan oleh Load Balancer Aplikasi eksternal
Jika aplikasi komputasi serverless Anda dipetakan ke domain kustom, sebaiknya perbarui data DNS sehingga traffic yang dikirim ke Cloud Run, Cloud Functions, Gateway API, atau URL domain kustom App Engine yang ada dirutekan melalui load balancer.
Misalnya, jika Anda memiliki domain kustom bernama example.com
dan semua layanan Cloud Run Anda dipetakan ke domain ini, Anda harus memperbarui data DNS untuk example.com
agar mengarah ke alamat IP load balancer.
Sebelum memperbarui data DNS, Anda dapat menguji konfigurasi secara lokal dengan memaksa resolusi DNS lokal domain kustom ke alamat IP load balancer. Untuk melakukan pengujian secara lokal, ubah file /etc/hosts/
di mesin lokal Anda agar mengarahkan example.com
ke alamat IP load balancer, atau gunakan tanda curl --resolve
untuk memaksa curl
agar menggunakan alamat IP load balancer untuk permintaan tersebut.
Saat data DNS untuk example.com
di-resolve ke alamat IP load balancer HTTP(S), permintaan yang dikirim ke example.com
akan mulai dirutekan melalui load balancer. Load balancer mengirimkannya ke layanan backend yang relevan sesuai dengan peta URL-nya. Selain itu, jika layanan backend dikonfigurasi dengan mask URL, NEG serverless menggunakan mask untuk merutekan permintaan ke layanan Cloud Run, Cloud Functions, Gateway API, atau App Engine yang sesuai.
Enable Cloud CDN
Dengan mengaktifkan Cloud CDN untuk layanan Cloud Run, Anda dapat mengoptimalkan penayangan konten dengan meng-cache konten yang dekat dengan pengguna Anda.
Anda dapat mengaktifkan Cloud CDN di layanan backend yang digunakan oleh Load Balancer Aplikasi eksternal global dengan menggunakan perintah gcloud compute
backend-services update
.
gcloud compute backend-services update helloworld-backend-service
--enable-cdn
--global
Cloud CDN didukung untuk layanan backend dengan Cloud Run, Cloud Functions, Gateway API, dan backend App Engine.
Mengaktifkan IAP di Load Balancer Aplikasi eksternal
Catatan: IAP tidak kompatibel dengan Cloud CDN.Anda dapat mengonfigurasi IAP untuk
diaktifkan atau dinonaktifkan (default). Jika diaktifkan, Anda harus memberikan nilai untuk
oauth2-client-id
dan oauth2-client-secret
.
Untuk mengaktifkan IAP, update layanan backend
agar menyertakan flag --iap=enabled
dengan oauth2-client-id
dan
oauth2-client-secret
.
gcloud compute backend-services update BACKEND_SERVICE_NAME \ --iap=enabled,oauth2-client-id=ID,oauth2-client-secret=SECRET \ --global
Aktifkan Google Cloud Armor
Google Cloud Armor adalah produk keamanan yang memberikan perlindungan terhadap serangan distributed denial of service (DDoS) ke semua load balancer proxy GCLB. Google Cloud Armor juga menyediakan kebijakan keamanan yang dapat dikonfigurasi untuk layanan yang diakses melalui Load Balancer Aplikasi eksternal. Untuk mempelajari kebijakan keamanan Google Cloud Armor untuk Load Balancer Aplikasi eksternal, baca Ringkasan kebijakan keamanan Google Cloud Armor.
Jika menggunakan Cloud Functions, Anda dapat memastikan bahwa permintaan yang dikirim ke URL default diblokir menggunakan setelan masuk internal-and-gclb
.
Jika menggunakan Cloud Run, Anda dapat memastikan bahwa permintaan yang dikirim ke URL default atau domain kustom lainnya yang disiapkan melalui Cloud Run diblokir dengan membatasi traffic masuk ke "load balancing internal dan cloud".
Jika menggunakan App Engine, Anda dapat menggunakan kontrol masuk sehingga aplikasi Anda hanya menerima permintaan yang dikirim dari load balancer (dan VPC jika Anda menggunakannya).
Tanpa setelan ingress yang tepat, pengguna dapat menggunakan URL default aplikasi serverless Anda untuk mengabaikan load balancer, kebijakan keamanan Google Cloud Armor, sertifikat SSL, dan kunci pribadi yang diteruskan melalui load balancer.
Opsional: Konfigurasikan kebijakan keamanan backend default. Kebijakan keamanan default membatasi traffic pada nilai minimum yang dikonfigurasi pengguna. Untuk informasi selengkapnya tentang kebijakan keamanan default, lihat Ringkasan pembatasan kapasitas.
- Untuk memilih tidak mengikuti kebijakan keamanan default Google Cloud Armor, pilih
None
di menu daftar kebijakan keamanan backend. - Di bagian Keamanan, pilih Kebijakan keamanan default.
- Di kolom Nama kebijakan, setujui nama yang dibuat otomatis atau masukkan nama untuk kebijakan keamanan Anda.
- Di kolom Request count, terima jumlah permintaan default atau masukkan bilangan bulat antara
1
dan10,000
. - Di kolom Interval, pilih interval.
- Di kolom Enforce on key, pilih salah satu nilai berikut: All, IP address, atau X-Forwarded-For IP address. Untuk informasi selengkapnya tentang opsi ini, lihat Mengidentifikasi klien untuk pembatasan kapasitas.
Mengaktifkan logging dan pemantauan
Anda dapat mengaktifkan, menonaktifkan, dan melihat log untuk layanan backend Load Balancer Aplikasi eksternal. Saat menggunakan konsol Google Cloud, logging diaktifkan secara default untuk layanan backend dengan backend NEG serverless. Anda dapat menggunakan gcloud
untuk
menonaktifkan logging bagi setiap layanan backend jika diperlukan. Untuk mengetahui petunjuknya, lihat
Logging.
Load balancer juga mengekspor data pemantauan ke Cloud Monitoring. Metrik Monitoring dapat digunakan untuk mengevaluasi konfigurasi, penggunaan, dan performa load balancer. Metrik juga dapat digunakan untuk memecahkan masalah serta meningkatkan pemanfaatan resource dan pengalaman pengguna. Untuk mengetahui petunjuknya, lihat Monitoring.
Memperbarui waktu tunggu keepalive HTTP klien
Load balancer yang dibuat pada langkah sebelumnya telah dikonfigurasi dengan nilai default untuk waktu tunggu keepalive HTTP klien. Untuk mengupdate waktu tunggu keepalive HTTP klien, gunakan petunjuk berikut.
Konsol
Di Konsol Google Cloud, buka halaman Load balancing.
- Klik nama load balancer yang ingin diubah.
- Klik Edit.
- Klik Frontend configuration.
- Luaskan Advanced features. Untuk HTTP keepalive timeout, masukkan nilai waktu tunggu dari 5 hingga 1.200 detik.
- Klik Perbarui.
- Untuk meninjau perubahan, klik Review and finalize, lalu klik Update.
gcloud
Untuk load balancer HTTP, perbarui proxy HTTP target menggunakan perintah gcloud compute target-http-proxies update
:
gcloud compute target-http-proxies update TARGET_HTTP_PROXY_NAME \ --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \ --global
Untuk load balancer HTTPS, perbarui proxy HTTPS target menggunakan perintah gcloud compute target-https-proxies update
:
gcloud compute target-https-proxies update TARGET_HTTPS_PROXY_NAME \ --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \ --global
Ganti kode berikut:
TARGET_HTTP_PROXY_NAME
: nama proxy HTTP target.TARGET_HTTPS_PROXY_NAME
: nama proxy HTTPS target.HTTP_KEEP_ALIVE_TIMEOUT_SEC
: nilai waktu tunggu keepalive HTTP dari 5 hingga 1.200 detik.
Aktifkan deteksi pencilan
Anda dapat mengaktifkan deteksi pencilan pada layanan backend global untuk mengidentifikasi NEG serverless yang tidak responsif dan mengurangi jumlah permintaan yang dikirim ke NEG serverless yang tidak responsif.
Deteksi pencilan diaktifkan di layanan backend dengan menggunakan salah satu metode berikut:
- Metode
consecutiveErrors
(outlierDetection.consecutiveErrors
), saat kode status HTTP seri5xx
memenuhi syarat sebagai error. - Metode
consecutiveGatewayFailure
(outlierDetection.consecutiveGatewayFailure
), yang hanya menggunakan kode status HTTP502
,503
, dan504
yang memenuhi syarat sebagai error.
Gunakan langkah-langkah berikut untuk mengaktifkan deteksi pencilan untuk layanan backend
yang sudah ada. Perlu diperhatikan bahwa meskipun setelah mengaktifkan deteksi pencilan, beberapa permintaan dapat dikirim ke layanan yang tidak responsif dan menampilkan kode status 5xx
ke klien. Untuk mengurangi tingkat error lebih lanjut, Anda dapat mengonfigurasi nilai yang lebih agresif untuk parameter deteksi pencilan. Untuk mengetahui informasi selengkapnya, lihat
kolom outlierDetection
.
Konsol
Di konsol Google Cloud, buka halaman Load balancing.
Klik nama load balancer yang layanan backend-nya ingin Anda edit.
Di halaman Load balancer details, klik
Edit.Di halaman Edit global external Application Load Balancer, klik Backend configuration.
Di halaman Backend configuration, klik
Edit untuk layanan backend yang ingin diubah.Scroll ke bawah, lalu luaskan bagian Advanced configurations.
Di bagian Deteksi luar, centang kotak Aktifkan.
Klik
Edit untuk mengonfigurasi deteksi pencilan.Pastikan opsi berikut dikonfigurasi dengan nilai ini:
Properti Nilai Error berkelanjutan 5 Interval 1.000 Waktu ejeksi dasar 30000 Persentase ejeksi maks. 50 Menimbulkan error berturut-turut 100 Dalam contoh ini, analisis deteksi pencilan berjalan setiap satu detik. Jika jumlah kode status
5xx
HTTP berturut-turut yang diterima oleh proxy Envoy adalah lima atau lebih, endpoint backend akan dikeluarkan dari kumpulan load balancing proxy Envoy tersebut selama 30 detik. Jika persentase yang berlaku ditetapkan ke 100%, layanan backend akan menerapkan penghapusan endpoint yang tidak responsif dari kumpulan load balancing proxy Envoy spesifik tersebut setiap kali analisis deteksi pencilan berjalan. Jika kondisi pengecualian terpenuhi, hingga 50% endpoint backend dari kumpulan load balancing dapat dikeluarkan.Klik Save.
Untuk mengupdate layanan backend, klik Update.
Untuk memperbarui load balancer, di halaman Edit global external Application Load Balancer, klik Update.
gcloud
Mengekspor layanan backend ke file YAML.
gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME.yaml --global
Ganti
BACKEND_SERVICE_NAME
dengan nama layanan backend.Edit konfigurasi YAML dari layanan backend guna menambahkan kolom untuk deteksi pencilan seperti yang ditandai dalam konfigurasi YAML berikut.
Dalam contoh ini, analisis deteksi pencilan berjalan setiap satu detik. Jika jumlah kode status
5xx
HTTP berturut-turut yang diterima oleh proxy Envoy adalah lima atau lebih, endpoint backend akan dikeluarkan dari kumpulan load balancing proxy Envoy tersebut selama 30 detik. Jika persentase yang berlaku ditetapkan ke 100%, layanan backend akan menerapkan penghapusan endpoint yang tidak responsif dari kumpulan load balancing proxy Envoy spesifik tersebut setiap kali analisis deteksi pencilan berjalan. Jika kondisi pengecualian terpenuhi, hingga 50% endpoint backend dari kumpulan load balancing dapat dikeluarkan.name: BACKEND_SERVICE_NAME backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME - balancingMode: UTILIZATION capacityScaler: 1.0 group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2 outlierDetection: baseEjectionTime: nanos: 0 seconds: 30 consecutiveErrors: 5 enforcingConsecutiveErrors: 100 interval: nanos: 0 seconds: 1 maxEjectionPercent: 50 port: 80 selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME sessionAffinity: NONE timeoutSec: 30 ...
Ganti kode berikut:
BACKEND_SERVICE_NAME
: nama layanan backendPROJECT_ID
: ID project AndaREGION_A
danREGION_B
: region tempat load balancer dikonfigurasi.SERVERLESS_NEG_NAME
: nama NEG serverless pertamaSERVERLESS_NEG_NAME_2
: nama NEG serverless kedua
Update layanan backend dengan mengimpor konfigurasi terbaru.
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME.yaml --global
Deteksi pencilan kini diaktifkan di layanan backend.
Menghapus NEG serverless
Grup endpoint jaringan tidak dapat dihapus jika dipasang ke layanan backend. Sebelum Anda menghapus NEG, pastikan NEG dilepas dari layanan backend.
Konsol
- Untuk memastikan NEG serverless yang ingin Anda hapus saat ini tidak digunakan oleh layanan backend mana pun, buka tab Backend services pada Menu lanjutan load balancing.
Buka tab Layanan backend - Jika NEG serverless saat ini digunakan:
- Klik nama layanan backend menggunakan NEG serverless.
- Klik Edit .
- Dari daftar Backend, klik untuk menghapus backend NEG serverless dari layanan backend.
- Klik Save.
- Buka halaman Grup endpoint jaringan di Konsol Google Cloud.
Buka halaman Grup Endpoint Jaringan - Pilih kotak centang untuk NEG serverless yang ingin Anda hapus.
- Klik Delete.
- Klik Delete lagi untuk mengonfirmasi.
gcloud
Untuk menghapus NEG serverless dari layanan backend, Anda harus menentukan region tempat NEG dibuat. Anda juga harus menentukan tanda --global
karena helloworld-backend-service
adalah resource global.
gcloud compute backend-services remove-backend helloworld-backend-service \ --network-endpoint-group=helloworld-serverless-neg \ --network-endpoint-group-region=us-central1 \ --global
Untuk menghapus NEG serverless:
gcloud compute network-endpoint-groups delete helloworld-serverless-neg \ --region=us-central1
Langkah selanjutnya
- Menggunakan logging dan pemantauan
- Memecahkan masalah NEG serverless
- Membersihkan penyiapan load balancer
- Menggunakan modul Terraform untuk load balancer HTTPS eksternal dengan backend Cloud Run