プライベート IP Looker(Google Cloud コア)インスタンスのカスタム ドメインを設定する: 異なるリージョンから送信されるトラフィック

Looker(Google Cloud コア)が提供するデフォルトのドメインではなく、カスタム ウェブドメインを介して Looker(Google Cloud コア)インスタンスを提供できます。

このドキュメント ページでは、次の両方の条件を満たすインスタンスのカスタム ドメインを設定してアクセスする方法について説明します。

  • インスタンスはプライベート IP のみである。
  • インスタンスへのトラフィックは、インスタンスが配置されているリージョンとは異なるリージョンから発信されているか、ハイブリッド ネットワークを経由して発信されている。

この種のインスタンスにカスタム ドメインを実装する手順は次のとおりです。

  1. カスタム ドメインを設定する
  2. VM と限定公開ゾーンを作成する
  3. リバース プロキシ サーバーを構成する
  4. ロードバランサを作成して構成する
  5. ファイアウォール ルールを作成する
  6. DNS A レコードを更新する
  7. OAuth 認証情報を更新する

カスタム ドメインを設定する

Looker(Google Cloud コア)インスタンスを作成したら、インスタンスにカスタム ドメインを設定できます。

始める前に

Looker(Google Cloud コア)インスタンスのドメインをカスタマイズする前に、ドメインの DNS レコードが保存されている場所を特定して、更新できるようにします。

必要なロール

Looker(Google Cloud コア)インスタンスのカスタム ドメインを作成するために必要な権限を取得するには、インスタンスが存在するプロジェクトに対する Looker 管理者 roles/looker.admin)IAM ロールを付与するよう管理者に依頼してください。ロールの付与の詳細については、アクセス権の管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

カスタム ドメインを作成する

Google Cloud コンソールで、Looker(Google Cloud コア)インスタンスのドメインをカスタマイズする手順は次のとおりです。

  1. [インスタンス] ページで、カスタム ドメインを設定するインスタンスの名前をクリックします。
  2. [カスタム ドメイン] タブをクリックします。
  3. [カスタム ドメインを追加] をクリックします。

    [新しいカスタム ドメインの追加] パネルが開きます。

  4. 文字、数字、ダッシュのみを使用して、使用するウェブドメインのホスト名を最大 64 文字(例: looker.examplepetstore.com)で入力します。

  5. [新しいカスタム ドメインの追加] パネルで [完了] をクリックして、[カスタム ドメイン] タブに戻ります。

設定すると、Google Cloud コンソールのインスタンスの詳細ページの [カスタム ドメイン] タブにある [ドメイン] 列にカスタム ドメインが表示されます。

カスタム ドメインが作成されると、その情報を表示したり、削除したりできます。

カスタム ドメインにアクセスする

プライベート IP 専用 Looker(Google Cloud コア)インスタンスへのトラフィックがインスタンスとは異なるリージョンから発信されている場合は、1 つ以上のプライベート IP リバース プロキシ サーバーとロードバランサを使用すると、インスタンスに安全にアクセスできます。

始める前に

プライベート IP カスタム ドメインへのアクセスを設定するために必要な権限を取得するには、インスタンスが存在するプロジェクトに対する次の IAM ロールを付与するよう管理者に依頼してください。

ロールの付与の詳細については、アクセス権の管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

ネットワーキングの概要

以降のセクションでは、ロードバランサを使用して冗長な NGINX または Apache プロキシ サーバーの設定を作成し、任意のリージョンまたはオンプレミスからカスタム ドメインにトラフィックを転送する方法について説明します。次の図は、このトポロジを表しています。

Cloud Router、内部ロードバランサ、プライベート サービス アクセスを使用した Looker(Google Cloud コア)インスタンスへの安全なアクセスを示す Google Cloud ネットワーク。

VM と限定公開ゾーンを作成する

  1. RHEL オペレーティング システムを使用して、プライベート IP 専用 VM インスタンスを 2 つ作成します。VM はプロキシ サーバーとして機能します。2 つのインスタンスは、Looker(Google Cloud コア)インスタンスと同じリージョン内に配置する必要がありますが、互いに異なるゾーンに配置する必要があります。
  2. Cloud DNS レコードを管理するための Cloud DNS 限定公開ゾーンを作成します。この限定公開ゾーンは、Looker(Google Cloud コア)インスタンスが配置されている VPC から利用できる必要があります。Cloud DNS 限定公開ゾーンは、VPC とオンプレミス ホストによって、Looker(Google Cloud コア)UI に到達するための DNS 解決に使用されます。ロードバランサを使用しているため、Cloud DNS 限定公開ゾーンの A レコードはロードバランサの IP アドレスにマッピングされます。

