Acessar uma instância do Looker (Google Cloud Core) usando o acesso a serviços privados: tráfego originado de diferentes regiões

Esta página de documentação descreve como configurar um domínio personalizado e o acesso a uma instância do Looker (Google Cloud Core) que atenda aos seguintes critérios:

Para acessar esse tipo de instância, execute as seguintes etapas:

  1. Configure o domínio personalizado.
  2. Crie VMs e uma zona particular.
  3. Configure os servidores proxy reversos.
  4. Crie e configure o balanceador de carga.
  5. Crie regras de firewall.
  6. Atualize o registro A do DNS.
  7. Atualize as credenciais do OAuth.

Configurar um domínio personalizado

Depois que sua instância do Looker (Google Cloud Core) for criada, você poderá configurar um domínio personalizado.

Antes de começar

Antes de personalizar o domínio da sua instância do Looker (Google Cloud Core), identifique onde os registros DNS do domínio estão armazenados para atualizá-los.

Funções exigidas

Para ter as permissões necessárias para criar um domínio personalizado para uma instância do Looker (Google Cloud Core), peça ao administrador para conceder a você Administrador do Looker (roles/looker.admin) no projeto em que a instância reside. Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias por meio de papéis personalizados ou de outros papéis predefinidos.

Criar um domínio personalizado

No console do Google Cloud, siga estas etapas para personalizar o domínio da sua instância do Looker (Google Cloud Core):

  1. Na página Instâncias, clique no nome da instância em que você quer configurar um domínio personalizado.
  2. Clique na guia DOMÍNIO PERSONALIZADO.

  3. Clique em ADICIONAR UM DOMÍNIO PERSONALIZADO.

    O painel Adicionar um novo domínio personalizado será aberto.

  4. Usando apenas letras, números e traços, insira o nome do host com até 64 caracteres do domínio da Web que você quer usar. Por exemplo: looker.examplepetstore.com.

  5. Clique em DONE no painel Add a new custom domain para retornar à guia CUSTOM DOMAIN.

Após a configuração, seu domínio personalizado vai aparecer na coluna Domínio da guia Domínio personalizado da página de detalhes da instância do console do Google Cloud.

Após criar o domínio personalizado, você poderá ver informações sobre ele ou excluir o domínio.

Acessar o domínio personalizado

Quando o tráfego para uma instância do Looker (Google Cloud Core) com IP particular se origina de uma região diferente, é possível usar um ou mais servidores de proxy reverso de IP particular e um balanceador de carga para fornecer acesso seguro à instância.

Antes de começar

Para receber as permissões necessárias para configurar o acesso a um domínio personalizado de IP particular, peça ao administrador para conceder a você seguintes papéis do IAM no projeto em que a instância reside:

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Também é possível conseguir as permissões necessárias por meio de papéis personalizados ou de outros papéis predefinidos.

Visão geral da rede

As seções a seguir mostram como criar uma configuração redundante de servidor proxy do Apache ou NGINX com um balanceador de carga para rotear o tráfego de qualquer região ou do local para o domínio personalizado. O diagrama a seguir representa essa topologia:

Uma rede do Google Cloud mostrando acesso seguro a uma instância do Looker (núcleo do Google Cloud) usando o Cloud Router, um balanceador de carga interno e o acesso a serviços particulares.

Criar VMs e uma zona particular

  1. Crie duas instâncias de VM somente de IP particular com um sistema operacional RHEL. As VMs vão atuar como servidores proxy. Elas precisam estar localizadas na mesma região da instância do Looker (Google Cloud Core), mas em zonas diferentes.
  2. Crie uma zona particular do Cloud DNS para gerenciar os registros do Cloud DNS. A zona particular precisa ficar visível para a VPC em que a instância do Looker (Google Cloud Core) está localizada. A zona particular do Cloud DNS será usada pela VPC e pelos hosts locais para que a resolução de DNS alcance a UI do Looker (Google Cloud Core). Como você vai usar um balanceador de carga, o registro A na zona particular do Cloud DNS será mapeado para o endereço IP do balanceador de carga.

Configurar os servidores de proxy reverso

Você pode usar qualquer servidor da Web que possa ser configurado como um servidor proxy reverso. Selecione uma das opções a seguir para conferir exemplos de como configurar servidores de proxy reverso usando o NGINX ou o Apache:

