En este documento, se explica cómo completar las siguientes tareas:
- Configura instancias de máquina virtual (VM) de Dataflow para el acceso a Internet
- Crea etiquetas de red
- Define reglas de firewall para la red asociada a tus trabajos de Dataflow
En este documento, se requiere que tengas conocimientos básicos de las redes de Google Cloud. A fin de definir una red para tu trabajo de Dataflow, consulta Especificar tu red y subred. Para obtener más información sobre cómo solucionar problemas de herramientas de redes, consulta Solucionar problemas de herramientas de redes de Dataflow.
Acceso a las APIs de Google Cloud para Dataflow
Las máquinas virtuales (VM) de trabajador de Dataflow deben llegar a las API y los servicios de Google Cloud. El conjunto de extremos de Google Cloud dependientes puede cambiar con el tiempo, pero todos son compatibles con los Controles del servicio de VPC. Usa uno de los siguientes métodos para configurar el acceso a las APIs de Google Cloud:
Configura el Acceso privado a Google. Con el Acceso privado a Google, las VM que solo tienen direcciones IP internas pueden acceder a las direcciones IP de Google Cloud y servicios.
Configura una dirección IP de extremo de Private Service Connect para acceder a las API y los servicios de Google Cloud.
Configura las VMs de trabajador con direcciones IP externas.
De forma predeterminada, las reglas de firewall y la configuración de DNS permiten el acceso a las APIs de Google Cloud. Sin embargo, es posible que estés restringiendo de forma activa el acceso a
un subconjunto de las APIs de Google Cloud, por ejemplo, si usas
Controles del servicio de VPC.
En este caso, como mínimo, proporciona acceso a restricted.googleapis.com
. Si usas Private Service Connect, proporciona acceso al paquete vpc-sc
.
Proporcionar acceso a dominios más permisivos, como private.googleapis.com
, también proporciona la funcionalidad requerida.
Para permitir el acceso a las APIs de Google Cloud necesarias a través de un dominio determinado, tu entorno debe cumplir con los siguientes requisitos:
Las reglas de firewall deben permitir la salida a todos los rangos de direcciones del dominio elegido.
El DNS debe resolver
*.googleapis.com
en el dominio que elegiste.
Por ejemplo, si tus reglas de firewall limitan la salida al rango de direcciones restricted.googleapis.com
, *.googleapis.com
debe resolverse a direcciones dentro de ese rango.
Para obtener más información, consulta Configura el DNS para googleapis.com.
Del mismo modo, si usas Private Service Connect, debes crear registros DNS para el dominio predeterminado googleapis.com
para garantizar el acceso a, al menos, todos los servicios del paquete vpc-sc
.
Acceso a Internet para Dataflow
Según tu caso de uso, tus VMs también pueden necesitar acceso a recursos fuera de Google Cloud. Usa uno de los siguientes métodos para configurar el acceso a Internet para Dataflow:
Configura las VM de trabajador con una dirección IP externa para que cumplan con los requisitos de acceso a Internet.
Configura una solución NAT, como Cloud NAT. Esta opción es para ejecutar trabajos que acceden a las API y los servicios fuera de Google Cloud que requieren acceso a Internet. Por ejemplo, los trabajos del SDK de Python pueden requerir acceso al Índice de paquetes de Python (PyPI) para descargar dependencias de canalizaciones. En este caso, debes configurar VMs de trabajador con direcciones IP externas o usar Cloud NAT. También puedes proporcionar dependencias de canalización de Python durante el envío de trabajos. Por ejemplo, puedes usar contenedores personalizados para proporcionar dependencias de canalización de Python, lo que quita la necesidad de acceder a PyPI en el entorno de ejecución.
Para obtener más información, consulta Administra las dependencias de canalización de Python en la documentación de Apache Beam.
Desactiva la dirección IP externa
De forma predeterminada, Dataflow asigna direcciones IP internas y externas a los trabajadores. Cuando desactivas las direcciones IP externas, el trabajo de Dataflow solo puede acceder a los recursos en los siguientes lugares:
- Otra instancia en la misma red de VPC
- Una red de VPC compartida
- Una red con intercambio de tráfico de red de VPC habilitado
Sin direcciones IP externas, aún puedes realizar tareas administrativas y de supervisión. Puedes acceder a los trabajadores mediante SSH a través de las opciones enumeradas en la lista anterior. Sin embargo, la canalización no puede acceder a Internet y los hosts de Internet no pueden acceder a tus trabajadores de Dataflow.
Si no usas direcciones IP externas, puedes proteger mejor tu infraestructura de procesamiento de datos. También puedes reducir la cantidad de direcciones IP externas que consumes de la cuota del proyecto de Google Cloud.
Si desactivas las direcciones IP externas, tus trabajos de Dataflow no podrán acceder a las APIs ni a los servicios fuera de Google Cloud que requieren acceso a Internet.
Para desactivar las direcciones IP externas, realiza una de las siguientes acciones:
Java
- Habilita el Acceso privado a Google para la red o subred.
- En los parámetros de tu trabajo de Dataflow, especifica
--usePublicIps=false
y--network=NETWORK-NAME
o--subnetwork=SUBNETWORK-NAME
.Según tu elección, reemplaza una de las siguientes acciones:
- NETWORK-NAME: el nombre de tu red de Compute Engine.
- SUBNETWORK-NAME: el nombre de tu subred de Compute Engine.
Python
- Para almacenar en etapa intermedia todas las dependencias de paquetes de Python, sigue las instrucciones de las dependencias de canalizaciones de Apache Beam.
- Habilita el Acceso privado a Google para la red o subred.
- En los parámetros de tu trabajo de Dataflow, especifica
--no_use_public_ips
y--network=NETWORK
o--subnetwork=SUBNETWORK
. - NETWORK-NAME: el nombre de tu red de Compute Engine.
- SUBNETWORK-NAME: el nombre de tu subred de Compute Engine.
Según tu elección, reemplaza una de las siguientes acciones:
Go
- Habilita el Acceso privado a Google para la red o subred.
- En los parámetros de tu trabajo de Dataflow, especifica
--no_use_public_ips
y--network=NETWORK
o--subnetwork=SUBNETWORK
. - NETWORK-NAME: el nombre de tu red de Compute Engine.
- SUBNETWORK-NAME: el nombre de tu subred de Compute Engine.
Según tu elección, reemplaza una de las siguientes acciones:
Etiquetas de red para Dataflow
Las etiquetas de red son atributos de texto que puedes adjuntar a las VM de Compute Engine. Las etiquetas de red te permiten hacer que las reglas de firewall de la red de VPC y ciertas rutas estáticas personalizadas se puedan aplicar a instancias de VM específicas. Dataflow admite la adición de etiquetas de red a todas las VM de trabajador que ejecutan un trabajo de Dataflow en particular.
Incluso si no usas el parámetro de red, Dataflow siempre agrega la etiqueta de red predeterminada dataflow
a cada VM de trabajador que creas.
Habilita las etiquetas de red
Puedes especificar las etiquetas de red solo cuando ejecutas la plantilla de trabajo de Dataflow para crear un trabajo. Después de que se inicia un trabajo, no puedes agregar más etiquetas de red al trabajo. Para aplicar etiquetas de red adicionales a un trabajo, debes volver a crear la plantilla de trabajo con las etiquetas de red requeridas.
Agrega lo siguiente al código de tu canalización, ya sea que lo ejecutes en Java o Python:
--experiments=use_network_tags=TAG-NAME
Reemplaza TAG-NAME por los nombres de las etiquetas. Si agregas más de una etiqueta, separa cada una con un punto y coma (;
) como se muestra en el siguiente formato: TAG-NAME-1;TAG-NAME-2;TAG-NAME-3;....
Habilita las etiquetas de red para las VMs plantillas flexibles
Cuando uses plantillas flexibles, para habilitar las etiquetas de red para las VMs de trabajador de Dataflow, usa la opción --additional-experiments
como se muestra en el siguiente ejemplo:
--additional-experiments=use_network_tags=TAG-NAME
Para habilitar las etiquetas de red para las VMs de trabajador y las VMs de selector, usa las siguientes dos opciones:
--additional-experiments=use_network_tags=TAG-NAME
--additional-experiments=use_network_tags_for_flex_templates=TAG-NAME
Reemplaza TAG-NAME por los nombres de las etiquetas. Si agregas más de una etiqueta, separa cada una con un punto y coma (;
) como se muestra en el siguiente formato: TAG-NAME-1;TAG-NAME-2;TAG-NAME-3;....
Después de habilitar las etiquetas de red, las etiquetas se analizan y se adjuntan a las VMs.
Consulta los límites que se aplican a las etiquetas de red.
Reglas de firewall para Dataflow
Las reglas de firewall permiten o rechazan el tráfico desde y hacia tus VMs. Si tus trabajos de Dataflow usan Dataflow Shuffle o Streaming Engine, solo debes asegurarte de que las reglas de firewall permitan el acceso a las APIs de Google Cloud.
De lo contrario, debes configurar reglas de firewall adicionales para que las VMs de Dataflow puedan enviar y recibir tráfico de red en el puerto TCP 12345
para los trabajos de transmisión y en el puerto TCP 12346
para los trabajos por lotes.
Un propietario, editor o administrador de seguridad del proyecto debe crear las reglas de firewall necesarias en la red de VPC que usan las VMs de Dataflow.
Antes de configurar las reglas de firewall para Dataflow, lee los siguientes documentos:
Descripción general de las reglas de firewall de VPC y Usa reglas de firewall de VPC
Descripción general de las políticas de firewall jerárquicas y Usa reglas y políticas de firewall jerárquicas
Cuando crees reglas de firewall para Dataflow, especifica las etiquetas de red de Dataflow. De lo contrario, las reglas de firewall se aplican a todas las VM de la red de VPC.
Cuando corresponda, las políticas de firewall jerárquicas se evalúan primero y estas reglas interrumpen las reglas de firewall de VPC. Si el trabajo de Dataflow está en un proyecto que forma parte de una organización o carpeta en la que se usan las políticas de firewall jerárquicas, se requiere el rol compute.orgFirewallPolicyAdmin
para realizar modificaciones en las políticas.
Si no creas etiquetas de red personalizadas cuando ejecutas el código de la canalización, las VMs de Dataflow usan la etiqueta predeterminada dataflow
. Si no hay etiquetas de red personalizadas, crea las reglas de firewall con la etiqueta dataflow
predeterminada.
Si creas etiquetas de red personalizadas cuando ejecutas el código de canalización, las VMs de Dataflow usan esas etiquetas. Crea las reglas de firewall con las etiquetas personalizadas.
Algunas redes de VPC, como la red default
creada de forma automática, incluyen una regla default-allow-internal
que cumple con los requisitos de firewall de Dataflow.
Ejemplo de regla de entrada de firewall
La regla de firewall de entrada permite que las VM de Dataflow reciban paquetes entre sí. Siempre debes crear reglas de firewall de permiso de entrada o el tráfico siempre está bloqueado, incluso si las reglas de salida permiten dicho tráfico.
En el siguiente ejemplo, se crea una regla de entrada de firewall para Dataflow, en la que todas las VM de trabajador tienen la etiqueta de red predeterminada dataflow
. Un propietario, editor o administrador de seguridad del proyecto puede usar el siguiente comando de gcloud
para crear una regla de permiso de entrada que permita el tráfico en los puertos TCP 12345
y 12346
de las VM con la etiqueta de red dataflow
a las VM con la misma etiqueta:
gcloud compute firewall-rules create FIREWALL_RULE_NAME_INGRESS \
--action=allow \
--direction=ingress \
--network=NETWORK \
--target-tags=CUSTOM_TAG \
--source-tags=CUSTOM_TAG \
--priority=PRIORITY_NUM \
--rules tcp:12345-12346
Reemplaza lo siguiente:
FIREWALL_RULE_NAME_INGRESS
es un nombre para la regla de firewall.NETWORK
es el nombre de la red que usan las VM de trabajadores.CUSTOM_TAG
: es una lista delimitada por comas de etiquetas de red.A continuación, se muestra una lista de lineamientos para usar etiquetas de red:
Si omites
--target-tags
, la regla se aplica a todas las VM de la red de VPC.Si omites
--source-tags
y todas las demás especificaciones de origen, se permite el tráfico de cualquier fuente.Si no especificaste etiquetas de red personalizadas y quieres que la regla sea específica de las VM de Dataflow, usa
dataflow
como etiqueta de red.Si especificaste etiquetas de red personalizadas y quieres que la regla sea específica para las VM de Dataflow, usa las etiquetas de red personalizadas.
PRIORITY_NUM
: la prioridad de la regla de firewall.Los números más bajos tienen prioridades más altas, y
0
es la prioridad más alta.
Ejemplo de regla de salida de firewall
La regla de firewall de salida permite que las VM de Dataflow se envíen paquetes entre sí. Si creaste reglas de firewall de denegación de salida, es posible que debas crear reglas de firewall de permiso de salida personalizadas en tu red de VPC.
En este ejemplo, se crea una regla de salida de firewall para Dataflow, en la que todas las VM de trabajador tienen la etiqueta de red predeterminada de dataflow
. Un propietario, editor o administrador de seguridad del proyecto puede usar el siguiente comando de gcloud
para crear una regla de permiso de salida que permita el tráfico de los puertos TCP 12345
y 12346
de las VM con la etiqueta de red dataflow
a las VM con la misma etiqueta:
gcloud compute firewall-rules create FIREWALL_RULE_NAME_EGRESS \
--network=NETWORK \
--action=allow \
--direction=egress \
--target-tags=CUSTOM_TAG \
--source-tags=CUSTOM_TAG \
--destination-ranges=DESTINATION-RANGES\
--priority=PRIORITY_NUM \
--rules tcp:12345-12346
Reemplaza lo siguiente:
FIREWALL_RULE_NAME_EGRESS
es un nombre para la regla de firewall.NETWORK
es el nombre de la red que usan las VM de trabajadores.CUSTOM_TAG
: es una lista delimitada por comas de etiquetas de red.A continuación, se muestra una lista de lineamientos para usar etiquetas de red:
Si omites
--target-tags
, la regla se aplica a todas las VM de la red de VPC.Si omites
--source-tags
y todas las demás especificaciones de origen, se permite el tráfico de cualquier fuente.Si no especificaste etiquetas de red personalizadas y quieres que la regla sea específica de las VM de Dataflow, usa
dataflow
como etiqueta de red.Si especificaste etiquetas de red personalizadas y quieres que la regla sea específica para las VM de Dataflow, usa las etiquetas de red personalizadas.
DESTINATION-RANGES
: una lista delimitada por comas de CIDRIncluye el rango de direcciones IP principal de la subred seleccionada.
PRIORITY_NUM
: la prioridad de la regla de firewall.Los números más bajos tienen prioridades más altas, y
0
es la prioridad más alta.
Para los puertos TCP específicos que usa Dataflow, puedes consultar el manifiesto del contenedor del proyecto. El manifiesto del contenedor especifica de manera explícita los puertos para asignar puertos de host al contenedor.
Acceso SSH a las VM de trabajador
Dataflow no requiere SSH; sin embargo, SSH es útil para la solución de problemas.
Si tu VM de trabajador tiene una dirección IP externa, puedes conectarte a la VM a través de la consola de Google Cloud o mediante Google Cloud CLI. Para conectarte mediante SSH, debes tener una regla de firewall que permita conexiones entrantes en el puerto TCP 22 desde al menos la dirección IP del sistema en el que se ejecuta gcloud
o el sistema que ejecuta el navegador web que usas para acceder a la consola de Google Cloud.
Para ver la configuración y la actividad de red, abre una sesión SSH en uno de tus trabajadores y ejecuta iproute2
. Para obtener más información, consulta la página iproute2
en la wiki de Linux Foundation.
Si necesitas conectarte a una VM de trabajador que solo tiene una dirección IP interna, consulta Elige una opción de conexión para VMs solo internas.
¿Qué sigue?
- Obtén información sobre las pruebas de conectividad. Las pruebas de conectividad son una herramienta de diagnóstico que te permite verificar la conectividad entre los extremos de red.
- Crea y ejecuta pruebas de conectividad.