リバース プロキシ サーバーを構成する

リバース プロキシ サーバーとして構成できる任意のウェブサーバーを使用できます。次のいずれかのオプションを選択して、NGINX または Apache を使用してリバース プロキシ サーバーを設定する方法の例を確認します。

NGINX

次の例では、NGINX リリース 1.22.1 と Red Hat Enterprise Linux リリース 8.9(Ootpa)を使用しています。VM で使用されている NGNIX と Red Hat のバージョンを確認するには、各 VM で以下のコマンドを実行します。

  1. まず、VM に接続します。

  2. 次のコマンドを使用して NGINX をインストールします。

    sudo yum install nginx -y
    
  3. VM で実行されている NGINX のバージョンを確認するには、次のコマンドを実行します。

    sudo nginx -v
    

    次のような出力が返されます。

    nginx version: nginx/1.22.1

  4. VM で実行されている NGINX のリリースを確認するには、次のコマンドを実行します。

    sudo rpm -qi nginx | grep Release
    

    次のような出力が返されます。

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

  5. VM で使用されている Red Hat のバージョンを確認するには、次のコマンドを実行します。

    sudo cat /etc/redhat-release
    

各プロキシ サーバーを設定するには、作成した 2 つの VM それぞれに対して次の手順を行います。

  1. VM に接続する
  2. /etc/nginx/nginx.conf ファイルを編集して、次の構成を含めます。

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

    次のように置き換えます。

    • CUSTOM_DOMAIN: Looker(Google Cloud コア)インスタンスのカスタム ドメイン
    • INGRESS_PRIVATE_IP: Looker(Google Cloud コア)インスタンスの上り(内向き)のプライベート IP

    また、次の点を考慮してください。

    • これは IPv4 のみの構成です。プロキシがプライベート IPv6 アドレスもリッスンする必要がある場合は、ファイルの listen [::]:443 ssl 行のコメントを外します。
    • アクセスログ レベルは debug に設定されています。お客様固有の環境で使用されるレベルに調整してください。
    • これらの手順の後半で参照する ssl-params.conf ファイルを実装する場合は、include snippets/ssl-params.conf のコメントを外します。
  3. Looker(Google Cloud コア)のカスタム ドメイン URL を参照する有効な TLS 証明書を作成します。この証明書は、Looker(Google Cloud コア)にアクセスしようとしているクライアントにプロキシが提示する証明書です。証明書の署名に使用する認証局(CA)は、クライアントから信頼されている必要があります。内部プライベート CA を使用してこの TLS 証明書に署名することもできます(または、セルフマネージド SSL 証明書を使用することもできます)。

    この例では、Certbot による自動更新は設定せずに Let's Encrypt 無料サービスを使用して証明書がすでに作成されているものとします。証明書が作成されたら、各プロキシ VM の certs ディレクトリと private ディレクトリに関連ファイルを保存します。

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

    custom-domain.custom-domain.com は、カスタム ドメインに置き換えます。

    certs ディレクトリと private ディレクトリがインストールに存在しない場合は、これらを作成するか、他のフォルダを使用できます。

  4. NGINX が証明書ファイルを取得するようにするには、ディレクトリ /etc/nginx/snippets を作成します。

    sudo mkdir /etc/nginx/snippets
    
  5. 構成ファイル /etc/nginx/snippets/self-signed.conf を作成します。

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

    この構成ファイルを編集して、保存した証明書ファイルのパスを追加します。

    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;
    

    custom-domain.custom-domain.com は、カスタム ドメインに置き換えます。

  6. 構成ファイルに前のステップで説明したファイルへの参照が含まれていることを確認するには、次のコマンドを実行します。

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

    追加したファイルパスが返されます。

  7. 必要に応じて ssl-params.conf NGINX ファイルを作成します。このファイルは、今後の NGINX 構成で再利用できるパラメータを格納するために使用できます。

    参考までに、ファイルの内容は次のようになります。

    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. NGINX が Looker(Google Cloud コア)Ingress IP にトラフィックを転送できるように SELinux を構成するには、httpd_can_network_connect SELinux ブール値パラメータを 1 に設定します。

    sudo setsebool -P httpd_can_network_connect 1
    
  9. 次のコマンドを使用して、NGINX プロセスを再起動できるようになります。

    sudo systemctl restart nginx
    
  10. 次のコマンドを使用して、NGINX が正しく再起動されたことを確認します。

    sudo systemctl status nginx
    

    次のような出力が返されます。

    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

