Accedi a un'istanza di Looker (Google Cloud core) utilizzando l'accesso privato ai servizi: traffico proveniente da regioni diverse

Questa pagina della documentazione descrive come configurare un dominio personalizzato e l'accesso a un'istanza di Looker (Google Cloud core) che soddisfi i seguenti criteri:

Per accedere a questo tipo di istanza, segui questi passaggi:

  1. Configura il dominio personalizzato.
  2. Crea delle VM e una zona privata.
  3. Configura i server proxy inverso.
  4. Crea e configura il bilanciatore del carico.
  5. Crea regole firewall.
  6. Aggiorna il record A DNS.
  7. Aggiorna le credenziali OAuth.

Configurazione di un dominio personalizzato

Dopo aver creato l'istanza di Looker (Google Cloud core), puoi configurare un dominio personalizzato.

Prima di iniziare

Prima di poter personalizzare il dominio dell'istanza di Looker (Google Cloud core), devi identificare dove sono archiviati i record DNS del dominio per poterli aggiornare.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per creare un dominio personalizzato per un'istanza di Looker (Google Cloud core), chiedi all'amministratore di concederti Ruolo IAM Amministratore Looker (roles/looker.admin) nel progetto in cui risiede l'istanza. Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Creare un dominio personalizzato

Nella console Google Cloud, segui questi passaggi per personalizzare il dominio dell'istanza di Looker (Google Cloud core):

  1. Nella pagina Istanze, fai clic sul nome dell'istanza per cui vuoi configurare un dominio personalizzato.
  2. Fai clic sulla scheda DOMINIO PERSONALIZZATO.

  3. Fai clic su AGGIUNGI UN DOMINIO PERSONALIZZATO.

    Si apre il riquadro Aggiungi un nuovo dominio personalizzato.

  4. Utilizzando solo lettere, numeri e trattini, inserisci il nome host di massimo 64 caratteri per il dominio web che vuoi utilizzare, ad esempio: looker.examplepetstore.com.

  5. Fai clic su FINE nel riquadro Aggiungi un nuovo dominio personalizzato per tornare alla scheda DOMINO PERSONALIZZATO.

Una volta configurato, il dominio personalizzato viene visualizzato nella colonna Dominio della scheda Dominio personalizzato della pagina dei dettagli dell'istanza della console Google Cloud.

Dopo aver creato il dominio personalizzato, puoi visualizzarne le informazioni o eliminarlo.

Accedere al dominio personalizzato

Quando il traffico verso un'istanza di Looker (Google Cloud core) con solo IP privato proviene da una regione diversa da quella dell'istanza, puoi utilizzare uno o più server proxy inversi IP privati e un bilanciatore del carico per fornire un accesso sicuro all'istanza.

Prima di iniziare

Per ottenere le autorizzazioni necessarie per configurare l'accesso a un dominio personalizzato con IP privato, chiedi all'amministratore di concederti i seguenti ruoli IAM nel progetto in cui si trova l'istanza:

Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite la ruoli o altri ruoli predefiniti ruoli.

Panoramica sul networking

Le sezioni seguenti mostrano come creare una configurazione del server proxy NGINX o Apache ridondante, con un bilanciatore del carico, per instradare il traffico da qualsiasi regione o da on-premise al dominio personalizzato. Il seguente diagramma rappresenta questa topologia:

Una rete Google Cloud che mostra l'accesso sicuro a un'istanza di Looker (Google Cloud core) tramite router Cloud, un bilanciatore del carico interno e l'accesso privato ai servizi.

Creare VM e una zona privata

  1. Crea due istanze VM solo con IP privati con un sistema operativo RHEL. Le VM fungeranno da server proxy. Devono trovarsi nella stessa regione dell'istanza Looker (Google Cloud core), ma in zone diverse.
  2. Crea una zona privata di Cloud DNS per la gestione dei record di Cloud DNS. La zona privata deve essere visibile al VPC in cui si trova l'istanza di Looker (Google Cloud core). La zona privata di Cloud DNS verrà utilizzata dal VPC e dagli host on-premise per la risoluzione DNS al fine di raggiungere l'UI di Looker (Google Cloud core). Poiché utilizzerai un bilanciatore del carico, il record A nella zona privata di Cloud DNS verrà mappato all'indirizzo IP del bilanciatore del carico.

Configura i server proxy inverso

Puoi utilizzare qualsiasi server web che può essere configurato come server proxy inverso. Seleziona una delle seguenti opzioni per visualizzare esempi di come configurare server proxy inversi utilizzando NGINX o Apache:

