Esta secção descreve a arquitetura de alto nível para estabelecer o controlo de saída de instâncias privadas do Cloud Data Fusion durante a fase de desenvolvimento e a fase de execução do pipeline.
O diagrama de arquitetura do sistema seguinte mostra como uma instância privada do Cloud Data Fusion se liga à Internet pública quando desenvolve um pipeline:
Pode controlar as ligações a aplicações SaaS e serviços de nuvem pública de terceiros durante o desenvolvimento ou a execução do pipeline, encaminhando todo o tráfego de saída através de projetos de clientes. Este processo usa os seguintes recursos:
Rota de rede VPC personalizada: uma rede VPC personalizada encaminha o tráfego através de uma rota personalizada importada para VMs de gateway, que exportam para uma VPC de projeto de inquilino através do peering de VPC.
VM de proxy: uma VM de proxy encaminha o tráfego de saída do Google Cloud projeto de inquilino do Cloud Data Fusion para o destino especificado através da Internet pública. Cria e gere uma VM de gateway nos seus projetos de cliente. Recomendamos que os configure numa configuração de alta disponibilidade (HA) através de um balanceador de carga interno (ILB). Se tiver várias instâncias privadas do Cloud Data Fusion que usam a mesma rede VPC, pode reutilizar a mesma VM na VPC.
Antes de começar
Pode estabelecer ligação a uma origem pública a partir de uma instância privada nas versões 6.4 ou posteriores do Cloud Data Fusion. Para usar uma dessas versões, pode criar uma nova instância privada do Cloud Data Fusion ou atualizar uma instância existente.
Quando criar uma ligação de peering de rede de VPC para a sua instância, selecione Exportar rotas.
Configure o controlo de saída durante o desenvolvimento do pipeline
O controlo de saída permite-lhe controlar ou filtrar o que pode sair da sua rede, o que é útil em ambientes dos VPC Service Controls. Não existe nenhum proxy de rede preferencial para realizar esta tarefa. Alguns exemplos de proxies incluem Squid proxy, HAProxy e Envoy.
Os exemplos neste guia descrevem como configurar o proxy HTTP para a filtragem HTTP em instâncias de VMs que usam uma imagem Debian. Os exemplos usam um servidor proxy Squid, que é uma das formas de configurar um servidor proxy.
Crie uma VM de proxy
Crie uma VM na mesma VPC que a sua instância privada do Cloud Data Fusion com o seguinte script de arranque e encaminhamento de IP.
Este script instala o proxy Squid e configura-o para intercetar o tráfego HTTP e permitir os domínios .squid-cache.org e .google.com. Pode substituir estes domínios pelos domínios que quer associar à sua instância do Cloud Data Fusion.
Consola
Aceda à página Instâncias de VM.
Clique em Criar instância.
Use a mesma VPC que tem o intercâmbio de redes configurado com a instância privada do Cloud Data Fusion. Para mais informações sobre a interligação de redes VPC neste cenário, consulte a secção Antes de começar.
Ative o encaminhamento de IP para a instância na mesma rede que a instância do Cloud Data Fusion.
No campo Script de arranque, introduza o seguinte script:
#! /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
Crie um trajeto personalizado
Crie uma rota personalizada para estabelecer ligação à instância de VM de gateway que criou.
Consola
Para criar o seu trajeto na Google Cloud consola, consulte o artigo Adicionar um trajeto estático.
Quando configurar o trajeto, faça o seguinte:
- Defina a Prioridade como superior ou igual a
1001. - Use o mesmo projeto e VPC que a instância privada do Cloud Data Fusion.
- Certifique-se de que a configuração do peering de rede VPC permite a exportação de rotas, para que a VPC do projeto de inquilino do Cloud Data Fusion importe esta rota personalizada através do peering de rede VPC.
gcloud
Para criar a sua rota na CLI gcloud:
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
Configure o controlo de saída para a execução do pipeline
Depois de conseguir aceder à Internet pública com nomes de anfitriões permitidos na pré-visualização e no Wrangler no seu ambiente de design, implemente o pipeline. As pipelines do Cloud Data Fusion implementadas são executadas em clusters do Dataproc por predefinição.
Para garantir que todo o tráfego da Internet pública do cluster do Dataproc passa por uma ou mais VMs de proxy, adicione a zona e os registos de DNS privados. Este passo é obrigatório porque o Cloud NAT não suporta a filtragem.
Nos registos DNS, inclua o endereço IP da VM de proxy ou do ILB.
Implemente o seu pipeline
Depois de validar o pipeline na fase de conceção, implemente o pipeline. Os pipelines implementados são executados em clusters do Dataproc por predefinição.
Para garantir que todo o tráfego da Internet pública do cluster do Dataproc passa por uma ou mais VMs de proxy, adicione uma rota personalizada com etiquetas de instância proxy e prioridade 1000 à mesma VPC que as VMs do Dataproc:
Modifique o pipeline para usar etiquetas do Dataproc, porque o Cloud NAT não suporta atualmente qualquer filtragem de saída.
O que se segue?
- Saiba mais sobre as redes no Cloud Data Fusion.