NGINX

O exemplo a seguir usa o NGINX versão 1.22.1 e o Red Hat Enterprise Linux versão 8.9 (Ootpa). Para verificar quais versões do NGNIX e Red Hat suas VMs estão usando, execute os seguintes comandos para cada VM.

  1. Primeiro, conecte-se à VM.

  2. Instale o NGINX usando o seguinte comando:

    sudo yum install nginx -y

  3. Para encontrar a versão do NGINX em execução na VM, execute o seguinte comando: 

    sudo nginx -v

    Isso vai retornar algo semelhante ao seguinte:

    nginx version: nginx/1.22.1

  4. Para verificar qual versão do NGINX a VM está executando, execute o seguinte comando: 

    sudo rpm -qi nginx | grep Release

    Isso vai retornar algo semelhante ao seguinte:

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

  5. Para verificar qual versão do Red Hat suas VMs estão usando, execute o seguinte comando:

    sudo cat /etc/redhat-release

Para configurar cada servidor proxy, use as instruções a seguir para cada uma das duas VMs que você criou.

  1. Conecte-se à VM.

  2. Edite o arquivo /etc/nginx/nginx.conf para conter a seguinte configuração:

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

    Substitua:

    • CUSTOM_DOMAIN: o domínio personalizado da sua instância do Looker (Google Cloud Core)
    • INGRESS_PRIVATE_IP: o IP privado de entrada da sua instância do Looker (Google Cloud Core)

    Além disso, considere o seguinte:

    • Essa é uma configuração somente IPv4. Se você precisa que o proxy também detecte no endereço IPv6 particular, remova a marca de comentário da linha listen [::]:443 ssl no arquivo.
    • O nível de registro de acesso é definido como debug. certifique-se de ajustá-lo ao nível usado em seu ambiente específico.
    • Se você implementar o arquivo ssl-params.conf, que é referenciado mais adiante nestas etapas, remova o comentário de include snippets/ssl-params.conf.

  3. Crie um certificado TLS válido que faça referência ao URL do domínio personalizado do Looker (Google Cloud Core). Esse certificado será o que o proxy apresentará aos clientes que tentam acessar o Looker (núcleo do Google Cloud). A autoridade certificadora (AC) usada para assinar o certificado precisa ser confiável para os clientes. Você também pode usar uma AC privada interna para assinar o certificado TLS. Como alternativa, também é possível usar um certificado SSL autogerenciado.

    Neste exemplo, suponha que o certificado já tenha sido criado com o serviço gratuito Let's Encrypt, sem configurar a renovação automática do Certbot. Depois que o certificado for criado, salve os arquivos relevantes nos diretórios certs e private em cada VM de proxy:

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

    Substitua custom-domain.custom-domain.com pelo domínio personalizado.

    Se os diretórios certs e private não existirem na instalação, crie-os ou use outras pastas.

  4. Para garantir que o NGINX colete os arquivos de certificado, crie o diretório /etc/nginx/snippets:

    sudo mkdir /etc/nginx/snippets

  5. Crie o arquivo de configuração, /etc/nginx/snippets/self-signed.conf:

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

    Edite o arquivo de configuração para adicionar os caminhos aos arquivos de certificado salvos:

    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;

    Substitua custom-domain.custom-domain.com pelo domínio personalizado.

  6. Para confirmar que o arquivo de configuração contém a referência aos arquivos mencionados na etapa anterior, execute o seguinte comando: 

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

    Ele vai retornar os caminhos de arquivo que você adicionou.

  7. Outra opção é criar o arquivo NGINX ssl-params.conf, que pode ser usado para armazenar parâmetros que podem ser reutilizados em configurações futuras do NGINX.

    Para referência, o conteúdo do arquivo deve ser semelhante ao seguinte:

    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. Para configurar o SELinux e permitir que o NGINX encaminhe o tráfego para o IP de entrada do Looker (Google Cloud Core), defina o parâmetro booleano httpd_can_network_connect do SELinux como 1:

    sudo setsebool -P httpd_can_network_connect 1

  9. Agora é possível reiniciar o processo do NGINX usando o seguinte comando:

    sudo systemctl restart nginx

  10. Verifique se o NGINX foi reiniciado corretamente usando o seguinte comando:

    sudo systemctl status nginx

    A saída será semelhante a esta:

    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

