Benutzerdefinierte Domain für eine private IP-Instanz von Looker (Google Cloud Core) einrichten: Traffic aus verschiedenen Regionen

Sie können Ihre Looker (Google Cloud Core)-Instanz über eine benutzerdefinierte Webdomain statt über die von Looker (Google Cloud Core) bereitgestellte Standarddomain bereitstellen.

Auf dieser Dokumentationsseite wird beschrieben, wie Sie eine benutzerdefinierte Domain für Instanzen einrichten und darauf zugreifen, die die beiden folgenden Kriterien erfüllen:

  • Die Instanz hat nur eine private IP-Adresse.
  • Der Traffic zur Instanz stammt entweder aus anderen Regionen, in denen sich die Instanz befindet, oder über ein Hybridnetzwerk.

Führen Sie die folgenden Schritte aus, um für diese Art von Instanz eine benutzerdefinierte Domain zu implementieren:

  1. Richten Sie die benutzerdefinierte Domain ein.
  2. VMs und private Zonen erstellen
  3. Reverse-Proxyserver konfigurieren
  4. Load-Balancer erstellen und konfigurieren
  5. Firewallregeln erstellen
  6. DNS-A-Eintrag aktualisieren
  7. Aktualisieren Sie die OAuth-Anmeldedaten.

Benutzerdefinierte Domain einrichten

Nachdem Ihre Looker (Google Cloud Core)-Instanz erstellt wurde, können Sie eine benutzerdefinierte Domain für die Instanz einrichten.

Hinweise

Bevor Sie die Domain Ihrer Looker (Google Cloud Core)-Instanz anpassen können, müssen Sie ermitteln, wo die DNS-Einträge Ihrer Domain gespeichert sind, damit Sie sie aktualisieren können.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Looker-Administrator (roles/looker.admin) für das Projekt zu gewähren, in dem sich die Instanz befindet, um die Berechtigungen zu erhalten, die Sie zum Erstellen einer benutzerdefinierten Domain für eine Looker (Google Cloud Core)-Instanz benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.

Möglicherweise können Sie die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Benutzerdefinierte Domain erstellen

Führen Sie in der Google Cloud Console die folgenden Schritte aus, um die Domain Ihrer Looker (Google Cloud Core)-Instanz anzupassen:

  1. Klicken Sie auf der Seite Instanzen auf den Namen der Instanz, für die Sie eine benutzerdefinierte Domain einrichten möchten.
  2. Klicken Sie auf den Tab BENUTZERDEFINIERTE DOMAIN.

  3. Klicken Sie auf BENUTZERDEFINIERTE DOMAIN HINZUFÜGEN.

    Daraufhin wird der Bereich Neue benutzerdefinierte Domain hinzufügen geöffnet.

  4. Geben Sie den Hostnamen mit bis zu 64 Zeichen für die gewünschte Webdomain ein, z. B. looker.examplepetstore.com. Verwenden Sie ausschließlich Buchstaben, Ziffern und Bindestriche.

  5. Klicken Sie im Bereich Neue benutzerdefinierte Domain hinzufügen auf FERTIG, um zum Tab BENUTZERDEFINIERTE DOMAIN zurückzukehren.

Ihre benutzerdefinierte Domain wird in der Spalte Instanz-URL auf der Seite Instanzen der Google Cloud Console angezeigt.

Nachdem Ihre benutzerdefinierte Domain erstellt wurde, können Sie sich Informationen dazu ansehen oder sie löschen.

Auf die benutzerdefinierte Domain zugreifen

Wenn Traffic zu einer Looker (Google Cloud Core)-Instanz mit privater IP-Adresse aus einer anderen Region als der Instanz stammt, können Sie einen oder mehrere private IP-Reverse-Proxy-Server und einen Load Balancer verwenden, um sicheren Zugriff auf die Instanz zu ermöglichen.

Hinweise

