Acceder a una instancia de Looker (Google Cloud core) mediante acceso a servicios privados

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 los siguientes criterios:

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

  1. Configura el dominio personalizado.
  2. Crea máquinas virtuales y una zona privada.
  3. Configura los servidores proxy inverso.
  4. Crea y configura el balanceador de carga.
  5. Crea reglas de cortafuegos.
  6. Actualiza el registro A de DNS.
  7. Actualiza las credenciales de OAuth.

Configurar un dominio personalizado

Una vez que se haya creado tu instancia de Looker (Google Cloud core), podrás configurar un dominio personalizado.

Antes de empezar

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 para crear un dominio personalizado para una instancia de Looker (Google Cloud core), pide a tu administrador que te conceda el rol de gestión de identidades y accesos Administrador de Looker (roles/looker.admin) en el proyecto en el que reside la instancia. Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones.

También puedes conseguir los permisos necesarios a través de roles personalizados u otros roles predefinidos.

Crear un dominio personalizado

En la Google Cloud consola, 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 quieras configurar un dominio personalizado.
  2. Haz clic en la pestaña DOMINIO PERSONALIZADO.

  3. Haz clic en AÑADIR UN DOMINIO PERSONALIZADO.

    Se abrirá el panel Añadir un dominio personalizado.

  4. Introduce el nombre de host del dominio web que quieras usar (hasta 64 caracteres) con letras, números y guiones. Por ejemplo: looker.examplepetstore.com.

  5. Haz clic en HECHO en el panel Añadir un nuevo dominio personalizado para volver a la pestaña DOMINIO PERSONALIZADO.

Una vez que haya configurado su dominio personalizado, se mostrará en la columna Dominio de la pestaña DOMINIO PERSONALIZADO de la página de detalles de la instancia de Looker (Google Cloud core) en la consola de Google Cloud .

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

Acceder al dominio personalizado

Cuando el tráfico a una instancia de Looker (Google Cloud core) con conexiones privadas (PSA) procede de una región diferente a la de la instancia, puedes usar uno o varios servidores proxy inverso de IP privada y un balanceador de carga para proporcionar acceso seguro a la instancia.

Antes de empezar

Para obtener los permisos que necesitas para configurar el acceso a un dominio personalizado de conexiones privadas, pide a tu administrador que te conceda los siguientes roles de gestión de identidades y accesos en el proyecto en el que reside la instancia:

Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones.

También puedes conseguir los permisos necesarios a través de roles personalizados u otros roles predefinidos.

Información general sobre las redes

En las siguientes secciones se muestra cómo crear una configuración de servidor proxy redundante de NGINX o Apache, con un balanceador de carga, para enrutar el tráfico desde cualquier región o desde las instalaciones locales 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 (núcleo de Google Cloud) mediante Cloud Router, un balanceador de carga interno y Acceso a servicios privados.

Crear VMs, una zona privada y un registro A

Sigue los pasos que se indican en las secciones siguientes.

Crear VMs

Crea dos instancias de VM con solo IP privada y un sistema operativo RHEL. Las VMs actuarán como servidores proxy. Deben estar ubicadas en la misma región que la instancia de Looker (Google Cloud Core), pero en zonas diferentes entre sí.

Crear una zona privada

Crea una zona privada de Cloud DNS que sea visible para la VPC en la que se encuentra la instancia de Looker (Google Cloud Core). La zona privada de Cloud DNS la usarán la VPC y los hosts on-premise para la resolución de DNS con el fin de acceder a la interfaz de usuario de Looker (Google Cloud core). El nombre de la zona debe coincidir con el dominio personalizado.

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

Haz los cambios siguientes:

  • NAME: un nombre para la zona.
  • DESCRIPTION: descripción de la zona.

  • DNS_SUFFIX: el sufijo DNS de tu zona, como examplepetstore.com.

  • VPC_NETWORK_LIST: lista separada por comas de redes de VPC autorizadas para consultar la zona. Asegúrate de incluir la VPC que contiene tu instancia de Looker (Google Cloud Core).

  • LABELS: lista opcional de pares clave-valor separados por comas, como dept=marketing o project=project1. Para obtener más información, consulta la documentación del SDK.

Una vez que se haya configurado la zona, si te desplazas a ella en la página Zonas de Cloud DNS de la consola de Google Cloud , verás que es privada, que tiene el nombre del dominio personalizado y que incluye conjuntos de registros del dominio personalizado.

Añadir el registro A de Cloud DNS

