Accede a una instancia de Looker (Google Cloud Core) con acceso a servicios privados: Tráfico que se origina en diferentes regiones

En esta página de documentación, se describe cómo configurar un dominio personalizado y el acceso a una instancia de Looker (Google Cloud Core) que cumpla con los siguientes criterios:

Para acceder a este tipo de instancia, sigue estos pasos:

  1. Configura el dominio personalizado.
  2. Crea VMs y una zona privada.
  3. Configura los servidores proxy inversos.
  4. Crea y configura el balanceador de cargas.
  5. Crea reglas de firewall.
  6. Actualiza el registro A de DNS.
  7. Actualiza las credenciales de OAuth.

Configurar un dominio personalizado

Después de crear tu instancia de Looker (Google Cloud Core), puedes configurar un dominio personalizado.

Antes de comenzar

Antes de personalizar el dominio de tu instancia de Looker (Google Cloud Core), identifica dónde se almacenan los registros DNS de tu dominio para poder actualizarlos.

Roles obligatorios

Para obtener los permisos que necesitas a fin de crear un dominio personalizado para una instancia de Looker (Google Cloud Core), solicita a tu administrador que te otorgue el Rol de IAM Administrador de Looker (roles/looker.admin) en el proyecto en el que reside la instancia. Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.

También puedes obtener los permisos necesarios mediante roles personalizados o cualquier otro rol predefinido.

Crea un dominio personalizado

En la consola de Google Cloud, sigue estos pasos para personalizar el dominio de tu instancia de Looker (Google Cloud Core):

  1. En la página Instancias, haz clic en el nombre de la instancia para la que deseas configurar un dominio personalizado.
  2. Haz clic en la pestaña CUSTOM DOMAIN.

  3. Haz clic en AGREGAR UN DOMINIO PERSONALIZADO.

    Se abrirá el panel Agregar un nuevo dominio personalizado.

  4. Usa solo letras, números y guiones para ingresar un nombre de host de hasta 64 caracteres para el dominio web que quieras usar, por ejemplo: looker.examplepetstore.com.

  5. Haz clic en LISTO en el panel Agregar un nuevo dominio personalizado para volver a la pestaña DOMINIO PERSONALIZADO.

Una vez configurado, el dominio personalizado se muestra en la columna Dominio de la pestaña Dominio personalizado de la página de detalles de la instancia de la consola de Google Cloud.

Una vez que se haya creado tu dominio personalizado, podrás ver información sobre él o borrarlo.

Accede al dominio personalizado

Cuando el tráfico a una instancia de Looker (Google Cloud Core) que solo tiene IP privada se origina en una región diferente a la de la instancia, puedes usar uno o más servidores proxy inversos de IP privada y un balanceador de cargas para proporcionar acceso seguro a la instancia.

Antes de comenzar

Para obtener los permisos que necesitas para configurar el acceso a un dominio personalizado de IP privada, sigue estos pasos: solicita a tu administrador que te otorgue el siguientes roles de IAM en el proyecto en el que reside la instancia:

Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.

También puedes obtener los permisos necesarios mediante roles personalizados o cualquier otro rol predefinido.

Descripción general de las Herramientas de redes

En las siguientes secciones, se muestra cómo crear una configuración redundante de un servidor proxy NGINX o Apache, con un balanceador de cargas, para enrutar el tráfico desde cualquier región o desde el entorno local al dominio personalizado. En el siguiente diagrama, se representa esta topología:

Una red de Google Cloud que muestra el acceso seguro a una instancia de Looker (Google Cloud Core) con Cloud Router, un balanceador de cargas interno y el Acceso a servicios privados.

Crea VMs y una zona privada

  1. Crea dos instancias de VM solo de IP privada con un sistema operativo RHEL. Las VMs actuarán como tus servidores proxy. Deben estar ubicados en la misma región que la instancia de Looker (Google Cloud Core), pero en zonas diferentes.
  2. Crea una zona privada de Cloud DNS para administrar tus registros de Cloud DNS. La zona privada debe ser visible para la VPC en la que se encuentra la instancia de Looker (Google Cloud Core). La VPC y los hosts locales usarán la zona privada de Cloud DNS para la resolución de DNS para llegar a la IU de Looker (núcleo de Google Cloud). Dado que usarás un balanceador de cargas, el registro A en la zona privada de Cloud DNS se asignará a la dirección IP del balanceador de cargas.

Configura los servidores proxy inversos

