Accéder à une instance Looker (Google Cloud Core) à l'aide de l'accès aux services privés : trafic provenant de différentes régions

Cette page de documentation explique comment configurer un domaine personnalisé et un accès à une instance Looker (Google Cloud Core) qui répond aux critères suivants :

Pour accéder à ce type d'instance, procédez comme suit :

  1. Configurez le domaine personnalisé.
  2. Créez des VM et une zone privée.
  3. Configurez les serveurs proxy inverses.
  4. Créez et configurez l'équilibreur de charge.
  5. Créez des règles de pare-feu.
  6. Mettez à jour l'enregistrement DNS A.
  7. Mettez à jour les identifiants OAuth.

Définir un domaine personnalisé

Une fois votre instance Looker (Google Cloud Core) créée, vous pouvez configurer un domaine personnalisé.

Avant de commencer

Pour pouvoir personnaliser le domaine de votre instance Looker (Google Cloud Core), vous devez identifier l'emplacement de stockage des enregistrements DNS de votre domaine afin de pouvoir les mettre à jour.

Rôles requis

Pour obtenir les autorisations nécessaires à la création d'un domaine personnalisé pour une instance Looker (Google Cloud Core), demandez à votre administrateur de vous accorder le Administrateur Looker (roles/looker.admin) sur le projet dans lequel réside l'instance. Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

Créer un domaine personnalisé

Dans la console Google Cloud, procédez comme suit pour personnaliser le domaine de votre instance Looker (Google Cloud Core) :

  1. Sur la page Instances, cliquez sur le nom de l'instance pour laquelle vous souhaitez configurer un domaine personnalisé.
  2. Cliquez sur l'onglet DOMAINE PERSONNALISÉ.

  3. Cliquez sur AJOUTER UN DOMAINE PERSONNALISÉ.

    Le panneau Ajouter un domaine personnalisé s'ouvre.

  4. N'utilisez que des lettres, des chiffres et des tirets. Saisissez un nom d'hôte comportant jusqu'à 64 caractères pour le domaine Web que vous voulez utiliser (par exemple, looker.examplepetstore.com).

  5. Cliquez sur OK dans le panneau Ajouter un domaine personnalisé pour revenir à l'onglet DOMAINE PERSONNALISÉ.

Une fois configuré, votre domaine personnalisé s'affiche dans la colonne Domaine de l'onglet Domaine personnalisé de la page Informations sur l'instance de la console Google Cloud.

Une fois votre domaine personnalisé créé, vous pouvez afficher des informations à son sujet ou le supprimer.

Accéder au domaine personnalisé

Lorsque le trafic vers une instance Looker (Google Cloud Core) uniquement avec adresse IP privée provient d'une région différente de celle de l'instance, vous pouvez utiliser un ou plusieurs serveurs proxy inverses d'adresses IP privées et un équilibreur de charge pour fournir un accès sécurisé à l'instance.

Avant de commencer

Pour obtenir les autorisations dont vous avez besoin pour configurer l’accès à un domaine personnalisé d’adresse IP privée, demandez à votre administrateur de vous accorder le les rôles IAM suivants sur le projet dans lequel se trouve l'instance:

Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

Présentation de la mise en réseau

Les sections suivantes vous expliquent comment créer une configuration de serveur proxy NGINX ou Apache redondante, avec un équilibreur de charge, pour acheminer le trafic depuis n'importe quelle région ou depuis un site sur site vers le domaine personnalisé. Le diagramme suivant représente cette topologie :

Réseau Google Cloud montrant un accès sécurisé à une instance Looker (Google Cloud Core) à l'aide de Cloud Router, d'un équilibreur de charge interne et de l'accès aux services privés.

