Aceda a uma instância do Looker (Google Cloud core) através do acesso a serviços privados

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

Para aceder a este tipo de instância, siga estes passos:

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

Configure um domínio personalizado

Depois de criar a instância do Looker (Google Cloud core), pode configurar um domínio personalizado.

Antes de começar

Antes de poder personalizar o domínio da sua instância do Looker (Google Cloud core), identifique onde os registos de DNS do seu domínio estão armazenados para que os possa atualizar.

Funções necessárias

Para receber as autorizações de que precisa para criar um domínio personalizado para uma instância do Looker (Google Cloud core), peça ao seu administrador para lhe conceder a função de IAM administrador do Looker (roles/looker.admin) no projeto em que a instância reside. Para mais informações sobre a atribuição de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

Também pode conseguir as autorizações necessárias através de funções personalizadas ou outras funções predefinidas.

Crie um domínio personalizado

Na Google Cloud consola, siga estes passos 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 para a qual quer configurar um domínio personalizado.
  2. Clique no separador DOMÍNIO PERSONALIZADO.

  3. Clique em ADICIONAR UM DOMÍNIO PERSONALIZADO.

    É apresentado o painel Adicionar um novo domínio personalizado.

  4. Usando apenas letras, números e travessões, introduza o nome do anfitrião de até 64 carateres para o domínio Web que quer usar, por exemplo: looker.examplepetstore.com.

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

Depois de configurar o domínio personalizado, este é apresentado na coluna Domínio no separador DOMÍNIO PERSONALIZADO da página de detalhes da instância do Looker (Google Cloud core) na Google Cloud consola.

Depois de criar o domínio personalizado, pode ver informações sobre o mesmo ou eliminá-lo.

Aceda ao domínio personalizado

Quando o tráfego para uma instância do Looker (Google Cloud core) apenas de IP privado tem origem numa região diferente da instância, pode usar um ou mais servidores proxy inverso de IP privado e um equilibrador de carga para fornecer acesso seguro à instância.

Antes de começar

Para receber as autorizações de que precisa para configurar o acesso a um domínio personalizado de IP privado, peça ao seu administrador para lhe conceder as seguintes funções de IAM no projeto em que a instância reside:

Para mais informações sobre a atribuição de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

Também pode conseguir as autorizações necessárias através de funções personalizadas ou outras funções predefinidas.

Vista geral das redes

As secções seguintes mostram como criar uma configuração de servidor proxy NGINX ou Apache redundante, com um balanceador de carga, para encaminhar o tráfego de qualquer região ou de instalações para o domínio personalizado. O diagrama seguinte representa esta topologia:

Uma rede do Google Cloud que mostra o acesso seguro a uma instância do Looker (Google Cloud core) através do Cloud Router, de um equilibrador de carga interno e do acesso a serviços privados.

Crie VMs, uma zona privada e um registo A

Conclua os passos nas secções seguintes.

Crie VMs

Crie duas instâncias de VM apenas com IP privado com um sistema operativo RHEL. As VMs atuam como os seus servidores proxy. Devem estar localizados na mesma região que a instância do Looker (essencial para o Google Cloud), mas em zonas diferentes entre si.

Crie uma zona privada

Crie uma zona privada do Cloud DNS visível para a VPC na qual a instância do Looker (Google Cloud core) está localizada. A zona privada do Cloud DNS é usada pela VPC e pelos anfitriões no local para a resolução de DNS para alcançar a IU do Looker (Google Cloud core). O nome da zona deve 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 o seguinte:

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

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

  • VPC_NETWORK_LIST: uma lista delimitada por vírgulas de redes VPC autorizadas a consultar a zona. Certifique-se de que inclui a VPC que contém a sua instância do Looker (Google Cloud core).

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

Assim que a zona estiver configurada, se navegar para a zona na página Zonas de DNS na nuvem da consola Google Cloud , pode ver que é privada, tem o nome do domínio personalizado e tem conjuntos de registos para o domínio personalizado.

Adicione o registo A do Cloud DNS

