Acessar uma instância do Looker (Google Cloud Core) usando o acesso a serviços particulares

Nesta página de documentação, descrevemos 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, siga estas etapas:

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

Configurar um domínio personalizado

Depois que a 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 poder atualizá-los.

Funções exigidas

Para receber 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ê o papel do IAM de Administrador do Looker (roles/looker.admin) no projeto em que a instância está localizada. 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 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 de até 64 caracteres para o domínio da Web que você quer usar. Por exemplo: looker.examplepetstore.com.

  5. Clique em CONCLUÍDO no painel Adicionar um novo domínio personalizado para voltar à guia DOMÍNIO PERSONALIZADO.

Depois que o domínio personalizado é configurado, ele aparece na coluna Domínio da guia DOMÍNIO PERSONALIZADO na página de detalhes da instância do Looker (Google Cloud Core) no console Google Cloud .

Depois que seu domínio personalizado for criado, você poderá ver informações sobre ele ou excluí-lo.

Acessar o domínio personalizado

Quando o tráfego para uma instância do Looker (Google Cloud Core) somente com IP particular se origina de uma região diferente da instância, é possível usar um ou mais servidores 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ê os 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 NGINX ou Apache, com um balanceador de carga, para rotear o tráfego de qualquer região ou de um ambiente 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 (Google Cloud Core) usando o Cloud Router, um balanceador de carga interno e o acesso a serviços particulares.

Criar VMs, uma zona particular e um registro A

Conclua as etapas nas seções a seguir.

Criar VMs

Crie duas instâncias de VM somente com IP particular e um sistema operacional RHEL. As VMs vão atuar como servidores proxy. Elas precisam estar na mesma região da instância do Looker (Google Cloud Core), mas em zonas diferentes.

Criar uma zona particular

Crie uma zona particular do Cloud DNS visível para a VPC em que a instância do Looker (Google Cloud Core) está localizada. A zona privada do Cloud DNS será usada pela VPC e pelos hosts locais para a resolução de DNS alcançar a UI do Looker (Google Cloud Core). O nome da zona precisa corresponder ao domínio personalizado.

  gcloud dns managed-zones create NAME \
  --description=DESCRIPTION \
  --dns-name=DNS_SUFFIX \
  --networks=VPC_NETWORK_LIST \
  --labels=LABELS \
  --visibility=private

Substitua:

  • NAME: um nome para a zona.
  • DESCRIPTION: uma descrição para a zona.

  • DNS_SUFFIX: o sufixo DNS da zona, como examplepetstore.com.

  • VPC_NETWORK_LIST: uma lista delimitada por vírgulas de redes VPC que estão autorizadas a consultar a zona. Inclua a VPC que contém sua instância do Looker (Google Cloud Core).

  • LABELS: uma lista opcional de pares de chave-valor, como dept=marketing ou project=project1. Para mais informações, consulte a documentação do SDK.

Depois que a zona é configurada, se você navegar até ela na página Zonas do Cloud DNS do console do Google Cloud , vai notar que ela é particular, tem o nome do domínio personalizado e tem conjuntos de registros para ele.

Adicionar o registro A do Cloud DNS

Siga estas etapas para adicionar o registro A do Cloud DNS:

  1. Como você vai usar um balanceador de carga, o registro A na zona privada do Cloud DNS será mapeado para o endereço IP do balanceador de carga.

    O IP privado de entrada destacado na guia "Detalhes" da página "Instâncias".

  2. Adicione um registro A de DNS para o domínio personalizado na zona particular, que consiste no endereço IP de entrada da instância do Looker (Google Cloud Core). O registro A usa o nome de domínio totalmente qualificado (FQDN), o mesmo que você configurou como o domínio personalizado do Looker (Google Cloud Core).

    A configuração completa vai mostrar o registro A do domínio personalizado quando você visualizar os detalhes da zona particular na página Zonas do Cloud DNS do console do Google Cloud .

    Para disponibilizar os serviços de resolução de nomes de uma rede VPC para redes locais conectadas a ela usando túneis do Cloud VPN, anexos de VLAN do Cloud Interconnect ou dispositivos roteadores, use uma política de servidor de entrada.

    Depois que os registros DNS do seu domínio forem atualizados e o domínio for verificado no console do Google Cloud, o status do domínio personalizado mapeado para a instância será atualizado de Não verificado para Disponível na guia Domínio personalizado da página Instâncias.

Configurar os servidores 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 ver exemplos de como configurar servidores de proxy reverso usando NGINX ou Apache:

NGINX