Sigue estos pasos para añadir el registro A de Cloud DNS:

  1. Como vas a usar un balanceador de carga, el registro A de la zona privada de Cloud DNS se asignará a la dirección IP del balanceador de carga.

    La IP de entrada resaltada en la pestaña Detalles de la página Instancias.

  2. Añade un registro A de DNS para el dominio personalizado en la zona privada, que consta de la dirección IP de entrada de la instancia de Looker (Google Cloud Core). El registro A usa el nombre de dominio completo (FQDN), que es el mismo que configuraste como dominio personalizado de Looker (Google Cloud core).

    La configuración completa debería mostrar el registro A del dominio personalizado cuando veas los detalles de la zona privada en la página Zonas de Cloud DNS de la consola de Google Cloud .

    Para que los servicios de resolución de nombres de una red de VPC estén disponibles en las redes on-premise que están conectadas a la red de VPC mediante túneles de Cloud VPN, vinculaciones de VLAN de Cloud Interconnect o dispositivos Router, puedes usar una política de servidor entrante.

    Una vez que se hayan actualizado los registros DNS de tu dominio y se haya verificado en la consola de Google Cloud, el estado del dominio personalizado asignado a la instancia cambiará de Sin verificar a Disponible en la pestaña Dominio personalizado de la página Instancias.

Configurar 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 proxy inverso con NGINX o Apache:

NGINX

En el siguiente ejemplo, se usan 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 NGINX y Red Hat usan tus VMs, ejecuta los siguientes comandos en cada VM.

  1. Primero, conéctate a la VM.

  2. Instala NGINX con el siguiente comando:

    sudo yum install nginx -y

  3. Para saber qué versión de NGINX está ejecutando la VM, ejecuta el siguiente comando: 

    sudo nginx -v

    Debería devolver algo similar a lo siguiente:

    nginx version: nginx/1.22.1

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

    sudo rpm -qi nginx | grep Release

    Debería devolver algo similar a lo 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, sigue las instrucciones que se indican a continuación en cada una de las dos máquinas virtuales que has creado.

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

    Haz los cambios siguientes:

    • CUSTOM_DOMAIN: el dominio personalizado de tu instancia de Looker (servicio principal de Google Cloud)
    • INGRESS_PRIVATE_IP: la IP de entrada de tu instancia de Looker (Google Cloud Core)

    Además, ten en cuenta lo siguiente:

    • Esta es una configuración solo para IPv4. Si quieres que el proxy también escuche en su dirección IPv6, quita el comentario de la línea listen [::]:443 ssl del archivo.
    • El nivel de registro de acceso se ha definido como debug. Asegúrate de ajustarlo al nivel que se utilice 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 de certificación (CA) utilizada para firmar el certificado debe ser de confianza para tus clientes. También puedes usar una CA privada interna para firmar este certificado TLS. También puedes usar un certificado SSL autogestionado.

    En este ejemplo, se da por hecho que el certificado ya se ha creado con el servicio gratuito Let's Encrypt, sin configurar la renovación automática a través de Certbot. Una vez que se haya creado el certificado, guarda los archivos correspondientes en los directorios certs y private de cada máquina virtual proxy:

    /etc/pki/tls/certs/custom-domain.custom-domain.com.fullchain.pem;
/etc/pki/tls/private/custom-domain.custom-domain.com.key.pem;

    Sustituye 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 detecta 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 añadir las rutas a los archivos de certificado que has guardado:

    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;

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

  6. Para confirmar que el archivo de configuración contiene 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 devolver las rutas de los archivos que has añadido.

  7. También puedes crear el archivo ssl-params.confNGINX, que se puede usar para almacenar parámetros que se pueden reutilizar en futuras configuraciones de NGINX.

    El contenido del archivo debería 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 forma que permita que NGINX reenvíe tráfico a la IP de entrada de Looker (Google Cloud Core), asigna el valor 1 al parámetro booleano httpd_can_network_connect de SELinux:

    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 ha reiniciado correctamente con el siguiente comando:

    sudo systemctl status nginx

    Debería devolver 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