Conclua os passos seguintes para adicionar o registo A do Cloud DNS:

  1. Uma vez que vai usar um equilibrador de carga, o registo A na zona privada do Cloud DNS vai ser mapeado para o endereço IP do equilibrador de carga.

    O IP privado de entrada realçado no separador Detalhes da página Instâncias.

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

    A configuração completa deve mostrar o registo A do domínio personalizado quando vir os detalhes da zona privada na página Zonas do Cloud DNS da Google Cloud consola.

    Para disponibilizar os serviços de resolução de nomes de uma rede VPC a redes no local que estejam ligadas à rede VPC através de túneis do Cloud VPN, anexos de VLAN do Cloud Interconnect ou dispositivos de router, pode usar uma política de servidor de entrada.

    Assim que os registos DNS do seu domínio forem atualizados e o domínio for validado na Google Cloud Console, o estado do domínio personalizado mapeado para a instância é atualizado de Não validado para Disponível no separador Domínio personalizado da página Instâncias.

Configure os servidores proxy reverse

Pode usar qualquer servidor Web que possa ser configurado como um servidor proxy inverso. Selecione uma das seguintes opções para ver exemplos de como configurar servidores proxy inverso com o NGINX ou o Apache:

NGINX

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

  1. Primeiro, estabeleça ligação à VM.

  2. Instale o NGINX com o seguinte comando:

    sudo yum install nginx -y

  3. Para encontrar a versão do NGINX que a VM está a executar, execute o seguinte comando: 

    sudo nginx -v

    Isto deve devolver algo semelhante ao seguinte:

    nginx version: nginx/1.22.1

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

    sudo rpm -qi nginx | grep Release

    Isto deve devolver algo semelhante ao seguinte:

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

  5. Para verificar que versão do Red Hat as suas VMs estão a usar, execute o seguinte comando:

    sudo cat /etc/redhat-release

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

  1. Estabeleça ligação à VM.

  2. Edite o ficheiro /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 o seguinte:

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

    Além disso, considere o seguinte:

    • Esta é uma configuração apenas IPv4. Se precisar que o proxy também escute no respetivo endereço IPv6 privado, descomente a linha listen [::]:443 ssl no ficheiro.
    • O nível de registo de acesso está definido como debug. Certifique-se de que o ajusta ao nível usado no seu ambiente específico.
    • Se implementar o ficheiro ssl-params.conf, que é referenciado mais tarde nestes passos, 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). Este certificado é o que o proxy apresenta aos clientes que estão a tentar aceder ao Looker (Google Cloud core). A autoridade de certificação (AC) usada para assinar o certificado tem de ser fidedigna para os seus clientes. Também pode usar uma AC privada interna para assinar este certificado TLS. (Em alternativa, também pode usar um certificado SSL autogerido.)

    Neste exemplo, vamos assumir que o certificado já foi criado através do serviço gratuito Let's Encrypt, sem configurar a renovação automática através do Certbot. Depois de criar o certificado, guarde os ficheiros 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 seu domínio personalizado.

    Se os diretórios certs e private não existirem na sua instalação, pode criá-los ou usar outras pastas.

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

    sudo mkdir /etc/nginx/snippets

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

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

    Edite o ficheiro de configuração para adicionar os caminhos aos ficheiros de certificado que guardou:

    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 seu domínio personalizado.

  6. Para confirmar que o ficheiro de configuração contém a referência aos ficheiros mencionados no passo anterior, execute o seguinte comando: 

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

    Deve devolver os caminhos dos ficheiros que adicionou.

  7. Opcionalmente, crie o ficheiro ssl-params.confNGINX, que pode ser usado para armazenar parâmetros que podem ser reutilizados em configurações futuras do NGINX.

    Como referência, o conteúdo do ficheiro deve ter um aspeto 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 de modo a 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, pode reiniciar o processo do NGINX através do seguinte comando:

    sudo systemctl restart nginx

  10. Verifique se o NGINX foi reiniciado corretamente através do seguinte comando:

    sudo systemctl status nginx

    Deve ser apresentado um resultado semelhante ao seguinte:

    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 estes passos para cada MV.

  1. Primeiro, estabeleça ligação à VM.

  2. Instale o Apache:

    sudo yum install httpd -y

  3. O exemplo seguinte usa o lançamento 7.9 do Red Hat Enterprise Linux. Para verificar que versões do Red Hat as suas VMs estão a usar, execute o seguinte comando:

    cat /etc/redhat-release

    Isto deve devolver o seguinte:

    Red Hat Enterprise Linux Server release 7.9 (Maipo)

  4. O exemplo seguinte usa a versão 2.4.6 do Apache. Para verificar que versões do Apache as suas VMs estão a usar, execute os seguintes comandos para cada VM:

    sudo httpd -version

    Isto deve devolver 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

    Deve ser apresentado um resultado semelhante ao seguinte:

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

    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 o seguinte:

    • 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 que os ficheiros de certificado TLS estão disponíveis nos diretórios referenciados no ficheiro /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 o mod_ssl não estiver instalado, instale-o com o seguinte comando:

    sudo yum install mod_ssl

    Depois de instalar o mod_ssl, tem de o ativar adicionando a seguinte linha ao ficheiro de configuração do Apache, /etc/httpd/conf/httpd.conf:

    LoadModule ssl_module modules/mod_ssl.so

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

  10. Execute o seguinte comando 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 alterações:

    sudo systemctl restart httpd

  12. Verifique se o módulo de reescrita está carregado e pronto no Apache através deste comando:

    sudo httpd -M | grep rewrite

    Deve ser apresentado um resultado semelhante ao seguinte:

    rewrite_module (shared)

  13. Por fim, inicie ou reinicie o processo do Apache para se certificar de que todas as alterações de configuração são detetadas:

    sudo systemctl restart httpd

  14. Verifique se o processo do Apache foi reiniciado corretamente através do seguinte comando: 

    sudo systemctl status httpd

    Deve ser apresentado um resultado semelhante ao seguinte:

    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.