Bitten Sie Ihren Administrator, Ihnen für das Projekt, in dem sich die Instanz befindet, die folgenden IAM-Rollen zu gewähren, damit Sie die Berechtigungen erhalten, die Sie zum Einrichten des Zugriffs auf eine benutzerdefinierte IP-Domain benötigen:

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.

Möglicherweise können Sie die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Netzwerkübersicht

In den folgenden Abschnitten wird gezeigt, wie Sie eine redundante NGINX- oder Apache-Proxyserver-Einrichtung mit einem Load-Balancer erstellen, um Traffic aus einer beliebigen Region oder von einer lokalen Umgebung an die benutzerdefinierte Domain weiterzuleiten. Das folgende Diagramm stellt diese Topologie dar:

Ein Google Cloud-Netzwerk, das sicheren Zugriff auf eine Looker (Google Cloud Core)-Instanz mit Cloud Router, einem internen Load-Balancer und dem Zugriff auf private Dienste zeigt.

VMs und private Zone erstellen

  1. Erstellen Sie zwei VM-Instanzen mit privater IP-Adresse mit einem RHEL-Betriebssystem. Die VMs dienen als Proxyserver. Sie sollten sich in derselben Region wie die Looker (Google Cloud Core)-Instanz befinden, jedoch in unterschiedlichen Zonen.
  2. Erstellen Sie eine private Cloud DNS-Zone zum Verwalten Ihrer Cloud DNS-Einträge. Die private Zone sollte für die VPC sichtbar sein, in der sich die Looker (Google Cloud Core)-Instanz befindet. Die private Cloud DNS-Zone wird von der VPC und den lokalen Hosts für die DNS-Auflösung verwendet, um die Benutzeroberfläche von Looker (Google Cloud Core) zu erreichen. Da Sie einen Load-Balancer verwenden, wird der A-Eintrag in der privaten Cloud DNS-Zone der IP-Adresse des Load-Balancers zugeordnet.

Reverse-Proxy-Server konfigurieren

Sie können einen beliebigen Webserver verwenden, der als Reverse-Proxy-Server konfiguriert werden kann. Wählen Sie eine der folgenden Optionen aus, um Beispiele zum Einrichten von Reverse-Proxy-Servern mit NGINX oder Apache anzuzeigen:

NGINX

Im folgenden Beispiel werden NGINX Release 1.22.1 und Red Hat Enterprise Linux Release 8.9 (Ootpa) verwendet. Führen Sie für jede VM die folgenden Befehle aus, um zu prüfen, welche Versionen von NGNIX und Red Hat Ihre VMs verwenden.

  1. Stellen Sie zuerst eine Verbindung zur VM her.

  2. Installieren Sie NGINX mit dem folgenden Befehl:

    sudo yum install nginx -y

  3. Führen Sie den folgenden Befehl aus, um die von der VM ausgeführte NGINX-Version zu ermitteln:

    sudo nginx -v

    Die Ausgabe sollte in etwa so aussehen:

    nginx version: nginx/1.22.1

  4. Führen Sie folgenden Befehl aus, um zu prüfen, welcher NGINX-Release auf der VM ausgeführt wird:

    sudo rpm -qi nginx | grep Release

    Die Ausgabe sollte in etwa so aussehen:

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

  5. Führen Sie den folgenden Befehl aus, um zu prüfen, welche Version von Red Hat Ihre VMs verwenden:

    sudo cat /etc/redhat-release