NGINX

L'esempio seguente utilizza NGINX release 1.22.1 e Red Hat Enterprise Linux release 8.9 (Ootpa). Per controllare le versioni di Nginx e Red Hat in uso nelle tue VM, esegui i comandi seguenti per ogni VM.

  1. Innanzitutto, connettiti alla VM.

  2. Installa NGINX utilizzando il seguente comando:

    sudo yum install nginx -y

  3. Per trovare la versione NGINX in esecuzione della VM, esegui questo comando: 

    sudo nginx -v

    Dovresti visualizzare un messaggio simile al seguente:

    nginx version: nginx/1.22.1

  4. Per controllare la release di NGINX in esecuzione nella VM, esegui quanto segue: 

    sudo rpm -qi nginx | grep Release

    Dovresti visualizzare un messaggio simile al seguente:

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

  5. Per controllare la versione di Red Hat utilizzata dalle VM, esegui il seguente comando:

    sudo cat /etc/redhat-release

Per configurare ogni server proxy, segui le istruzioni riportate di seguito per ciascuna delle due VM che hai creato.

  1. Connettiti alla VM.

  2. Modifica il file /etc/nginx/nginx.conf in modo che contenga la seguente configurazione:

    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;
  }
}

    Sostituisci quanto segue:

    • CUSTOM_DOMAIN: il dominio personalizzato della tua istanza di Looker (Google Cloud core)
    • INGRESS_PRIVATE_IP: l'IP privato di ingresso per l'istanza di Looker (Google Cloud core)

    Inoltre, considera quanto segue:

    • Questa è una configurazione solo IPv4. Se vuoi che il proxy ascolti anche sul suo indirizzo IPv6 privato, rimuovi il commento dalla riga listen [::]:443 ssl nel file.
    • Il livello del log di accesso è impostato su debug; assicurati di regolarlo in base al livello utilizzato nel tuo ambiente specifico.
    • Se implementi il file ssl-params.conf, a cui viene fatto riferimento più avanti in questi passaggi, rimuovi il commento da include snippets/ssl-params.conf.

  3. Crea un certificato TLS valido che faccia riferimento all'URL del dominio personalizzato Looker (Google Cloud core). Questo certificato sarà quello che il proxy presenta ai client che tentano di accedere a Looker (Google Cloud core). L'autorità di certificazione (CA) utilizzata per firmare il certificato deve essere attendibile per i client. Puoi anche utilizzare una CA privata interna per firmare questo certificato TLS. In alternativa, puoi anche utilizzare un certificato SSL autogestito.

    In questo esempio, supponiamo che il certificato sia già stato creato utilizzando il servizio gratuito Let's Encrypt, senza configurare il rinnovo automatico tramite Certbot. Dopo aver creato il certificato, salva i file pertinenti nelle directory certs e private su ogni VM proxy:

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

    Sostituisci custom-domain.custom-domain.com con il tuo dominio personalizzato.

    Se le directory certs e private non esistono nell'installazione, puoi crearle o utilizzare altre cartelle.

  4. Per assicurarti che NGINX rilevi i file dei certificati, crea la directory /etc/nginx/snippets:

    sudo mkdir /etc/nginx/snippets

  5. Crea il file di configurazione /etc/nginx/snippets/self-signed.conf:

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

    Modifica il file di configurazione per aggiungere i percorsi ai file dei certificati che hai salvato:

    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;

    Sostituisci custom-domain.custom-domain.com con il tuo dominio personalizzato.

  6. Per confermare che il file di configurazione contenga il riferimento ai file menzionati nel passaggio precedente, esegui questo comando: 

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

    Dovrebbe restituire i percorsi dei file che hai aggiunto.

  7. Facoltativamente, crea il file NGINX ssl-params.conf, che può essere utilizzato per memorizzare parametri che possono essere riutilizzati nelle configurazioni NGINX future.

    Come riferimento, i contenuti del file dovrebbero essere simili ai seguenti:

    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. Per configurare SELinux in modo che consenta a NGINX di inoltrare il traffico all'IP di ingresso di Looker (Google Cloud core), imposta il parametro booleano httpd_can_network_connect SELinux su 1:

    sudo setsebool -P httpd_can_network_connect 1

  9. Ora puoi riavviare il processo NGINX utilizzando il seguente comando:

    sudo systemctl restart nginx

  10. Verifica che NGINX sia stato riavviato correttamente utilizzando il seguente comando:

    sudo systemctl status nginx

    Dovrebbe restituire un output simile al seguente:

    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