Crie e configure o balanceador de carga

Estes exemplos usam grupos de pontos finais de rede (NEGs) zonais com GCE_VM_IPpontos finais como back-ends do balanceador de carga de passagem interno. Se preferir usar back-ends baseados em grupos de instâncias, siga a documentação disponível na página de documentação Configure um Network Load Balancer de passagem interno com back-ends de grupos de instâncias de VMs.

  1. Crie um NEG zonal separado para cada zona de computação onde planeia implementar servidores proxy. Por exemplo, se quiser implementar servidores proxy em cada uma das três zonas de computação da região onde o Looker (Google Cloud core) está implementado, crie três NEGs zonais. Consulte a página de documentação Quotas e limites para verificar quantos pontos finais são suportados 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 o seguinte:

    • NEG_NAME: o nome do NEG que está a criar.
    • 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 na qual o servidor proxy está localizado.

    Repita este passo para qualquer zona adicional onde vai implementar 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 o seguinte:

    • 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 este passo até que cada VM do servidor proxy seja adicionada a um NEG como um ponto final.

  3. Crie uma verificação de funcionamento regional que vai 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 o seguinte:

    • PROTOCOL: o protocolo usado para a verificação do estado. As opções válidas são grpc, http, https, http2, ssl e tcp.
    • NAME: o nome da verificação de funcionamento. Num determinado projeto, cada verificação de estado global tem de ter um nome exclusivo e as verificações de estado regionais têm de ter nomes exclusivos numa determinada região.
    • REGION: Todos os balanceadores de carga, exceto os balanceadores de carga de aplicações externos regionais e os balanceadores de carga de aplicações internos regionais, usam verificações de funcionamento globais (--global). Os balanceadores de carga de aplicações internos regionais usam verificações de funcionamento regionais cuja região tem de corresponder à região do serviço de back-end.
    • DESCRIPTION: uma descrição opcional.
    • CHECK_INTERVAL: o período desde o início da ligação de um sistema de sonda de verificação de saúde até ao início do seguinte. As unidades são segundos. Se for omitido,o 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 tem de ser inferior ou igual a CHECK_INTERVAL. As unidades são segundos. Se for omitido, Google Cloud usa um valor de 5s (5 segundos).
    • HEALTHY_THRESHOLD e UNHEALTHY_THRESHOLD: especifique o número de sondagens sequenciais que têm de ser bem-sucedidas ou falhar para que a instância de VM seja considerada em bom ou mau estado. Se qualquer um for omitido, oGoogle Cloud usa um limite predefinido de 2.
    • PORT_SPECIFICATION: Define a especificação da porta através de uma das flags de especificação da porta.
    • ADDITIONAL_FLAGS: Outras flags para especificar portas e opções específicas do PROTOCOL. Consulte Flags adicionais para verificações de estado de HTTP, HTTPS e HTTP/2, Flags adicionais para verificações de estado de SSL e TCP ou Flag adicional para verificações de estado de gRPC.

  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 o seguinte:

    • BS_NAME: o nome do balanceador de carga que está a criar.
    • PROXY_INSTANCES_REGION: a região em que os servidores proxy estão localizados.
    • HC_NAME: o nome da verificação de saúde regional que criou.
    • HC_REGION: a região onde se encontra a verificação de funcionamento.

    Além disso:

    • A flag --session-affinity=CLIENT_IP direciona o pedido de um cliente específico para a mesma VM de instância de proxy de back-end, com base num 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 ligações não persistem 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 o seguinte:

    • BS_NAME: o nome do serviço de back-end que criou.
    • BS_REGION: a região onde o serviço de back-end está localizado. Esta deve ser a mesma região onde os servidores proxy estão localizados.
    • NEG_NAME: o nome do NEG que está a adicionar.
    • NEG_ZONE: a zona em que o NEG está localizado.

    Repita este passo para o NEG adicional que criou.

  6. Reserve um endereço IP interno na VPC dentro do intervalo de IP da sub-rede onde as instâncias de proxy estão ligadas. Esta será a morada IP virtual (VIP) do balanceador de carga interno. A reserva do endereço garante que o IP não é 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 o seguinte:

    • ADDRESS_NAMES: Os nomes de um ou mais [--purpose=SHARED_LOADBALANCER_VIP] endereços que quer criar. No caso de vários endereços, especifique todos os endereços como uma lista, separados por espaços. Por exemplo, example-address-1 example-address-2 example-address-3
    • REGION: a região deste pedido.
    • SUBNETWORK: A sub-rede para este endereço IP interno.
    • IP_ADDRESS: O endereço IP a reservar, que tem de estar dentro do intervalo de IP principal da sub-rede. Se não for especificado, é automaticamente atribuído um endereço IP da 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 o seguinte:

    • FW_RULE_NAME: o nome da regra de encaminhamento que está a criar.
    • BS_REGION: a região onde o serviço de back-end está localizado
    • PROXY_INSTANCES_VPC_NAME: o nome da VPC na qual as VMs do servidor proxy foram criadas
    • RESERVED_IP_ADDRESS_SUBNET: a sub-rede na qual 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 equilibrador de carga é acessível a partir de qualquer região (e não apenas da BS_REGION). Isto permite que os 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 funcionamento funcionem, crie regras de firewall de entrada aplicáveis à VM de proxy com balanceamento de carga para permitir o tráfego dos intervalos de IP do verificador de funcionamento.

