表示されているのは Looker のドキュメントです。Looker Studio のドキュメントについては、https://support.google.com/looker-studio をご覧ください。

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

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

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

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

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

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

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

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

始める前に

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

必要なロール

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

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

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

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

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

[新しいカスタムドメインの追加] パネルが開きます。
文字、数字、ダッシュのみを使用して、使用するウェブドメインのホスト名を最大 64 文字（例: looker.examplepetstore.com）で入力します。
[新しいカスタムドメインの追加] パネルで [完了] をクリックして、[カスタムドメイン] タブに戻ります。

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

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

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

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

始める前に

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

Looker 管理者（roles/looker.admin）
Compute インスタンス管理者（v1）（roles/compute.instanceAdmin.v1）
DNS 管理者（roles/dns.admin）
Compute ロードバランサ管理者（roles/compute.loadBalancerAdmin）
Compute ネットワーク管理者（roles/compute.networkAdmin）
Compute セキュリティ管理者（roles/compute.securityAdmin）
Google OAuth を使用する場合: OAuth Config 編集者（roles/oauthconfig.editor）

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

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

ネットワーキングの概要

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

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

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

RHEL オペレーティングシステムを使用して、プライベート IP 専用 VM インスタンスを 2 つ作成します。VM はプロキシサーバーとして機能します。2 つのインスタンスは、Looker（Google Cloud コア）インスタンスと同じリージョン内に配置する必要がありますが、互いに異なるゾーンに配置する必要があります。
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 で以下のコマンドを実行します。

まず、VM に接続します。
次のコマンドを使用して NGINX をインストールします。
```
sudo yum install nginx -y
```
VM で実行されている NGINX のバージョンを確認するには、次のコマンドを実行します。
```
sudo nginx -v
```
次のような出力が返されます。

nginx version: nginx/1.22.1
VM で実行されている NGINX のリリースを確認するには、次のコマンドを実行します。
```
sudo rpm -qi nginx | grep Release
```
次のような出力が返されます。

Release : 1.module+el8.8.0+20355+6d9c8a63.1
VM で使用されている Red Hat のバージョンを確認するには、次のコマンドを実行します。
```
sudo cat /etc/redhat-release
```

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

VM に接続する。

/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 のコメントを外します。

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 ディレクトリがインストールに存在しない場合は、これらを作成するか、他のフォルダを使用できます。
NGINX が証明書ファイルを取得するようにするには、ディレクトリ /etc/nginx/snippets を作成します。
```
sudo mkdir /etc/nginx/snippets
```
構成ファイル /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 は、カスタムドメインに置き換えます。

注: 証明書ファイルを別のパスに保存した場合は、そのパスが /etc/nginx/snippets/self-signed.conf 構成ファイルに反映されていることを確認してください。
構成ファイルに前のステップで説明したファイルへの参照が含まれていることを確認するには、次のコマンドを実行します。
```
sudo more /etc/nginx/snippets/self-signed.conf
```
追加したファイルパスが返されます。
必要に応じて ssl-params.conf NGINX ファイルを作成します。このファイルは、今後の NGINX 構成で再利用できるパラメータを格納するために使用できます。

注: ssl-params.conf を実装する場合は、nginx.conf ファイルの include snippets/ssl-params.conf のコメントを外します。
参考までに、ファイルの内容は次のようになります。
```
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";
```
注: 現時点では strict transport security は無効にしてください。strict transport security を有効にする必要があり、その影響を把握している場合は、add_header Strict-Transport-Security で始まる行のコメントを外します。
NGINX が Looker（Google Cloud コア）Ingress IP にトラフィックを転送できるように SELinux を構成するには、httpd_can_network_connect SELinux ブール値パラメータを 1 に設定します。
```
sudo setsebool -P httpd_can_network_connect 1
```
次のコマンドを使用して、NGINX プロセスを再起動できるようになります。
```
sudo systemctl restart nginx
```

次のコマンドを使用して、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 に対して次の手順を行います。

まず、VM に接続します。
Apache をインストールします。
```
sudo yum install httpd -y
```
次の例では、Red Hat Enterprise Linux リリース 7.9 を使用します。VM で使用されている Red Hat のバージョンを確認するには、次のコマンドを実行します。
```
cat /etc/redhat-release
```
次のような出力が返されます。