Créer des VM et une zone privée

  1. Créez deux instances de VM privées uniquement avec adresse IP privée avec un système d'exploitation RHEL. Les VM agiront en tant que serveurs proxy. Elles doivent se trouver dans la même région que l'instance Looker (Google Cloud Core), mais dans des zones différentes les unes des autres.
  2. Créez une zone privée Cloud DNS pour gérer vos enregistrements Cloud DNS. La zone privée doit être visible par le VPC dans lequel se trouve l'instance Looker (Google Cloud Core). La zone privée Cloud DNS sera utilisée par le VPC et les hôtes sur site pour la résolution DNS afin d'atteindre l'interface utilisateur de Looker (Google Cloud Core). Étant donné que vous utiliserez un équilibreur de charge, l'enregistrement A de la zone privée Cloud DNS sera mappé sur l'adresse IP de l'équilibreur de charge.

Configurer les serveurs de proxy inverse

Vous pouvez utiliser n’importe quel serveur Web pouvant être configuré comme serveur proxy inverse. Sélectionnez l'une des options suivantes pour voir des exemples de configuration de serveurs proxy inverses à l'aide de NGINX ou d'Apache :

NGINX

L'exemple suivant utilise la version 1.22.1 de NGINX et la version 8.9 (Ootpa) de Red Hat Enterprise Linux. Pour vérifier les versions de NGNIX et de Red Hat que vos VM utilisent, exécutez les commandes suivantes pour chaque VM.

  1. Commencez par vous connecter à la VM.

  2. Installez NGINX à l'aide de la commande suivante :

    sudo yum install nginx -y

  3. Pour trouver la version de NGINX exécutée par la VM, exécutez la commande suivante : 

    sudo nginx -v

    Vous devriez obtenir un résultat semblable à celui-ci:

    nginx version: nginx/1.22.1

  4. Pour vérifier la version de NGINX exécutée par la VM, exécutez la commande suivante : 

    sudo rpm -qi nginx | grep Release

    Vous devriez obtenir un résultat semblable à celui-ci:

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

  5. Pour vérifier la version de Red Hat utilisée par vos VM, exécutez la commande suivante:

    sudo cat /etc/redhat-release

Pour configurer chaque serveur proxy, suivez les instructions ci-dessous pour chacune des deux VM que vous avez créées.

  1. Connectez-vous à la VM.

  2. Modifiez le fichier /etc/nginx/nginx.conf pour qu'il contienne la configuration suivante :

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

    Remplacez les éléments suivants :

    • CUSTOM_DOMAIN : domaine personnalisé de votre instance Looker (Google Cloud Core)
    • INGRESS_PRIVATE_IP : adresse IP privée d'entrée de votre instance Looker (Google Cloud Core)

    En outre, tenez compte des points suivants :

    • Cette configuration n'est compatible qu'avec le protocole IPv4. Si vous souhaitez que le proxy écoute également son adresse IPv6 privée, annulez la mise en commentaire de la ligne listen [::]:443 ssl dans le fichier.
    • Le niveau du journal des accès est défini sur debug. Veillez à l'ajuster au niveau utilisé dans votre environnement spécifique.
    • Si vous implémentez le fichier ssl-params.conf, qui est référencé plus loin dans ces étapes, supprimez le commentaire de include snippets/ssl-params.conf.

  3. Créez un certificat TLS valide qui fait référence à l'URL du domaine personnalisé Looker (Google Cloud Core). Ce certificat sera celui que le proxy présentera aux clients qui tentent d'accéder à Looker (Google Cloud Core). L'autorité de certification (CA) utilisée pour signer le certificat doit être approuvée par vos clients. Vous pouvez également utiliser une autorité de certification privée interne pour signer ce certificat TLS. Vous pouvez également utiliser un certificat SSL autogéré.

    Dans cet exemple, supposons que le certificat a déjà été créé à l'aide du service gratuit Let's Encrypt, sans configurer le renouvellement automatique via Certbot. Une fois le certificat créé, enregistrez les fichiers appropriés dans les répertoires certs et private de chaque VM proxy:

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

    Remplacez custom-domain.custom-domain.com par votre domaine personnalisé.

    Si les répertoires certs et private n'existent pas dans votre installation, vous pouvez les créer ou utiliser d'autres dossiers.

  4. Pour vous assurer que NGINX récupère les fichiers de certificat, créez le répertoire /etc/nginx/snippets:

    sudo mkdir /etc/nginx/snippets

  5. Créez le fichier de configuration /etc/nginx/snippets/self-signed.conf:

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

    Modifiez le fichier de configuration pour ajouter les chemins d'accès aux fichiers de certificat que vous avez enregistrés :

    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;

    Remplacez custom-domain.custom-domain.com par votre domaine personnalisé.

  6. Pour vérifier que le fichier de configuration contient la référence aux fichiers mentionnés à l'étape précédente, exécutez la commande suivante: 

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

    Les chemins d'accès aux fichiers que vous avez ajoutés devraient s'afficher.

  7. Vous pouvez également créer le fichier NGINX ssl-params.conf, qui permet de stocker les paramètres réutilisables dans les futures configurations NGINX.

    Pour référence, le contenu du fichier doit se présenter comme suit :

    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. Pour configurer SELinux afin d'autoriser NGINX à transférer le trafic vers l'adresse IP d'entrée de Looker (Google Cloud Core), définissez le paramètre booléen SELinux httpd_can_network_connect sur 1 :

    sudo setsebool -P httpd_can_network_connect 1

  9. Vous pouvez maintenant redémarrer le processus NGINX à l'aide de la commande suivante :

    sudo systemctl restart nginx

  10. Vérifiez que NGINX a correctement redémarré à l'aide de la commande suivante:

    sudo systemctl status nginx

    Un résultat semblable aux lignes suivantes doit s'afficher:

    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

