NEG de Internet de HTTPS de PSA de Looker

1. Introducción

Solo las instancias de Looker (Google Cloud Core) que usan el acceso privado a servicios para su conexión privada admiten una configuración de IP privada y pública.

Una instancia de Looker (Google Cloud Core) que tiene una conexión IP privada (acceso privado a servicios) y una conexión IP pública tiene una URL pública, y todo el tráfico entrante pasará por la conexión IP pública. El tráfico saliente se enruta a través de tu VPC, que se puede configurar para permitir solo el tráfico de IP privadas, como se ilustra en la figura 1.

Figure1

La comunicación con github.com se resuelve en una dirección IP pública, por lo que no se puede acceder a ella desde una instancia de Looker implementada como privada o pública y privada.

En este codelab, realizarás una conexión HTTPS de dirección sur a GitHub con un balanceador de cargas de proxy TCP interno y un grupo de extremos de red (NEG) de Internet invocado desde el PSA de Looker.

Qué aprenderás

• Requisitos de red
• Establece la conectividad a GitHub desde Looker con una conexión de prueba

Requisitos

• Proyecto de Google Cloud con permisos de propietario
• Cuenta y repositorio de GitHub
• Token de acceso personal de GitHub (clásico)
• Instancia de PSA de Looker existente con la opción Pública y privada o Solo privada habilitada

2. Qué compilarás

Implementarás un balanceador de cargas de proxy TCP interno y un NEG de Internet configurado con la dirección IP resuelta de github.com que aprovecha Cloud NAT para la salida de Internet a las organizaciones de github.com resueltas por Looker.

3. Requisitos de red

A continuación, se desglosan los requisitos de red:

Componentes	Descripción
VPC ($vpc_network)	VPC en modo personalizado
Subred de la regla de reenvío	Se usa para asignar una dirección IP al balanceador de cargas de proxy TCP interno regional
Subred de solo proxy	A cada uno de los proxies del balanceador de cargas se le asigna una dirección IP interna. Los paquetes enviados desde un proxy a una VM o un extremo de backend tienen una dirección IP de origen de la subred de solo proxy.
NEG de Internet	Es un recurso que se usa para definir un backend externo para el balanceador de cargas. No se puede acceder al extremo solo desde Cloud VPN o Cloud Interconnect.
Servicio de backend	Un servicio de backend actúa como puente entre tu balanceador de cargas y tus recursos de backend. En el instructivo, el servicio de backend está asociado con el NEG de Internet.
Cloud Router	Cloud NAT depende de los Cloud Routers para las capacidades del plano de control, pero no para la administración de sesiones de BGP.
Cloud NAT	El NEG de Internet regional aprovecha Cloud NAT para la salida a Internet.

4. Topología del codelab

5. Configuración y requisitos

Configuración del entorno de autoaprendizaje

1. Accede a consola de Google Cloud y crea un proyecto nuevo o reutiliza uno existente. Si aún no tienes una cuenta de Gmail o de Google Workspace, debes crear una.

• El Nombre del proyecto es el nombre visible de los participantes de este proyecto. Es una cadena de caracteres que no se utiliza en las APIs de Google. Puedes actualizarla cuando quieras.
• El ID del proyecto es único en todos los proyectos de Google Cloud y es inmutable (no se puede cambiar después de configurarlo). La consola de Cloud genera automáticamente una cadena única. Por lo general, no importa cuál sea. En la mayoría de los codelabs, deberás hacer referencia al ID de tu proyecto (suele identificarse como PROJECT_ID). Si no te gusta el ID que se generó, podrías generar otro aleatorio. También puedes probar uno propio y ver si está disponible. No se puede cambiar después de este paso y se usa el mismo durante todo el proyecto.
• Recuerda que hay un tercer valor, un número de proyecto, que usan algunas APIs. Obtén más información sobre estos tres valores en la documentación.

Precaución: El ID del proyecto es único a nivel global y no lo puede usar nadie más después de que lo hayas seleccionado. Eres el único usuario de ese ID. Incluso si se borra un proyecto, no se puede volver a usar el ID.

Nota: Si usas una cuenta de Gmail, puedes dejar la ubicación predeterminada como Sin organización. Si usas una cuenta de Google Workspace, elige una ubicación adecuada para tu organización.

