Menyiapkan domain kustom untuk instance IP pribadi Looker (inti Google Cloud): Traffic yang berasal dari berbagai region

Anda dapat menyalurkan instance Looker (Google Cloud core) melalui domain web kustom, bukan melalui domain default yang disediakan Looker (Google Cloud core).

Halaman dokumentasi ini menjelaskan cara menyiapkan dan mengakses domain kustom untuk instance yang memenuhi kedua kriteria berikut:

  • Instance merupakan IP pribadi saja.
  • Traffic ke instance berasal dari region yang berbeda tempat instance berada di atau melalui jaringan hybrid.

Guna menerapkan domain kustom untuk instance jenis ini, lakukan langkah-langkah berikut:

  1. Siapkan domain kustom.
  2. Buat VM dan zona pribadi.
  3. Konfigurasikan server reverse proxy.
  4. Buat dan konfigurasi load balancer.
  5. Buat aturan firewall.
  6. Perbarui data A DNS.
  7. Perbarui kredensial OAuth.

Menyiapkan domain kustom

Setelah instance Looker (Google Cloud core) dibuat, Anda dapat menyiapkan domain kustom untuk instance.

Sebelum memulai

Sebelum Anda dapat menyesuaikan domain instance Looker (Google Cloud core), identifikasi lokasi penyimpanan data DNS domain Anda, agar Anda dapat memperbaruinya.

Peran yang diperlukan

Guna mendapatkan izin yang diperlukan untuk membuat domain kustom untuk instance Looker (Google Cloud core), minta administrator untuk memberi Anda Peran IAM Looker Admin (roles/looker.admin) pada project tempat instance berada. Untuk mengetahui informasi selengkapnya tentang cara memberikan peran, lihat Mengelola akses ke project, folder, dan organisasi.

Anda mungkin juga bisa mendapatkan izin yang diperlukan melalui perintah peran atau setelan standar lainnya peran tertentu.

Membuat domain kustom

Di konsol Google Cloud, ikuti langkah-langkah berikut untuk menyesuaikan domain instance Looker (Google Cloud core) Anda:

  1. Di halaman Instances, klik nama instance yang ingin Anda siapkan domain kustomnya.
  2. Klik tab DOMAIN KUSTOM.

  3. Klik TAMBAHKAN DOMAIN KUSTOM.

    Tindakan ini akan membuka panel Tambahkan domain kustom baru.

  4. Hanya dengan menggunakan huruf, angka, dan tanda hubung, masukkan nama host yang berisi maksimal 64 karakter untuk domain web yang ingin Anda gunakan — misalnya: looker.examplepetstore.com.

  5. Klik DONE di panel Add a new custom domain untuk kembali ke tab CUSTOM DOMAIN.

Setelah disiapkan, domain kustom Anda akan ditampilkan di kolom Domain di tab Custom Domain pada halaman detail instance Konsol Google Cloud.

Setelah domain kustom dibuat, Anda dapat melihat informasi tentang domain tersebut atau menghapusnya.

Mengakses domain kustom

Jika traffic ke instance Looker (inti Google Cloud) khusus IP pribadi berasal dari region yang berbeda dengan instance, Anda dapat menggunakan satu atau beberapa server reverse proxy IP pribadi dan load balancer untuk menyediakan akses yang aman ke instance.

Sebelum memulai

Untuk mendapatkan izin akses yang Anda butuhkan untuk mengatur akses ke domain khusus IP pribadi, minta administrator untuk memberi Anda peran IAM berikut pada project tempat instance berada:

Untuk mengetahui informasi selengkapnya tentang cara memberikan peran, lihat Mengelola akses ke project, folder, dan organisasi.

Anda mungkin juga bisa mendapatkan izin yang diperlukan melalui perintah peran atau setelan standar lainnya peran tertentu.

Ringkasan jaringan

Bagian berikut menunjukkan cara membuat penyiapan server proxy NGINX atau Apache yang redundan, dengan load balancer, untuk merutekan traffic dari wilayah mana pun atau dari lokal ke domain kustom. Diagram berikut mewakili topologi ini:

