Auf eine Looker-Instanz (Google Cloud Core) mit Zugriff auf private Dienste zugreifen: Traffic aus verschiedenen Regionen

Auf dieser Dokumentationsseite wird beschrieben, wie Sie eine benutzerdefinierte Domain und den Zugriff auf eine Looker (Google Cloud Core)-Instanz einrichten, die die folgenden Kriterien erfüllt:

• Die Instanz hat nur eine private IP-Adresse.
• Die Instanz wurde zum Zeitpunkt der Erstellung für den Zugriff auf private Dienste eingerichtet.
• 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 auf diese Art von Instanz zuzugreifen:

1. Richten Sie die benutzerdefinierte Domain ein.
2. VMs und private Zonen erstellen
3. Reverse-Proxyserver konfigurieren
4. Load-Balancer erstellen und konfigurieren
5. Erstellen Sie Firewallregeln.
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 einrichten.

Hinweis

Hinweis: Benutzerdefinierte Domains können nicht mit einer looker.com-Domain erstellt werden.

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 Admin (roles/looker.admin) für das Projekt zuzuweisen, 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 auf Projekte, Ordner und Organisationen verwalten.

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

Benutzerdefinierte Domain erstellen

Hinweis: Eine benutzerdefinierte Domain kann nach der Erstellung nicht mehr geändert werden. Wenn Sie Änderungen an der benutzerdefinierten Domain vornehmen möchten, müssen Sie die vorhandene benutzerdefinierte Domain löschen und eine neue erstellen.

So passen Sie in der Google Cloud Console die Domain Ihrer Looker (Google Cloud Core)-Instanz an:

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. Verwenden Sie dabei nur Buchstaben, Ziffern und Bindestriche, z. B. looker.examplepetstore.com.

   

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

Hinweis: Die Aktualisierung der benutzerdefinierten Domain dauert 10 bis 15 Minuten.

Nach der Einrichtung wird Ihre benutzerdefinierte Domain in der Spalte Domain auf dem Tab Benutzerdefinierte Domain der Detailseite der Instanz in 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.

Hinweis

Um die Berechtigungen zu erhalten, die Sie zum Einrichten des Zugriffs auf eine private IP-Domain benötigen, bitten Sie Ihren Administrator, Ihnen folgende IAM-Rollen für das Projekt, in dem sich die Instanz befindet:

• Looker-Administrator (roles/looker.admin)
• Compute-Instanzadministrator (Version 1) (roles/compute.instanceAdmin.v1)
• DNS-Administrator (roles/dns.admin)
• Administrator für Compute-Load-Balancer (roles/compute.loadBalancerAdmin)
• Compute-Netzwerkadministrator (roles/compute.networkAdmin)
• Compute-Sicherheitsadministrator (roles/compute.securityAdmin)
• Google OAuth verwenden: OAuth-Konfigurationsbearbeiter (roles/oauthconfig.editor)

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

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

Netzwerkübersicht

Hinweis: In einem Proof-of-Concept-Szenario können Sie einen Reverse-Proxyserver einrichten und müssen keinen Load-Balancer einrichten.

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:

VMs und private Zone erstellen

1. Erstellen Sie zwei VM-Instanzen mit nur privaten IP-Adressen und einem RHEL-Betriebssystem. Die VMs dienen als Proxyserver. Sie sollten sich in derselben Region wie die Looker-Instanz (Google Cloud Core) befinden, aber in verschiedenen Zonen.
2. Erstellen Sie eine private Cloud DNS-Zone, um Ihre Cloud DNS-Einträge zu verwalten. Die private Zone muss für das VPC sichtbar sein, in dem sich die Looker-Instanz (Google Cloud Core) 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 jeden 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

Hinweis: Dieses Konfigurationsbeispiel verwendet NGNIX-Proxyserver unter RHEL und dient als funktionierender Ausgangspunkt für Ihre benutzerdefinierte Proxy-Konfiguration. Diese Konfiguration wurde mit NGINX-Release 1.22.1 getestet, das auf Red Hat Enterprise Linux-Release 8.9 installiert ist.