Puedes usar cualquier servidor web que se pueda configurar como servidor proxy inverso. Selecciona una de las siguientes opciones para ver ejemplos de cómo configurar servidores de proxy inverso con NGINX o Apache:

NGINX

En el siguiente ejemplo, se usa la versión 1.22.1 de NGINX y la versión 8.9 (Ootpa) de Red Hat Enterprise Linux. Para comprobar qué versiones de NGNIX y Red Hat usan tus VMs, ejecuta los siguientes comandos para cada VM.

  1. Primero, conéctate a la VM.

  2. Instala NGINX con el siguiente comando:

    sudo yum install nginx -y

  3. Para encontrar la versión de NGINX que ejecuta la VM, ejecuta el siguiente comando: 

    sudo nginx -v

    Se debería mostrar algo similar a lo siguiente:

    nginx version: nginx/1.22.1

  4. Para comprobar qué versión de NGINX ejecuta la VM, ejecuta lo siguiente: 

    sudo rpm -qi nginx | grep Release

    Se debería mostrar un resultado similar al siguiente:

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

  5. Para comprobar qué versión de Red Hat usan tus VMs, ejecuta el siguiente comando:

    sudo cat /etc/redhat-release

Para configurar cada servidor proxy, usa las siguientes instrucciones para cada una de las dos VMs que creaste.

  1. Conéctate a la VM.

  2. Edita el archivo /etc/nginx/nginx.conf para que contenga la siguiente configuración:

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

    Reemplaza lo siguiente:

    • CUSTOM_DOMAIN: El dominio personalizado de tu instancia de Looker (Google Cloud Core)
    • INGRESS_PRIVATE_IP: La IP privada de entrada para tu instancia de Looker (Google Cloud Core)

    Además, ten en cuenta lo siguiente:

    • Esta es una configuración de solo IPv4. Si necesitas que el proxy también escuche en su dirección IPv6 privada, quita el comentario de la línea listen [::]:443 ssl en el archivo.
    • El nivel de registro de acceso se establece en debug. asegúrate de ajustarlo al nivel que se usa en tu entorno específico.
    • Si implementas el archivo ssl-params.conf, al que se hace referencia más adelante en estos pasos, quita el comentario de include snippets/ssl-params.conf.

  3. Crea un certificado TLS válido que haga referencia a la URL del dominio personalizado de Looker (Google Cloud core). Este certificado será el que el proxy presente a los clientes que intenten acceder a Looker (Google Cloud Core). La autoridad certificadora (AC) que se usa para firmar el certificado debe ser de confianza para tus clientes. también puedes usar una AC privada interna para firmar este certificado TLS. (Como alternativa, también puedes usar un certificado SSL autoadministrado).

    En este ejemplo, supongamos que el certificado ya se creó con el servicio gratuito Let's Encrypt sin configurar la renovación automática a través de Certbot. Una vez creado el certificado, guarda los archivos relevantes en los directorios certs y private de 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;

    Reemplaza custom-domain.custom-domain.com por tu dominio personalizado.

    Si los directorios certs y private no existen en tu instalación, puedes crearlos o usar otras carpetas.

  4. Para asegurarte de que NGINX detecte los archivos de certificado, crea el directorio /etc/nginx/snippets:

    sudo mkdir /etc/nginx/snippets

  5. Crea el archivo de configuración, /etc/nginx/snippets/self-signed.conf:

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

    Edita el archivo de configuración para agregar las rutas de acceso a los archivos de certificado que guardaste:

    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;

    Reemplaza custom-domain.custom-domain.com por tu dominio personalizado.

  6. Para confirmar que el archivo de configuración contenga la referencia a los archivos que se mencionaron en el paso anterior, ejecuta el siguiente comando: 

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

    Debería mostrar las rutas de acceso a los archivos que agregaste.

  7. De manera opcional, crea el archivo ssl-params.conf de NGINX, que se puede usar para almacenar parámetros que se pueden volver a usar en futuras configuraciones de NGINX.

    Como referencia, el contenido del archivo debe ser similar al siguiente:

    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 SELinux de modo que permita que NGINX reenvíe el tráfico a la IP de entrada de Looker (Google Cloud Core), establece el parámetro booleano httpd_can_network_connect de SELinux en 1:

    sudo setsebool -P httpd_can_network_connect 1

  9. Ahora puedes reiniciar el proceso de NGINX con el siguiente comando:

    sudo systemctl restart nginx

  10. Verifica que NGINX se haya reiniciado correctamente con el siguiente comando:

    sudo systemctl status nginx

    Se debería mostrar un resultado similar al siguiente:

    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