Red Hat Enterprise Linux Server release 7.9 (Maipo)
次の例では、Apache リリース 2.4.6 を使用します。VM で使用されている Apache のバージョンを確認するには、各 VM で次のコマンドを実行します。
```
sudo httpd -version
```
次のような出力が返されます。
```
Server version: Apache/2.4.6 (Red Hat Enterprise Linux)
Server built:   date
```

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.

プロキシ 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。

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

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
```
Apache 構成ファイル /etc/httpd/conf/httpd.conf で、Listen 80 を Listen 443 に置き換えます。
次のコマンドを実行して、Apache プロキシ VM がトラフィックを Looker（Google Cloud コア）に転送できるようにします。
```
/usr/sbin/setsebool -P httpd_can_network_connect 1
```
最後に、Apache を再起動して変更を適用します。
```
sudo systemctl restart httpd
```
次のコマンドを使用して、Apache で書き換えモジュールが読み込まれ、実行可能であることを確認します。
```
sudo httpd -M | grep rewrite
```
次のような出力が返されます。
rewrite_module (shared)
最後に、Apache プロセスを起動または再起動して、すべての構成変更が反映されるようにします。
```
sudo systemctl restart httpd
```

次のコマンドを使用して、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 つのゾーン 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 をデプロイするゾーンを追加する場合は、この手順を繰り返します。
同じゾーンの 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 にエンドポイントとして追加されるまで、この手順を繰り返します。
内部ロードバランサによって使用されるリージョンヘルスチェックを作成します。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: ヘルスチェックに使用されるプロトコル。有効なオプションは grpc、http、https、http2、ssl、tcp です。
- NAME: ヘルスチェックの名前。各グローバルヘルスチェックには、特定のプロジェクト内で一意の名前を付ける必要があります。リージョンヘルスチェックには、特定のリージョン内で一意の名前を付ける必要があります。
- REGION: リージョン外部アプリケーションロードバランサとリージョン内部アプリケーションロードバランサを除くすべてのロードバランサは、グローバルヘルスチェック（--global）を使用します。リージョン内部アプリケーションロードバランサが使用するヘルスチェックのリージョンは、バックエンドサービスのリージョンと一致している必要があります。
- DESCRIPTION: 説明（省略可）
- CHECK_INTERVAL: ヘルスチェックプローブシステムのある接続の開始から次の接続の開始までの時間。単位は秒です。省略した場合、Google Cloud では 5s（5 秒）の値が使用されます。
- TIMEOUT: Google Cloud がプローブに対するレスポンスを待つ時間。TIMEOUT の値は、CHECK_INTERVAL 以下にする必要があります。単位は秒です。省略した場合、Google Cloud では 5s（5 秒）の値が使用されます。
- HEALTHY_THRESHOLD と UNHEALTHY_THRESHOLD: VM インスタンスが正常であるか、正常でないかを判定するために必要になるプローブの成功または失敗の連続回数を示します。いずれのしきい値も省略されている場合は、デフォルトの 2 が使用されます。
- PORT_SPECIFICATION: ポート指定フラグのいずれかを使用してポート指定を定義します。
- ADDITIONAL_FLAGS: PROTOCOL に固有のポートとオプションを指定するための追加フラグ。詳しくは、HTTP、HTTPS、HTTP/2 ヘルスチェックのその他のフラグ、SSL および TCP ヘルスチェックの追加フラグ、gRPC ヘルスチェックの追加フラグをご覧ください。
バックエンドサービスを作成します。
```
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 では接続が維持されないことを意味します。
各 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 を作成する場合はこの手順を繰り返します。
プロキシインスタンスが接続されているサブネットの 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 アドレスが自動的に割り振られます。
転送ルールを作成し、バックエンドサービスと 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 認証情報を更新する

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

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

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

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

始める前に

必要なロール

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

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

始める前に

ネットワーキングの概要

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

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

NGINX

Apache

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

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

DNS A レコードを更新する

OAuth 認証情報を更新する

ユーザーの追加

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

次のステップ

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

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

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

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

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

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