Im folgenden Beispiel werden NGINX Release 1.22.1 und Red Hat Enterprise Linux Release 8.9 (Ootpa) verwendet. Führen Sie die folgenden Befehle auf jeder VM aus, um zu prüfen, welche Versionen von Nginx und Red Hat auf Ihren VMs verwendet werden.

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 NGINX-Version zu ermitteln, die auf der VM ausgeführt wird:

   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 auf Ihren VMs verwendet wird:

   sudo cat /etc/redhat-release
   

Verwenden Sie die folgende Anleitung für jede der beiden von Ihnen erstellten VMs, um die Proxyserver einzurichten.

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-Instanz (Google Cloud Core)
   • INGRESS_PRIVATE_IP: Die private IP-Adresse für den Eingang Ihrer Looker-Instanz (Google Cloud Core)

   Beachten Sie außerdem Folgendes:

   • Dies ist eine reine IPv4-Konfiguration. Wenn der Proxy auch auf seiner privaten IPv6-Adresse lauschen soll, entfernen Sie den Kommentar in der Datei für die Zeile listen [::]:443 ssl.
   • Die Zugriffsprotokollebene ist auf debug festgelegt. Passen Sie sie an die Ebene an, die in Ihrer Umgebung verwendet wird.
   • Wenn Sie die Datei ssl-params.conf implementieren, auf die später in diesen Schritten verwiesen wird, entfernen Sie den Kommentar zu 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 wird von dem Proxy an Clients gesendet, die auf Looker (Google Cloud Core) zugreifen möchten. Die Zertifizierungsstelle, die zum Signieren des Zertifikats verwendet wird, muss von Ihren Clients als vertrauenswürdig eingestuft werden. Sie können auch eine interne private Zertifizierungsstelle verwenden, um dieses TLS-Zertifikat zu 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. Damit NGINX die Zertifikatsdateien erfassen kann, erstellen Sie das Verzeichnis /etc/nginx/snippets:

   sudo mkdir /etc/nginx/snippets
   

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

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

   Bearbeiten Sie die Konfigurationsdatei, um die Pfade zu den gespeicherten Zertifikatsdateien hinzuzufügen:

   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.

   Hinweis: Wenn Sie die Zertifikatdateien unter einem anderen Pfad gespeichert haben, achten Sie darauf, dass der Pfad in der /etc/nginx/snippets/self-signed.conf-Konfigurationsdatei korrekt angegeben ist.

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

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

   Es sollten die von Ihnen hinzugefügten Dateipfade zurückgegeben werden.

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

   Hinweis: Wenn Sie ssl-params.conf implementieren, entfernen Sie das Kommentarzeichen include snippets/ssl-params.conf in der Datei nginx.conf.

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

   Hinweis: Deaktivieren Sie die strikte Transportsicherheit vorerst. Wenn Sie die strenge Transportsicherheit aktivieren möchten und sich der damit verbundenen Auswirkungen bewusst sind, können Sie das Kommentarzeichen in der Zeile entfernen, die mit add_header Strict-Transport-Security beginnt.

8. Wenn Sie SELinux so konfigurieren möchten, dass NGINX Traffic an die Ingress-IP von Looker (Google Cloud Core) weiterleiten kann, setzen Sie den booleschen Parameter httpd_can_network_connect von 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

Hinweis: Die folgende Konfiguration wurde mit Apache-Release 2.4.6 getestet, der auf Red Hat Enterprise Linux-Release 7.9 installiert ist.

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 die Konfigurationsdatei /etc/httpd/conf.d/ssl.conf auf der Proxy-VM und fügen Sie der Datei 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-Instanz (Google Cloud Core).
   • 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
   

   Nachdem mod_ssl installiert wurde, müssen Sie es aktivieren, indem Sie der Apache-Konfigurationsdatei /etc/httpd/conf/httpd.conf die folgende Zeile hinzufügen:

   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 den Traffic an Looker (Google Cloud Core) weiterleiten kann:

    /usr/sbin/setsebool -P httpd_can_network_connect 1
    