Completa estos pasos para cada VM.

  1. Primero, conéctate a la VM.

  2. Instala Apache:

    sudo yum install httpd -y

  3. En el siguiente ejemplo, se usa Red Hat Enterprise Linux versión 7.9. Para verificar qué versiones de Red Hat usan tus VMs, ejecuta el siguiente comando:

    cat /etc/redhat-release

    Esto debería mostrar lo siguiente:

    Red Hat Enterprise Linux Server release 7.9 (Maipo)

  4. En el siguiente ejemplo, se usa la versión 2.4.6 de Apache. Para comprobar qué versiones de Apache usan tus VMs, ejecuta los siguientes comandos para cada VM:

    sudo httpd -version

    Esto debería mostrar lo siguiente:

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

  5. Para obtener más información sobre el servidor Apache, ejecuta el siguiente comando:

    sudo rpm -qi httpd

    Se debería mostrar un resultado similar al siguiente:

    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. Crea el archivo de configuración /etc/httpd/conf.d/ssl.conf en la VM del proxy y agrégale la siguiente configuración:

    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/

    Reemplaza lo siguiente:

    • custom domain of Looker (Google Cloud core): Es el dominio personalizado de tu instancia de Looker (Google Cloud Core).
    • private IP of Looker (Google Cloud core): Es la IP privada de tu instancia de Looker (Google Cloud Core).

  7. Confirma que los archivos del certificado TLS estén disponibles en los directorios a los que se hace referencia en el archivo /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. Comprueba si mod_ssl está instalado:

    sudo yum list installed | grep mod_ssl

    Si mod_ssl no está instalado, instálalo con el siguiente comando:

    sudo yum install mod_ssl

    Una vez que mod_ssl esté instalado, debes habilitarlo agregando la siguiente línea al archivo de configuración de Apache, /etc/httpd/conf/httpd.conf:

    LoadModule ssl_module modules/mod_ssl.so

  9. En el archivo de configuración de Apache, /etc/httpd/conf/httpd.conf, reemplaza Listen 80 por Listen 443.

  10. Ejecuta el siguiente comando para permitir que la VM de proxy de Apache reenvíe el tráfico a Looker (Google Cloud Core):

    /usr/sbin/setsebool -P httpd_can_network_connect 1

  11. Por último, reinicia Apache para aplicar los cambios:

    sudo systemctl restart httpd

  12. Verifica que el módulo de reescritura esté cargado y listo en Apache con el siguiente comando:

    sudo httpd -M | grep rewrite

    Se debería mostrar un resultado similar al siguiente:

    rewrite_module (shared)

  13. Por último, inicia o reinicia el proceso de Apache para asegurarte de que se apliquen todos los cambios de configuración:

    sudo systemctl restart httpd

  14. Usa el siguiente comando para verificar que el proceso de Apache se reinició correctamente: 

    sudo systemctl status httpd

    Se debería mostrar un resultado similar al siguiente:

    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.

Crea y configura el balanceador de cargas