Conclua estas etapas para cada VM.

  1. Primeiro, conecte-se à VM.

  2. Instale o Apache:

    sudo yum install httpd -y

  3. O exemplo a seguir usa a versão 7.9 do Red Hat Enterprise Linux. Para verificar quais versões do Red Hat suas VMs estão usando, execute o seguinte comando:

    cat /etc/redhat-release

    A seguinte resposta será retornada:

    Red Hat Enterprise Linux Server release 7.9 (Maipo)

  4. O exemplo a seguir usa o Apache versão 2.4.6. Para verificar quais versões do Apache suas VMs estão usando, execute os seguintes comandos para cada uma delas:

    sudo httpd -version

    A seguinte resposta será retornada:

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

  5. Para mais informações sobre o servidor Apache, execute o seguinte comando:

    sudo rpm -qi httpd

    Com isso, será retornada uma saída semelhante a esta:

    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. Crie o arquivo de configuração /etc/httpd/conf.d/ssl.conf na VM de proxy e adicione a seguinte configuração ao arquivo:

    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/

    Substitua:

    • custom domain of Looker (Google Cloud core): o domínio personalizado da sua instância do Looker (Google Cloud Core).
    • private IP of Looker (Google Cloud core): o IP privado da sua instância do Looker (Google Cloud Core).

  7. Confirme se os arquivos de certificado TLS estão disponíveis nos diretórios referenciados no arquivo /etc/httpd/conf.d/ssl.conf:

    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. Verifique se o mod_ssl está instalado:

    sudo yum list installed | grep mod_ssl

    Se mod_ssl não estiver instalado, instale-o com o seguinte comando:

    sudo yum install mod_ssl

    Depois que mod_ssl estiver instalado, ative-o adicionando a seguinte linha ao arquivo de configuração do Apache, /etc/httpd/conf/httpd.conf:

    LoadModule ssl_module modules/mod_ssl.so

  9. No arquivo de configuração do Apache, /etc/httpd/conf/httpd.conf, substitua Listen 80 por Listen 443.

  10. Execute o comando abaixo para permitir que a VM do proxy Apache encaminhe o tráfego para o Looker (Google Cloud Core):

    /usr/sbin/setsebool -P httpd_can_network_connect 1

  11. Por fim, reinicie o Apache para aplicar as mudanças:

    sudo systemctl restart httpd

  12. Verifique se o módulo de substituição está carregado e pronto no Apache usando este comando:

    sudo httpd -M | grep rewrite

    O resultado será semelhante a este:

    rewrite_module (shared)

  13. Por fim, inicie ou reinicie o processo do Apache para garantir que todas as mudanças de configuração sejam aplicadas:

    sudo systemctl restart httpd

  14. Use o seguinte comando para verificar se o processo do Apache foi reiniciado corretamente: 

    sudo systemctl status httpd

    O resultado será semelhante a este:

    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.

Criar e configurar o balanceador de carga

