1. Introducción
Solo las instancias de Looker (Google Cloud Core) que usan acceso a servicios privados 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 de IP privada (acceso a servicios privados) y una conexión de IP pública tiene una URL pública, y todo el tráfico entrante pasará por la conexión de 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 privada, 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 norte a sur a GitHub con un balanceador de cargas de proxy TCP interno y un grupo de extremos de red de Internet (NEG) 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 Public + Private o solo Private habilitados
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 a Internet a las organizaciones de github.com que resuelve Looker.
3. Requisitos de red
A continuación, se muestra un desglose de 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 regional interno. |
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 un puente entre el 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 se basa en Cloud Routers para las funciones 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
- Accede a Google Cloud Console 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.
- 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 existente de PSA Looker, por lo que ya se creó la VPC asociada.
En 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
En 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 de proxy TCP interno regional usa la puerta de enlace de NAT para la salida a Internet con la opción de configuración –endpoint-types=ENDPOINT_TYPE_MANAGED_PROXY_LB, por lo que la misma NATGW no admitirá la salida a Internet de GCE/GKE. Implementa una puerta de enlace de NAT adicional con el parámetro –endpoint-types=ENDPOINT_TYPE_VM para la salida a Internet de GCE/GKE.
En Cloud Shell, crea el Cloud Router:
gcloud compute routers create $vpc_network-cloud-router --network $vpc_network --region $region
En 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
En 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
En 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 maneras 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 tanto, para obtener el mejor rendimiento, abre una terminal local, realiza un comando 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 el parámetro –network-endpoint-type en internet_ip_port.
En 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
En 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 FQDN
De forma opcional, puedes crear un NEG de Internet y establecer el tipo de extremo de red en internet_FQDN_port.
En 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
En 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 conste de la dirección IP del balanceador de cargas de proxy TCP interno.
A partir de ese momento, 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 de 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 DNS con intercambio para una conexión de servicio privada que envía solicitudes de registros en un espacio de nombres determinado que se origina en la red de VPC del productor de servicios a la red de VPC del consumidor para que se resuelvan.
En Cloud Shell, crea un peered-dns-domain que el buscador 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 a GitHub
En los siguientes pasos, usarás Looker Console para crear un proyecto que valide la conectividad HTTPS a github.com.
12. Crea un proyecto nuevo
Habilita el modo de desarrollo
En Looker Console, navega a:
Habilita el modo de desarrollo (página inferior izquierda). Una vez que lo hagas, se mostrará el banner "Estás en modo de desarrollo".
Crea un proyecto nuevo
En la consola de Cloud, navega a:
Desarrollar → Proyectos
Selecciona Nuevo proyecto de LookML
Proporciona un nombre para el proyecto, selecciona Proyecto en blanco y, luego, Crear proyecto.
Selecciona Configurar Git.
Configura Git
Actualiza la URL del repositorio con los detalles de GitHub HTTPS, 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 el token de acceso personal (clásico) y, luego, selecciona Probar y finalizar configuración.
Selecciona Acciones de Git
Selecciona Probar conexión de Git
Valida la prueba de conexión de Git
13. Limpia
Desde 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 Looker Console.
Cosmopup piensa que los codelabs son geniales.
