このドキュメント ページでは、次の条件を満たす 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 プロキシ サーバーの設定を作成し、任意のリージョンまたはオンプレミスからカスタム ドメインにトラフィックを転送する方法について説明します。次の図は、このトポロジを表しています。
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.1VM が実行している NGINX リリースを確認するには、次のコマンドを実行します。
sudo rpm -qi nginx | grep Release
次のような出力が返されます。
Release : 1.module+el8.8.0+20355+6d9c8a63.1VM で使用されている 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 は、カスタム ドメインに置き換えます。
構成ファイルに前のステップで説明したファイルへの参照が含まれていることを確認するには、次のコマンドを実行します。
sudo more /etc/nginx/snippets/self-signed.conf
追加したファイルパスが返されます。
必要に応じて
ssl-params.confNGINX ファイルを作成します。このファイルは、今後の 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";
NGINX が Looker（Google Cloud コア）Ingress IP にトラフィックを転送できるように SELinux を構成するには、
httpd_can_network_connectSELinux ブール値パラメータを 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.
プロキシ 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 コア）インスタンスのユーザー認証方法の設定が完了していることを確認してください。
トラブルシューティング
Chrome を使用して Looker（Google Cloud コア）のカスタム ドメインにアクセスしているときに、
NET::ERR_CERT_COMMON_NAME_INVALIDや HSTS ポリシーエラーなどの Chrome エラーが発生した場合は、次の手順で修正できます。chrome://net-internals/#hstsを開く- カスタム ドメインを入力して、HSTS / PKP セットをクエリします。カスタム ドメインのポリシーは [Found:] に表示されます。
- [Delete domain security policies] で、[ドメイン] フィールドにカスタム ドメインを入力します。
- [削除] をクリックしてポリシーを削除します。
証明書エラーのトラブルシューティングを行うには、SSL 証明書のトラブルシューティングのドキュメント ページをご覧ください。Google マネージド証明書の場合は、Google マネージド証明書の発行を許可する認証局を明示的に承認してください。
次のステップ
- Looker（Google Cloud コア）をデータベースに接続する
- ユーザー向けに Looker（Google Cloud コア）インスタンスを準備する
- Looker（Google Cloud コア）内のユーザーを管理する