Suivez ces étapes pour chaque VM.

  1. Commencez par vous connecter à la VM.

  2. Installez Apache :

    sudo yum install httpd -y

  3. L'exemple suivant utilise la version 7.9 de Red Hat Enterprise Linux. Pour vérifier les versions de Red Hat utilisées par vos VM, exécutez la commande suivante:

    cat /etc/redhat-release

    Vous devriez obtenir le résultat suivant:

    Red Hat Enterprise Linux Server release 7.9 (Maipo)

  4. L'exemple suivant utilise la version 2.4.6 d'Apache. Pour vérifier les versions d'Apache utilisées par vos VM, exécutez les commandes suivantes pour chaque VM :

    sudo httpd -version

    Le résultat devrait être le suivant :

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

  5. Pour en savoir plus sur le serveur Apache, exécutez la commande suivante :

    sudo rpm -qi httpd

    Un résultat semblable à celui-ci s'affiche :

    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. Créez le fichier de configuration /etc/httpd/conf.d/ssl.conf sur la VM proxy et ajoutez la configuration suivante au fichier:

    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/

    Remplacez les éléments suivants :

    • custom domain of Looker (Google Cloud core) : domaine personnalisé de votre instance Looker (Google Cloud Core).
    • private IP of Looker (Google Cloud core): adresse IP privée de votre instance Looker (Google Cloud Core).

  7. Vérifiez que les fichiers de certificat TLS sont disponibles dans les répertoires référencés dans le fichier /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. Vérifiez si mod_ssl est installé :

    sudo yum list installed | grep mod_ssl

    Si mod_ssl n'est pas installé, installez-le à l'aide de la commande suivante:

    sudo yum install mod_ssl

    Une fois mod_ssl installé, vous devez l'activer en ajoutant la ligne suivante au fichier de configuration Apache, /etc/httpd/conf/httpd.conf :

    LoadModule ssl_module modules/mod_ssl.so

  9. Dans le fichier de configuration Apache, /etc/httpd/conf/httpd.conf, remplacez Listen 80 par Listen 443.

  10. Exécutez la commande suivante pour autoriser la VM proxy Apache à transférer le trafic vers Looker (Google Cloud Core):

    /usr/sbin/setsebool -P httpd_can_network_connect 1

  11. Enfin, redémarrez Apache pour appliquer les modifications :

    sudo systemctl restart httpd

  12. Vérifiez que le module de réécriture est chargé et prêt sur Apache à l'aide de la commande suivante:

    sudo httpd -M | grep rewrite

    Un résultat semblable au suivant s'affiche :

    rewrite_module (shared)

  13. Enfin, démarrez ou redémarrez le processus Apache pour vous assurer que toutes les modifications de configuration sont prises en compte :

    sudo systemctl restart httpd

  14. Vérifiez que le processus Apache a bien redémarré à l'aide de la commande suivante : 

    sudo systemctl status httpd

    Un résultat semblable au suivant s'affiche :

    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.