各 VM に対して次の手順を行います。

  1. まず、VM に接続します。

  2. Apache をインストールします。

    sudo yum install httpd -y
    
  3. 次の例では、Red Hat Enterprise Linux リリース 7.9 を使用します。VM で使用されている Red Hat のバージョンを確認するには、次のコマンドを実行します。

    cat /etc/redhat-release
    

    次のような出力が返されます。

    Red Hat Enterprise Linux Server release 7.9 (Maipo)

  4. 次の例では、Apache リリース 2.4.6 を使用します。VM で使用されている Apache のバージョンを確認するには、各 VM で次のコマンドを実行します。

    sudo httpd -version
    

    次のような出力が返されます。

    Server version: Apache/2.4.6 (Red Hat Enterprise Linux)
    Server built:   date
    
  5. Apache サーバーの詳細を確認するには、次のコマンドを実行します。

    sudo rpm -qi httpd
    

    次のような出力が返されます。

    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. プロキシ VM に構成ファイル /etc/httpd/conf.d/ssl.conf を作成し、次の構成をそのファイルに追加します。

    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/
    
    

    次のように置き換えます。

    • custom domain of Looker (Google Cloud core): Looker(Google Cloud コア)インスタンスのカスタム ドメイン。
    • private IP of Looker (Google Cloud core): Looker(Google Cloud コア)インスタンスのプライベート IP。
  7. /etc/httpd/conf.d/ssl.conf ファイルで参照されているディレクトリで TLS 証明書ファイルが利用可能であることを確認します。

    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. mod_ssl がインストールされているかどうかを確認します。

    sudo yum list installed | grep mod_ssl
    

    mod_ssl がインストールされていない場合は、次のコマンドを使用してインストールします。

    sudo yum install mod_ssl
    

    mod_ssl をインストールしたら、Apache 構成ファイル /etc/httpd/conf/httpd.conf に次の行を追加して有効にする必要があります。

    LoadModule ssl_module modules/mod_ssl.so
    
  9. Apache 構成ファイル /etc/httpd/conf/httpd.conf で、Listen 80Listen 443 に置き換えます。

  10. 次のコマンドを実行して、Apache プロキシ VM がトラフィックを Looker(Google Cloud コア)に転送できるようにします。

    /usr/sbin/setsebool -P httpd_can_network_connect 1
    
  11. 最後に、Apache を再起動して変更を適用します。

    sudo systemctl restart httpd
    
  12. 次のコマンドを使用して、Apache で書き換えモジュールが読み込まれ、実行可能であることを確認します。

    sudo httpd -M | grep rewrite
    

    次のような出力が返されます。

    rewrite_module (shared)

  13. 最後に、Apache プロセスを起動または再起動して、すべての構成変更が反映されるようにします。

    sudo systemctl restart httpd
    
  14. 次のコマンドを使用して、Apache プロセスが正しく再起動されたことを確認します。

    sudo systemctl status httpd
    

    次のような出力が返されます。

    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.
    

ロードバランサの作成と設定