2. A continuación, deberás habilitar la facturación en la consola de Cloud para usar las APIs o los recursos de Cloud. Ejecutar este codelab no costará mucho, tal vez nada. Para cerrar recursos y evitar que se generen cobros más allá de este instructivo, puedes borrar los recursos que creaste o borrar el proyecto. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de $300.

Inicia Cloud Shell

Si bien Google Cloud y Spanner se pueden operar de manera remota desde tu laptop, en este codelab usarás Google Cloud Shell, un entorno de línea de comandos que se ejecuta en la nube.

En Google Cloud Console, haz clic en el ícono de Cloud Shell en la barra de herramientas en la parte superior derecha:

El aprovisionamiento y la conexión al entorno deberían tomar solo unos minutos. Cuando termine el proceso, debería ver algo como lo siguiente:

Esta máquina virtual está cargada con todas las herramientas de desarrollo que necesitarás. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud, lo que permite mejorar considerablemente el rendimiento de la red y la autenticación. Todo tu trabajo en este codelab se puede hacer en un navegador. No es necesario que instales nada.

6. Antes de comenzar

Habilita las APIs

En Cloud Shell, asegúrate de que tu ID del proyecto esté configurado:

gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]
project=[YOUR-PROJECT-ID]
region=[YOUR-REGION]
vpc_network=[VPC Name]
echo $project
echo $region
echo $vpc-network

Habilita todos los servicios necesarios con el siguiente comando:

gcloud services enable compute.googleapis.com

7. Componentes de la red de VPC

Red de VPC

El requisito previo del instructivo es una instancia de Looker de PSA existente, por lo que la VPC asociada ya está creada.

Dentro de Cloud Shell, crea la subred de la regla de reenvío:

gcloud compute networks subnets create psa-fr-subnet --network $vpc_network --range 172.16.20.0/28 --region $region --enable-private-ip-google-access

Dentro de Cloud Shell, crea la subred regional de solo proxy:

gcloud compute networks subnets create $region-proxyonly-subnet \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=$region \
  --network=$vpc_network \
  --range=10.10.10.0/24

Crea la puerta de enlace de NAT pública

El balanceador de cargas del proxy TCP interno regional usa la puerta de enlace de NAT para la salida de Internet con la opción de configuración --endpoint-types=ENDPOINT_TYPE_MANAGED_PROXY_LB, por lo que la misma puerta de enlace de NAT no admitirá la salida de Internet de GCE/GKE. Implementa una puerta de enlace NAT adicional con –endpoint-types=ENDPOINT_TYPE_VM para la salida a Internet de GCE/GKE.

Dentro de Cloud Shell, crea el Cloud Router:

gcloud compute routers create $vpc_network-cloud-router --network $vpc_network --region $region

Dentro de Cloud Shell, crea la puerta de enlace de Cloud NAT que habilita la salida a Internet para el balanceador de cargas de proxy TCP:

gcloud compute routers nats create $vpc_network-natgw \
  --router=$vpc_network-cloud-router \
  --endpoint-types=ENDPOINT_TYPE_MANAGED_PROXY_LB \
  --nat-custom-subnet-ip-ranges=$region-proxyonly-subnet \
  --auto-allocate-nat-external-ips \
  --region=$region

Reserva la dirección IP del balanceador de cargas

Dentro de Cloud Shell, reserva una dirección IP interna para el balanceador de cargas que se usará más adelante como el registro A de DNS para github.com:

gcloud compute addresses create internet-neg-lb-ip \
  --region=$region \
  --subnet=psa-fr-subnet

Dentro de Cloud Shell, consulta la dirección IP reservada:

gcloud compute addresses describe internet-neg-lb-ip \
  --region=$region | grep -i address:

Resultado de ejemplo:

user@cloudshell$ gcloud compute addresses describe internet-neg-lb-ip   --region=$region | grep -i address:
address: 172.16.20.2

8. NEG de Internet