Jaringan Google Cloud yang menampilkan akses aman ke instance Looker (Google Cloud core) menggunakan Cloud Router, load balancer internal, dan Akses Layanan Pribadi.

Membuat VM dan zona pribadi

  1. Buat dua instance VM khusus IP pribadi dengan sistem operasi RHEL. VM akan bertindak sebagai server {i>proxy<i} Anda. Keduanya harus berada di dalam region yang sama dengan instance Looker (inti Google Cloud), tetapi berada di zona yang berbeda antara satu sama lain.
  2. Buat zona pribadi Cloud DNS untuk mengelola data Cloud DNS Anda. Zona pribadi harus terlihat oleh VPC tempat instance Looker (inti Google Cloud) berada. Zona pribadi Cloud DNS akan digunakan oleh VPC dan host lokal untuk resolusi DNS agar dapat menjangkau UI Looker (Google Cloud core). Karena Anda akan menggunakan load balancer, data A di zona pribadi Cloud DNS akan dipetakan ke alamat IP load balancer.

Mengonfigurasi server proxy terbalik

Anda dapat menggunakan server web apa pun yang dapat dikonfigurasi sebagai server {i>reverse proxy<i}. Pilih salah satu opsi berikut untuk melihat contoh cara menyiapkan server reverse proxy menggunakan NGINX atau Apache:

NGINX

Contoh berikut menggunakan rilis NGINX 1.22.1 dan rilis Red Hat Enterprise Linux 8.9 (Ootpa). Untuk memeriksa versi NGNIX dan Red Hat yang digunakan VM Anda, jalankan perintah berikut untuk setiap VM.

  1. Pertama, hubungkan ke VM.

  2. Instal NGINX menggunakan perintah berikut:

    sudo yum install nginx -y

  3. Untuk mengetahui versi NGINX yang dijalankan VM, jalankan perintah berikut: 

    sudo nginx -v

    Tindakan ini akan menampilkan sesuatu yang mirip dengan berikut ini:

    nginx version: nginx/1.22.1

  4. Untuk memeriksa rilis NGINX yang dijalankan VM, jalankan perintah berikut: 

    sudo rpm -qi nginx | grep Release

    Perintah ini akan menampilkan sesuatu yang mirip dengan yang berikut ini:

    Release : 1.module+el8.8.0+20355+6d9c8a63.1

  5. Untuk memeriksa versi Red Hat yang digunakan VM Anda, jalankan perintah berikut:

    sudo cat /etc/redhat-release

Untuk menyiapkan setiap server proxy, gunakan petunjuk berikut untuk masing-masing dari dua VM yang Anda buat.

  1. Menghubungkan ke VM.

  2. Edit file /etc/nginx/nginx.conf agar berisi konfigurasi berikut:

    events {
  worker_connections 1024;
}

