Accede a una instancia de Looker (Google Cloud Core) con el 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 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

Una vez que se haya creado 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 que puedas actualizarlos.

Roles obligatorios

Para obtener los permisos que necesitas para crear un dominio personalizado para una instancia de Looker (Google Cloud Core), pídele a tu administrador que te otorgue el rol de IAM de 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 DOMINIO PERSONALIZADO.

  3. Haz clic en ADD A CUSTOM DOMAIN.

    Se abrirá el panel Agregar un nuevo dominio personalizado.

  4. Con solo letras, números y guiones, ingresa el nombre de host de hasta 64 caracteres para el dominio web que deseas usar, por ejemplo, looker.examplepetstore.com.

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

Una vez que configures tu 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 .

Después de crear tu dominio personalizado, puedes ver información sobre él o borrarlo.

Accede al dominio personalizado

Cuando el tráfico a una instancia de Looker (Google Cloud Core) solo con IP privada se origina en una región diferente a la de la instancia, puedes usar uno o más servidores proxy inversos con 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, pídele a tu administrador que te otorgue los 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 del servidor proxy de NGINX o Apache, con un balanceador de cargas, 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 (Google Cloud Core) con Cloud Router, un balanceador de cargas interno y el acceso a servicios privados.

Crea VMs, una zona privada y un registro A

Completa los pasos que se indican en las siguientes secciones.

Crea las VM

Crea dos instancias de VM solo con IP privada y 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 entre sí.

Crea 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 locales para la resolución de DNS y, así, acceder a la IU 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

Reemplaza lo siguiente:

  • NAME: Es el nombre de tu zona.
  • DESCRIPTION: Es una descripción para tu zona.

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

  • VPC_NETWORK_LIST: Es una lista delimitada por comas de redes de VPC que están autorizadas a consultar la zona. Asegúrate de incluir la VPC que contiene tu instancia de Looker (Google Cloud Core).

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

Una vez que se configura la zona, si navegas a ella en la página Zonas de Cloud DNS de la consola de Google Cloud , puedes ver que es privada, que se denomina según el dominio personalizado y que tiene conjuntos de registros para el dominio personalizado.

Agrega el registro A de Cloud DNS

Para agregar el registro A de Cloud DNS, completa los siguientes pasos:

  1. Como 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.

    La IP privada de entrada destacada en la pestaña Detalles de la página Instancias

  2. Agrega 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 completamente calificado (FQDN), el mismo que configuraste como el dominio personalizado de Looker (Google Cloud Core).

    La configuración completa debe 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 para las redes locales que están conectadas a la red de VPC a través de túneles de Cloud VPN, adjuntos de VLAN de Cloud Interconnect o dispositivos de router, puedes usar una política de servidor entrante.

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

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 proxy inversos 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 verificar qué versiones de NGINX 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

    Esto debería mostrar un resultado similar al siguiente:

    nginx version: nginx/1.22.1

  4. Para verificar qué versión de NGINX ejecuta la VM, ejecuta el siguiente comando: 

    sudo rpm -qi nginx | grep Release

    Esto debería mostrar un resultado similar al siguiente:

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

  5. Para verificar 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 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: Es el dominio personalizado de tu instancia de Looker (Google Cloud Core).
    • INGRESS_PRIVATE_IP: Es 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 solo para IPv4. Si necesitas que el proxy también escuche en su dirección IPv6 privada, quita la marca de comentario de la línea listen [::]:443 ssl en el archivo.
    • El nivel de registro de acceso está establecido 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 la marca de 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 será el certificado que el proxy presentará a los clientes que intenten acceder a Looker (Google Cloud Core). Tus clientes deben confiar en la autoridad certificadora (CA) que se usa para firmar el certificado. También puedes usar una CA privada interna para firmar este certificado TLS. (Como alternativa, también puedes usar un certificado SSL autoadministrado).

    En este ejemplo, se supone que el certificado ya se creó con el servicio gratuito de 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 pertinentes 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 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 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 reutilizar en futuras configuraciones de NGINX.

    Como referencia, 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 modo que permita que NGINX reenvíe 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

    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 la versión 7.9 de Red Hat Enterprise Linux. 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 verificar 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 se instale mod_ssl, 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 del proxy de Apache reenvíe 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 este comando:

    sudo httpd -M | grep rewrite

    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 implementen todos los cambios en la configuración:

    sudo systemctl restart httpd

  14. Verifica que el proceso de Apache se haya reiniciado correctamente con el siguiente comando: 

    sudo systemctl status httpd

    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 (NEG) zonales con extremos de GCE_VM_IP como backends del balanceador de cargas de red de transferencia interno. Si prefieres usar backends basados en grupos de instancias, consulta la documentación disponible en la página Configura un balanceador de cargas de red de transferencia interno con backends de grupos de instancias de VM.

  1. Crea un NEG zonal independiente 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 Cuotas y límites para verificar cuántos extremos 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

    Reemplaza lo siguiente:

    • NEG_NAME: Es el nombre del NEG que crearás.
    • 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 cada 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 VM del servidor proxy se agregue a un NEG como extremo.

  3. Crea una verificación de estado regional que usará 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: 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 la conexión de un sistema de sondeo de verificación de estado hasta el inicio de la 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 umbral predeterminado de 2.
    • PORT_SPECIFICATION define la especificación de 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 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 crearás.
    • 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.

    Además:

    • La marca --session-affinity=CLIENT_IP dirige la solicitud de un cliente específico a la misma VM de instancia de proxy de backend, según un hash creado en la dirección IP del cliente y la dirección de destino.
    • La marca --connection-persistence-on-unhealthy-backends=NEVER_PERSIST significa que las conexiones no persistirán en las VMs de instancias de proxy en mal 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: Es la región en la que se encuentra el servicio de backend. Debe ser la misma región en la que se encuentran los servidores proxy.
    • NEG_NAME: Es el nombre del NEG que agregarás.
    • 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 a la que se conectan las instancias de proxy. Esta será la dirección IP virtual (VIP) del balanceador de cargas interno. Reservar la dirección garantizará 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: Son los nombres de una o más direcciones [--purpose=SHARED_LOADBALANCER_VIP] que deseas 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 al servicio de backend y a 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 la VIP.
    • RESERVED_IP_ADDRESS: Es la dirección IP virtual del balanceador de cargas.
    • BS_NAME: El nombre del servicio de backend

    Además:

    • 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 todas las regiones accedan 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 tráfico se balancea para permitir 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 de varias nubes obtenga acceso al servicio de backend del balanceador de cargas.

Actualiza el registro A de 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 & Services > Credentials y selecciona el ID de cliente de OAuth del cliente de OAuth que usa tu instancia de Looker (Google Cloud Core).

  2. Haz clic en el botón Agregar URI para actualizar el campo Orígenes de JavaScript autorizados en tu cliente de OAuth y, así, 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 URIs 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 del usuario 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 con los siguientes pasos:

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

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

¿Qué sigue?