En este ejemplo, se usan grupos de extremos de red zonales (NEG) con extremos GCE_VM_IP como backends del balanceador de cargas de red de transferencia interno. Si prefieres usar backends basados en grupos de instancias, sigue la documentación disponible en la página de documentación Configura un balanceador de cargas de red de transferencia interno con backends de grupos de instancias de VM.

  1. Crea un NEG zonal separado para cada zona de procesamiento en la que planeas implementar servidores proxy. Por ejemplo, si deseas implementar servidores proxy en cada una de las tres zonas de procesamiento de la región en la que se implementa Looker (Google Cloud Core), crea tres NEG zonales. Consulta la página de documentación de Cuotas y límites para verificar cuántos extremos son compatibles por NEG zonal.

    Para crear un NEG zonal, usa el siguiente 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

    Reemplaza lo siguiente:

    • NEG_NAME: Es el nombre del NEG que estás creando.
    • PROXY_INSTANCE_ZONE: Es la zona en la que se encuentra el servidor proxy.
    • PROXY_INSTANCE_VPC: Es la VPC que contiene el servidor proxy.
    • PROXY_INSTANCE_SUBNET: Es la subred en la que se encuentra el servidor proxy.

    Repite este paso para cualquier zona adicional en la que implementarás una VM de servidor proxy.

  2. Agrega cada servidor proxy al NEG en la misma zona:

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

    Reemplaza lo siguiente:

    • PROXY_INSTANCE_ZONE: Es la zona en la que se encuentra el servidor proxy.
    • NEG_NAME: Es el nombre del NEG en la misma zona que el servidor proxy.
    • PROXY_INSTANCE_NAME: Es el nombre del servidor proxy.

    Repite este paso hasta que cada una de las VMs del servidor proxy se agregue a un NEG como extremo.

  3. Crea una verificación de estado regional que utilizará el balanceador de cargas interno. Usa el 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

    Reemplaza lo siguiente:

    • PROTOCOL: Es el protocolo que se usa para la verificación de estado. Las opciones válidas son grpc, http, https, http2, ssl y tcp.
    • NAME: Es el nombre de la verificación de estado. Dentro de un proyecto determinado, cada verificación de estado global debe tener un nombre único, y las verificaciones de estado regionales deben tener nombres únicos dentro de una región determinada.
    • REGION: Todos los balanceadores de cargas, excepto los balanceadores de cargas de aplicaciones regionales externos e internos usan verificaciones de estado globales (--global). Los balanceadores de cargas de aplicaciones regionales internos usan verificaciones de estado regionales cuya región debe coincidir con la del servicio de backend.
    • DESCRIPTION: Es una descripción opcional.
    • CHECK_INTERVAL: Es la cantidad de tiempo desde el inicio de un estado. comprueba la conexión del sistema de sondeo al inicio del siguiente. Las unidades son segundos. Si se omite, Google Cloud usa un valor de 5s (5 segundos).
    • TIMEOUT: Es la cantidad de tiempo que Google Cloud espera una respuesta a un sondeo. El valor de TIMEOUT debe ser menor o igual que CHECK_INTERVAL. Las unidades son segundos. Si se omite, Google Cloud usa un valor de 5s (5 segundos).
    • HEALTHY_THRESHOLD y UNHEALTHY_THRESHOLD: Especifican la cantidad de sondeos secuenciales que deben tener éxito o fallar para que la instancia de VM se considere en buen o mal estado. Si se omite alguno, Google Cloud usa un límite predeterminado de 2.
    • PORT_SPECIFICATION define la especificación de puerto mediante una de las marcas de especificación de puerto.
    • ADDITIONAL_FLAGS: Son otras marcas para especificar puertos y opciones específicas de PROTOCOL. Consulta Marcas adicionales para las verificaciones de estado HTTP, HTTPS y HTTP/2, Marcas adicionales para las verificaciones de estado de SSL y TCP o Marca adicional para las verificaciones de estado de gRPC.

  4. Crea el servicio de backend:

    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

    Reemplaza lo siguiente:

    • BS_NAME: Es el nombre del balanceador de cargas que creas.
    • PROXY_INSTANCES_REGION: Es la región en la que se encuentran los servidores proxy.
    • HC_NAME: Es el nombre de la verificación de estado regional que creaste.
    • HC_REGION: Es la región en la que se encuentra la verificación de estado.

    Tenga en cuenta estos datos:

    • La marca --session-affinity=CLIENT_IP dirige la solicitud de un cliente específico a la misma VM de la instancia de proxy de backend, en función de un hash creado en la dirección IP de cliente y en la dirección de destino.
    • La marca --connection-persistence-on-unhealthy-backends=NEVER_PERSIST significa que las conexiones no se conservarán en las VMs de la instancia de proxy que no están en buen estado.

  5. Agrega cada uno de los NEG al servicio de backend:

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

    Reemplaza lo siguiente:

    • BS_NAME: Es el nombre del servicio de backend que creaste.
    • BS_REGION: La región en la que se encuentra el servicio de backend. debería ser la misma que la región en la que se ubican los servidores proxy.
    • NEG_NAME: Es el nombre del NEG que agregas.
    • NEG_ZONE: Es la zona en la que se encuentra el NEG.

    Repite este paso para el NEG adicional que creaste.

  6. Reserva una dirección IP interna en la VPC dentro del rango de IP de la subred donde están conectadas las instancias de proxy. Esta será la dirección IP virtual (VIP) del balanceador de cargas interno. Si reservas la dirección, te asegurarás de que ningún otro objeto use la IP. Para reservar la dirección IP interna, usa el comando compute addresses create:

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

    Reemplaza lo siguiente:

    • ADDRESS_NAMES: Los nombres de uno o más [--purpose=SHARED_LOADBALANCER_VIP] direcciones IP que quieres crear. En el caso de varias direcciones, especifica todas las direcciones como una lista, separadas por espacios, por ejemplo, example-address-1 example-address-2 example-address-3.
    • REGION: Es la región para esta solicitud.
    • SUBNETWORK: Es la subred para esta dirección IP interna.
    • IP_ADDRESS: Es la dirección IP que se reservará, que debe estar dentro del rango de IP principal de la subred. Si no se especifica, se asigna una dirección IP de forma automática desde la subred.

  7. Crea la regla de reenvío y asóciala con el servicio de backend y la 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

    Reemplaza lo siguiente:

    • FW_RULE_NAME: Es el nombre de la regla de reenvío que creas.
    • BS_REGION: Es la región en la que se encuentra el servicio de backend.
    • PROXY_INSTANCES_VPC_NAME: Es el nombre de la VPC en la que se crearon las VMs del servidor proxy.
    • RESERVED_IP_ADDRESS_SUBNET: Es la subred en la que se encuentra el VIP.
    • RESERVED_IP_ADDRESS: Es la dirección VIP para el balanceador de cargas.
    • BS_NAME: Es el nombre del servicio de backend.

    Tenga en cuenta estos datos:

    • La marca --allow-global-access indica que se puede acceder a la VIP del balanceador de cargas desde cualquier región (no solo desde BS_REGION). Esto permite que los clientes de cada región lleguen a la instancia de Looker (Google Cloud Core).