http {
  log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

  log_format debug  '$http_x_forwarded_for - $remote_user [$time_local] '
                    '"$request_method $scheme://$host$request_uri $server_protocol" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" $request_time';

  access_log  /var/log/nginx/access.log  debug;

  sendfile            on;
  tcp_nopush          on;
  keepalive_timeout   65;
    types_hash_max_size 4096;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

server {
  listen 443 ssl;
  # listen [::]:443 ssl;
  include snippets/self-signed.conf;
  # include snippets/ssl-params.conf;
  server_name CUSTOM_DOMAIN;
  location / {
    proxy_pass https://INGRESS_PRIVATE_IP/$request_uri;
    proxy_set_header Host $server_name;
    proxy_http_version 1.1;
  }
}
server {
  listen 80;
  # listen [::]:80;
  server_name CUSTOM_DOMAIN;
  return 302 https://$server_name$request_uri;
  }
}

    Ganti kode berikut:

    • CUSTOM_DOMAIN: Domain kustom instance Looker (Google Cloud core) Anda
    • INGRESS_PRIVATE_IP: IP pribadi masuk untuk instance Looker (Google Cloud core) Anda

    Selain itu, pertimbangkan hal-hal berikut:

    • Ini adalah konfigurasi khusus IPv4. Jika Anda mengharuskan proxy juga memproses alamat IPv6 pribadinya, hapus tanda komentar pada baris listen [::]:443 ssl di file.
    • Level log akses ditetapkan ke debug; pastikan untuk menyesuaikannya dengan level yang digunakan di lingkungan tertentu.
    • Jika Anda menerapkan file ssl-params.conf, yang dirujuk nanti dalam langkah-langkah ini, hapus tanda komentar include snippets/ssl-params.conf.

  3. Buat sertifikat TLS valid yang merujuk ke URL domain kustom Looker (Google Cloud core). Sertifikat ini akan menjadi sertifikat yang diberikan proxy kepada klien yang mencoba mengakses Looker (inti Google Cloud). Otoritas Sertifikat (CA) yang digunakan untuk menandatangani sertifikat harus dipercaya oleh klien Anda; Anda juga dapat menggunakan CA pribadi internal untuk menandatangani sertifikat TLS ini. (Atau, Anda juga dapat menggunakan sertifikat SSL yang dikelola sendiri.)

    Dalam contoh ini, anggaplah sertifikat telah dibuat menggunakan layanan gratis Let's Encrypt, tanpa perlu menyiapkan perpanjangan otomatis melalui Certbot. Setelah sertifikat dibuat, simpan file yang relevan di direktori certs dan private di setiap VM proxy:

    /etc/pki/tls/certs/custom-domain.custom-domain.com.fullchain.pem;
/etc/pki/tls/private/custom-domain.custom-domain.com.key.pem;

    Ganti custom-domain.custom-domain.com dengan domain kustom Anda.

    Jika direktori certs dan private tidak ada di penginstalan, Anda dapat membuatnya atau menggunakan folder lain.

  4. Untuk memastikan bahwa NGINX mengambil file sertifikat, buat direktori /etc/nginx/snippets:

    sudo mkdir /etc/nginx/snippets

  5. Buat file konfigurasi, /etc/nginx/snippets/self-signed.conf:

    sudo touch /etc/nginx/snippets/self-signed.conf

    Edit file konfigurasi untuk menambahkan jalur ke file sertifikat yang Anda simpan:

    ssl_certificate /etc/pki/tls/certs/custom-domain.custom-domain.com.fullchain.pem;
ssl_certificate_key /etc/pki/tls/private/custom-domain.custom-domain.com.key.pem;

    Ganti custom-domain.custom-domain.com dengan domain kustom Anda.

  6. Untuk mengonfirmasi bahwa file konfigurasi berisi referensi ke file yang disebutkan di langkah sebelumnya, jalankan perintah berikut: 

    sudo more /etc/nginx/snippets/self-signed.conf

    Ini akan menampilkan jalur file yang Anda tambahkan.

  7. Secara opsional, buat file NGINX ssl-params.conf, yang dapat digunakan untuk menyimpan parameter yang dapat digunakan kembali dalam konfigurasi NGINX mendatang.

    Untuk referensi, isi file akan terlihat seperti berikut:

    ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/dhparam.pem;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
ssl_ecdh_curve secp384r1;
ssl_session_timeout  10m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 127.0.0.53 valid=300s;
resolver_timeout 5s;
# Disable strict transport security for now. You can uncomment the following
# line if you understand the implications.
#add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";

  8. Untuk mengonfigurasi SELinux agar dapat meneruskan traffic ke IP masuk Looker (Google Cloud core), tetapkan parameter boolean SELinux httpd_can_network_connect ke 1:

    sudo setsebool -P httpd_can_network_connect 1

  9. Sekarang Anda dapat memulai ulang proses NGINX menggunakan perintah berikut:

    sudo systemctl restart nginx

  10. Pastikan NGINX telah dimulai ulang dengan benar menggunakan perintah berikut:

    sudo systemctl status nginx

    Output yang ditampilkan akan mirip dengan berikut ini:

    nginx.service - The nginx HTTP and reverse proxy server
  Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
  Active: active (running) since Tue 2024-05-14 11:58:00 UTC; 9min ago
  Process: 144044 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
  Process: 144042 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
  Process: 144039 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