Folgen Sie zum Einrichten der einzelnen Proxyserver den folgenden Anleitungen für jede der beiden VMs, die Sie erstellt haben.

  1. Verbindung zur VM herstellen

  2. Bearbeiten Sie die Datei /etc/nginx/nginx.conf so, dass sie die folgende Konfiguration enthält:

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

    Ersetzen Sie Folgendes:

    • CUSTOM_DOMAIN: Die benutzerdefinierte Domain Ihrer Looker (Google Cloud Core)-Instanz
    • INGRESS_PRIVATE_IP: Die private IP-Adresse für eingehenden Traffic für Ihre Looker (Google Cloud Core)-Instanz

    Beachten Sie außerdem Folgendes:

    • Dies ist eine reine IPv4-Konfiguration. Wenn der Proxy auch seine private IPv6-Adresse überwachen soll, entfernen Sie das Kommentarzeichen in der Zeile listen [::]:443 ssl in der Datei.
    • Die Zugriff-Log-Ebene ist auf debug festgelegt. Achten Sie darauf, sie an die Ebene anzupassen, die in Ihrer spezifischen Umgebung verwendet wird.
    • Wenn Sie die Datei ssl-params.conf implementieren, auf die weiter unten in diesen Schritten verwiesen wird, entfernen Sie die Kommentarzeichen von include snippets/ssl-params.conf.

  3. Erstellen Sie ein gültiges TLS-Zertifikat, das auf die URL der benutzerdefinierten Looker (Google Cloud Core)-Domain verweist. Dieses Zertifikat stellt der Proxy Clients vor, die versuchen, auf Looker (Google Cloud Core) zuzugreifen. Die zum Signieren des Zertifikats verwendete Zertifizierungsstelle muss von Ihren Clients als vertrauenswürdig eingestuft werden. Sie können dieses TLS-Zertifikat auch mit einer internen privaten Zertifizierungsstelle signieren. Alternativ können Sie auch ein selbstverwaltetes SSL-Zertifikat verwenden.

    In diesem Beispiel wird davon ausgegangen, dass das Zertifikat bereits mit dem kostenlosen "Let's Encrypt"-Dienst erstellt wurde, ohne die automatische Verlängerung durch Certbot einzurichten. Nachdem das Zertifikat erstellt wurde, speichern Sie die relevanten Dateien auf jeder Proxy-VM in den Verzeichnissen certs und private:

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

    Ersetzen Sie custom-domain.custom-domain.com durch Ihre benutzerdefinierte Domain.

    Wenn die Verzeichnisse certs und private in Ihrer Installation nicht vorhanden sind, können Sie sie entweder erstellen oder andere Ordner verwenden.

  4. Erstellen Sie das Verzeichnis /etc/nginx/snippets, damit NGINX die Zertifikatsdateien erfassen kann:

    sudo mkdir /etc/nginx/snippets

  5. Erstellen Sie die Konfigurationsdatei /etc/nginx/snippets/self-signed.conf:

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

    Fügen Sie in der Konfigurationsdatei die Pfade zu den gespeicherten Zertifikatsdateien hinzu:

    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;

    Ersetzen Sie custom-domain.custom-domain.com durch Ihre benutzerdefinierte Domain.

  6. Prüfen Sie mit dem folgenden Befehl, ob die Konfigurationsdatei den Verweis auf die im vorherigen Schritt genannten Dateien enthält:

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

    Sie sollte die von Ihnen hinzugefügten Dateipfade zurückgeben.

  7. Erstellen Sie optional die NGINX-Datei ssl-params.conf, in der Parameter gespeichert werden können, die in zukünftigen NGINX-Konfigurationen wiederverwendet werden können.

    Der Inhalt der Datei sollte in etwa so aussehen:

    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. Um SELinux so zu konfigurieren, dass NGINX Traffic an die Ingress-IP-Adresse von Looker (Google Cloud Core) weiterleitet, setzen Sie den booleschen Parameter httpd_can_network_connect für SELinux auf 1:

    sudo setsebool -P httpd_can_network_connect 1

  9. Sie können den NGINX-Prozess jetzt mit dem folgenden Befehl neu starten:

    sudo systemctl restart nginx

  10. Prüfen Sie mit dem folgenden Befehl, ob NGINX ordnungsgemäß neu gestartet wurde:

    sudo systemctl status nginx

    Die Ausgabe sollte in etwa so aussehen:

    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