Completa questi passaggi per ogni VM.

  1. Innanzitutto, connettiti alla VM.

  2. Installa Apache:

    sudo yum install httpd -y

  3. L'esempio seguente utilizza Red Hat Enterprise Linux release 7.9. Per verificare quali versioni di Red Hat stanno utilizzando le tue VM, esegui questo comando:

    cat /etc/redhat-release

    Dovrebbe essere restituito quanto segue:

    Red Hat Enterprise Linux Server release 7.9 (Maipo)

  4. L'esempio seguente utilizza la release 2.4.6 di Apache. Per controllare le versioni di Apache utilizzate dalle VM, esegui i seguenti comandi per ogni VM:

    sudo httpd -version

    Dovresti visualizzare quanto segue:

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

  5. Per saperne di più sul server Apache, esegui questo comando:

    sudo rpm -qi httpd

    Dovresti visualizzare un output simile al seguente:

    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. Crea il file di configurazione /etc/httpd/conf.d/ssl.conf sulla VM proxy e aggiungi la configurazione seguente al file:

    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/

    Sostituisci quanto segue:

    • custom domain of Looker (Google Cloud core): il dominio personalizzato della tua istanza di Looker (Google Cloud core).
    • private IP of Looker (Google Cloud core): l'IP privato della tua istanza di Looker (Google Cloud core).

  7. Verifica che i file del certificato TLS siano disponibili nelle directory indicate nel 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. Controlla se l'app mod_ssl è installata:

    sudo yum list installed | grep mod_ssl

    Se mod_ssl non è installato, installalo con il seguente comando:

    sudo yum install mod_ssl

    Una volta installato mod_ssl, devi attivarlo aggiungendo la seguente riga al file di configurazione di Apache, /etc/httpd/conf/httpd.conf:

    LoadModule ssl_module modules/mod_ssl.so

  9. Nel file di configurazione Apache, /etc/httpd/conf/httpd.conf, sostituisci Listen 80 con Listen 443.

  10. Esegui questo comando per consentire alla VM del proxy Apache di inoltrare il traffico a Looker (Google Cloud core):

    /usr/sbin/setsebool -P httpd_can_network_connect 1

  11. Infine, riavvia Apache per applicare le modifiche:

    sudo systemctl restart httpd

  12. Verifica che il modulo di riscrittura sia caricato e pronto su Apache utilizzando questo comando:

    sudo httpd -M | grep rewrite

    Dovrebbe restituire un output simile al seguente:

    rewrite_module (shared)

  13. Infine, avvia o riavvia il processo Apache, per assicurarti che vengano rilevate tutte le modifiche alla configurazione:

    sudo systemctl restart httpd

  14. Verifica che il processo Apache sia stato riavviato correttamente utilizzando il seguente comando: 

    sudo systemctl status httpd

    Dovrebbe restituire un output simile al seguente:

    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.

Crea e configura il bilanciatore del carico