Main PID: 144045 (nginx)
    Tasks: 2 (limit: 11040)
  Memory: 2.6M
  CGroup: /system.slice/nginx.service
          ├─144045 nginx: master process /usr/sbin/nginx
          └─144046 nginx: worker process
May 14 11:58:00 proxy-three-eu-w4 systemd[1]: nginx.service: Succeeded.
May 14 11:58:00 proxy-three-eu-w4 systemd[1]: Stopped The nginx HTTP and reverse proxy server.
May 14 11:58:00 proxy-three-eu-w4 systemd[1]: Starting The nginx HTTP and reverse proxy server...
May 14 11:58:00 proxy-three-eu-w4 nginx[144042]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
May 14 11:58:00 proxy-three-eu-w4 nginx[144042]: nginx: configuration file /etc/nginx/nginx.conf test is successful
May 14 11:58:00 proxy-three-eu-w4 systemd[1]: Started The nginx HTTP and reverse proxy server.

Apache

Selesaikan langkah-langkah berikut untuk setiap VM.

  1. Pertama, hubungkan ke VM.

  2. Instal Apache:

    sudo yum install httpd -y

  3. Contoh berikut menggunakan Red Hat Enterprise Linux rilis 7.9. Untuk memeriksa versi Red Hat yang digunakan VM Anda, jalankan perintah berikut:

    cat /etc/redhat-release

    Tindakan ini akan menampilkan hal berikut:

    Red Hat Enterprise Linux Server release 7.9 (Maipo)

  4. Contoh berikut menggunakan rilis Apache 2.4.6. Untuk memeriksa versi Apache yang digunakan VM Anda, jalankan perintah berikut untuk setiap VM:

    sudo httpd -version

    Tindakan ini akan menampilkan hal berikut:

    Server version: Apache/2.4.6 (Red Hat Enterprise Linux)
Server built:   date

  5. Untuk mengetahui informasi selengkapnya tentang server Apache, jalankan perintah berikut:

    sudo rpm -qi httpd

    Perintah ini akan menampilkan output yang mirip dengan berikut ini:

    Name        : httpd
Version     : 2.4.6
Release     : 99.el7_9.1
Architecture: x86_64
Install Date: Tue May  7 15:48:59 2024
Group       : System Environment/Daemons
Size        : 3899819
License     : ASL 2.0
Signature   : RSA/SHA256, Fri Apr 28 17:09:45 2023, Key ID 199e2f91fd431d51
Source RPM  : httpd-2.4.6-99.el7_9.1.src.rpm
Build Date  : Fri Apr 28 16:56:11 2023
Build Host  : x86-vm-40.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. 
Vendor      : Red Hat, Inc.
URL         : http://httpd.apache.org/
Summary     : Apache HTTP Server
Description :
The Apache HTTP Server is a powerful, efficient, and extensible
web server.

  6. Buat file konfigurasi /etc/httpd/conf.d/ssl.conf di VM proxy, lalu tambahkan konfigurasi berikut ke file tersebut:

    ServerName custom domain of Looker (Google Cloud core)