11. Starten Sie abschließend Apache neu, um die Änderungen anzuwenden:

    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 Sie abschließend den Apache-Prozess oder starten Sie ihn neu, damit 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 Instanzgruppen-basierte Back-Ends verwenden möchten, folgen Sie der Dokumentation auf der Seite 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: Das VPC, das 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 in derselben Zone wie der Proxyserver.
   • 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 Zeit ab Beginn eines Status. die Verbindung des Prüfsystems bis zum Start des nächsten prüfen. Die Einheiten sind Sekunden. Wenn keine Angabe gemacht wird, verwendet Google Cloud den Wert 5s (5 Sekunden).
   • TIMEOUT: Die Zeit, die Google Cloud wartet. um eine Antwort auf eine Prüfung zu erhalten. 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, die erfolgreich sein müssen oder fehlschlagen müssen, damit die VM-Instanz als gesund oder ungesund gelten. 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 zum Angeben von Ports und spezifische Optionen für 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 nicht auf nicht fehlerfreien Proxy-Instanz-VMs bestehen bleiben.

5. Fügen Sie dem Backend-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 von Ihnen erstellten Backend-Dienstes.
   • BS_REGION: Die Region, in der sich der Back-End-Dienst befindet. Diese Region sollte mit der Region der Proxyserver übereinstimmen.
   • 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 die Reservierung 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 von mindestens einem [--purpose=SHARED_LOADBALANCER_VIP] 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 muss sich im primären IP-Bereich des Subnetzes befinden. 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 Backend-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 des VPC, in dem die Proxyserver-VMs erstellt wurden
   • RESERVED_IP_ADDRESS_SUBNET: Das Subnetz, in dem sich die VIP befindet
   • RESERVED_IP_ADDRESS: die virtuelle IP-Adresse für den Load-Balancer
   • BS_NAME: Der Name des Backend-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 der BS_REGION). So können Clients in jeder Region die Looker-Instanz (Google Cloud Core) erreichen.

Firewallregeln erstellen

Damit die Systemdiagnose funktioniert, müssen Sie Firewallregeln für eingehenden Traffic erstellen, die auf die Proxy-VM mit Load Balancing angewendet werden können und Traffic von IP-Bereichen des Systemdiagnose-Probers zulassen.

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 Domain von Looker (Google Cloud Core), sodass er auf die VIP-Adresse des Load Balancers verweist. Die von Ihnen erstellte private Cloud DNS-Zone verwaltet die benutzerdefinierte Domain und wird vom VPC verwendet, in dem sich die Proxy-Instanzen befinden.

OAuth-Anmeldedaten aktualisieren

Hinweis: Sie können einen beliebigen OAuth-Client verwenden, um Autorisierungsanmeldedaten für Ihre Looker (Google Cloud Core)-Instanz zu erstellen. In diesen Schritten wird beispielsweise beschrieben, wie Sie die Anmeldedaten mit der Google Cloud Console aktualisieren. Wenn Sie einen anderen Client verwenden, passen Sie die Schritte entsprechend an.

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

2. Klicken Sie auf die Schaltfläche URI hinzufügen, um das Feld Autorisierte JavaScript-Quellen in Ihrem OAuth-Client zu aktualisieren und denselben DNS-Namen anzugeben, 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 URIs /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.

Fehlerbehebung

• Wenn Sie Chrome verwenden, um auf die benutzerdefinierte Domain von Looker (Google Cloud Core) zuzugreifen, und ein Chrome-Fehler wie NET::ERR_CERT_COMMON_NAME_INVALID oder ein HSTS-Richtlinienfehler auftritt, können Sie ihn 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 Domainsicherheitsrichtlinien löschen die benutzerdefinierte Domain in das Feld Domain ein.
  4. Klicken Sie auf Löschen, um die Richtlinien zu löschen.

• Informationen zur Behebung von Zertifikatsfehlern finden Sie auf der Dokumentationsseite Fehlerbehebung bei SSL-Zertifikaten. Achten Sie bei von Google verwalteten Zertifikaten darauf, die Zertifizierungsstelle, die Ihr von Google verwaltetes Zertifikat ausstellen darf, explizit autorisieren.

Nächste Schritte

• Looker (Google Cloud Core) mit Ihrer Datenbank verbinden
• Looker-Instanz (Google Cloud Core) für Nutzer vorbereiten
• Nutzer in Looker verwalten (Google Cloud Core)