Esta é a documentação do Looker. Para conferir a documentação do Looker Studio, acesse https://support.google.com/looker-studio.

Esta página foi traduzida pela API Cloud Translation.

Configurar um domínio personalizado para uma instância de IP privado do Looker (Google Cloud Core): tráfego proveniente de diferentes regiões

É possível exibir sua instância do Looker (Google Cloud Core) usando um domínio da Web personalizado em vez do domínio padrão fornecido pelo Looker (Google Cloud Core).

Esta página de documentação descreve como configurar e acessar um domínio personalizado para instâncias que atendem a estes dois critérios:

A instância é apenas IP particular.
O tráfego para a instância tem origem em regiões diferentes daquela em que a instância está localizada ou por meio de uma rede híbrida.

Para implementar um domínio personalizado para esse tipo de instância, execute as seguintes etapas:

Configurar o domínio personalizado.
Crie VMs e uma zona particular.
Configure os servidores proxy reversos.
Crie e configure o balanceador de carga.
Crie regras de firewall.
Atualize o registro A do DNS.
Atualize as credenciais do OAuth.

Configurar um domínio personalizado

Depois de criar a instância do Looker (Google Cloud Core), configure 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ê o papel do IAM Administrador do Looker (roles/looker.admin) no projeto em que a instância reside. Para mais informações sobre como conceder papéis, consulte Gerenciar acesso.

Também é possível receber as permissões necessárias com papéis personalizados ou 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):

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

O painel Adicionar um novo domínio personalizado será aberto.
Usando apenas letras, números e hifens, insira o nome do host com até 64 caracteres para o domínio da Web que você quer usar, por exemplo: looker.examplepetstore.com.
Clique em CONCLUÍDO no painel Adicionar um novo domínio personalizado para retornar à guia DOMÍNIO PERSONALIZADO.

A coluna URL da instância na página Instâncias do console do Google Cloud vai mostrar o domínio personalizado.

Após a criação do domínio personalizado, é possível 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 privado se origina de uma região diferente da instância, é possível usar um ou mais servidores proxy reversos 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:

Administrador do Looker (roles/looker.admin)
Administrador da instância do Compute (v1) (roles/compute.instanceAdmin.v1)
Administrador do DNS (roles/dns.admin)
Administrador do balanceador de carga do Compute (roles/compute.loadBalancerAdmin)
Administrador de rede do Compute (roles/compute.networkAdmin)
Administrador de segurança do Compute (roles/compute.securityAdmin)
Use o Google OAuth: Editor de configuração do OAuth (roles/oauthconfig.editor)

Para mais informações sobre como conceder papéis, consulte Gerenciar acesso.

Também é possível receber as permissões necessárias com papéis personalizados ou 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 (Google Cloud Core) usando o Cloud Router, um balanceador de carga interno e o Acesso privado a serviços.

criar VMs e uma zona particular

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 que a instância do Looker (Google Cloud Core), mas em zonas diferentes.
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 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 ver exemplos de como configurar servidores de proxy reverso usando NGINX ou 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.

Primeiro, conecte-se à VM.
Instale o NGINX usando o seguinte comando:
```
sudo yum install nginx -y
```
Para encontrar a versão do NGINX que a VM está executando, execute o seguinte comando:
```
sudo nginx -v
```
Isso deve retornar algo semelhante ao seguinte:

nginx version: nginx/1.22.1
Para verificar qual versão do NGINX a VM está executando, execute o seguinte comando:
```
sudo rpm -qi nginx | grep Release
```
Isso deve retornar algo semelhante ao seguinte:

Release : 1.module+el8.8.0+20355+6d9c8a63.1
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.

Conecte-se à VM.

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 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 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 será referenciado posteriormente nestas etapas, remova a marca de comentário de include snippets/ssl-params.conf.