In questo esempio vengono utilizzati gruppi di endpoint di rete (NEG) a livello di zona con endpoint GCE_VM_IP come backend del bilanciatore del carico di rete passthrough interno. Se preferisci utilizzare backend basati su gruppi di istanze, segui la documentazione disponibile nella pagina Configura un bilanciatore del carico di rete passthrough interno con backend di gruppi di istanze VM.

  1. Crea un NEG a livello di zona separato per ogni zona di computing in cui prevedi di eseguire il deployment dei server proxy. Ad esempio, se vuoi eseguire il deployment di server proxy in ognuna delle tre zone di calcolo della regione in cui è implementato Looker (Google Cloud core), crea tre NEG zonali. Consulta la pagina della documentazione su Quote e limiti per verificare quanti endpoint sono supportati per NEG di zona.

    Per creare un NEG zonale, utilizza il seguente comando gcloud:

    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

    Sostituisci quanto segue:

    • NEG_NAME: il nome del NEG che stai creando.
    • PROXY_INSTANCE_ZONE: la zona in cui si trova il server proxy.
    • PROXY_INSTANCE_VPC: il VPC che contiene il server proxy.
    • PROXY_INSTANCE_SUBNET: la subnet in cui si trova il server proxy.

    Ripeti questo passaggio per eventuali altre zone in cui verrà implementata una VM server proxy.

  2. Aggiungi ogni server proxy al NEG nella stessa zona:

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

    Sostituisci quanto segue:

    • PROXY_INSTANCE_ZONE: la zona in cui si trova il server proxy.
    • NEG_NAME: il nome del gruppo di elenchi negativi nella stessa zona del server proxy.
    • PROXY_INSTANCE_NAME: il nome del server proxy.

    Ripeti questo passaggio finché ciascuna delle VM del server proxy viene aggiunta a un NEG come endpoint.

  3. Crea un controllo di integrità a livello di regione che verrà utilizzato dal bilanciatore del carico interno. Utilizza il comando 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

    Sostituisci quanto segue:

    • PROTOCOL: il protocollo utilizzato per il controllo di integrità. Valido sono grpc, http, https, http2, ssl e tcp.
    • NAME: il nome del controllo di integrità. All'interno di un determinato progetto, ogni controllo di integrità globale deve avere un nome univoco e i controlli di integrità regionali devono avere nomi univoci all'interno di una determinata regione.
    • REGION: tutti i bilanciatori del carico ad eccezione di I bilanciatori del carico delle applicazioni esterni regionali e i bilanciatori del carico delle applicazioni interni regionali utilizzano controlli di integrità globali (--global). I bilanciatori del carico delle applicazioni interni regionali utilizzano le applicazioni regionali la cui regione deve corrispondere a quella del servizio di backend.
    • DESCRIPTION: una descrizione facoltativa.
    • CHECK_INTERVAL: il tempo che intercorre tra l'inizio del collegamento di un sistema di probe di controllo dell'integrità e l'inizio del successivo. Le unità sono secondi. Se omesso, Google Cloud utilizza il valore 5s (5 secondi).
    • TIMEOUT: il tempo che Google Cloud attende per una risposta a un'indagine. Il valore di TIMEOUT deve essere minore o uguale a CHECK_INTERVAL. Le unità sono in secondi. Se omesso, Google Cloud utilizza il valore 5s (5 secondi).
    • HEALTHY_THRESHOLD e UNHEALTHY_THRESHOLD: specifica i campi di probe sequenziali che devono avere esito positivo o negativo affinché l'istanza VM integro o non integro. Se uno dei due viene omesso, Google Cloud utilizza una soglia predefinita di 2.
    • PORT_SPECIFICATION: definisce la specifica della porta utilizzando uno dei flag di specifica della porta.
    • ADDITIONAL_FLAGS: altri flag per specificare porte e specifiche di PROTOCOL. Consulta Flag aggiuntivi per i controlli di integrità HTTP, HTTPS e HTTP/2, Flag aggiuntivi per i controlli di integrità SSL e TCP o Flag aggiuntivo per i controlli di integrità gRPC.

  4. Crea il servizio di 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

    Sostituisci quanto segue:

    • BS_NAME: il nome del bilanciatore del carico che stai creando.
    • PROXY_INSTANCES_REGION: la regione in cui si trovano i server proxy.
    • HC_NAME: il nome del controllo di integrità a livello di regione che hai creato.
    • HC_REGION: la regione in cui si trova il controllo di integrità.

    Inoltre:

    • Il flag --session-affinity=CLIENT_IP indirizza la richiesta di un client specifico alla stessa VM dell'istanza proxy di backend, in base a un hash creato sia sull'indirizzo IP del client sia sull'indirizzo di destinazione.
    • L'indicatore --connection-persistence-on-unhealthy-backends=NEVER_PERSIST indica che le connessioni non rimarranno nelle VM di istanze proxy non integre.

  5. Aggiungi ciascuno dei NEG al servizio di backend:

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

    Sostituisci quanto segue:

    • BS_NAME: il nome del servizio di backend che hai creato.
    • BS_REGION: la regione in cui si trova il servizio di backend, che deve essere la stessa in cui si trovano i server proxy.
    • NEG_NAME: il nome del NEG che stai aggiungendo.
    • NEG_ZONE: la zona in cui si trova il NEG.

    Ripeti questo passaggio per il gruppo di esclusioni aggiuntivo che hai creato.

  6. Prenota un indirizzo IP interno nel VPC all'interno dell'intervallo IP della subnet in cui sono collegate le istanze proxy. Sarà l'indirizzo IP virtuale (VIP) del bilanciatore del carico interno. La prenotazione dell'indirizzo garantisce che l'IP non venga utilizzato da nessun altro oggetto. Per prenotare l'indirizzo IP interno, utilizza il comando compute addresses create:

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

    Sostituisci quanto segue:

    • ADDRESS_NAMES: i nomi di uno o più [--purpose=SHARED_LOADBALANCER_VIP] indirizzi che vuoi creare. In caso di più indirizzi, specifica tutti gli indirizzi come elenco separato da spazi, ad esempioexample-address-1 example-address-2 example-address-3
    • REGION: la regione per questa richiesta.
    • SUBNETWORK: la subnet per questo indirizzo IP interno.
    • IP_ADDRESS: l'indirizzo IP da prenotare, che deve rientrare nell'intervallo IP principale della subnet. Se non specificato, un indirizzo IP viene allocato automaticamente dalla subnet.

  7. Crea la regola di inoltro e associala al servizio di backend e all'IP virtuale:

    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

    Sostituisci quanto segue:

    • FW_RULE_NAME: il nome della regola di inoltro che stai creando.
    • BS_REGION: la regione in cui si trova il servizio di backend
    • PROXY_INSTANCES_VPC_NAME: il nome del VPC in cui sono state create le VM del server proxy
    • RESERVED_IP_ADDRESS_SUBNET: la subnet in cui si trova il VIP
    • RESERVED_IP_ADDRESS: l'indirizzo VIP per il bilanciatore del carico
    • BS_NAME: il nome del servizio di backend

    Inoltre:

    • Il flag --allow-global-access indica che il VIP del bilanciatore del carico è raggiungibile da qualsiasi regione (non solo da BS_REGION). In questo modo i clienti in ogni regione possono raggiungere l'istanza di Looker (Google Cloud core).