Führen Sie diese Schritte für jede VM aus.

  1. Stellen Sie zuerst eine Verbindung zur VM her.

  2. Installieren Sie Apache:

    sudo yum install httpd -y

  3. Im folgenden Beispiel wird Red Hat Enterprise Linux Release 7.9 verwendet. Führen Sie den folgenden Befehl aus, um zu prüfen, welche Versionen von Red Hat Ihre VMs verwenden:

    cat /etc/redhat-release

    Daraufhin sollte Folgendes zurückgegeben werden:

    Red Hat Enterprise Linux Server release 7.9 (Maipo)

  4. Im folgenden Beispiel wird die Apache-Version 2.4.6 verwendet. Führen Sie für jede VM die folgenden Befehle aus, um zu prüfen, welche Apache-Versionen Ihre VMs verwenden:

    sudo httpd -version

    Daraufhin sollte Folgendes zurückgegeben werden:

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

  5. Führen Sie den folgenden Befehl aus, um weitere Informationen zum Apache-Server zu erhalten:

    sudo rpm -qi httpd

    Die Ausgabe sollte in etwa so aussehen:

    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. Erstellen Sie auf der Proxy-VM die Konfigurationsdatei /etc/httpd/conf.d/ssl.conf und fügen Sie ihr die folgende Konfiguration hinzu:

    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/

    Ersetzen Sie Folgendes:

    • custom domain of Looker (Google Cloud core): Die benutzerdefinierte Domain Ihrer Looker (Google Cloud Core)-Instanz.
    • private IP of Looker (Google Cloud core): Die private IP-Adresse Ihrer Looker (Google Cloud Core)-Instanz.

  7. Prüfen Sie, ob die TLS-Zertifikatsdateien in den Verzeichnissen verfügbar sind, auf die in der Datei /etc/httpd/conf.d/ssl.conf verwiesen wird:

    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. Prüfen Sie, ob mod_ssl installiert ist:

    sudo yum list installed | grep mod_ssl

    Wenn mod_ssl nicht installiert ist, installieren Sie es mit dem folgenden Befehl:

    sudo yum install mod_ssl

    Sobald mod_ssl installiert ist, müssen Sie ihn aktivieren. Fügen Sie dazu die folgende Zeile in die Apache-Konfigurationsdatei /etc/httpd/conf/httpd.conf ein:

    LoadModule ssl_module modules/mod_ssl.so

  9. Ersetzen Sie in der Apache-Konfigurationsdatei /etc/httpd/conf/httpd.conf Listen 80 durch Listen 443.

  10. Führen Sie den folgenden Befehl aus, damit die Apache Proxy-VM Traffic an Looker (Google Cloud Core) weiterleiten kann:

    /usr/sbin/setsebool -P httpd_can_network_connect 1

  11. Starten Sie Apache neu, um die Änderungen zu übernehmen:

    sudo systemctl restart httpd

  12. Überprüfen Sie mit dem folgenden Befehl, ob das Rewrite-Modul in Apache geladen und bereit ist:

    sudo httpd -M | grep rewrite

    Die Ausgabe sollte in etwa so aussehen:

    rewrite_module (shared)

  13. Starten oder starten Sie den Apache-Prozess neu, um sicherzustellen, dass alle Konfigurationsänderungen übernommen werden:

    sudo systemctl restart httpd

  14. Prüfen Sie mit dem folgenden Befehl, ob der Apache-Prozess korrekt neu gestartet wurde:

    sudo systemctl status httpd

    Die Ausgabe sollte in etwa so aussehen:

    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.

Load-Balancer erstellen und konfigurieren