この例では、内部パススルー ネットワーク ロードバランサのバックエンドとして、GCE_VM_IP エンドポイントを含むゾーン ネットワーク エンドポイント グループ(NEG)を使用します。インスタンス グループベースのバックエンドを使用する場合は、VM インスタンス グループのバックエンドを使用して内部パススルー ネットワーク ロードバランサを設定するのドキュメント ページの説明に沿って対応してください。

  1. プロキシ サーバーをデプロイする予定のコンピューティング ゾーンには、それぞれ 1 つのゾーン NEG を個別に作成します。たとえば、Looker(Google Cloud コア)がデプロイされているリージョンの 3 つのコンピューティング ゾーンにそれぞれプロキシ サーバーをデプロイする場合は、3 つのゾーン NEG を作成します。1 つのゾーン NEG でサポートされているエンドポイントの数を確認するには、割り当てと上限のドキュメント ページをご覧ください。

    ゾーン NEG を作成するには、次の gcloud コマンドを使用します。

    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
    

    次のように置き換えます。

    • NEG_NAME: 作成する NEG の名前。
    • PROXY_INSTANCE_ZONE: プロキシ サーバーが配置されるゾーン。
    • PROXY_INSTANCE_VPC: プロキシ サーバーを含む VPC。
    • PROXY_INSTANCE_SUBNET: プロキシ サーバーが配置されるサブネット。

    プロキシ サーバー VM をデプロイするゾーンを追加する場合は、この手順を繰り返します。

  2. 同じゾーンの NEG に各プロキシ サーバーを追加します。

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

    次のように置き換えます。

    • PROXY_INSTANCE_ZONE: プロキシ サーバーが配置されるゾーン。
    • NEG_NAME: プロキシ サーバーと同じゾーンの NEG の名前。
    • PROXY_INSTANCE_NAME: プロキシ サーバーの名前。

    各プロキシ サーバー VM が NEG にエンドポイントとして追加されるまで、この手順を繰り返します。

  3. 内部ロードバランサによって使用されるリージョン ヘルスチェックを作成します。compute health-checks create コマンドを使用します。

    gcloud compute health-checks create PROTOCOL NAME \
        --region=REGION \
        --description=DESCRIPTION \
        --check-interval=CHECK_INTERVAL \
        --timeout=TIMEOUT \
        --healthy-threshold=HEALTHY_THRESHOLD \
        --unhealthy-threshold=UNHEALTHY_THRESHOLD \
        PORT_SPECIFICATION \
        ADDITIONAL_FLAGS
    

    次のように置き換えます。

    • PROTOCOL: ヘルスチェックに使用されるプロトコル。有効なオプションは grpchttphttpshttp2ssltcp です。
    • NAME: ヘルスチェックの名前。各グローバル ヘルスチェックには、特定のプロジェクト内で一意の名前を付ける必要があります。リージョン ヘルスチェックには、特定のリージョン内で一意の名前を付ける必要があります。
    • REGION: リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサを除くすべてのロードバランサは、グローバル ヘルスチェック(--global)を使用します。リージョン内部アプリケーション ロードバランサが使用するヘルスチェックのリージョンは、バックエンド サービスのリージョンと一致している必要があります。
    • DESCRIPTION: 説明(省略可)
    • CHECK_INTERVAL: ヘルスチェック プローブ システムのある接続の開始から次の接続の開始までの時間。単位は秒です。省略した場合、Google Cloud では 5s(5 秒)の値が使用されます。
    • TIMEOUT: Google Cloud がプローブに対するレスポンスを待つ時間。TIMEOUT の値は、CHECK_INTERVAL 以下にする必要があります。単位は秒です。省略した場合、Google Cloud では 5s(5 秒)の値が使用されます。
    • HEALTHY_THRESHOLDUNHEALTHY_THRESHOLD: VM インスタンスが正常であるか、正常でないかを判定するために必要になるプローブの成功または失敗の連続回数を示します。いずれのしきい値も省略されている場合は、デフォルトの 2 が使用されます。
    • PORT_SPECIFICATION: ポート指定フラグのいずれかを使用してポート指定を定義します。
    • ADDITIONAL_FLAGS: PROTOCOL に固有のポートとオプションを指定するための追加フラグ。詳しくは、HTTP、HTTPS、HTTP/2 ヘルスチェックのその他のフラグSSL および TCP ヘルスチェックの追加フラグgRPC ヘルスチェックの追加フラグをご覧ください。
  4. バックエンド サービスを作成します

    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
    

    次のように置き換えます。

    • BS_NAME: 作成しているロードバランサの名前。
    • PROXY_INSTANCES_REGION: プロキシ サーバーが配置されるリージョン。
    • HC_NAME: 作成したリージョン ヘルスチェックの名前。
    • HC_REGION: ヘルスチェックが配置されているリージョン。

    また、次の方法もあります。

    • --session-affinity=CLIENT_IP フラグは、クライアントの IP アドレスと宛先アドレスの両方で作成されたハッシュに基づいて、特定のクライアントのリクエストを同じバックエンド プロキシ インスタンス VM に向けます。
    • --connection-persistence-on-unhealthy-backends=NEVER_PERSIST フラグは、正常でないプロキシ インスタンス VM では接続が維持されないことを意味します。
  5. 各 NEG をバックエンド サービスに追加します。

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

    次のように置き換えます。

    • BS_NAME: 作成したバックエンド サービスの名前。
    • BS_REGION: バックエンド サービスが配置されるリージョン。これは、プロキシ サーバーが配置されるリージョンと同じである必要があります。
    • NEG_NAME: 追加する NEG の名前。
    • NEG_ZONE: NEG が配置されるゾーン。

    追加の NEG を作成する場合はこの手順を繰り返します。

  6. プロキシ インスタンスが接続されているサブネットの IP 範囲内の VPC で、内部 IP アドレスを予約します。これが内部ロードバランサの仮想 IP アドレス(VIP)になります。アドレスを予約すると、その IP は他のオブジェクトで使用されなくなります。内部 IP アドレスを予約するには、compute addresses create コマンドを使用します。

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

    次のように置き換えます。

    • ADDRESS_NAMES: 作成する 1 つ以上の [--purpose=SHARED_LOADBALANCER_VIP] アドレスの名前。複数のアドレスの場合は、各アドレスをスペースで区切ったリストで指定します(例: example-address-1 example-address-2 example-address-3)。
    • REGION: このリクエストのリージョン。
    • SUBNETWORK: この内部 IP アドレスのサブネット。
    • IP_ADDRESS: 予約する IP アドレス。サブネットのプライマリ IP 範囲内になければなりません。指定しない場合、サブネットから IP アドレスが自動的に割り振られます。
  7. 転送ルールを作成し、バックエンド サービスと 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
    

    次のように置き換えます。

    • FW_RULE_NAME: 作成している転送ルールの名前
    • BS_REGION: バックエンド サービスが配置されるリージョン
    • PROXY_INSTANCES_VPC_NAME: プロキシ サーバー VM が作成された VPC の名前
    • RESERVED_IP_ADDRESS_SUBNET: VIP が配置されるサブネット
    • RESERVED_IP_ADDRESS: ロードバランサの VIP アドレス
    • BS_NAME: バックエンド サービスの名前

    また、次の方法もあります。

    • --allow-global-access フラグは、ロードバランサの VIP が(BS_REGION だけでなく)任意のリージョンから到達可能であることを示します。これにより、すべてのリージョンのクライアントが Looker(Google Cloud コア)インスタンスにアクセスできます。

