Über den Zugriff auf private Dienste auf eine Looker (Google Cloud Core)-Instanz zugreifen

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

So greifen Sie auf eine solche Instanz zu:

  1. Benutzerdefinierte Domain einrichten
  2. VMs und eine private Zone erstellen
  3. Reverse-Proxy-Server konfigurieren
  4. Load-Balancer erstellen und konfigurieren
  5. Firewallregeln erstellen
  6. DNS-A-Eintrag aktualisieren
  7. OAuth-Anmeldedaten aktualisieren

Benutzerdefinierte Domain einrichten

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

Hinweise

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-Administrator (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 die Domain Ihrer Looker (Google Cloud Core)-Instanz in der Google Cloud -Konsole 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 öffnet sich der Bereich Neue benutzerdefinierte Domain hinzufügen.

  4. Geben Sie den Hostnamen der Webdomain ein, die Sie verwenden möchten. Er darf maximal 64 Zeichen lang sein und nur Buchstaben, Ziffern und Bindestriche enthalten, 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 Ihre benutzerdefinierte Domain eingerichtet wurde, wird sie in der Google Cloud Console auf der Seite mit den Instanzdetails von Looker (Google Cloud Core) auf dem Tab BENUTZERDEFINIERTE DOMAIN in der Spalte Domain angezeigt.

Nachdem Sie eine benutzerdefinierte Domain erstellt haben, 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 einer privaten 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.

Hinweise

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-Proxy-Serverkonfiguration mit einem Load-Balancer erstellen, um Traffic aus einer beliebigen Region oder von einem lokalen Standort an die benutzerdefinierte Domain weiterzuleiten. Das folgende Diagramm veranschaulicht diese Topologie:

Ein Google Cloud-Netzwerk mit sicherem Zugriff auf eine Looker (Google Cloud Core)-Instanz ü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 nur privaten IP-Adressen und einem RHEL-Betriebssystem. Die VMs fungieren als Ihre Proxyserver. Sie sollten sich in derselben Region wie die Looker (Google Cloud Core)-Instanz, aber in unterschiedlichen Zonen befinden.

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 von der VPC und den lokalen Hosts für die DNS-Auflösung verwendet, um die Looker (Google Cloud Core)-Benutzeroberfläche zu erreichen. Der Name der Zone sollte 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, dass die VPC enthalten ist, die 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.

Nachdem die Zone eingerichtet ist, können Sie in der Cloud DNS-Zonen-Seite der Google Cloud -Konsole sehen, dass sie privat ist, nach der benutzerdefinierten Domain benannt ist und Datensatzgruppen 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 Ingress-IP-Adresse, die auf dem Tab „Details“ der Seite „Instanzen“ 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. Für den A-Eintrag wird der vollständig qualifizierte Domainname (Fully Qualified Domain Name, FQDN) verwendet, den Sie als benutzerdefinierte Domain für Looker (Google Cloud Core) konfiguriert haben.

    In der vollständigen Einrichtung sollte der A-Eintrag für die benutzerdefinierte Domain angezeigt werden, wenn Sie die Details der privaten Zone auf der Seite Cloud DNS-Zonen der Google Cloud -Konsole aufrufen.

    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-Appliances 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, wird der Status der benutzerdefinierten Domain, die der Instanz zugeordnet ist, auf dem Tab Benutzerdefinierte Domain der Seite Instanzen von Nicht bestätigt zu Verfügbar aktualisiert.

Reverse-Proxy-Server konfigurieren

Sie können jeden Webserver verwenden, der als Reverse-Proxyserver 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 werden NGINX-Release 1.22.1 und Red Hat Enterprise Linux-Release 8.9 (Ootpa) verwendet. Führen Sie die folgenden Befehle für jede VM aus, um zu prüfen, welche Versionen von NGNIX 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 den folgenden Befehl aus, um zu prüfen, 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 zum Einrichten der einzelnen Proxyserver die folgende Anleitung für jede der beiden erstellten VMs.

  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 Ingress-IP-Adresse für Ihre Looker (Google Cloud Core)-Instanz

    Beachten Sie außerdem Folgendes:

    • Dies ist eine reine IPv4-Konfiguration. Wenn der Proxy auch auf seiner privaten IPv6-Adresse lauschen soll, entfernen Sie das Kommentarzeichen vor der Zeile listen [::]:443 ssl in der Datei.
    • Die Zugriffsprotokollebene ist auf debug festgelegt. Passen Sie sie an die Ebene an, die in Ihrer Umgebung verwendet wird.
    • Wenn Sie die ssl-params.conf-Datei implementieren, auf die später in dieser Anleitung verwiesen wird, entfernen Sie die Kommentarzeichen vor include snippets/ssl-params.conf.

  3. Erstellen Sie ein gültiges TLS-Zertifikat, das auf die benutzerdefinierte Domain-URL von Looker (Google Cloud Core) verweist. Dieses Zertifikat wird vom Proxy für Clients präsentiert, 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 Dienst von Let's Encrypt erstellt wurde, ohne dass die automatische Verlängerung über Certbot eingerichtet wurde. Speichern Sie die relevanten Dateien nach dem Erstellen des Zertifikats 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 Zertifikatsdateien 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 bestätigen, dass die Konfigurationsdatei den Verweis auf die Dateien enthält, die im vorherigen Schritt erwähnt wurden: 

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

    Es sollten die Dateipfade zurückgegeben werden, die Sie hinzugefügt haben.

  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 Ingress-IP-Adresse von Looker (Google Cloud Core) weiterleiten kann, setzen Sie den booleschen SELinux-Parameter httpd_can_network_connect 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. Apache installieren:

    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

    In diesem Fall 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 verwendet werden:

    sudo httpd -version

    In diesem Fall sollte Folgendes zurückgegeben werden:

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

  5. Weitere Informationen zum Apache-Server erhalten Sie mit dem folgenden Befehl:

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

    Nach der Installation von mod_ssl 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 Traffic an Looker (Google Cloud Core) weiterleiten kann:

    /usr/sbin/setsebool -P httpd_can_network_connect 1

  11. Starten Sie zum Schluss Apache neu, damit die Änderungen übernommen werden:

    sudo systemctl restart httpd

  12. Prüfen Sie mit diesem 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 den Apache-Prozess schließlich neu, damit alle Konfigurationsänderungen übernommen werden:

    sudo systemctl restart httpd

  14. Prüfen Sie mit dem folgenden Befehl, ob der Apache-Prozess richtig 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 Backends des internen Passthrough-Network Load Balancers verwendet. Wenn Sie lieber Instanzgruppen-Back-Ends verwenden möchten, folgen Sie der Anleitung auf der Dokumentationsseite Internen Passthrough-Network-Load-Balancer mit VM-Instanzgruppen-Back-Ends einrichten.

  1. Erstellen Sie für jede Compute-Zone, in der Sie Proxyserver bereitstellen möchten, eine separate zonale NEG. 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. Informationen dazu, wie viele Endpunkte pro zonaler NEG unterstützt werden, finden Sie auf der Dokumentationsseite Kontingente und Limits.

    Mit dem folgenden gcloud-Befehl können Sie eine zonale NEG 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 Proxy-Server-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 Proxy-Server-VMs als Endpunkt zu einer NEG 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 Zeitspanne, die Google Cloud auf eine Antwort auf eine Prüfung wartet. 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 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 einen Standardschwellenwert von 2.
    • PORT_SPECIFICATION: Definiert die Portspezifikation mit einem der Flags zur Portspezifikation.
    • ADDITIONAL_FLAGS: Weitere Flags zur Festlegung 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. Back-End-Dienst erstellen:

    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 regionalen Systemdiagnose, die Sie erstellt haben.
    • 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 anhand eines Hashwerts, der aus der IP-Adresse des Clients und der Zieladresse erstellt wird.
    • Das Flag --connection-persistence-on-unhealthy-backends=NEVER_PERSIST bedeutet, dass Verbindungen nicht auf fehlerhaften Proxy-Instanz-VMs bestehen bleiben.

  5. Fügen Sie dem Backend-Dienst jede der 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. Dies sollte dieselbe Region sein, 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ätzlichen NEG, die Sie erstellt haben.

  6. Reservieren Sie eine interne IP-Adresse in der VPC im IP-Bereich des Subnetzes, mit dem die Proxy-Instanzen verbunden sind. Dies ist die virtuelle IP-Adresse (VIP) des internen Load Balancers. Durch das Reservieren der Adresse wird sichergestellt, dass die IP nicht von einem 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 der VPC, in der die Proxy-Server-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 BS_REGION). So können Clients in jeder Region auf die Looker (Google Cloud Core)-Instanz zugreifen.