In diesem Beispiel werden zonale Netzwerk-Endpunktgruppen (NEGs) mit GCE_VM_IP-Endpunkten als Back-Ends des internen Passthrough-Network Load Balancers verwendet. Wenn Sie lieber auf Instanzgruppen basierende Back-Ends verwenden möchten, folgen Sie der Dokumentation auf der Dokumentationsseite Internen Passthrough-Network Load Balancer mit VM-Instanzgruppen-Back-Ends einrichten.

  1. Erstellen Sie eine separate zonale NEG für jede Compute-Zone, in der Sie Proxyserver bereitstellen möchten. Wenn Sie beispielsweise Proxyserver in jeder der drei Computing-Zonen der Region bereitstellen möchten, in der Looker (Google Cloud Core) bereitgestellt wird, erstellen Sie drei zonale NEGs. Auf der Dokumentationsseite Kontingente und Limits können Sie prüfen, wie viele Endpunkte pro zonaler NEG unterstützt werden.

    Verwenden Sie den folgenden gcloud-Befehl, um eine zonale NEG zu erstellen:

    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

    Ersetzen Sie Folgendes:

    • NEG_NAME: Der Name der NEG, die Sie erstellen.
    • PROXY_INSTANCE_ZONE: Die Zone, in der sich der Proxyserver befindet.
    • PROXY_INSTANCE_VPC: Die VPC, die den Proxyserver enthält.
    • PROXY_INSTANCE_SUBNET: Das Subnetz, in dem sich der Proxyserver befindet.

    Wiederholen Sie diesen Schritt für jede zusätzliche Zone, in der Sie eine Proxyserver-VM bereitstellen.

  2. Fügen Sie jeden Proxyserver der NEG in derselben Zone hinzu:

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

    Ersetzen Sie Folgendes:

    • PROXY_INSTANCE_ZONE: Die Zone, in der sich der Proxyserver befindet.
    • NEG_NAME: Der Name der NEG, die sich in derselben Zone wie der Proxyserver befindet.
    • PROXY_INSTANCE_NAME: Der Name des Proxyservers.

    Wiederholen Sie diesen Schritt, bis jede der Proxyserver-VM einer NEG als Endpunkt hinzugefügt wurde.

  3. Erstellen Sie eine regionale Systemdiagnose, die vom internen Load-Balancer verwendet wird. Führen Sie den Befehl compute health-checks create aus:

    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

    Ersetzen Sie Folgendes:

    • PROTOCOL: Das für die Systemdiagnose verwendete Protokoll. Gültige Optionen sind grpc, http, https, http2, ssl und tcp.
    • NAME: Der Name der Systemdiagnose. Innerhalb eines bestimmten Projekts muss jede globale Systemdiagnose einen eindeutigen Namen haben und regionale Systemdiagnosen müssen innerhalb einer bestimmten Region eindeutige Namen haben.
    • REGION: Alle Load-Balancer mit Ausnahme von regionalen externen Application Load Balancern und regionalen internen Application Load Balancern verwenden globale Systemdiagnosen (--global). Regionale interne Application Load Balancer verwenden regionale Systemdiagnosen, deren Region mit der Region des Backend-Dienstes übereinstimmen muss.
    • DESCRIPTION: Eine optionale Beschreibung.
    • CHECK_INTERVAL: Die Zeitspanne vom Start der Verbindung eines Prüfsystems zur Systemdiagnose bis zum Start der nächsten. Die Einheiten sind Sekunden. Wenn keine Angabe gemacht wird, verwendet Google Cloud den Wert 5s (5 Sekunden).
    • TIMEOUT: Die Zeit, die Google Cloud bei einer Prüfung auf eine Antwort wartet. Der Wert von TIMEOUT muss kleiner oder gleich CHECK_INTERVAL sein. Die Einheit sind Sekunden. Wenn keine Angabe gemacht wird, verwendet Google Cloud den Wert 5s (5 Sekunden).
    • HEALTHY_THRESHOLD und UNHEALTHY_THRESHOLD: Geben Sie die Anzahl der sequenziellen Prüfungen an, die bestanden werden oder fehlschlagen müssen, damit die VM-Instanz als fehlerfrei oder fehlerhaft eingestuft wird. Wenn einer der Parameter nicht angegeben ist, verwendet Google Cloud den Standardschwellenwert 2.
    • PORT_SPECIFICATION: Definiert die Portspezifikation mit einem der Flags zur Portspezifikation.
    • ADDITIONAL_FLAGS: Andere Flags zur Angabe von Ports und Optionen speziell für das PROTOCOL. Weitere Informationen finden Sie unter Zusätzliche Flags für HTTP-, HTTPS- und HTTP/2-Systemdiagnosen, Zusätzliche Flags für SSL- und TCP-Systemdiagnosen oder Zusätzliches Flag für gRPC-Systemdiagnosen.

  4. Erstellen Sie den Back-End-Dienst:

    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

    Ersetzen Sie Folgendes:

    • BS_NAME: Der Name des Load-Balancers, den Sie erstellen.
    • PROXY_INSTANCES_REGION: Die Region, in der sich die Proxyserver befinden.
    • HC_NAME: Der Name der von Ihnen erstellten regionalen Systemdiagnose.
    • HC_REGION: Die Region, in der sich die Systemdiagnose befindet.

    Außerdem:

    • Das Flag --session-affinity=CLIENT_IP leitet die Anfrage eines bestimmten Clients an dieselbe Back-End-Proxy-Instanz-VM weiter, und zwar basierend auf einem Hash, der sowohl für die Client-IP-Adresse als auch für die Zieladresse erstellt wurde.
    • Das Flag --connection-persistence-on-unhealthy-backends=NEVER_PERSIST bedeutet, dass Verbindungen auf nicht fehlerfreien Proxy-Instanz-VMs nicht aufrechterhalten werden.

  5. Fügen Sie dem Back-End-Dienst die einzelnen NEGs hinzu:

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

    Ersetzen Sie Folgendes:

    • BS_NAME: Der Name des Back-End-Dienstes, den Sie erstellt haben.
    • BS_REGION: Die Region, in der sich der Back-End-Dienst befindet. Sie sollte mit der Region übereinstimmen, in der sich die Proxyserver befinden.
    • NEG_NAME: Der Name der NEG, die Sie hinzufügen.
    • NEG_ZONE: Die Zone, in der sich die NEG befindet.

    Wiederholen Sie diesen Schritt für die zusätzliche NEG, die Sie erstellt haben.

  6. Reservieren Sie eine interne IP-Adresse in der VPC innerhalb des IP-Bereichs des Subnetzes, mit dem die Proxy-Instanzen verbunden sind. Dies ist die virtuelle IP-Adresse (VIP) des internen Load-Balancers. Durch Reservieren der Adresse wird sichergestellt, dass die IP-Adresse von keinem anderen Objekt verwendet wird. Reservieren Sie die interne IP-Adresse mit dem Befehl compute addresses create:

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

    Ersetzen Sie Folgendes:

    • ADDRESS_NAMES: Die Namen einer oder mehrerer [--purpose=SHARED_LOADBALANCER_VIP]-Adressen, die Sie erstellen möchten. Geben Sie bei mehreren Adressen alle Adressen als Liste an, getrennt durch Leerzeichen. Beispiel: example-address-1 example-address-2 example-address-3.
    • REGION: Die Region für diese Anfrage.
    • SUBNETWORK: Das Subnetz für diese interne IP-Adresse.
    • IP_ADDRESS: Die zu reservierende IP-Adresse, die sich im primären IP-Bereich des Subnetzes befinden muss. Wenn hier keine Angabe gemacht wird, wird automatisch eine IP-Adresse aus dem Subnetz zugewiesen.

  7. Erstellen Sie die Weiterleitungsregel und verknüpfen Sie sie mit dem Back-End-Dienst und der VIP:

    gcloud compute forwarding-rules create FW_RULE_NAME --region=BS_REGION \