Créer et configurer l'équilibreur de charge

Cet exemple utilise des groupes de points de terminaison du réseau (NEG) zonaux avec GCE_VM_IP points de terminaison comme backends de l'équilibreur de charge réseau passthrough interne. Si vous préférez utiliser des backends basés sur des groupes d'instances, suivez la documentation disponible sur la page Configurer un équilibreur de charge réseau passthrough interne avec des backends de groupe d'instances de VM.

  1. Créez un NEG zonal distinct pour chaque zone de calcul dans laquelle vous prévoyez de déployer des serveurs proxy. Par exemple, si vous souhaitez déployer des serveurs proxy dans chacune des trois zones de calcul de la région où Looker (Google Cloud Core) est déployé, créez trois NEG zonaux. Consultez la page de documentation Quotas et limites pour vérifier le nombre de points de terminaison acceptés par NEG zonal.

    Pour créer un NEG zonal, utilisez la commande gcloud suivante:

    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

    Remplacez les éléments suivants :

    • NEG_NAME : nom du NEG que vous créez.
    • PROXY_INSTANCE_ZONE: zone dans laquelle se trouve le serveur proxy.
    • PROXY_INSTANCE_VPC : VPC contenant le serveur proxy.
    • PROXY_INSTANCE_SUBNET: sous-réseau dans lequel se trouve le serveur proxy.

    Répétez cette étape pour toute autre zone dans laquelle vous allez déployer une VM de serveur proxy.

  2. Ajoutez chaque serveur proxy au NEG dans la même zone:

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

    Remplacez les éléments suivants :

    • PROXY_INSTANCE_ZONE : zone dans laquelle se trouve le serveur proxy.
    • NEG_NAME : nom du NEG situé dans la même zone que le serveur proxy.
    • PROXY_INSTANCE_NAME: nom du serveur proxy.

    Répétez cette étape jusqu'à ce que chacune des VM de serveur proxy soit ajoutée à un NEG en tant que point de terminaison.

  3. Créez une vérification d'état régionale qui sera utilisée par l'équilibreur de charge interne. Exécutez la commande 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

    Remplacez les éléments suivants :

    • PROTOCOL : protocole utilisé pour la vérification de l'état. Les options valides sont grpc, http, https, http2, ssl et tcp.
    • NAME : nom de la vérification d'état. Dans un projet donné, chaque vérification d'état globale doit posséder un nom unique, et les vérifications d'état régionales doivent posséder des noms uniques au sein d'une région donnée.
    • REGION : tous les équilibreurs de charge, à l'exception des équilibreurs de charge d'application externes régionaux et des équilibreurs de charge d'application internes régionaux, utilisent des vérifications d'état mondiales (--global). Les équilibreurs de charge d'application internes régionaux utilisent des vérifications d'état régionales, pour lesquelles la région doit correspondre à celle du service de backend.
    • DESCRIPTION : description facultative.
    • CHECK_INTERVAL : durée écoulée entre le début d'une connexion du système de test de vérification d'état et le début de la connexion suivante. Cette valeur est exprimée en secondes. En cas d'omission, Google Cloud utilise la valeur 5s (cinq secondes).
    • TIMEOUT : durée pendant laquelle Google Cloud attend une réponse à une vérification. La valeur de TIMEOUT doit être inférieure ou égale à celle de CHECK_INTERVAL. Cette valeur est exprimée en secondes. En cas d'omission, Google Cloud utilise la valeur 5s (cinq secondes).
    • HEALTHY_THRESHOLD et UNHEALTHY_THRESHOLD : spécifiez le nombre de vérifications séquentielles qui doivent réussir ou échouer pour que l'instance de VM soit considérée comme opérationnelle ou non. Si l'une de ces valeurs est omise, Google Cloud utilise le seuil par défaut défini sur 2.
    • PORT_SPECIFICATION : définit la spécification du port à l'aide de l'une des options de spécification du port.
    • ADDITIONAL_FLAGS: autres options permettant de spécifier des ports et Options spécifiques à PROTOCOL. Consultez les sections Options supplémentaires pour les vérifications d'état HTTP, HTTPS et HTTP/2, Options supplémentaires pour les vérifications d'état SSL et TCP ou Options supplémentaires pour les vérifications d'état gRPC.

  4. Créez le service de 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

    Remplacez les éléments suivants :

    • BS_NAME: nom de l'équilibreur de charge que vous créez.
    • PROXY_INSTANCES_REGION : région dans laquelle se trouvent les serveurs proxy.
    • HC_NAME : nom de la vérification d'état régionale que vous avez créée.
    • HC_REGION : région dans laquelle se trouve la vérification d'état.

    De plus :

    • L'indicateur --session-affinity=CLIENT_IP dirige la requête d'un client spécifique vers la même VM d'instance de proxy backend, en fonction d'un hachage créé à la fois sur l'adresse IP du client et l'adresse de destination.
    • L'indicateur --connection-persistence-on-unhealthy-backends=NEVER_PERSIST signifie que les connexions ne persistent pas sur les VM d'instance de proxy non opérationnelles.

  5. Ajoutez chacun des NEG au service de backend :

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

    Remplacez les éléments suivants :

    • BS_NAME: nom du service de backend que vous avez créé.
    • BS_REGION: région dans laquelle se trouve le service de backend. celle-ci doit être la même que la région dans laquelle se trouvent les serveurs proxy.
    • NEG_NAME : nom du NEG que vous ajoutez.
    • NEG_ZONE : zone dans laquelle se trouve le NEG.

    Répétez cette étape pour le NEG supplémentaire que vous avez créé.

  6. Réservez une adresse IP interne dans le VPC, dans la plage d'adresses IP du sous-réseau où les instances de proxy sont connectées. Il s'agira de l'adresse IP virtuelle (VIP) de l'équilibreur de charge interne. En réservant l'adresse, vous vous assurez qu'elle ne sera utilisée par aucun autre objet. Pour réserver l'adresse IP interne, utilisez la commande compute addresses create :

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

    Remplacez les éléments suivants :

    • ADDRESS_NAMES: Les noms d'un ou de plusieurs éléments [--purpose=SHARED_LOADBALANCER_VIP] que vous souhaitez créer. Dans le cas de plusieurs adresses, spécifiez toutes les adresses sous forme de liste, séparées par des espaces, par exemple example-address-1 example-address-2 example-address-3.
    • REGION : région de la requête
    • SUBNETWORK : sous-réseau de l'adresse IP interne
    • IP_ADDRESS: l'adresse IP à réserver, qui doit être comprise dans la plage d'adresses IP principale du sous-réseau. Si elle n'est pas spécifiée, une adresse IP est automatiquement attribuée à partir du sous-réseau.

  7. Créez la règle de transfert et associez-la au service de backend et à l'adresse IP virtuelle :

    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

    Remplacez les éléments suivants :

    • FW_RULE_NAME: nom de la règle de transfert que vous créez.
    • BS_REGION: région dans laquelle se trouve le service de backend
    • PROXY_INSTANCES_VPC_NAME: nom du VPC dans lequel les VM du serveur proxy ont été créées
    • RESERVED_IP_ADDRESS_SUBNET : sous-réseau dans lequel se trouve l'adresse VIP
    • RESERVED_IP_ADDRESS: adresse IP virtuelle de l'équilibreur de charge
    • BS_NAME: nom du service de backend

    De plus :

    • L'indicateur --allow-global-access indique que l'adresse IP virtuelle de l'équilibreur de charge est accessible depuis n'importe quelle région (et pas seulement depuis BS_REGION). Cela permet aux clients de chaque région d'accéder à l'instance Looker (Google Cloud Core).

