Configura un dominio personalizzato per un'istanza di Looker con IP privato (Google Cloud core): traffico proveniente da regioni diverse

Puoi gestire l'istanza di Looker (Google Cloud core) tramite un dominio web personalizzato anziché tramite il dominio predefinito fornito da Looker (Google Cloud core).

Questa pagina della documentazione descrive come configurare e accedere a un dominio personalizzato per le istanze che soddisfano entrambi i seguenti criteri:

  • L'istanza è solo IP privato.
  • Il traffico verso l'istanza proviene da regioni diverse da quelle in cui si trova l'istanza o tramite il networking ibrido.

Per implementare un dominio personalizzato per 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 inversi.
  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 per l'istanza.

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 il ruolo IAM Amministratore Looker (roles/looker.admin) per il progetto in cui risiede l'istanza. Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso.

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

Crea un dominio personalizzato

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

  1. Nella pagina Istanze, fai clic sul nome dell'istanza per la quale 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 DOMINIO PERSONALIZZATO.

Il dominio personalizzato viene visualizzato nella colonna URL istanza nella pagina Istanze della console Google Cloud.

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

Accedi 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 sul progetto in cui risiede l'istanza:

Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso.

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

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.

Crea VM e una zona privata

  1. Crea due istanze VM solo con IP privato con un sistema operativo RHEL. Le VM agiranno da server proxy. Devono trovarsi all'interno della stessa regione dell'istanza di Looker (Google Cloud core), ma in zone diverse l'una dall'altra.
  2. Crea una zona privata di Cloud DNS per la gestione dei record di Cloud DNS. La zona privata deve essere visibile nel 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 inversi

Puoi utilizzare qualsiasi server web che possa 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 verificare quali versioni di NGNIX e Red Hat utilizzano le 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

    Il risultato dovrebbe essere simile al seguente:

    nginx version: nginx/1.22.1

  4. Per verificare quale release NGINX è in esecuzione la VM, esegui questo comando: 

    sudo rpm -qi nginx | grep Release

    Il risultato dovrebbe essere simile al seguente:

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

  5. Per verificare quale versione di Red Hat sta utilizzando le tue VM, esegui questo comando:

    sudo cat /etc/redhat-release

Per configurare ciascun 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 in entrata per la tua istanza di Looker (Google Cloud core)

    Inoltre, considera quanto segue:

    • Questa è una configurazione solo IPv4. Se richiedi che il proxy ascolti anche il 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 verrà fatto riferimento in un secondo momento 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 considerata attendibile dai 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. Una volta 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

    Dovrebbero essere restituiti 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 da consentire a NGINX di inoltrare il traffico all'IP in entrata di Looker (Google Cloud core), imposta il parametro booleano SELinux httpd_can_network_connect 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 essere restituito 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. Nell'esempio seguente viene utilizzato Apache release 2.4.6. Per verificare quali versioni di Apache sono in uso nelle tue VM, esegui i comandi seguenti per ogni VM:

    sudo httpd -version

    Dovrebbe essere restituito 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

    Dovrebbe essere restituito 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 mod_ssl è installato:

    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 abilitarlo aggiungendo la riga seguente al file di configurazione 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 essere restituito 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 comando seguente: 

    sudo systemctl status httpd

    Dovrebbe essere restituito 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 della documentazione Configurare 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 ciascuna delle tre zone di computing dell'area geografica in cui viene eseguito il deployment di Looker (Google Cloud core), crea tre NEG a livello di zona. Consulta la pagina della documentazione su Quote e limiti per verificare quanti endpoint sono supportati per NEG di zona.

    Per creare un NEG a livello di zona, 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 qualsiasi zona aggiuntiva in cui eseguirai il deployment di una VM del 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 NEG 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à. Le opzioni valide 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, mentre i controlli di integrità a livello di regione devono avere nomi univoci all'interno di una determinata regione.
    • REGION: tutti i bilanciatori del carico, ad eccezione dei bilanciatori del carico delle applicazioni esterni regionali e dei bilanciatori del carico delle applicazioni interni regionali, utilizzano i controlli di integrità globali (--global). I bilanciatori del carico delle applicazioni interni regionali utilizzano i controlli di integrità a livello di regione la cui regione deve corrispondere alla regione del servizio di backend.
    • DESCRIPTION: una descrizione facoltativa.
    • CHECK_INTERVAL: la quantità di tempo che intercorre dall'inizio della connessione del sistema di probe del controllo di integrità all'inizio di quella successiva. Le unità sono in secondi. Se omesso, Google Cloud utilizza il valore 5s (5 secondi).
    • TIMEOUT: il tempo di attesa di Google Cloud per una risposta a un probe. 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 il numero di probe sequenziali che devono avere esito positivo o negativo affinché l'istanza VM sia considerata in stato 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 delle specifiche della porta.
    • ADDITIONAL_FLAGS: altri flag per specificare porte e opzioni 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 aggiuntivi 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.
    • Il flag --connection-persistence-on-unhealthy-backends=NEVER_PERSIST indica che le connessioni non verranno mantenute su VM con 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; dovrebbe corrispondere alla regione 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 NEG aggiuntivo che hai creato.

  6. Prenota un indirizzo IP interno nel VPC all'interno dell'intervallo IP della subnet in cui sono connesse le istanze proxy. Sarà l'indirizzo IP virtuale (VIP) del bilanciatore del carico interno. Se prenota l'indirizzo, avrai la certezza che l'IP non sarà 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ù indirizzi [--purpose=SHARED_LOADBALANCER_VIP] che vuoi creare. In caso di più indirizzi, specifica tutti gli indirizzi in un elenco, separati da spazi, ad esempio example-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 essere compreso nell'intervallo IP principale della subnet. Se non specificato, un indirizzo IP viene allocato automaticamente dalla subnet.

  7. Crea la regola di forwarding e associala al servizio di backend e al 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

    Sostituisci quanto segue:

    • FW_RULE_NAME: il nome della regola di forwarding 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 del 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 client 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 Looker (Google Cloud core) in modo che punti al VIP del bilanciatore del carico. La zona privata di Cloud DNS che hai creato gestisce il dominio personalizzato e viene utilizzata dal VPC in cui si trovano le istanze proxy.

Aggiornare le credenziali OAuth

  1. Per accedere al client OAuth, nella console Google Cloud vai ad API e servizi > Credenziali e seleziona 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 (Google Cloud core). 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. Se il tuo dominio personalizzato è looker.examplepetstore.com, devi inserire looker.examplepetstore.com/oauth2callback.

Aggiunta di utenti

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

Assicurati che il metodo di autenticazione dell'utente sia completamente configurato per l'istanza di Looker (Google Cloud core) prima di aggiungere utenti all'istanza.

Risolvere gli errori dei criteri HSTS

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 una query sul set 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.

Passaggi successivi