--load-balancing-scheme=internal --network=PROXY_INSTANCES_VPC_NAME --subnet=RESERVED_IP_ADDRESS_SUBNET \
--address=RESERVED_IP_ADDRESS --ip-protocol=tcp --ports=ALL --backend-service=BS_NAME \
--backend-service-region=BS_REGION --allow-global-access

    Ersetzen Sie Folgendes:

    • FW_RULE_NAME: Der Name der Weiterleitungsregel, die Sie erstellen.
    • BS_REGION: Die Region, in der sich der Back-End-Dienst befindet
    • PROXY_INSTANCES_VPC_NAME: Der Name der VPC, in der die Proxyserver-VMs erstellt wurden.
    • RESERVED_IP_ADDRESS_SUBNET: Subnetz, in dem sich die VIP befindet
    • RESERVED_IP_ADDRESS: die virtuelle IP-Adresse für den Load-Balancer
    • BS_NAME: Der Name des Back-End-Dienstes.

    Außerdem:

    • Das Flag --allow-global-access gibt an, dass die VIP des Load-Balancers von jeder Region aus erreichbar ist (nicht nur von BS_REGION). So können Clients in jeder Region die Looker (Google Cloud Core)-Instanz erreichen.

Firewallregeln erstellen

Damit Systemdiagnosen funktionieren, erstellen Sie Firewallregeln für eingehenden Traffic, die für die Proxy-VM mit Load-Balancing gelten, um Traffic von IP-Bereichen des Systemdiagnose-Probers zuzulassen.