#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
SSLEngine on
#   SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect.  Disable SSLv2 access by default:
SSLProtocol all -SSLv2 -SSLv3
#   SSL Cipher Suite:
#   List the ciphers that the client is permitted to negotiate.
#   See the mod_ssl documentation for a complete list.
SSLCipherSuite HIGH:3DES:!aNULL:!MD5:!SEED:!IDEA
#   Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate.  If
# the certificate is encrypted, then you will be prompted for a
# pass phrase.  Note that a kill -HUP will prompt again.  A new
# certificate can be generated using the genkey(1) command.
# SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateFile "/etc/pki/tls/certs/custom domain of Looker (Google Cloud core).crt"
#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
# SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
SSLCertificateKeyFile "/etc/pki/tls/private/custom domain of Looker (Google Cloud core).key"
SSLProxyEngine On
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
ProxyPreserveHost On
RewriteEngine On
AllowEncodedSlashes NoDecode
ProxyPass / https://private IP of Looker (Google Cloud core)>:443/
RewriteCond %{REQUEST_URI} ^/render/
RewriteRule ^(.*)$ https://private IP of Looker (Google Cloud core)>:443/$1 [P]
RewriteRule ^(.*)$ https://private IP of Looker (Google Cloud core)>:443/$1 [P,NE]
ProxyPassReverse / https://private IP of Looker (Google Cloud core):443/

    Ganti kode berikut:

    • custom domain of Looker (Google Cloud core): Domain kustom instance Looker (inti Google Cloud) Anda.
    • private IP of Looker (Google Cloud core): IP pribadi instance Looker (inti Google Cloud) Anda.

  7. Pastikan file sertifikat TLS tersedia di direktori yang dirujuk dalam file /etc/httpd/conf.d/ssl.conf:

    SSLCertificateFile "/etc/pki/tls/certs/custom domain of Looker (Google Cloud core).crt"
SSLCertificateKeyFile "/etc/pki/tls/private/custom domain of Looker (Google Cloud core).key"

  8. Periksa apakah mod_ssl telah diinstal:

    sudo yum list installed | grep mod_ssl

    Jika mod_ssl tidak diinstal, instal dengan perintah berikut:

    sudo yum install mod_ssl

    Setelah mod_ssl terinstal, Anda harus mengaktifkannya dengan menambahkan baris berikut ke file konfigurasi Apache, /etc/httpd/conf/httpd.conf:

    LoadModule ssl_module modules/mod_ssl.so

  9. Di file konfigurasi Apache, /etc/httpd/conf/httpd.conf, ganti Listen 80 dengan Listen 443.

  10. Jalankan perintah berikut untuk mengizinkan VM proxy Apache meneruskan traffic ke Looker (Google Cloud core):

    /usr/sbin/setsebool -P httpd_can_network_connect 1

  11. Terakhir, mulai ulang Apache untuk menerapkan perubahan:

    sudo systemctl restart httpd

  12. Pastikan modul penulisan ulang dimuat dan siap di Apache menggunakan perintah ini:

    sudo httpd -M | grep rewrite

    Tindakan ini akan menampilkan output yang mirip dengan berikut ini:

    rewrite_module (shared)

  13. Terakhir, mulai atau mulai ulang proses Apache, untuk memastikan semua perubahan konfigurasi diambil:

    sudo systemctl restart httpd

  14. Pastikan proses Apache telah dimulai ulang dengan benar menggunakan perintah berikut: 

    sudo systemctl status httpd

    Tindakan ini akan menampilkan output yang mirip dengan berikut ini:

    httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
Active: active (running) since Tue 2024-05-14 15:41:57 UTC; 1s ago
  Docs: man:httpd(8)
        man:apachectl(8)
Main PID: 1400 (httpd)
Status: "Processing requests..."
CGroup: /system.slice/httpd.service
        ├─1400 /usr/sbin/httpd -DFOREGROUND
        ├─1401 /usr/sbin/httpd -DFOREGROUND
        ├─1402 /usr/sbin/httpd -DFOREGROUND
        ├─1403 /usr/sbin/httpd -DFOREGROUND
        ├─1404 /usr/sbin/httpd -DFOREGROUND
        └─1405 /usr/sbin/httpd -DFOREGROUND
May 14 15:41:57 proxy-ingress-apache systemd[1]: Starting The Apache HTTP Server...
May 14 15:41:57 proxy-ingress-apache systemd[1]: Started The Apache HTTP Server.

Membuat dan mengonfigurasi load balancer