Existen dos formas de configurar el extremo externo al que hace referencia el NEG de Internet: INTERNET_FQDN_PORT o INTERNET_IP_PORT. Si se elige el formato INTERNET_IP_PORT (opción 1), solo se puede usar una dirección IP pública enrutable por Internet. Si se elige el formato INTERNET_FQDN_PORT (opción 2), el FQDN se puede resolver en una dirección IP pública enrutable por Internet o en una dirección IP privada, según el alcance del extremo: regional o global.

Opción 1: Configura el NEG de Internet con la dirección IP

El NEG de Internet requiere la dirección IP resuelta de Github.com, por lo que, para obtener el mejor rendimiento, abre una terminal local, realiza un dig y obtén la dirección IP de github.com.

El ejemplo de una terminal local genera la dirección IP resuelta 140.82.113.4

bash-3.2$ dig github.com
; <<>> DiG 9.10.6 <<>> github.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64801
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;github.com.                        IN        A
;; ANSWER SECTION:
github.com.                60        IN        A        140.82.113.4
;; Query time: 409 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Sep 26 15:50:45 CDT 2024
;; MSG SIZE  rcvd: 65

Crea un NEG de Internet y establece –network-endpoint-type en internet_ip_port.

Dentro de Cloud Shell, crea un NEG de Internet que se use para github.com:

gcloud compute network-endpoint-groups create github-internet-neg \
    --network-endpoint-type=INTERNET_IP_PORT \
    --network=$vpc_network \
    --region=$region

NOTA: ip=[IP resuelta de github.com],port=443 es obligatorio para admitir HTTPS

Dentro de Cloud Shell, actualiza el NEG de Internet github-internet-neg con la dirección IP resuelta de github.com y el puerto 443:

gcloud compute network-endpoint-groups update github-internet-neg \
    --add-endpoint="ip=[your-resolved-ip],port=443" \
    --region=$region

Ejemplo:

gcloud compute network-endpoint-groups update github-internet-neg \
    --add-endpoint="ip=140.82.113.4,port=443" \
    --region=$region

Opción 2: Configura el NEG de Internet con el FQDN

De manera opcional, puedes crear un NEG de Internet y establecer –network-endpoint-type en internet_FQDN_port.

Dentro de Cloud Shell, crea un NEG de Internet que se use para github.com:

gcloud compute network-endpoint-groups create github-internet-neg \
    --network-endpoint-type=INTERNET_FQDN_PORT \
    --network=$vpc_network \
    --region=$region

NOTA: El puerto 443 es obligatorio para admitir HTTPS.

Dentro de Cloud Shell, actualiza el NEG de Internet github-internet-neg con el FQDN github.com:

gcloud compute network-endpoint-groups update github-internet-neg \
    --add-endpoint="fqdn=github.com,port=443" \
    --region=$region

9. Crea el servicio de GitHub

Crea componentes del balanceador de cargas

En Cloud Shell, haz lo siguiente:

gcloud compute backend-services create psa-backend-svc  --protocol=tcp --region=$region --load-balancing-scheme=INTERNAL_MANAGED

gcloud compute backend-services add-backend psa-backend-svc --network-endpoint-group=github-internet-neg --network-endpoint-group-region=$region --region=$region

En Cloud Shell, crea un proxy TCP de destino para enrutar las solicitudes a tu servicio de backend:

gcloud compute target-tcp-proxies create producer-lb-tcp-proxy \
      --backend-service=psa-backend-svc  \
      --region=$region

En la siguiente sintaxis, crea una regla de reenvío (balanceador de cargas de proxy TCP interno).

En Cloud Shell, haz lo siguiente:

gcloud compute forwarding-rules create psa-github-fr \
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network-tier=PREMIUM \
     --network=$vpc_network \
     --subnet=psa-fr-subnet \
     --address=internet-neg-lb-ip \
     --target-tcp-proxy=producer-lb-tcp-proxy \
     --target-tcp-proxy-region=$region \
     --region=$region \
     --ports=443

10. Zona del DNS de GitHub

En la siguiente sección, crearás una política de respuesta de DNS para GitHub.com con un registro A que consta de la dirección IP del balanceador de cargas de proxy TCP interno.

A partir de entonces, el intercambio de tráfico de DNS compartirá la zona github.com con el PSA de Looker, lo que permitirá la conectividad a GitHub a través del balanceador de cargas interno en combinación con el NEG de Internet y Cloud NAT.

