Notez que vous consultez la documentation Looker. Pour accéder à la documentation sur Looker Studio, consultez la page https://support.google.com/looker-studio.

Cette page a été traduite par l'API Cloud Translation.

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:

Configurez le domaine personnalisé.
Créez des VM et une zone privée.
Configurez les serveurs de proxy inverse.
Créez et configurez l'équilibreur de charge.
Créez des règles de pare-feu.
Mettez à jour l'enregistrement DNS A.
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

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 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é

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

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

Le panneau Ajouter un domaine personnalisé s'ouvre.
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).
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 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 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:

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: OAuth Config Editor (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

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:

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

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

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.

Commencez par vous connecter à la VM.
Installez NGINX à l'aide de la commande suivante:
```
sudo yum install nginx -y
```
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
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
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.

Connectez-vous à la VM.

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'adapter 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.

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 AC 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.
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
```
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.
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.
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 du 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.
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
```
Vous pouvez maintenant redémarrer le processus NGINX à l'aide de la commande suivante:
```
sudo systemctl restart nginx
```

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

Procédez comme suit pour chaque VM.

Commencez par vous connecter à la VM.
Installez Apache:
```
sudo yum install httpd -y
```
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)
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
```

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.

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

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"

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
```
Dans le fichier de configuration Apache, /etc/httpd/conf/httpd.conf, remplacez Listen 80 par Listen 443.
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
```
Enfin, redémarrez Apache pour appliquer les modifications:
```
sudo systemctl restart httpd
```
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)
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
```

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.

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.
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.
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 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é depuis le début d'un état vérifiez la connexion du système de vérification au début du suivant. Cette valeur est exprimée en secondes. En cas d'omission, Google Cloud utilise la valeur 5s (cinq secondes).
- TIMEOUT: temps d'attente de Google Cloud pour obtenir 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 paramètre le nombre de vérifications séquentielles qui doivent réussir ou échouer pour que l'instance de VM être considérées comme saines ou non opérationnelles. 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.
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.
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éé.
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: 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.
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 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

Accédez à votre client OAuth en accédant à API et Services > Identifiants et en sélectionnant l'ID client OAuth du client OAuth utilisé par votre instance Looker (Google Cloud Core).
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.
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:

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

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

Définir un domaine personnalisé

Avant de commencer

Rôles requis

Créer un domaine personnalisé

Accéder au domaine personnalisé

Avant de commencer

Présentation de la mise en réseau

Créer des VM et une zone privée

Configurer les serveurs de proxy inverse

NGINX

Apache

Créer et configurer l'équilibreur de charge

Créer des règles de pare-feu

Mettre à jour l'enregistrement DNS A

Mettre à jour les identifiants OAuth

Ajout de comptes utilisateur

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

Étape suivante