Créer des règles de pare-feu

Pour que les vérifications d'état fonctionnent, créez des règles de pare-feu d'entrée applicables à la VM proxy faisant l'objet d'un équilibrage de charge afin d'autoriser le trafic provenant des plages d'adresses IP du système de vérification d'état.

De plus, créez une règle de pare-feu d'entrée pour autoriser le trafic provenant d'environnements sur site ou multicloud à accéder au service backend de l'équilibreur de charge.

Mettre à jour l'enregistrement DNS A

Modifiez l'enregistrement A du domaine personnalisé Looker (Google Cloud Core) pour qu'il pointe vers l'adresse IP virtuelle de l'équilibreur de charge. La zone privée Cloud DNS que vous avez créée gère le domaine personnalisé et est utilisée par le VPC où se trouvent les instances de proxy.

Modifier les identifiants OAuth

  1. Pour accéder à votre client OAuth, accédez à API et services > Identifiants dans la console Google Cloud, puis sélectionnez l'ID client OAuth du client OAuth utilisé par votre instance Looker (Google Cloud core).

  2. Cliquez sur le bouton Ajouter un URI pour mettre à jour le champ Origines JavaScript autorisées de votre client OAuth afin d'inclure le même nom DNS que celui que votre organisation utilisera pour accéder à Looker (Google Cloud Core). Ainsi, si votre domaine personnalisé est looker.examplepetstore.com, saisissez looker.examplepetstore.com comme URI.

  3. Mettez à jour ou ajoutez le domaine personnalisé à la liste des URI de redirection autorisés pour les identifiants OAuth que vous avez utilisés lorsque vous avez créé l'instance Looker (Google Cloud Core). Ajoutez /oauth2callback à la fin de l'URI. Par exemple, si votre domaine personnalisé est looker.examplepetstore.com, saisissez looker.examplepetstore.com/oauth2callback.