Este exemplo usa grupos de endpoints de rede zonais (NEGs) com endpoints GCE_VM_IP como back-ends do balanceador de carga de rede de passagem interna. Caso prefira usar back-ends baseados em grupo de instâncias, siga a documentação na página Configurar um balanceador de carga de rede de passagem interna com back-ends de grupos de instâncias de VM.

  1. Crie um NEG por zona de computação em que você planeja implantar servidores proxy. Por exemplo, se você quiser implantar servidores proxy em cada uma das três zonas de computação da região em que o Looker (Google Cloud Core) está implantado, crie três NEGs por zona. Consulte a página de documentação Cotas e limites para conferir quantos endpoints são aceitos por NEG por zona.

    Para criar um NEG por zona, use o seguinte comando 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

    Substitua:

    • NEG_NAME: o nome do NEG que você está criando.
    • PROXY_INSTANCE_ZONE: a zona em que o servidor proxy está localizado.
    • PROXY_INSTANCE_VPC: a VPC que contém o servidor proxy.
    • PROXY_INSTANCE_SUBNET: a sub-rede em que o servidor proxy está localizado.

    Repita esta etapa para qualquer outra zona em que você implantará uma VM de servidor proxy.

  2. Adicione cada servidor proxy ao NEG na mesma zona:

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

    Substitua:

    • PROXY_INSTANCE_ZONE: a zona em que o servidor proxy está localizado.
    • NEG_NAME: o nome do NEG na mesma zona que o servidor proxy.
    • PROXY_INSTANCE_NAME: o nome do servidor proxy.

    Repita essa etapa até que cada VM do servidor proxy seja adicionada a um NEG como endpoint.

  3. Crie uma verificação de integridade regional que será usada pelo balanceador de carga interno. Use o comando 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

    Substitua:

    • PROTOCOL: o protocolo usado para a verificação de integridade. As opções válidas são grpc, http, https, http2, ssl, e tcp.
    • NAME: o nome da verificação de integridade. Em um determinado projeto, cada verificação de integridade global precisa ter um nome exclusivo. Já as verificações de integridade regionais precisam ter nomes exclusivos em uma determinada região.
    • REGION: todos os balanceadores de carga, exceto balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos regionais, usam verificações de integridade globais (--global). Os balanceadores de carga de aplicativo internos regionais usam verificações de integridade regionais que precisam ter a região correspondente à região do serviço de back-end.
    • DESCRIPTION: uma descrição opcional.
    • CHECK_INTERVAL: o tempo desde o início de uma integridade Verifique a conexão do sistema da sonda para iniciar a próxima. As unidades são informadas em segundos. Se omitido, o Google Cloud usará um valor de 5s (cinco segundos);
    • TIMEOUT: o tempo que o Google Cloud aguarda por uma resposta a uma sondagem. O valor de TIMEOUT precisa ser menor ou igual ao valor de CHECK_INTERVAL. As unidades são informadas em segundos. Se omitido, o Google Cloud usará um valor de 5s (cinco segundos).
    • HEALTHY_THRESHOLD e UNHEALTHY_THRESHOLD: especificam o número de sondagens sequenciais que precisam ser bem-sucedidas ou falhar para que a instância VM seja considerada íntegra ou não. Se omitidos, o Google Cloud usará um limite padrão de 2.
    • PORT_SPECIFICATION: define a especificação da porta usando uma das Sinalizações de especificação de porta.
    • ADDITIONAL_FLAGS: outras flags usadas para especificar portas e opções próprias de PROTOCOL. Consulte Sinalizações adicionais para verificações de integridade HTTP, HTTPS e HTTP/2 , Sinalizações adicionais para verificações de integridade de SSL e TCP ou Sinalização adicional para verificações de integridade do gRPC para criar um anexo da VLAN de monitoramento.

  4. Crie o serviço de back-end:

    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

    Substitua:

    • BS_NAME: o nome do balanceador de carga que você está criando.
    • PROXY_INSTANCES_REGION: a região onde os servidores proxy estão localizados.
    • HC_NAME: o nome da verificação de integridade regional que você criou.
    • HC_REGION: a região em que a verificação de integridade está localizada.

    Além disso:

    • A flag --session-affinity=CLIENT_IP direciona a solicitação de um cliente específico para a mesma VM de instância de proxy de back-end com base em um hash criado no endereço IP do cliente e no endereço de destino.
    • A flag --connection-persistence-on-unhealthy-backends=NEVER_PERSIST significa que as conexões não vão persistir em VMs de instâncias de proxy não íntegras.

  5. Adicione cada um dos NEGs ao serviço de back-end:

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

    Substitua:

    • BS_NAME: o nome do serviço de back-end que você criou.
    • BS_REGION: a região em que o serviço de back-end está localizado. Ela precisa ser a mesma em que os servidores proxy estão localizados.
    • NEG_NAME: o nome do NEG que você está adicionando.
    • NEG_ZONE: a zona em que o NEG está localizado.

    Repita essa etapa para o NEG adicional que você criou.

  6. Reserve um endereço IP interno na VPC dentro do intervalo de IP da sub-rede em que as instâncias do proxy estão conectadas. Esse será o endereço IP virtual (VIP) do balanceador de carga interno. Reservar o endereço garante que o IP não será usado por nenhum outro objeto. Para reservar o endereço IP interno, use o comando compute addresses create:

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

    Substitua:

    • ADDRESS_NAMES: Os nomes de um ou mais [--purpose=SHARED_LOADBALANCER_VIP] e os endereços que você quer criar. No caso de vários endereços, especifique todos como uma lista, separados por espaços. Por exemplo, example-address-1 example-address-2 example-address-3.
    • REGION: a região desta solicitação
    • SUBNETWORK: a sub-rede deste endereço IP interno
    • IP_ADDRESS: o endereço IP a ser reservado, que precisam estar no intervalo de IP primário da sub-rede. Se não for especificado, um endereço IP será alocado automaticamente pela sub-rede.

  7. Crie a regra de encaminhamento e associe-a ao serviço de back-end e ao 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

    Substitua:

    • FW_RULE_NAME: o nome da regra de encaminhamento que você está criando.
    • BS_REGION: a região em que o serviço de back-end está localizado
    • PROXY_INSTANCES_VPC_NAME: o nome da VPC em que as VMs do servidor proxy foram criadas
    • RESERVED_IP_ADDRESS_SUBNET: a sub-rede em que o VIP está localizado.
    • RESERVED_IP_ADDRESS: o endereço VIP do balanceador de carga
    • BS_NAME: o nome do serviço de back-end

    Além disso:

    • A flag --allow-global-access indica que o VIP do balanceador de carga pode ser acessado de qualquer região (não apenas da BS_REGION). Isso permite que os clientes em todas as regiões acessem a instância do Looker (Google Cloud Core).

