Acessar uma instância do Looker (Google Cloud Core) usando o acesso a serviços particulares: 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, siga estas etapas:

  1. Configure o domínio personalizado.
  2. Crie VMs e uma zona particular.
  3. Configure os servidores de proxy reverso.
  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 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 instância do Looker (Google Cloud Core), identifique onde os registros DNS do domínio estão armazenados para que você possa 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 Administrador do Looker (roles/looker.admin) papel do IAM no projeto em que a instância está. 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 (núcleo do Google Cloud):

  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 DONE no painel Add a new custom domain para retornar à guia CUSTOM DOMAIN.

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

Depois que o domínio personalizado for criado, você poderá acessar informações ou excluí-lo.

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 privado, peça ao administrador para conceder a você os seguintes papéis do IAM no projeto em que a instância está:

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 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, uma zona particular e um registro A

Siga as etapas nas seções a seguir.

Criar VMs

Crie duas instâncias de VM somente com 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.

Criar uma zona particular

Crie uma zona particular do Cloud DNS que seja 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 acesse a interface do Looker (núcleo do Google Cloud). 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 da 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 (núcleo do Google Cloud).

  • 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 for 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 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 particular 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 do 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 (núcleo do Google Cloud).

    A configuração completa vai mostrar o registro A do domínio personalizado quando você consultar 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 à rede VPC usando túneis do Cloud VPN, anexos da VLAN do Cloud Interconnect ou dispositivos roteadores, use uma política de servidor de entrada.

    Depois que os registros DNS do 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 vai mudar de Não verificado para Disponível na guia Domínio personalizado da página Instâncias.

Configurar os servidores proxy reversos

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 a versão 1.22.1 do NGINX e a versão 8.9 (Ootpa) do Red Hat Enterprise Linux. Para verificar as versões do Nginx e do Red Hat usadas pelas VMs, execute os comandos abaixo 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 está em execução na VM, execute o seguinte: 

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

  1. Conecte-se à VM.

  2. Edite o arquivo /etc/nginx/nginx.conf para que ele contenha 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 ouça no endereço IPv6 particular, remova a marca de comentário da linha listen [::]:443 ssl no arquivo.
    • O nível do registro de acesso está definido como debug. Ajuste-o para o 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 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. Você também pode usar um certificado SSL autogerenciado.

    Neste exemplo, suponhamos que o certificado já tenha sido 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 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. Opcionalmente, crie o arquivo ssl-params.conf do NGINX, que pode ser usado para armazenar parâmetros que podem ser reutilizados em futuras configurações 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 você pode reiniciar o processo 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 a versão 7.9 do Red Hat Enterprise Linux. Para verificar quais versões do Red Hat estão sendo usadas nas VMs, execute o seguinte comando:

    cat /etc/redhat-release

    Isso deve 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 para cada VM:

    sudo httpd -version

    Isso deve 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 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 o mod_ssl for instalado, você precisará ativá-lo 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 a seguir para permitir que a VM do proxy Apache encaminhe o tráfego para o Looker (núcleo do Google Cloud):

    /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 detectadas:

    sudo systemctl restart httpd

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

    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. Se você 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 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 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 qualquer outra 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. 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 decorrido 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 usa um valor de 5s (5 segundos).
    • TIMEOUT: o tempo que Google Cloud espera por uma resposta a uma sondagem. O valor de TIMEOUT precisa ser menor ou igual ao CHECK_INTERVAL. As unidades são informadas em segundos. Se omitido, Google Cloud usa um valor de 5s (cinco segundos).
    • HEALTHY_THRESHOLD e UNHEALTHY_THRESHOLD: especificam o número de sondagens sequenciais que precisam ser bem-sucedidas ou não para que a instância VM seja considerada íntegra ou não. Se um deles for omitido, 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 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â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 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 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 proxy com balanceamento de carga para permitir o tráfego dos intervalos de IP da 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 multinuvem 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 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 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 seu cliente OAuth e incluir o mesmo nome de DNS que sua organização vai usar para acessar o Looker (núcleo do Google Cloud). Portanto, 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 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 estar 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 à instância.

Solução de problemas

  • Se você estiver usando o Chrome para acessar o domínio personalizado do Looker (núcleo do Google Cloud) 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 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 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 de certificação que você quer permitir para emitir o certificado gerenciado pelo Google.

A seguir