Ajout de comptes utilisateur

Une fois les étapes précédentes effectuées, les utilisateurs peuvent accéder à l'URL du domaine personnalisé.

Assurez-vous que la méthode d'authentification des utilisateurs est entièrement configurée pour l'instance Looker (Google Cloud Core) avant d'ajouter des utilisateurs à l'instance.

Dépannage

  • Si vous utilisez Chrome pour accéder au domaine personnalisé Looker (Google Cloud Core) et que vous recevez une erreur Chrome (par exemple, NET::ERR_CERT_COMMON_NAME_INVALID) ou une erreur liée aux règles HSTS, vous pouvez résoudre le problème en procédant comme suit:

    1. Ouvrir chrome://net-internals/#hsts
    2. Saisissez le domaine personnalisé pour interroger l'ensemble HSTS/PKP. Toutes les règles du domaine personnalisé s'affichent sous Found (Trouvé).
    3. Sous Supprimer les règles de sécurité du domaine, saisissez le domaine personnalisé dans le champ Domaine.
    4. Cliquez sur Supprimer pour supprimer les règles.

  • Pour résoudre les erreurs de certificat, consultez la page de documentation Résoudre les problèmes liés aux certificats SSL. Pour les certificats gérés par Google, veillez à autoriser explicitement l'autorité de certification que vous souhaitez autoriser à émettre votre certificat géré par Google.

Étape suivante