Configurer un domaine personnalisé pour une instance Looker (Google Cloud Core) avec adresse IP privée: trafic provenant de différentes régions

Vous pouvez diffuser votre instance Looker (Google Cloud Core) via un domaine Web personnalisé plutôt que via le domaine par défaut fourni par Looker (Google Cloud Core).

Cette page de documentation explique comment configurer un domaine personnalisé et y accéder pour les instances qui répondent aux deux critères suivants:

• L'instance ne dispose que d'une adresse IP privée.
• Le trafic vers l'instance provient soit de régions différentes de celle dans laquelle se trouve l'instance, soit de mise en réseau hybride.

Pour implémenter un domaine personnalisé pour 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 de proxy inverse.
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é pour celle-ci.

Avant de commencer

Remarque :Les domaines personnalisés ne peuvent pas être créés à l'aide d'un domaine looker.com.

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 pour créer un domaine personnalisé pour une instance Looker (Google Cloud Core), demandez à votre administrateur de vous accorder le rôle IAM Administrateur Looker (roles/looker.admin) sur le projet dans lequel se trouve l'instance. Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

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é

Remarque :Une fois le domaine personnalisé créé, vous ne pouvez plus le modifier. Si vous souhaitez modifier le domaine personnalisé, vous devez supprimer le domaine personnalisé existant et en créer un autre.

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É.

Remarque :La mise à jour du domaine personnalisé prend 10 à 15 minutes.

Votre domaine personnalisé s'affiche dans la colonne URL de l'instance de la page Instances de la console Google Cloud.

Une fois votre domaine personnalisé créé, vous pouvez afficher les informations le concernant 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 IP privés ainsi qu'un équilibreur de charge pour fournir un accès sécurisé à l'instance.

Avant de commencer

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

• Administrateur Looker (roles/looker.admin)
• Administrateur d'instances Compute (v1) (roles/compute.instanceAdmin.v1)
• DNS Admin (Administrateur DNS) (roles/dns.admin)
• Administrateur de l'équilibreur de charge Compute (roles/compute.loadBalancerAdmin)
• Administrateur de réseaux Compute (roles/compute.networkAdmin)
• Administrateur de sécurité de Compute (roles/compute.securityAdmin)
• Utiliser Google OAuth : Éditeur de configuration OAuth (roles/oauthconfig.editor)

Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

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

Remarque :Dans un scénario de démonstration de faisabilité, vous pouvez configurer un serveur proxy inverse et éviter de configurer un équilibreur de charge.

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

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é à 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 afficher des exemples de configuration de serveurs de proxy inverse à l'aide de NGINX ou Apache:

NGINX

Remarque :Cet exemple de configuration utilise des serveurs proxy NGNIX sur RHEL. Il est fourni comme point de départ de votre configuration de proxy personnalisée. Cette configuration a été testée avec la version 1.22.1 de NGINX installée sur la version 8.9 de Red Hat Enterprise Linux.

L'exemple suivant utilise la version 1.22.1 de NGINX et la version 8.9 de Red Hat Enterprise Linux (Ootpa). 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 que la VM exécute, 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 quelle version NGINX est 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 y inclure 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 pour 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 de journalisation d'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, annulez la mise en commentaire de include snippets/ssl-params.conf.

3. Créez un certificat TLS valide qui 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 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é.

   Remarque :Si vous avez enregistré les fichiers de certificat dans un autre chemin d'accès, assurez-vous que celui-ci apparaît dans le fichier de configuration /etc/nginx/snippets/self-signed.conf.

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.

   Remarque :Si vous implémentez ssl-params.conf, annulez la mise en commentaire de include snippets/ssl-params.conf dans le fichier nginx.conf.

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

   Remarque :Désactivez la sécurité stricte de transport pour le moment. Si vous souhaitez activer la sécurité stricte des transports et que vous comprenez les conséquences de cette opération, vous pouvez annuler la mise en commentaire de la ligne commençant par add_header Strict-Transport-Security.

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

Remarque :La configuration suivante a été testée avec la version 2.4.6 d'Apache installée sur la version 7.9 de Red Hat Enterprise Linux.

Procédez comme suit 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 que vos VM utilisent, exécutez les commandes suivantes pour chaque VM:

   sudo httpd -version
   

   Vous devriez obtenir le résultat 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
   

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

   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 aux lignes suivantes doit s'afficher:

    rewrite_module (shared)

13. Enfin, démarrez ou redémarrez le processus Apache pour vous assurer que toutes les modifications de configuration ont été récupérées:

    sudo systemctl restart httpd
    

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

    sudo systemctl status httpd
    

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

    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 groupes 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 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 du 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;état Les options valides sont grpc, http, https, http2, ssl et tcp.
   • NAME: nom de la vérification de l'état. Dans un projet donné, chaque vérification de l'état globale doit avoir un nom unique, et les vérifications d'état régionales doivent porter des noms uniques dans 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: temps écoulé entre le début d'une connexion du système 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: temps pendant lequel 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 tests séquentiels qui doivent réussir ou échouer pour que l'instance de VM soit considérée comme opérationnelle ou non opérationnelle. 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 des 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 où se trouvent les serveurs proxy.
   • HC_NAME: nom de la vérification de l'état régionale que vous avez créée.
   • HC_REGION: région dans laquelle se trouve la vérification de l'état.

   De plus :

   • L'option --session-affinity=CLIENT_IP dirige la requête d'un client spécifique vers la même VM d'instance de proxy de backend, en fonction d'un hachage créé à la fois sur l'adresse IP du client et sur l'adresse de destination.
   • L'option --connection-persistence-on-unhealthy-backends=NEVER_PERSIST signifie que les connexions ne persistent pas sur les VM d'instances 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. Elle doit être identique à 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 pour le VPC dans la plage d'adresses IP du sous-réseau auquel 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 que l'adresse IP ne sera utilisée par aucun autre objet. Pour réserver l'adresse IP interne, exécutez 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 : noms d'une ou de plusieurs adresses [--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: 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 IP virtuelle
   • RESERVED_IP_ADDRESS: adresse IP virtuelle de l'équilibreur de charge
   • BS_NAME: nom du service de backend

   De plus :

   • L'option --allow-global-access indique que l'adresse IP virtuelle de l'équilibreur de charge est accessible depuis n'importe quelle région (pas seulement la région 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 vérificateur d'état.

En outre, 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 de 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.

Mettre à jour les identifiants OAuth

Remarque :Vous pouvez utiliser n'importe quel client OAuth pour créer des identifiants d'autorisation pour votre instance Looker (Google Cloud Core). Par exemple, ces étapes vous expliquent comment mettre à jour les identifiants à l'aide de la console Google Cloud. Si vous utilisez un autre client, ajustez les étapes en conséquence.

1. Accédez à votre client OAuth en accédant à API et services > Identifiants dans la console Google Cloud, puis en sélectionnant 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 dans votre client OAuth afin d'inclure le nom DNS 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 lors de la création de l'instance Looker (Google Cloud Core). Ajoutez /oauth2callback à la fin de l'URI. Ainsi, 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.

Résoudre les erreurs liées aux règles HSTS

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 applicables au 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.

Étapes suivantes

• Gérer les utilisateurs dans Looker (Google Cloud Core)
• Configurer votre instance Looker (Google Cloud Core)
• Connecter Looker (Google Cloud Core) à votre base de données