Sigue estos pasos con cada máquina virtual.

  1. Primero, conéctate a la VM.

  2. Instala Apache:

    sudo yum install httpd -y

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

    cat /etc/redhat-release

    Debería devolver 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 en cada VM:

    sudo httpd -version

    Debería devolver 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

    Debería devolver 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 proxy y añade la siguiente configuración al archivo:

    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/

    Haz los cambios siguientes:

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

  7. Confirma que los archivos de 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 hayas instalado mod_ssl, debes habilitarlo añadiendo 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, sustituye Listen 80 por Listen 443.

  10. Ejecuta el siguiente comando para permitir que la VM 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 se haya cargado y esté listo en Apache con este comando:

    sudo httpd -M | grep rewrite

    Debería devolver 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. Verifica que el proceso de Apache se ha reiniciado correctamente con el siguiente comando: 

    sudo systemctl status httpd

    Debería devolver 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.

Crear y configurar el balanceador de carga

En este ejemplo se usan grupos de puntos finales de red (NEGs) por zonas con GCE_VM_IP puntos finales como backends del balanceador de carga de red interno de pases. Si prefieres usar backends basados en grupos de instancias, consulta la documentación disponible en la página Configurar un balanceador de carga de red pasarela interno con backends de grupos de instancias de VM.

  1. Crea un NEG zonal independiente para cada zona de computación en la que quieras implementar servidores proxy. Por ejemplo, si quieres desplegar servidores proxy en cada una de las tres zonas de computación de la región en la que se ha desplegado Looker (Google Cloud core), crea tres NEGs zonales. Consulta la página de documentación Cuotas y límites para ver cuántos endpoints se admiten 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

    Haz los cambios siguientes:

    • NEG_NAME: el nombre del NEG que vas a crear.
    • PROXY_INSTANCE_ZONE: la zona en la que se encuentra el servidor proxy.
    • PROXY_INSTANCE_VPC: la VPC que contiene el servidor proxy.
    • PROXY_INSTANCE_SUBNET: la subred en la que se encuentra el servidor proxy.

    Repite este paso con cada zona adicional en la que vayas a implementar una VM de servidor proxy.

  2. Añada cada servidor proxy al NEG de la misma zona:

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

    Haz los cambios siguientes:

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

    Repite este paso hasta que cada una de las VMs del servidor proxy se añada a un NEG como punto final.

  3. Crea una comprobación del estado regional que usará el balanceador de carga 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

    Haz los cambios siguientes:

    • PROTOCOL: el protocolo usado para la comprobación del estado. Las opciones válidas son grpc, http, https, http2, ssl y tcp.
    • NAME: el nombre de la comprobación del estado. En un proyecto determinado, cada comprobación de estado global debe tener un nombre único, y las comprobaciones de estado regionales deben tener nombres únicos en una región determinada.
    • REGION: Todos los balanceadores de carga, excepto los balanceadores de carga de aplicación externos regionales y los balanceadores de carga de aplicación internos regionales, usan comprobaciones del estado globales (--global). Los balanceadores de carga de aplicación internos regionales usan comprobaciones del estado regionales cuya región debe coincidir con la del servicio de backend.
    • DESCRIPTION: una descripción opcional.
    • CHECK_INTERVAL: el tiempo transcurrido desde el inicio de la conexión de un sistema de sondeo de comprobación de estado hasta el inicio del siguiente. Las unidades son segundos. Si se omite, Google Cloud usa el valor 5s (5 segundos).
    • TIMEOUT: tiempo que Google Cloud espera una respuesta a una petición. El valor de TIMEOUT debe ser inferior o igual a CHECK_INTERVAL. Las unidades son segundos. Si se omite,Google Cloud usa el valor 5s (5 segundos).
    • HEALTHY_THRESHOLD y UNHEALTHY_THRESHOLD: especifica el número de comprobaciones secuenciales que deben completarse correctamente o fallar para que la instancia de VM se considere en buen estado o en mal estado. Si se omite alguno de los dos,Google Cloud usa un umbral predeterminado de 2.
    • PORT_SPECIFICATION: define la especificación del puerto mediante una de las marcas de especificación de puerto.
    • ADDITIONAL_FLAGS: otras marcas para especificar puertos y opciones específicas de PROTOCOL. Consulta Banderas adicionales para comprobaciones de estado de HTTP, HTTPS y HTTP/2, Banderas adicionales para comprobaciones de estado de SSL y TCP o Bandera adicional para comprobaciones 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

    Haz los cambios siguientes:

    • BS_NAME: el nombre del balanceador de carga que vas a crear.
    • PROXY_INSTANCES_REGION: la región en la que se encuentran los servidores proxy.
    • HC_NAME: el nombre de la comprobación del estado regional que has creado.
    • HC_REGION: la región en la que se encuentra la comprobación del estado.

    También tienes estas opciones:

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

  5. Añade cada uno de los NEGs 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

    Haz los cambios siguientes:

    • BS_NAME: el nombre del servicio de backend que has creado.
    • BS_REGION: la región en la que se encuentra el servicio de backend. Debe ser la misma que la región en la que se encuentran los servidores proxy.
    • NEG_NAME: el nombre del NEG que vas a añadir.
    • NEG_ZONE: la zona en la que se encuentra el NEG.

    Repite este paso con el NEG adicional que has creado.

  6. Reserva una dirección IP interna en la VPC dentro del intervalo de IP de la subred a la que están conectadas las instancias proxy. Esta será la dirección IP virtual (VIP) del balanceador de carga interno. Al reservar la dirección, te aseguras de que ningún otro objeto la utilice. 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

    Haz los cambios siguientes:

    • ADDRESS_NAMES: los nombres de una o varias direcciones [--purpose=SHARED_LOADBALANCER_VIP] que quieras crear. Si hay varias direcciones, especifícalas todas en una lista separadas por espacios. Por ejemplo, example-address-1 example-address-2 example-address-3
    • REGION: la región de esta solicitud.
    • SUBNETWORK: la subred de esta dirección IP interna.
    • IP_ADDRESS: la dirección IP que se va a reservar, que debe estar dentro del intervalo de IP principal de la subred. Si no se especifica ninguna, se asigna automáticamente una dirección IP de la subred.

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

    Haz los cambios siguientes:

    • FW_RULE_NAME: El nombre de la regla de reenvío que estás creando.
    • BS_REGION: región en la que se encuentra el servicio de backend
    • PROXY_INSTANCES_VPC_NAME: nombre de la VPC en la que se crearon las VMs del servidor proxy
    • RESERVED_IP_ADDRESS_SUBNET: la subred en la que se encuentra la IP virtual
    • RESERVED_IP_ADDRESS: dirección IP virtual del balanceador de carga.
    • BS_NAME: el nombre del servicio de backend.

    También tienes estas opciones:

    • La marca --allow-global-access indica que se puede acceder a la dirección IP virtual del balanceador de carga desde cualquier región (no solo desde BS_REGION). De esta forma, los clientes de todas las regiones pueden acceder a la instancia de Looker (núcleo de Google Cloud).