Crie regras de firewall

Para que as verificações de integridade funcionem, crie regras de firewall de entrada aplicáveis à VM do proxy que está com a carga balanceada para permitir o tráfego dos intervalos de IP da sondagem da verificação de integridade.

Além disso, crie uma regra de firewall de entrada para permitir que o tráfego de ambientes locais ou multi-cloud acesse o serviço de back-end do balanceador de carga.

Atualizar o registro A do DNS

Mude o registro A do domínio personalizado do Looker (Google Cloud Core) para apontar para o VIP do balanceador de carga. A zona particular do Cloud DNS que você criou gerencia o domínio personalizado e é usada pela VPC onde as instâncias de proxy estão localizadas.

Atualizar as credenciais do OAuth

  1. Acesse seu cliente OAuth navegando até APIs e serviços > Credenciais no console do Google Cloud e selecionando o ID do cliente OAuth usado pela sua instância do Looker (núcleo do Google Cloud).

  2. Clique no botão Adicionar URI para atualizar o campo Origens JavaScript autorizadas no cliente OAuth e incluir o mesmo nome DNS que a organização vai usar para acessar o Looker (Google Cloud Core). Portanto, se o domínio personalizado for looker.examplepetstore.com, insira looker.examplepetstore.com como URI.

  3. Atualize ou adicione o domínio personalizado à lista de URIs de redirecionamento autorizados para as credenciais do OAuth usadas ao criar a instância do Looker (Google Cloud Core). Adicione /oauth2callback ao final do URI. Portanto, se o domínio personalizado for looker.examplepetstore.com, insira looker.examplepetstore.com/oauth2callback.

Como adicionar usuários

Depois que as etapas anteriores forem concluídas, o URL do domínio personalizado vai ficar acessível aos usuários.

Verifique se o método de autenticação do usuário está totalmente configurado para a instância do Looker (Google Cloud Core) antes de adicionar usuários.

Solução de problemas

  • Se você estiver usando o Chrome para acessar o domínio personalizado do Looker (Google Cloud Core) e receber um erro do Chrome, como NET::ERR_CERT_COMMON_NAME_INVALID ou um erro de política HSTS, siga estas etapas para corrigir o problema:

    1. Abrir chrome://net-internals/#hsts
    2. Insira o domínio personalizado para consultar o conjunto de HSTS/PKP. Todas as políticas para o domínio personalizado aparecerão em Encontrados:.
    3. Em Excluir políticas de segurança de domínio, insira o domínio personalizado no campo Domínio.
    4. Clique em Excluir para remover as políticas.

  • Para resolver problemas de erros de certificado, consulte a página de documentação Solução de problemas de certificados SSL. Para certificados gerenciados pelo Google, autorize explicitamente a autoridade certificadora que você quer autorizar a emitir o certificado gerenciado pelo Google.

A seguir