Crea regole firewall

Affinché i controlli di integrità funzionino, crea regole firewall in entrata applicabili alla VM proxy di cui viene bilanciato il carico per consentire il traffico proveniente da intervalli IP di controllo di integrità.

Inoltre, crea una regola firewall in entrata per consentire al traffico proveniente da ambienti on-premise o multi-cloud di accedere al servizio di backend del bilanciatore del carico.

Aggiorna il record A DNS

Modifica il record A del dominio personalizzato di Looker (Google Cloud core) in modo che punti al VIP del bilanciatore del carico. La zona privata Cloud DNS che hai creato gestisce il dominio personalizzato e viene utilizzata dal VPC in cui si trovano le istanze proxy.

Aggiorna le credenziali OAuth

  1. Per accedere al tuo client OAuth, nella console Google Cloud vai ad API e Servizi > Credenziali e selezionando l'ID client OAuth per il client OAuth utilizzato dalla tua istanza di Looker (Google Cloud core).

  2. Fai clic sul pulsante Aggiungi URI per aggiornare il campo Origini JavaScript autorizzate nel client OAuth in modo da includere lo stesso nome DNS che la tua organizzazione utilizzerà per accedere a Looker (componente principale di Google Cloud). Se il tuo dominio personalizzato è looker.examplepetstore.com, inserisci looker.examplepetstore.com come URI.

  3. Aggiorna o aggiungi il dominio personalizzato all'elenco degli URI di reindirizzamento autorizzati per le credenziali OAuth che hai utilizzato durante la creazione dell'istanza di Looker (Google Cloud core). Aggiungi /oauth2callback alla fine dell'URI. Pertanto, se il tuo dominio personalizzato è looker.examplepetstore.com, inserisci looker.examplepetstore.com/oauth2callback.

Aggiunta di utenti

Una volta completati i passaggi precedenti, l'URL del dominio personalizzato sarà accessibile agli utenti.

Prima di aggiungere utenti all'istanza, assicurati che il metodo di autenticazione utente sia completamente configurato per l'istanza di Looker (Google Cloud core).

Risoluzione dei problemi

  • Se utilizzi Chrome per accedere al dominio personalizzato Looker (Google Cloud core) e ricevi un errore di Chrome come NET::ERR_CERT_COMMON_NAME_INVALID o un errore del criterio HSTS, puoi correggerlo seguendo questa procedura:

    1. Apri chrome://net-internals/#hsts
    2. Inserisci il dominio personalizzato per eseguire query sull'insieme HSTS/PKP. Qualsiasi criterio per il dominio personalizzato verrà visualizzato in Risultato trovato:.
    3. In Elimina i criteri di sicurezza del dominio, inserisci il dominio personalizzato nel campo Dominio.
    4. Fai clic su Elimina per eliminare i criteri.

  • Per risolvere gli errori relativi ai certificati, consulta la pagina della documentazione Risoluzione dei problemi relativi ai certificati SSL. Per i certificati gestiti da Google, assicurati di autorizzare esplicitamente l'autorità di certificazione che vuoi autorizzare a emettere il certificato gestito da Google.

Passaggi successivi