Contoh ini menggunakan grup endpoint jaringan zona (NEG) dengan endpoint GCE_VM_IP sebagai backend Load Balancer Jaringan passthrough internal. Jika Anda lebih suka menggunakan backend berbasis grup instance, ikuti dokumentasi yang tersedia di halaman dokumentasi Menyiapkan Load Balancer Jaringan passthrough internal dengan backend grup instance VM.

  1. Buat satu NEG zona terpisah untuk setiap zona komputasi tempat Anda berencana men-deploy server proxy. Misalnya, jika Anda ingin men-deploy server proxy di ketiga zona komputasi region tempat Looker (Google Cloud core) di-deploy, buat tiga NEG zona. Lihat halaman dokumentasi Kuota dan batas untuk memeriksa jumlah endpoint yang didukung per NEG zona.

    Untuk membuat NEG zona, gunakan perintah gcloud berikut:

    gcloud compute network-endpoint-groups create NEG_NAME --network-endpoint-type=gce-vm-ip \
--zone=PROXY_INSTANCE_ZONE --network=PROXY_INSTANCE_VPC \
--subnet=PROXY_INSTANCE_SUBNET

    Ganti kode berikut:

    • NEG_NAME: Nama NEG yang Anda buat.
    • PROXY_INSTANCE_ZONE: Zona tempat server proxy berada.
    • PROXY_INSTANCE_VPC: VPC yang berisi server proxy.
    • PROXY_INSTANCE_SUBNET: Subnet tempat server proxy berada.

    Ulangi langkah ini untuk zona tambahan tempat Anda akan men-deploy VM server proxy.

  2. Tambahkan setiap server proxy ke NEG di zona yang sama:

    gcloud compute network-endpoint-groups update NEG_NAME --zone=PROXY_INSTANCE_ZONE \
--add-endpoint='instance=PROXY_INSTANCE_NAME'

    Ganti kode berikut:

    • PROXY_INSTANCE_ZONE: Zona tempat server proxy berada.
    • NEG_NAME: Nama NEG di zona yang sama dengan server proxy.
    • PROXY_INSTANCE_NAME: Nama server proxy.

    Ulangi langkah ini hingga setiap VM server proxy ditambahkan ke NEG sebagai endpoint.

  3. Buat health check regional yang akan digunakan oleh load balancer internal. Gunakan perintah compute health-checks create:

    gcloud compute health-checks create PROTOCOL NAME \
    --region=REGION \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    PORT_SPECIFICATION \
    ADDITIONAL_FLAGS

    Ganti kode berikut:

    • PROTOCOL: Protokol yang digunakan untuk pemeriksaan kondisi. Berlaku opsinya adalah grpc, http, https, http2, ssl, dan tcp.
    • NAME: Nama health check. Dalam project tertentu, setiap health check global harus memiliki nama unik, dan health check regional harus memiliki nama unik di dalam region tertentu.
    • REGION: Semua load balancer kecuali untuk Load Balancer Aplikasi eksternal regional dan Load Balancer Aplikasi internal regional digunakan health check global (--global). Load Balancer Aplikasi internal regional menggunakan health check yang regionnya harus cocok dengan region layanan backend.
    • DESCRIPTION: Deskripsi opsional.
    • CHECK_INTERVAL: Jumlah waktu dari awal satu kondisi memeriksa koneksi sistem probe ke awal koneksi berikutnya. Unit adalah detik. Jika dihilangkan, Google Cloud akan menggunakan nilai 5s (5 detik).
    • TIMEOUT: Jumlah waktu tunggu Google Cloud sebagai respons terhadap penyelidikan. Nilai TIMEOUT harus kurang dari atau sama dengan CHECK_INTERVAL. Unit dalam hitungan detik. Jika dihilangkan, Google Cloud menggunakan nilai 5s (5 detik).
    • HEALTHY_THRESHOLD dan UNHEALTHY_THRESHOLD: Menentukan jumlah pemeriksaan berurutan yang harus berhasil atau gagal agar instance VM dapat dianggap sehat atau tidak sehat. Jika salah satunya dihilangkan, Google Cloud menggunakan nilai minimum default sebesar 2.
    • PORT_SPECIFICATION: Menentukan spesifikasi port menggunakan salah satu Flag spesifikasi port.
    • ADDITIONAL_FLAGS: Flag lain untuk menentukan port dan opsi khusus untuk PROTOCOL. Lihat Tanda tambahan untuk HTTP, HTTPS, dan health check HTTP/2, Tanda tambahan untuk kondisi SSL dan TCP pemeriksaan, atau Flag tambahan untuk health check gRPC.

  4. Buat layanan backend:

    gcloud compute backend-services create BS_NAME --load-balancing-scheme=INTERNAL \