Firewallregeln erstellen

Damit Systemdiagnosen funktionieren, 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, um Traffic aus lokalen oder Multicloud-Umgebungen den Zugriff auf den Backend-Dienst des Load-Balancers zu ermöglichen.

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. Rufen Sie in der Google Cloud -Konsole APIs & Dienste > Anmeldedaten auf 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 zu aktualisieren. Es muss denselben DNS-Namen enthalten, 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 /oauth2callback am Ende des URI hinzu. Wenn Ihre benutzerdefinierte Domain also looker.examplepetstore.com ist, geben Sie looker.examplepetstore.com/oauth2callback ein.

Nutzer hinzufügen

Nachdem die vorherigen Schritte ausgeführt wurden, ist die benutzerdefinierte Domain-URL für Nutzer zugänglich.

Achten Sie darauf, dass die Nutzerauthentifizierungsmethode für die Looker (Google Cloud Core)-Instanz vollständig eingerichtet ist, bevor Sie Nutzer zur Instanz hinzufügen.

Fehlerbehebung

  • Wenn Sie mit Chrome auf die benutzerdefinierte Looker (Google Cloud Core)-Domain zugreifen und einen Chrome-Fehler wie NET::ERR_CERT_COMMON_NAME_INVALID oder einen HSTS-Richtlinienfehler erhalten, können Sie das Problem mit den folgenden Schritten 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.

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

Nächste Schritte