O exemplo a seguir usa a versão 1.22.1 do NGINX e a versão 8.9 (Ootpa) do Red Hat Enterprise Linux. Para verificar quais versões do NGNIX e do 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 a:

    nginx version: nginx/1.22.1

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

    sudo rpm -qi nginx | grep Release

    Isso vai retornar algo semelhante a:

    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 criadas.

  1. Conecte-se à VM.

  2. Edite o arquivo /etc/nginx/nginx.conf para incluir 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ê precisar que o proxy também escute no endereço IPv6 particular, remova o comentário da linha listen [::]:443 ssl no arquivo.
    • O nível de registro de acesso está definido como debug. Ajuste-o ao nível usado no 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á apresentado pelo proxy aos clientes que tentarem acessar o Looker (Google Cloud Core). A autoridade de certificação (CA) usada para assinar o certificado precisa ser confiável para seus clientes. Também é possível usar uma CA particular interna para assinar esse certificado TLS. Como alternativa, também é possível usar um certificado SSL autogerenciado.

    Neste exemplo, vamos presumir que o certificado já foi criado usando o serviço gratuito Let's Encrypt, sem configurar a renovação automática pelo 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 sua instalação, crie-os ou use outras pastas.

  4. Para garantir que o NGINX escolha 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 se 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. Opcionalmente, crie o arquivo ssl-params.conf do NGINX, 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 do SELinux httpd_can_network_connect como 1:

    sudo setsebool -P httpd_can_network_connect 1

  9. Agora você pode 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

    Ele vai retornar uma saída 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 o Red Hat Enterprise Linux versão 7.9. Para verificar quais versões do Red Hat suas VMs estão usando, execute o seguinte comando:

    cat /etc/redhat-release

    Isso vai retornar o seguinte:

    Red Hat Enterprise Linux Server release 7.9 (Maipo)

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

    sudo httpd -version

    Isso vai retornar o seguinte:

    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

    Isso vai retornar 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 a ele:

    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 particular 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, use o seguinte comando:

    sudo yum install mod_ssl

    Depois que mod_ssl for instalado, adicione a seguinte linha ao arquivo de configuração do Apache, /etc/httpd/conf/httpd.conf, para ativar:

    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 a seguir para permitir que a VM de proxy do 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 reescrita está carregado e pronto no Apache usando este comando:

    sudo httpd -M | grep rewrite

    Ele vai retornar uma saída semelhante a esta:

    rewrite_module (shared)

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

    sudo systemctl restart httpd

  14. Verifique se o processo do Apache foi reiniciado corretamente usando o seguinte comando: 

    sudo systemctl status httpd

    Ele vai retornar uma saída semelhante a esta:

    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 (NEGs) zonais com endpoints GCE_VM_IP como back-ends do balanceador de carga de rede de passagem interna. Se preferir usar back-ends baseados em grupos de instâncias, siga a documentação disponível 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 zonal separado para cada zona do Compute 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 zonais. Consulte a página de documentação Cotas e limites para verificar quantos endpoints são compatíveis por NEG zonal.

    Para criar um NEG zonal, 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 essa etapa para cada zona em que você vai 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 do 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 um 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, e 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 período entre o início da conexão de um sistema de sondagem de verificação de integridade e o início da próxima. As unidades são informadas em segundos. Se omitido, Google Cloud usará um valor de 5s (5 segundos).
    • TIMEOUT: o tempo que o Google Cloud aguarda 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, oGoogle Cloud usará um valor de 5s (5 segundos).
    • HEALTHY_THRESHOLD e UNHEALTHY_THRESHOLD: especificam o número sequencial de sondagens que precisam ser bem-sucedidas ou não para que a instância VM seja considerada íntegra ou não. Se omitidos, 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 para especificar portas e opções específicas do 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 em que 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ância 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. Precisa ser a mesma região 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 os outros NEGs criados.

  6. Reserve um endereço IP interno na VPC dentro do intervalo de IP da sub-rede em que as instâncias de 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 endereços [--purpose=SHARED_LOADBALANCER_VIP] 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 precisa estar no intervalo de IP principal 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 clientes em todas as regiões alcancem 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 de proxy com balanceamento de carga para permitir o tráfego de intervalos de IP de sondagem de verificação de integridade.

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

Atualizar o registro DNS A

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

Atualizar as credenciais do OAuth

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

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

  3. Atualize ou adicione o domínio personalizado à lista de URIs de redirecionamento autorizados para as credenciais OAuth usadas ao criar a instância do Looker (Google Cloud Core). Adicione /oauth2callback ao final do URI. Por exemplo, 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 a ela.

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 HSTS/PKP. Todas as políticas do domínio personalizado vão aparecer em Encontrado:.
    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 certificados, consulte a página de documentação Solução de problemas de certificados SSL. Para certificados gerenciados pelo Google, autorize explicitamente a autoridade de certificação que você quer permitir para emitir seu certificado gerenciado pelo Google.

A seguir