Erstellen Sie außerdem eine Firewallregel für eingehenden Traffic, damit Traffic aus lokalen oder Multi-Cloud-Umgebungen Zugriff auf den Back-End-Dienst des Load-Balancers erhält.

DNS-A-Eintrag aktualisieren

Ändern Sie den A-Eintrag der benutzerdefinierten Looker (Google Cloud Core)-Domain so, dass er auf die VIP des Load-Balancers verweist. Die von Ihnen erstellte private Cloud DNS-Zone verwaltet die benutzerdefinierte Domain und wird von der VPC verwendet, in der sich die Proxy-Instanzen befinden.

OAuth-Anmeldedaten aktualisieren

  1. Um auf Ihren OAuth-Client zuzugreifen, gehen Sie in der Google Cloud Console zu APIs und Dienste > Anmeldedaten und wählen Sie die OAuth-Client-ID für den OAuth-Client aus, der von Ihrer Looker (Google Cloud Core)-Instanz verwendet wird.

  2. Klicken Sie auf die Schaltfläche URI hinzufügen, um das Feld Autorisierte JavaScript-Quellen in Ihrem OAuth-Client so zu aktualisieren, dass es denselben DNS-Namen enthält, den Ihre Organisation für den Zugriff auf Looker (Google Cloud Core) verwendet. Wenn Ihre benutzerdefinierte Domain also looker.examplepetstore.com ist, geben Sie looker.examplepetstore.com als URI ein.

  3. Aktualisieren Sie die benutzerdefinierte Domain oder fügen Sie sie der Liste der autorisierten Weiterleitungs-URIs für die OAuth-Anmeldedaten hinzu, die Sie beim Erstellen der Looker (Google Cloud Core)-Instanz verwendet haben. Fügen Sie am Ende des URI /oauth2callback hinzu. Wenn Ihre benutzerdefinierte Domain also looker.examplepetstore.com ist, geben Sie looker.examplepetstore.com/oauth2callback ein.

Nutzer hinzufügen

Sobald die vorherigen Schritte ausgeführt wurden, können Nutzer auf die URL der benutzerdefinierten Domain zugreifen.

Die Nutzerauthentifizierungsmethode muss für die Looker (Google Cloud Core)-Instanz vollständig eingerichtet sein, bevor Sie Nutzer zur Instanz hinzufügen.

Fehler bei HSTS-Richtlinien beheben

Wenn Sie mit Chrome auf die benutzerdefinierte Domain von Looker (Google Cloud Core) zugreifen und einen Chrome-Fehler wie NET::ERR_CERT_COMMON_NAME_INVALID oder einen HSTS-Richtlinienfehler erhalten, können Sie das Problem so beheben:

  1. chrome://net-internals/#hsts öffnen
  2. Geben Sie die benutzerdefinierte Domain ein, um den HSTS/PKP-Satz abzufragen. Alle Richtlinien für die benutzerdefinierte Domain werden unter Gefunden: angezeigt.
  3. Geben Sie unter Domain-Sicherheitsrichtlinien löschen die benutzerdefinierte Domain in das Feld Domain ein.
  4. Klicken Sie auf Löschen, um die Richtlinien zu löschen.

Nächste Schritte