ファイアウォール ルールの作成

ヘルスチェックを機能させるには、ヘルスチェック プローバーの IP 範囲からのトラフィックを許可するように、ロード バランシングされているプロキシ VM に適用される上り(内向き)ファイアウォール ルールを作成します。

また、上り(内向き)ファイアウォール ルールを作成して、オンプレミス環境またはマルチクラウド環境からのトラフィックがロードバランサのバックエンド サービスにアクセスできるようにします。

DNS A レコードを更新する

ロードバランサの VIP を指すように、Looker(Google Cloud コア)カスタム ドメインの A レコードを変更します。作成した Cloud DNS 限定公開ゾーンは、カスタム ドメインを管理し、プロキシ インスタンスが配置されている VPC で使用されます。

OAuth 認証情報を更新する

  1. Google Cloud コンソールで [API とサービス] > [認証情報] に移動し、Looker(Google Cloud コア)インスタンスで使用されている OAuth クライアントの OAuth クライアント ID を選択して、OAuth クライアントにアクセスします。
  2. [URI を追加] ボタンをクリックして、OAuth クライアントの [承認済みの JavaScript 生成元] フィールドを更新し、組織が Looker(Google Cloud コア)へのアクセスに使用する DNS 名を追加します。たとえば、カスタム ドメインが looker.examplepetstore.com の場合は、URI として「looker.examplepetstore.com」を入力します。

  3. Looker(Google Cloud コア)インスタンスを作成するときに使用した OAuth 認証情報承認済みリダイレクト URI のリストに、カスタム ドメインを更新または追加します。URI の末尾に /oauth2callback を追加します。たとえば、カスタム ドメインが looker.examplepetstore.com の場合は、「looker.examplepetstore.com/oauth2callback」と入力します。

ユーザーの追加

上記の手順が完了すると、ユーザーはカスタム ドメインの URL にアクセスできるようになります。

ユーザーをインスタンスに追加する前に、Looker(Google Cloud コア)インスタンスのユーザー認証方法の設定が完了していることを確認してください。

HSTS ポリシーエラーのトラブルシューティング

Chrome を使用して Looker(Google Cloud コア)のカスタム ドメインにアクセスしているときに、NET::ERR_CERT_COMMON_NAME_INVALID や HSTS ポリシーエラーなどの Chrome エラーが発生した場合は、次の手順で修正できます。

  1. chrome://net-internals/#hsts を開く
  2. カスタム ドメインを入力して、HSTS / PKP セットをクエリします。カスタム ドメインのポリシーは [Found:] に表示されます。
  3. [Delete domain security policies] で、[ドメイン] フィールドにカスタム ドメインを入力します。
  4. [削除] をクリックしてポリシーを削除します。

次のステップ