Looker(Google Cloud 핵심 서비스)가 제공하는 기본 도메인이 아닌 커스텀 웹 도메인을 통해 Looker(Google Cloud 핵심 서비스) 인스턴스를 제공할 수 있습니다.
이 문서 페이지에서는 다음 기준을 모두 충족하는 인스턴스의 커스텀 도메인을 설정하고 액세스하는 방법을 설명합니다.
- 인스턴스가 비공개 IP 전용입니다.
- 트래픽이 인스턴스가 있는 리전과 다른 리전에서 들어오거나 하이브리드 네트워킹을 통해 인스턴스로 들어옵니다.
이러한 종류의 인스턴스에 커스텀 도메인을 구현하려면 다음 단계를 따르세요.
- 커스텀 도메인을 설정합니다.
- VM 및 비공개 영역을 만듭니다.
- 리버스 프록시 서버를 구성합니다.
- 부하 분산기를 만들고 구성합니다.
- 방화벽 규칙을 만듭니다.
- DNS A 레코드를 업데이트합니다.
- OAuth 사용자 인증 정보를 업데이트합니다.
커스텀 도메인 설정
Looker(Google Cloud 핵심 서비스) 인스턴스가 생성되면 인스턴스에 커스텀 도메인을 설정할 수 있습니다.
시작하기 전에
Looker(Google Cloud 핵심 서비스) 인스턴스의 도메인을 맞춤설정하려면 먼저 도메인의 DNS 레코드가 저장된 위치를 확인하여 업데이트해야 합니다.
필요한 역할
Looker(Google Cloud 핵심 서비스) 인스턴스의 커스텀 도메인을 만드는 데 필요한 권한을 얻으려면 관리자에게 인스턴스가 있는 프로젝트에 대한 Looker Admin(roles/looker.admin) IAM 역할을 부여해 달라고 요청하세요.
역할 부여에 대한 자세한 내용은 액세스 관리를 참조하세요.
커스텀 역할이나 다른 사전 정의된 역할을 통해 필요한 권한을 얻을 수도 있습니다.
커스텀 도메인 만들기
Google Cloud 콘솔에서 다음 단계에 따라 Looker(Google Cloud 핵심 서비스) 인스턴스의 도메인을 맞춤설정합니다.
- 인스턴스 페이지에서 커스텀 도메인을 설정하려는 인스턴스의 이름을 클릭합니다.
- 커스텀 도메인 탭을 클릭합니다.
커스텀 도메인 추가를 클릭합니다.
그러면 새 커스텀 도메인 추가 패널이 열립니다.
문자, 숫자, 대시만 사용하여 사용하려는 웹 도메인의 호스트 이름을 최대 64자(예:
looker.examplepetstore.com)로 입력합니다.
새 커스텀 도메인 추가 패널에서 완료를 클릭하여 커스텀 도메인 탭으로 돌아갑니다.
설정이 완료되면 Google Cloud 콘솔의 인스턴스 세부정보 페이지의 커스텀 도메인 탭에 있는 도메인 열에 커스텀 도메인이 표시됩니다.
커스텀 도메인이 생성된 후에는 관련 정보를 확인하거나 삭제할 수 있습니다.
커스텀 도메인 액세스
비공개 IP 전용 Looker(Google Cloud 핵심 서비스) 인스턴스에 대한 트래픽이 인스턴스와 다른 리전에서 들어오는 경우 하나 이상의 비공개 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 구성 편집자(
roles/oauthconfig.editor)
역할 부여에 대한 자세한 내용은 액세스 관리를 참조하세요.
커스텀 역할이나 다른 사전 정의된 역할을 통해 필요한 권한을 얻을 수도 있습니다.
네트워킹 개요
다음 섹션에서는 부하 분산기를 사용하여 중복 NGINX 또는 Apache 프록시 서버 설정을 만들어 모든 리전에서 또는 온프레미스에서 커스텀 도메인으로 트래픽을 라우팅하는 방법을 보여줍니다. 다음 다이어그램은 이 토폴로지를 보여줍니다.
VM 및 비공개 영역 만들기
- RHEL 운영체제로 비공개 IP 전용 VM 인스턴스 2개를 만듭니다. VM이 프록시 서버 역할을 합니다. 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
각 프록시 서버를 설정하려면 생성된 두 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
그러면 추가한 파일 경로가 반환됩니다.
필요한 경우 향후 NGINX 구성에서 재사용할 수 있는 매개변수를 저장하는 데 사용할 수 있는
ssl-params.confNGINX 파일을 만듭니다.참고로 파일의 콘텐츠는 다음과 유사합니다.
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 핵심 서비스) 인그레스 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 인스턴스 그룹 백엔드로 내부 패스 스루 네트워크 부하 분산기 설정 문서 페이지에 있는 문서를 따르세요.
프록시 서버를 배포하려는 컴퓨팅 영역마다 별도의 영역별 NEG를 하나씩 만듭니다. 예를 들어 Looker(Google Cloud 핵심 서비스)가 배포된 리전의 컴퓨팅 영역 3개 각각에 프록시 서버를 배포하려는 경우 영역별 NEG를 3개 만듭니다. 영역별 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 인스턴스가 정상 또는 비정상으로 간주되려면 성공하거나 실패해야 하는 연속 프로브의 수를 지정합니다. 둘 중 하나를 생략하면 Google Cloud에서는 기본 기준점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: 만들려는[--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플래그는 BS_REGION뿐만 아니라 모든 리전에서 부하 분산기의 VIP에 연결할 수 있음을 나타냅니다. 따라서 모든 리전의 클라이언트가 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 세트를 쿼리합니다. 커스텀 도메인의 모든 정책이 찾음: 아래에 표시됩니다.
- 도메인 보안 정책 삭제에서 도메인 필드에 커스텀 도메인을 입력합니다.
- 삭제를 클릭하여 정책을 삭제합니다.
인증서 오류를 해결하려면 SSL 인증서 문제 해결 문서 페이지를 참고하세요. Google 관리형 인증서의 경우 Google 관리형 인증서를 발급하도록 허용하려는 인증 기관을 명시적으로 승인해야 합니다.
다음 단계
- Looker(Google Cloud 핵심 서비스) 내에서 사용자 관리
- Looker(Google Cloud 핵심 서비스) 인스턴스 구성
- Looker(Google Cloud 핵심 서비스)를 데이터베이스에 연결