--protocol=tcp --region=PROXY_INSTANCES_REGION --health-checks=HC_NAME \
--health-checks-region=HC_REGION --session-affinity=CLIENT_IP \
--connection-persistence-on-unhealthy-backends=NEVER_PERSIST

    Ganti kode berikut:

    • BS_NAME: Nama load balancer yang Anda buat.
    • PROXY_INSTANCES_REGION: Region tempat server proxy berada.
    • HC_NAME: Nama health check regional yang Anda buat.
    • HC_REGION: Wilayah tempat health check berada.

    Selain itu:

    • Flag --session-affinity=CLIENT_IP mengarahkan permintaan klien tertentu ke VM instance proxy backend yang sama, berdasarkan hash yang dibuat di alamat IP klien dan alamat tujuan.
    • Flag --connection-persistence-on-unhealthy-backends=NEVER_PERSIST berarti koneksi tidak akan tetap ada di VM instance proxy yang tidak responsif.

  5. Tambahkan setiap NEG ke layanan backend:

    gcloud compute backend-services add-backend BS_NAME --region=BS_REGION \
--network-endpoint-group=NEG_NAME --network-endpoint-group-zone=NEG_ZONE

    Ganti kode berikut:

    • BS_NAME: Nama layanan backend yang Anda buat.
    • BS_REGION: Region tempat layanan backend berada; region ini harus sama dengan region tempat server proxy berada.
    • NEG_NAME: Nama NEG yang Anda tambahkan.
    • NEG_ZONE: Zona tempat NEG berada.

    Ulangi langkah ini untuk NEG tambahan yang Anda buat.

  6. Cadangkan alamat IP internal di VPC di dalam rentang IP subnet tempat instance proxy terhubung. Ini akan menjadi alamat IP Virtual (VIP) dari load balancer internal. Dengan menyimpan alamat, Anda akan memastikan IP tidak akan digunakan oleh objek lain. Untuk mereservasi alamat IP internal, gunakan perintah compute addresses create:

    gcloud compute addresses create ADDRESS_NAMES \
    --region REGION --subnet SUBNETWORK \
    --addresses IP_ADDRESS

    Ganti kode berikut:

    • ADDRESS_NAMES: Nama satu atau beberapa alamat [--purpose=SHARED_LOADBALANCER_VIP] yang ingin Anda buat. Jika terdapat beberapa alamat, tentukan semua alamat sebagai daftar, yang dipisahkan dengan spasi—misalnya, example-address-1 example-address-2 example-address-3
    • REGION: Region untuk permintaan ini.
    • SUBNETWORK: Subnet untuk IP internal ini alamat IPv6
    • IP_ADDRESS: Alamat IP yang akan dicadangkan, yang harus berada dalam rentang IP utama subnet. Jika tidak ditentukan, alamat IP akan otomatis dialokasikan dari subnet.

  7. Buat aturan penerusan dan kaitkan dengan layanan backend dan VIP:

    gcloud compute forwarding-rules create FW_RULE_NAME --region=BS_REGION \
