En esta sección se describe la arquitectura de alto nivel para establecer el control de salida de las instancias privadas de Cloud Data Fusion durante la fase de desarrollo y la fase de ejecución de la canalización.
En el siguiente diagrama de arquitectura del sistema se muestra cómo se conecta una instancia privada de Cloud Data Fusion a Internet público cuando desarrollas una canalización:
Puedes controlar las conexiones a aplicaciones SaaS y servicios de nube pública de terceros durante el desarrollo o la ejecución de la canalización. Para ello, debes enrutar todo el tráfico de salida a través de proyectos de clientes. Este proceso utiliza los siguientes recursos:
Ruta de red de VPC personalizada: una ruta de red de VPC personalizada dirige el tráfico a través de una ruta personalizada importada a las VMs de la pasarela, que exportan a una VPC de proyecto de un arrendatario mediante el emparejamiento de VPCs.
Máquina virtual proxy: una máquina virtual proxy enruta el tráfico de salida de Google Cloud desde el proyecto de inquilino de Cloud Data Fusion hasta el destino especificado a través de Internet público. Crea y gestiona una VM de pasarela en tus proyectos de cliente. Te recomendamos que los configures en una configuración de alta disponibilidad (HA) con un balanceador de carga interno (ILB). Si tienes varias instancias privadas de Cloud Data Fusion que usan la misma red de VPC, puedes reutilizar la misma VM en la VPC.
Antes de empezar
Puedes conectarte a una fuente pública desde una instancia privada en Cloud Data Fusion 6.4 o versiones posteriores. Para usar una de esas versiones, puedes crear una instancia privada de Cloud Data Fusion o actualizar una instancia.
Cuando crees una conexión de emparejamiento de redes de VPC para tu instancia, selecciona Exportar rutas.
Configurar el control de salida durante el desarrollo de la canalización
El control de salida te permite controlar o filtrar lo que puede salir de tu red, lo que resulta útil en entornos de Controles de Servicio de VPC. No hay ningún proxy de red preferido para realizar esta tarea. Algunos ejemplos de proxies son Squid proxy, HAProxy y Envoy.
En los ejemplos de esta guía se describe cómo configurar un proxy HTTP para el filtrado HTTP en instancias de VM que usan una imagen de Debian. En los ejemplos se usa un servidor proxy Squid, que es una de las formas de configurar un servidor proxy.
Crear una VM proxy
Crea una VM en la misma VPC que tu instancia privada de Cloud Data Fusion con la siguiente secuencia de comandos de inicio y reenvío de IP.
Esta secuencia de comandos instala el proxy Squid y lo configura para interceptar el tráfico HTTP y permitir los dominios .squid-cache.org y .google.com. Puede sustituir estos dominios por los que quiera conectar con su instancia de Cloud Data Fusion.
Consola
Ve a la página Instancias de VM.
Haz clic en Crear instancia.
Usa la misma VPC que tiene configurado el emparejamiento de redes con la instancia privada de Cloud Data Fusion. Para obtener más información sobre el emparejamiento entre redes de VPC en este caso, consulta la sección Antes de empezar.
Habilita el reenvío de IP para la instancia en la misma red que la instancia de Cloud Data Fusion.
En el campo Secuencia de comandos de inicio, introduce la siguiente secuencia de comandos:
#! /bin/bash apt-get -y install squid3 cat <<EOF > /etc/squid/conf.d/debian.conf # # Squid configuration settings for Debian # logformat squid %ts.%03tu %6tr %>a %Ss/%03>Hs %<st %rm %ru %ssl::>sni %Sh/%<a %mt logfile_rotate 10 debug_options rotate=10 # configure intercept port http_port 3129 intercept # allow only certain sites acl allowed_domains dstdomain "/etc/squid/allowed_domains.txt" http_access allow allowed_domains # deny all other http requests http_access deny all EOF # Create a file with allowed egress domains # Replace these example domains with the domains that you want to allow # egress from in Data Fusion pipelines cat <<EOF > /etc/squid/allowed_domains.txt .squid-cache.org .google.com EOF /etc/init.d/squid restart iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3129 echo 1 > /proc/sys/net/ipv4/ip_forward echo net.ipv4.ip_forward=1 > /etc/sysctl.d/11-gce-network-security.conf iptables -t nat -A POSTROUTING -s 0.0.0.0/0 -p tcp --dport 443 -j MASQUERADE
gcloud
export CDF_PROJECT=<cdf-project>
export PROXY_VM=<proxy-vm>
export ZONE=<vm-zone>
export SUBNET=<subnet>
export VPC_NETWORK=<vpc-network>
export COMPUTE_ENGINE_SA=<compute-engine-sa>
gcloud beta compute --project=$CDF_PROJECT instances create $PROXY_VM --zone=$ZONE --machine-type=e2-medium --subnet=$SUBNET --no-address --metadata=startup-script=\#\!\ /bin/bash$'\n'apt-get\ -y\ install\ squid3$'\n'cat\ \<\<EOF\ \>\ /etc/squid/conf.d/debian.conf$'\n'\#$'\n'\#\ Squid\ configuration\ settings\ for\ Debian$'\n'\#$'\n'logformat\ squid\ \%ts.\%03tu\ \%6tr\ \%\>a\ \%Ss/\%03\>Hs\ \%\<st\ \%rm\ \%ru\ \%ssl::\>sni\ \%Sh/\%\<a\ \%mt$'\n'logfile_rotate\ 10$'\n'debug_options\ rotate=10$'\n'$'\n'\#\ configure\ intercept\ port$'\n'http_port\ 3129\ intercept$'\n'$'\n'\#\ allow\ only\ certain\ sites$'\n'acl\ allowed_domains\ dstdomain\ \"/etc/squid/allowed_domains.txt\"$'\n'http_access\ allow\ allowed_domains$'\n'$'\n'\#\ deny\ all\ other\ http\ requests$'\n'http_access\ deny\ all$'\n'EOF$'\n'$'\n'$'\n'\#\ Create\ a\ file\ with\ allowed\ egress\ domains$'\n'\#\ Replace\ these\ example\ domains\ with\ the\ domains\ that\ you\ want\ to\ allow\ $'\n'\#\ egress\ from\ in\ Data\ Fusion\ pipelines$'\n'cat\ \<\<EOF\ \>\ /etc/squid/allowed_domains.txt$'\n'.squid-cache.org$'\n'.google.com$'\n'EOF$'\n'$'\n'/etc/init.d/squid\ restart$'\n'$'\n'iptables\ -t\ nat\ -A\ PREROUTING\ -p\ tcp\ --dport\ 80\ -j\ REDIRECT\ --to-port\ 3129$'\n'echo\ 1\ \>\ /proc/sys/net/ipv4/ip_forward$'\n'echo\ net.ipv4.ip_forward=1\ \>\ /etc/sysctl.d/11-gce-network-security.conf$'\n'iptables\ -t\ nat\ -A\ POSTROUTING\ -s\ 0.0.0.0/0\ -p\ tcp\ --dport\ 443\ -j\ MASQUERADE --can-ip-forward --maintenance-policy=MIGRATE --service-account=$COMPUTE_ENGINE_SA --scopes=https://www.googleapis.com/auth/devstorage.read_only,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/trace.append --tags=http-server,https-server --image=debian-10-buster-v20210420 --image-project=debian-cloud --boot-disk-size=10GB --boot-disk-type=pd-balanced --boot-disk-device-name=instance-1 --no-shielded-secure-boot --shielded-vtpm --shielded-integrity-monitoring --reservation-affinity=any
gcloud compute --project=$CDF_PROJECT firewall-rules create egress-allow-http --direction=INGRESS --priority=1000 --network=$VPC_NETWORK --action=ALLOW --rules=tcp:80 --source-ranges=0.0.0.0/0 --target-tags=https-server
gcloud compute --project=$CDF_PROJECT firewall-rules create egress-allow-https --direction=INGRESS --priority=1000 --network=$VPC_NETWORK --action=ALLOW --rules=tcp:443 --source-ranges=0.0.0.0/0 --target-tags=https-server
Crear una ruta personalizada
Crea una ruta personalizada para conectarte a la instancia de VM de pasarela que has creado.
Consola
Para crear tu ruta en la consola Google Cloud , consulta Añadir una ruta estática.
Cuando configures la ruta, haz lo siguiente:
- Asigna al campo Prioridad un valor igual o superior a
1001. - Usa el mismo proyecto y la misma VPC que la instancia privada de Cloud Data Fusion.
- Asegúrate de que la configuración del emparejamiento de redes de VPC permita exportar rutas para que la VPC del proyecto de inquilino de Cloud Data Fusion importe esta ruta personalizada mediante el emparejamiento de redes de VPC.
gcloud
Para crear tu ruta en la CLI de gcloud, haz lo siguiente:
gcloud beta compute routes create $ROUTE --project=$CDF_PROJECT \ --network=$VPC_NETWORK --priority=1001 \ --destination-range=0.0.0.0/0 \ --next-hop-instance=$PROXY_VM \ --next-hop-instance-zone=$ZONE
Configurar el control de salida para la ejecución de la canalización
Cuando puedas acceder a Internet público con los nombres de host permitidos en Vista Previa y Wrangler en tu entorno de diseño, implementa tu canalización. Los flujos de procesamiento de Cloud Data Fusion implementados se ejecutan en clústeres de Dataproc de forma predeterminada.
Para asegurarte de que todo el tráfico de Internet público del clúster de Dataproc pase por una o varias VMs proxy, añade la zona y los registros de DNS privados. Este paso es obligatorio porque Cloud NAT no admite el filtrado.
En los registros DNS, incluye la dirección IP de la VM proxy o del ILB.
Desplegar un flujo de procesamiento
Una vez que hayas verificado la canalización en la fase de diseño, implementa la canalización. Los flujos de trabajo implementados se ejecutan en clústeres de Dataproc de forma predeterminada.
Para asegurarse de que todo el tráfico público de Internet del clúster de Dataproc pase por una o varias VMs proxy, añada una ruta personalizada con las etiquetas de instancia proxy y la prioridad 1000 a la misma VPC que las VMs de Dataproc:
Modifica tu flujo de procesamiento para que use etiquetas de Dataproc, ya que Cloud NAT no admite ningún filtrado de salida.
Siguientes pasos
- Consulta más información sobre las redes en Cloud Data Fusion.