Crea reglas de firewall

Para que las verificaciones de estado funcionen, crea reglas de firewall de entrada aplicables a la VM de proxy cuyo balanceo de cargas permite el tráfico de los rangos de IP de verificación de estado.

Además, crea una regla de firewall de entrada para permitir que el tráfico de entornos locales o multinube obtenga acceso al servicio de backend del balanceador de cargas.

Actualiza el registro A del DNS

Cambia el registro A del dominio personalizado de Looker (Google Cloud Core) para que apunte a la VIP del balanceador de cargas. La zona privada de Cloud DNS que creaste administra el dominio personalizado y la usa la VPC en la que se encuentran las instancias de proxy.

Actualiza las credenciales de OAuth

  1. Para acceder a tu cliente de OAuth, navega en la consola de Google Cloud a APIs y servicios > Credenciales y selecciona el ID de cliente de OAuth que usa tu instancia de Looker (núcleo de Google Cloud).

  2. Haz clic en el botón Agregar URI para actualizar el campo Orígenes autorizados de JavaScript en tu cliente de OAuth para incluir el mismo nombre de DNS que tu organización usará para acceder a Looker (Google Cloud Core). Por lo tanto, si tu dominio personalizado es looker.examplepetstore.com, debes ingresar looker.examplepetstore.com como el URI.

  3. Actualiza o agrega el dominio personalizado a la lista de URI de redireccionamiento autorizados para las credenciales de OAuth que usaste cuando creaste la instancia de Looker (Google Cloud Core). Agrega /oauth2callback al final del URI. Por lo tanto, si tu dominio personalizado es looker.examplepetstore.com, debes ingresar looker.examplepetstore.com/oauth2callback.

Agrega usuarios

Una vez que se completen los pasos anteriores, los usuarios podrán acceder a la URL del dominio personalizado.

Asegúrate de que el método de autenticación de usuarios esté completamente configurado para la instancia de Looker (Google Cloud Core) antes de agregar usuarios a la instancia.

Soluciona problemas

  • Si usas Chrome para acceder al dominio personalizado de Looker (Google Cloud Core) y recibes un error de Chrome, como NET::ERR_CERT_COMMON_NAME_INVALID o un error de política de HSTS, puedes solucionarlo siguiendo estos pasos:

    1. Abrir chrome://net-internals/#hsts
    2. Ingresa el dominio personalizado para consultar el conjunto de HSTS/PKP. Todas las políticas del dominio personalizado aparecerán en Encontrado:.
    3. En Borrar políticas de seguridad del dominio, ingresa el dominio personalizado en el campo Dominio.
    4. Haz clic en Borrar para eliminar las políticas.

  • Para solucionar problemas de certificados, consulta la página de documentación Soluciona problemas de certificados SSL. En el caso de los certificados administrados por Google, asegúrate de autorizar de forma explícita a la autoridad certificadora que deseas permitir que emita el certificado administrado por Google.

¿Qué sigue?