--load-balancing-scheme=internal --network=PROXY_INSTANCES_VPC_NAME --subnet=RESERVED_IP_ADDRESS_SUBNET \
--address=RESERVED_IP_ADDRESS --ip-protocol=tcp --ports=ALL --backend-service=BS_NAME \
--backend-service-region=BS_REGION --allow-global-access

    Ganti kode berikut:

    • FW_RULE_NAME: Nama aturan penerusan yang Anda buat.
    • BS_REGION: Region tempat layanan backend berada
    • PROXY_INSTANCES_VPC_NAME: Nama VPC tempat VM server proxy dibuat
    • RESERVED_IP_ADDRESS_SUBNET: Subnet tempat VIP berada
    • RESERVED_IP_ADDRESS: Alamat VIP untuk load balancer
    • BS_NAME: Nama layanan backend

    Selain itu:

    • Tanda --allow-global-access menunjukkan bahwa VIP load balancer dapat dijangkau dari region mana pun (bukan hanya BS_REGION). Dengan demikian, klien di setiap region dapat menjangkau instance Looker (inti Google Cloud).

Membuat aturan firewall

Agar health check berfungsi, buat aturan firewall ingress yang berlaku untuk VM proxy yang di-load balance untuk mengizinkan traffic dari rentang IP penguji health check.

Selain itu, buat aturan firewall masuk untuk mengizinkan traffic dari lingkungan lokal atau multicloud mendapatkan akses ke layanan backend load balancer.

Perbarui data A DNS

Ubah data A domain kustom Looker (inti Google Cloud) agar mengarah ke VIP load balancer. Zona pribadi Cloud DNS yang Anda buat mengelola domain kustom dan digunakan oleh VPC tempat instance proxy berada.

Memperbarui kredensial OAuth

  1. Akses klien OAuth Anda dengan membuka APIs & Services > Credentials di konsol Google Cloud dan memilih client ID OAuth untuk klien OAuth yang digunakan oleh instance Looker (inti Google Cloud) Anda.

  2. Klik tombol Tambahkan URI untuk memperbarui kolom Asal JavaScript resmi di klien OAuth Anda agar menyertakan nama DNS yang sama dengan yang akan digunakan organisasi Anda untuk mengakses Looker (inti Google Cloud). Jadi, jika domain kustom Anda adalah looker.examplepetstore.com, Anda memasukkan looker.examplepetstore.com sebagai URI.

  3. Perbarui atau tambahkan domain kustom ke daftar Authorized redirect URI untuk kredensial OAuth yang Anda gunakan saat membuat instance Looker (Google Cloud core). Tambahkan /oauth2callback ke akhir URI. Jadi, jika domain kustom Anda adalah looker.examplepetstore.com, masukkan looker.examplepetstore.com/oauth2callback.

Menambahkan pengguna

Setelah langkah sebelumnya selesai, URL domain kustom dapat diakses oleh pengguna.

Pastikan metode autentikasi pengguna sudah disiapkan sepenuhnya untuk instance Looker (inti Google Cloud) sebelum menambahkan pengguna ke instance.

Pemecahan masalah

  • Jika Anda menggunakan Chrome untuk mengakses domain kustom Looker (Google Cloud core) dan menerima error Chrome seperti NET::ERR_CERT_COMMON_NAME_INVALID atau error kebijakan PRIA, Anda dapat memperbaikinya dengan mengikuti langkah-langkah berikut:

    1. Buka chrome://net-internals/#hsts
    2. Masukkan domain kustom untuk mengkueri kumpulan laris/PKP. Semua kebijakan untuk domain kustom akan muncul di bagian Ditemukan:.
    3. Pada bagian Delete domain security policies, masukkan domain kustom di kolom Domain.
    4. Klik Delete untuk menghapus kebijakan.

  • Untuk memecahkan masalah error sertifikat, lihat halaman dokumentasi Memecahkan masalah sertifikat SSL. Untuk sertifikat yang dikelola Google, pastikan untuk memberi otorisasi secara eksplisit kepada Certificate Authority yang ingin Anda izinkan untuk menerbitkan sertifikat yang dikelola Google.

Langkah selanjutnya