Crie um certificado TLS válido que faça referência ao URL de domínio personalizado do Looker (Google Cloud Core). O proxy apresenta esse certificado aos clientes que estão tentando acessar o Looker (Google Cloud Core). Os clientes precisam confiar na autoridade de certificação (CA, na sigla em inglês) usada para assinar o certificado. Você também pode usar uma AC privada interna para assinar esse 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 sua instalação, será possível criá-los ou usar outras pastas.
Para garantir que o NGINX colete os arquivos de certificado, crie o diretório /etc/nginx/snippets:
```
sudo mkdir /etc/nginx/snippets
```
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.

Observação: se você salvou os arquivos de certificado em um caminho diferente, verifique se o caminho está refletido no arquivo de configuração /etc/nginx/snippets/self-signed.conf.
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
```
A consulta retornará os caminhos de arquivo que você adicionou.

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

Para configurar o SELinux e permitir que o NGINX encaminhe 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
```
Agora é possível reiniciar o processo do NGINX usando o seguinte comando:
```
sudo systemctl restart nginx
```

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.

Primeiro, conecte-se à VM.
Instale o Apache:
```
sudo yum install httpd -y
```
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
```
A seguinte resposta será retornada:

Red Hat Enterprise Linux Server release 7.9 (Maipo)
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 uma delas:
```
sudo httpd -version
```
A seguinte resposta será retornada:
```
Server version: Apache/2.4.6 (Red Hat Enterprise Linux)
Server built:   date
```

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.

Crie o arquivo de configuração /etc/httpd/conf.d/ssl.conf na VM do 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 instância do Looker (Google Cloud Core).
private IP of Looker (Google Cloud core): o IP privado da instância do Looker (Google Cloud Core).

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"

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
```
No arquivo de configuração do Apache, /etc/httpd/conf/httpd.conf, substitua Listen 80 por Listen 443.
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
```
Por fim, reinicie o Apache para aplicar as mudanças:
```
sudo systemctl restart httpd
```
Verifique se o módulo de regravação está carregado e pronto no Apache usando este comando:
```
sudo httpd -M | grep rewrite
```
A saída será semelhante a esta:
rewrite_module (shared)
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
```

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

sudo systemctl status httpd

A saída será 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

Neste exemplo, usamos grupos de endpoints de rede (NEGs) zonais com endpoints GCE_VM_IP como back-ends do balanceador de carga de rede de passagem interna. Caso você 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.

Criar 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 onde 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 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.
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.
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: tempo total 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, o Google Cloud usará um valor de 5s (cinco segundos);
- TIMEOUT: o tempo que o Google Cloud aguarda a resposta de 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 não para que a instância de 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 sinalizações 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.
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 sinalização --session-affinity=CLIENT_IP direciona a solicitação de um cliente específico para a mesma VM da 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.
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, que 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.
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 vai 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 dentro do intervalo de IP principal da sub-rede. Se não for especificado, um endereço IP será alocado automaticamente pela sub-rede.
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 de BS_REGION. Isso permite que os clientes de 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 de várias nuvens tenha acesso ao serviço de back-end do balanceador de carga.

Atualizar o registro A do DNS

Alterar 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 do proxy estão localizadas.

Atualizar as credenciais do OAuth

No console do Google Cloud, acesse APIs e serviços > Credenciais no console do Google Cloud e selecione o ID do cliente OAuth usado pela sua instância do Looker (Google Cloud Core).
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.
Atualize ou adicione o domínio personalizado à lista de URIs de redirecionamento autorizados das 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.

Adicionar usuários

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

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

Resolver erros de política de HSTS

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 de HSTS, faça o seguinte:

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

Configurar um domínio personalizado para uma instância de IP privado do Looker (Google Cloud Core): tráfego proveniente de diferentes regiões

Configurar um domínio personalizado

Antes de começar

Funções exigidas

Criar um domínio personalizado

Acessar o domínio personalizado

Antes de começar

Visão geral da rede

criar VMs e uma zona particular

Configurar os servidores proxy reversos

NGINX

Apache

Criar e configurar o balanceador de carga

Crie regras de firewall

Atualizar o registro A do DNS

Atualizar as credenciais do OAuth

Adicionar usuários

Resolver erros de política de HSTS

A seguir