Auf eine Looker (Google Cloud Core)-Instanz 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-Instanz (Google Cloud Core) einrichten, die die folgenden Kriterien erfüllt:

So greifen Sie auf diese Art von Instanz zu:

  1. Richten Sie die benutzerdefinierte Domain ein.
  2. VMs und eine private Zone erstellen
  3. Konfigurieren Sie die Reverse-Proxy-Server.
  4. Erstellen und konfigurieren Sie den Load Balancer.
  5. Erstellen Sie Firewallregeln.
  6. Aktualisieren Sie den DNS-A-Eintrag.
  7. Aktualisieren Sie die OAuth-Anmeldedaten.

Benutzerdefinierte Domain einrichten

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

Hinweis

Bevor Sie die Domain Ihrer Looker (Google Cloud Core)-Instanz anpassen können, müssen Sie herausfinden, 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

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.

Nachdem Sie die benutzerdefinierte Domain eingerichtet haben, wird sie in der Spalte Domain auf dem Tab BENUTZERDEFINIERTE DOMAIN der Seite mit den Instanzdetails von Looker (Google Cloud Core) in der Google Cloud Console angezeigt.

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

Auf die benutzerdefinierte Domain zugreifen

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

Hinweis

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Projekt zuzuweisen, in dem sich die Instanz befindet, um die Berechtigungen zu erhalten, die Sie zum Einrichten des Zugriffs auf eine benutzerdefinierte Domain mit privater IP-Adresse 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.

Netzwerkübersicht

In den folgenden Abschnitten wird gezeigt, wie Sie eine redundante NGINX- oder Apache-Proxyserverkonfiguration mit einem Load Balancer erstellen, um Traffic aus einer beliebigen Region oder lokal an die benutzerdefinierte Domain weiterzuleiten. Das folgende Diagramm veranschaulicht diese Topologie:

Ein Google Cloud-Netzwerk mit sicherem Zugriff auf eine Looker-Instanz (Google Cloud Core) über Cloud Router, einen internen Load Balancer und den Zugriff auf private Dienste.

VMs, eine private Zone und einen A‑Eintrag erstellen

Führen Sie die Schritte in den folgenden Abschnitten aus.

VMs erstellen

Erstellen Sie zwei VM-Instanzen mit ausschließlich 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.

Private Zone erstellen

Erstellen Sie eine private Cloud DNS-Zone, die für die VPC sichtbar ist, in der sich die Looker (Google Cloud Core)-Instanz befindet. Die private Cloud DNS-Zone wird vom VPC und den lokalen Hosts für die DNS-Auflösung verwendet, um die Looker-Benutzeroberfläche (Google Cloud Core) aufzurufen. Der Name der Zone muss mit der benutzerdefinierten Domain übereinstimmen.

  gcloud dns managed-zones create NAME \
  --description=DESCRIPTION \
  --dns-name=DNS_SUFFIX \
  --networks=VPC_NETWORK_LIST \
  --labels=LABELS \
  --visibility=private

Ersetzen Sie Folgendes:

  • NAME: Ein Name für Ihre Zone.
  • DESCRIPTION: Eine Beschreibung für Ihre Zone.

  • DNS_SUFFIX: das DNS-Suffix für Ihre Zone, z. B. examplepetstore.com.

  • VPC_NETWORK_LIST: eine durch Kommas getrennte Liste von VPC-Netzwerken, die zum Abfragen der Zone autorisiert sind. Achten Sie darauf, das VPC anzugeben, das Ihre Looker (Google Cloud Core)-Instanz enthält.

  • LABELS: Eine optionale durch Kommas getrennte Liste von Schlüssel/Wert-Paaren wie dept=marketing oder project=project1. Weitere Informationen finden Sie in der SDK-Dokumentation.

Wenn Sie die Zone in der Google Cloud Console auf der Seite Cloud DNS-Zonen aufrufen, sehen Sie, dass sie privat ist, nach der benutzerdefinierten Domain benannt ist und Datensätze für die benutzerdefinierte Domain enthält.

Cloud DNS-A-Eintrag hinzufügen

Führen Sie die folgenden Schritte aus, um den Cloud DNS-A-Eintrag hinzuzufügen:

  1. Da Sie einen Load Balancer verwenden, wird der A-Eintrag in der privaten Cloud DNS-Zone der IP-Adresse des Load Balancers zugeordnet.

    Die private IP-Adresse für den Eingang, die auf der Seite „Instanzen“ auf dem Tab „Details“ hervorgehoben ist.

  2. Fügen Sie der privaten Zone einen DNS-A-Eintrag für die benutzerdefinierte Domain hinzu, der aus der Ingress-IP-Adresse der Looker (Google Cloud Core)-Instanz besteht. Der A-Eintrag verwendet den voll qualifizierten Domainnamen (Fully Qualified Domain Name, FQDN), den Sie als benutzerdefinierte Domain für Looker (Google Cloud Core) konfiguriert haben.

    Nach Abschluss der Einrichtung sollte der A-Eintrag für die benutzerdefinierte Domain angezeigt werden, wenn Sie sich die Details der privaten Zone auf der Seite Cloud DNS-Zonen in der Google Cloud Console ansehen.

    Wenn Sie die Namensauflösungsdienste eines VPC-Netzwerks für lokale Netzwerke verfügbar machen möchten, die über Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder Router-Appliance mit dem VPC-Netzwerk verbunden sind, können Sie eine Serverrichtlinie für eingehenden Traffic verwenden.

    Sobald die DNS-Einträge Ihrer Domain aktualisiert und Ihre Domain in der Google Cloud Console bestätigt wurde, ändert sich der Status der benutzerdefinierten Domain, die der Instanz zugeordnet ist, auf der Seite Instanzen auf dem Tab Benutzerdefinierte Domain von Nicht bestätigt zu Verfügbar.

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 für die Einrichtung von Reverse-Proxy-Servern mit NGINX oder Apache aufzurufen:

NGINX

Im folgenden Beispiel wird 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. So prüfen Sie, welche NGINX-Version 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 aus der 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 Domain von Looker (Google Cloud Core) verweist. Dieses Zertifikat wird von dem Proxy an Clients gesendet, die versuchen, auf Looker (Google Cloud Core) zuzugreifen. 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 Dienst „Let's Encrypt“ erstellt wurde, ohne dass die automatische Verlängerung über Certbot eingerichtet wurde. Nachdem das Zertifikat erstellt wurde, speichern Sie die entsprechenden Dateien in den Verzeichnissen certs und private auf jeder Proxy-VM:

    /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 Zertifikatdateien erkennt, 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.

  6. Führen Sie den folgenden Befehl aus, um zu prüfen, ob die Konfigurationsdatei den Verweis auf die im vorherigen Schritt genannten Dateien enthält: 

    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.

    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. Wenn Sie SELinux so konfigurieren möchten, dass NGINX Traffic an die Eingangs-IP-Adresse 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 richtig 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 auf Ihren VMs verwendet werden:

    cat /etc/redhat-release

    Daraufhin sollte Folgendes zurückgegeben werden:

    Red Hat Enterprise Linux Server release 7.9 (Maipo)

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

    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-Instanz (Google Cloud Core).

  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, können Sie es mit dem folgenden Befehl installieren:

    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 den Wert 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. Prüfen Sie mit dem folgenden Befehl, ob das Rewrite-Modul in Apache geladen und einsatzbereit 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 Rechenzone, in der Sie Proxyserver bereitstellen möchten. Wenn Sie beispielsweise Proxyserver in jeder der drei Rechenzonen der Region bereitstellen möchten, in der Looker (Google Cloud Core) bereitgestellt wird, erstellen Sie drei zonale NEGs. Auf der Seite Kontingente und Limits finden Sie Informationen dazu, 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 weitere Zone, in der Sie eine Proxyserver-VM bereitstellen.

  2. Fügen Sie der NEG in derselben Zone jeden Proxyserver 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 jeder der Proxyserver-VMs 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: 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 Zeitspanne, Google Cloud die auf eine Antwort auf eine Prüfung gewartet wird. Der Wert von TIMEOUT muss kleiner oder gleich CHECK_INTERVAL sein. Die Einheit sind Sekunden. Wenn keine Angabe gemacht wird, verwendetGoogle Cloud den Wert 5s (5 Sekunden).
    • HEALTHY_THRESHOLD und UNHEALTHY_THRESHOLD: Geben Sie die Anzahl der sequenziellen Testdurchläufe 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, verwendetGoogle Cloud den Standardschwellenwert 2.
    • PORT_SPECIFICATION: Definiert die Portspezifikation mit einem der Flags zur Portspezifikation.
    • ADDITIONAL_FLAGS: Weitere 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 VM der Back-End-Proxy-Instanz weiter. Dabei wird ein Hashwert aus der Client-IP-Adresse und der Zieladresse erstellt.
    • 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 übereinstimmen, in der sich die Proxyserver befinden.
    • NEG_NAME: Der Name der hinzugefügten NEG.
    • 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, in 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. Verwenden Sie den Befehl compute addresses create, um die interne IP-Adresse zu reservieren:

    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 innerhalb des primären IP-Bereichs 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 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 Backend-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 VIP-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 den eingehenden Traffic, damit Traffic aus lokalen oder Multi-Cloud-Umgebungen auf den Load Balancer-Backenddienst zugreifen kann.

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

  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 lautet, geben Sie looker.examplepetstore.com als URI ein.

  3. Aktualisieren oder fügen Sie die benutzerdefinierte Domain 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 lautet, 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.

Achten Sie darauf, dass die Nutzerauthentifizierungsmethode für die Looker (Google Cloud Core)-Instanz vollständig eingerichtet ist, bevor Sie der Instanz Nutzer 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 Fehlerbehebung bei Zertifikaten finden Sie auf der Seite Fehlerbehebung bei SSL-Zertifikaten. Bei von Google verwalteten Zertifikaten müssen Sie die Zertifizierungsstelle, der Sie die Ausstellung Ihres von Google verwalteten Zertifikats erlauben möchten, ausdrücklich autorisieren.

Nächste Schritte