En Cloud Shell, crea la zona de la política de respuesta:

gcloud dns --project=$project response-policies create github-com --description="" --networks="$vpc_network"

En Cloud Shell, crea el registro A de DNS que consta de la dirección IP del balanceador de cargas del proxy TCP, [insert-your-ip-address]:

gcloud dns --project=$project response-policies rules create github --response-policy="github-com" --dns-name="github.com." --local-data=name="github.com.",type="A",ttl=300,rrdatas="[insert-your-ip-address]"

Ejemplo:

gcloud dns --project=$project response-policies rules create github --response-policy="github-com" --dns-name="github.com." --local-data=name="github.com.",type="A",ttl=300,rrdatas="172.16.20.2"

Actualiza el intercambio de tráfico de DNS

En esta sección, usarás la sintaxis "gcloud services peered-dns-domains create", que crea un dominio de DNS interconectado para una conexión de servicio privada que envía solicitudes de registros en un espacio de nombres determinado que se originan en la red de VPC del productor de servicios a la red de VPC del consumidor para que se resuelvan.

NOTA: Crear un peered-dns-domain para las redes de servicio influirá en todos los servicios administrados de Google que aprovechen la conexión de intercambio de tráfico de VPC de las redes de servicio.

En Cloud Shell, crea un peered-dns-domain que Looker consultará para github.com:

gcloud services peered-dns-domains create github-com --project=$project --network=$vpc_network --dns-suffix=github.com.

11. Prueba la conectividad con GitHub

En los siguientes pasos, usarás la consola de Looker para crear un proyecto y validar la conectividad HTTPS a github.com.

12. Crea un proyecto nuevo

Habilita el modo de desarrollo

En la consola de Looker, navega a:

Habilita el modo de desarrollo (en la parte inferior izquierda de la página). Una vez que lo selecciones, se mostrará el banner "Estás en modo de desarrollo".

Crea un proyecto nuevo

En la consola de Cloud, navega a:

Develop → Projects

Selecciona Nuevo proyecto de LookML

Proporciona un nombre para el proyecto, selecciona Proyecto en blanco y, luego, Crear proyecto.

Selecciona Configure Git.

Configura Git

Actualiza la URL del repositorio con los detalles de HTTPS de GitHub, asegúrate de agregar .git a la URL y, luego, selecciona Continuar.

Ejemplo:

Actualiza la selección con tu nombre de usuario de GitHub y tu token de acceso personal (clásico). Luego, selecciona Probar y finalizar la configuración.

Selecciona Acciones de Git

Selecciona Probar conexión de Git

Valida la prueba de conexión de Git

13. Limpia

En una sola terminal de Cloud Shell, borra los componentes del lab:

gcloud compute forwarding-rules delete psa-github-fr --region=$region -q

gcloud compute target-tcp-proxies delete producer-lb-tcp-proxy --region=$region -q

gcloud compute backend-services delete psa-backend-svc --region=$region -q

gcloud compute routers nats delete $vpc_network-natgw --router=$vpc_network-cloud-router --router-region=$region -q

gcloud compute routers delete $vpc_network-cloud-router --region=$region -q

gcloud compute network-endpoint-groups delete github-internet-neg --region=$region -q

gcloud compute addresses delete internet-neg-lb-ip --region=$region -q

gcloud compute networks subnets delete psa-fr-subnet $region-proxyonly-subnet --region=$region -q

gcloud services peered-dns-domains delete github-com --network=$vpc_network -q

gcloud dns --project=$project response-policies rules delete github --response-policy="github-com" -q

gcloud dns response-policies update github-com --networks= -q

gcloud dns response-policies delete github-com

14. Felicitaciones

¡Felicitaciones! Configuraste y validaste correctamente la conectividad a GitHub con la consola de Looker.

Cosmopup cree que los codelabs son increíbles.

¿Qué sigue?

Lecturas y videos adicionales

• Configura y prueba una conexión de Git | Looker | Google Cloud

Documentos de referencia

• Configura un balanceador de cargas de red de proxy interno regional con un backend externo
• Descripción general de Cloud NAT