Crear reglas de cortafuegos

Para que las comprobaciones del estado funcionen, crea reglas de cortafuegos de entrada aplicables a la VM proxy que se esté balanceando para permitir el tráfico de los intervalos de direcciones IP de la sonda de comprobación del estado.

Además, crea una regla de cortafuegos de entrada para permitir que el tráfico de entornos on-premise o multinube acceda al servicio de backend del balanceador de carga.

Actualizar el registro A de DNS

Cambia el registro A del dominio personalizado de Looker (Google Cloud core) para que apunte a la IP virtual del balanceador de carga. La zona privada de Cloud DNS que has creado gestiona el dominio personalizado y la utiliza la VPC en la que se encuentran las instancias proxy.

Actualizar las credenciales de OAuth

  1. Para acceder a tu cliente de OAuth, ve a APIs & Services > Credentials (APIs y servicios > Credenciales) en la consola y selecciona el ID de cliente de OAuth del cliente de OAuth que usa tu instancia de Looker (Google Cloud core). Google Cloud

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

  3. Actualiza o añade el dominio personalizado a la lista de URIs de redirección autorizadas de las credenciales de OAuth que has usado al crear la instancia de Looker (Google Cloud core). Añade /oauth2callback al final del URI. Por lo tanto, si tu dominio personalizado es looker.examplepetstore.com, debes introducir looker.examplepetstore.com/oauth2callback.

Añadir a usuarios

Una vez que se hayan completado 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 en la instancia de Looker (Google Cloud core) antes de añadir usuarios a la instancia.

Solución de 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 HSTS, puedes solucionarlo siguiendo estos pasos:

    1. Abrir chrome://net-internals/#hsts
    2. Introduce el dominio personalizado para consultar el conjunto HSTS/PKP. Las políticas del dominio personalizado aparecerán en Encontrado:.
    3. En Delete domain security policies (Eliminar políticas de seguridad de dominio), introduce el dominio personalizado en el campo Domain (Dominio).
    4. Haga clic en Eliminar para eliminar las políticas.

  • Para solucionar problemas con los certificados, consulta la página de documentación Solucionar problemas de certificados SSL. En el caso de los certificados gestionados por Google, asegúrate de autorizar explícitamente a la autoridad de certificación que quieras que emita tu certificado gestionado por Google.

Siguientes pasos