Configura un dominio personalizado para una instancia de IP privada de Looker (Google Cloud Core): Tráfico que se origina en diferentes regiones

Puedes entregar tu instancia de Looker (Google Cloud Core) con un dominio web personalizado en lugar del dominio predeterminado que proporciona Looker (Google Cloud Core).

En esta página de documentación, se describe cómo configurar un dominio personalizado y acceder a él para instancias que cumplen con los siguientes criterios:

• La instancia solo tiene IP privada.
• El tráfico a la instancia se origina desde regiones diferentes a las que se encuentra en la instancia o a través de redes híbridas.

Si quieres implementar un dominio personalizado para este tipo de instancia, sigue estos pasos:

1. Configura el dominio personalizado.
2. Crea VM 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 del 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 para ella.

Antes de comenzar

Nota: Los dominios personalizados no se pueden crear con un dominio de looker.com.

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.

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

Crea un dominio personalizado

Nota: No puedes modificar un dominio personalizado una vez que se crea. Si quieres realizar cambios en el dominio personalizado, debes borrar el dominio personalizado existente y crear uno nuevo.

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

Nota: La actualización del dominio personalizado tarda entre 10 y 15 minutos en completarse.

En la columna URL de la instancia en la página Instancias de la consola de Google Cloud, se mostrará tu dominio personalizado.

Después de crear tu dominio personalizado, puedes ver su información 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:

• Administrador de Looker (roles/looker.admin)
• Administrador de instancias de Compute (v1) (roles/compute.instanceAdmin.v1)
• Administrador de DNS (roles/dns.admin)
• Administrador de balanceador de cargas de Compute (roles/compute.loadBalancerAdmin)
• Administrador de la red de Compute (roles/compute.networkAdmin)
• Administrador de seguridad de Compute (roles/compute.securityAdmin)
• Usa Google OAuth: Editor de configuración de OAuth (roles/oauthconfig.editor)

Si quieres obtener más información para otorgar roles, consulta Administra el acceso.

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

Descripción general de las Herramientas de redes

Nota: En una situación de prueba de concepto, puedes configurar un servidor proxy inverso y evitar configurar un balanceador de cargas.

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:

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 dentro de la misma región que la instancia de Looker (Google Cloud Core), pero en zonas diferentes entre sí.
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 que la resolución de DNS llegue a la IU de Looker (Google Cloud Core). 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

Nota: En este ejemplo de configuración, se usan servidores proxy NGNIX en RHEL y se proporciona como punto de partida para la configuración de proxy personalizada. Esta configuración se probó con la versión 1.22.1 de NGINX instalada en la versión 8.9 de Red Hat Enterprise Linux.

En el siguiente ejemplo, se usa NGINX versión 1.22.1 y Red Hat Enterprise Linux versión 8.9 (Ootpa). 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 un resultado similar al 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 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 de dominio personalizado de Looker (Google Cloud Core). Este certificado será el que presentará el proxy 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 que se haya creado el certificado, guarda los archivos relevantes en los directorios certs y private de cada VM del 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 reciba 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.

   Nota: Si guardaste los archivos del certificado en una ruta diferente, asegúrate de que la ruta se refleje en el archivo de configuración /etc/nginx/snippets/self-signed.conf.

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 NGINX ssl-params.conf, que se puede usar para almacenar parámetros que se pueden volver a usar en configuraciones de NGINX futuras.

   Nota: Si implementas ssl-params.conf, quita el comentario de include snippets/ssl-params.conf en el archivo nginx.conf.

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

   Nota: Inhabilita la seguridad de transporte estricta por el momento. Si deseas habilitar una seguridad de transporte estricta y comprendes las implicaciones de hacerlo, puedes quitar el comentario de la línea que comienza con add_header Strict-Transport-Security.

8. Para configurar SELinux con el objetivo de permitir que NGINX reenvíe el tráfico a la IP de entrada de Looker (Google Cloud Core), establece el parámetro booleano de SELinux httpd_can_network_connect 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

Nota: La siguiente configuración se probó con la versión 2.4.6 de Apache instalada en Red Hat Enterprise Linux 7.9.

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 comprobar qué versiones de Red Hat están usando 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): 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 del 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 (NEG) zonales 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 quieres 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 de 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 VM del servidor proxy se agregue a un NEG como un 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: La cantidad de tiempo que espera Google Cloud para obtener 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: Especifica la la cantidad de sondeos secuenciales que deben realizarse con éxito o fallar para que la instancia de VM considerarse sano o no saludable. 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: 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 estás agregando.
   • 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 están conectadas 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: 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: 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 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 del proxy cuyas cargas se balancean 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 múltiples nubes obtenga acceso al servicio de backend del balanceador de cargas.

Actualiza el registro A del DNS

Cambiar 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

Nota: Puedes usar cualquier cliente de OAuth para crear credenciales de autorización para tu instancia de Looker (Google Cloud Core). A modo de ejemplo, estos pasos te guiarán en la actualización de las credenciales con la consola de Google Cloud. Si usas otro cliente, ajusta los pasos según corresponda.

1. Accede a tu cliente de OAuth en la consola de Google Cloud, a APIs & Servicios > Credentials y selecciona el ID de cliente de OAuth para el 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 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 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 para la instancia de Looker (Google Cloud Core) antes de agregar usuarios a la instancia.

Soluciona errores relacionados con la política de HSTS

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 la 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 para el dominio personalizado aparecerán en Encontrado:.
3. En Borrar las políticas de seguridad del dominio, ingresa el dominio personalizado en el campo Dominio.
4. Haz clic en Borrar para eliminar las políticas.

¿Qué sigue?

• Administra usuarios en Looker (Google Cloud Core)
• Configura tu instancia de Looker (Google Cloud Core)
• Conecta Looker (Google Cloud Core) a tu base de datos