Além disso, crie uma regra de firewall de entrada para permitir que o tráfego de ambientes no local ou multinuvem aceda ao serviço de back-end do balanceador de carga.

Atualize o registo A de DNS

Altere o registo A do domínio personalizado do Looker (Google Cloud core) para apontar para o VIP do equilibrador de carga. A zona privada do Cloud DNS que criou gere o domínio personalizado e é usada pela VPC onde as instâncias de proxy estão localizadas.

Atualize as credenciais do OAuth

  1. Aceda ao seu cliente OAuth navegando na Google Cloud consola para APIs e serviços > Credenciais e selecionando o ID de cliente OAuth 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 seu cliente OAuth de modo a incluir o mesmo nome DNS que a sua organização vai usar para aceder ao Looker (essencial para o Google Cloud). Assim, se o seu domínio personalizado for looker.examplepetstore.com, introduza looker.examplepetstore.com como o URI.

  3. Atualize ou adicione o domínio personalizado à lista de URIs de redirecionamento autorizados para as credenciais OAuth que usou quando criou a instância do Looker (Google Cloud core). Adicionar /oauth2callback ao final do URI. Assim, se o seu domínio personalizado for looker.examplepetstore.com, introduza looker.examplepetstore.com/oauth2callback.

Adicionar utilizadores

Assim que os passos anteriores forem concluídos, o URL do domínio personalizado fica acessível aos utilizadores.

Certifique-se de que o método de autenticação do utilizador está totalmente configurado para a instância do Looker (Google Cloud core) antes de adicionar utilizadores à instância.

Resolução de problemas

  • Se estiver a usar o Chrome para aceder ao 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, pode corrigi-lo com os seguintes passos:

    1. Abrir chrome://net-internals/#hsts
    2. Introduza o domínio personalizado para consultar o conjunto HSTS/PKP. Todas as políticas para o domínio personalizado são apresentadas em Encontrado:.
    3. Em Eliminar políticas de segurança de domínio, introduza o domínio personalizado no campo Domínio.
    4. Clique em Eliminar para eliminar as políticas.

  • Para resolver problemas de erros de certificados, consulte a página de documentação Resolução de problemas de certificados SSL. Para certificados geridos pela Google, certifique-se de que autoriza explicitamente a autoridade de certificação que quer permitir que emita o seu certificado gerido pela Google.

O que se segue?