Configura las plantillas flexibles

En esta página, se documentan varias opciones de configuración de la plantilla de Flex de Dataflow, incluidas las siguientes:

Para configurar una plantilla flexible muestra, consulta el instructivo de plantilla flexible.

Comprende los permisos de las plantillas de Flex

Cuando trabajas con plantillas de Flex, necesitas tres conjuntos de permisos:

  • Permisos para crear recursos
  • Permisos para compilar una plantilla flexible
  • Permisos para ejecutar una plantilla de Flex

Permisos para crear recursos

Para desarrollar y ejecutar una canalización de plantilla de Flex, debes crear varios recursos (por ejemplo, un bucket de etapa de pruebas). Para tareas de creación de recursos únicas, puedes usar el rol básico Propietario.

Permisos para compilar una plantilla flexible

Como desarrollador de una plantilla de Flex, debes compilar la plantilla a fin de que esté disponible para los usuarios. La compilación implica subir una especificación de plantilla a un bucket de Cloud Storage y aprovisionar una imagen de Docker con el código y las dependencias necesarias para ejecutar la canalización. Para compilar una plantilla de Flex, necesitas acceso de lectura y escritura a Cloud Storage y acceso de Escritor de Artifact Registry a tu repositorio de Artifact Registry. Puedes otorgar estos permisos si asignas el siguiente rol:

  • Administrador de almacenamiento (roles/storage.admin)
  • Editor de Cloud Build (roles/cloudbuild.builds.editor)
  • Escritor de Artifact Registry (roles/artifactregistry.writer)

Permisos para ejecutar una plantilla de Flex

Cuando ejecutas una plantilla flexible, Dataflow crea un trabajo por ti. Para crear el trabajo, la cuenta de servicio de Dataflow necesita el siguiente permiso:

  • dataflow.serviceAgent

Cuando usas Dataflow por primera vez, el servicio te asigna este rol, por lo que no necesitas otorgar este permiso.

De forma predeterminada, la cuenta de servicio de Compute Engine se usa para las VMs de iniciador y de trabajador. La cuenta de servicio necesita las siguientes funciones y capacidades:

  • Administrador de objetos de almacenamiento (roles/storage.objectAdmin)
  • Visualizador (roles/viewer)
  • Trabajador de Dataflow (roles/dataflow.worker)
  • Acceso de lectura y escritura al bucket de etapa de pruebas
  • Acceso de lectura a la imagen de la plantilla flexible

Para otorgar acceso de lectura y escritura al bucket de etapa de pruebas, puedes usar el rol Administrador de objetos de almacenamiento (roles/storage.objectAdmin). Si deseas obtener más información, consulta Roles de IAM para Cloud Storage.

Para otorgar acceso de lectura a la imagen de la plantilla de Flex, puedes usar el rol Visualizador de objetos de almacenamiento (roles/storage.objectViewer). Para obtener más información, consulta Configurar el control de acceso.

Configura las variables de entorno de Dockerfile obligatorias

Si deseas crear tu propio Dockerfile para un trabajo de plantilla de Flex, especifica las siguientes variables de entorno:

Java

Especifica FLEX_TEMPLATE_JAVA_MAIN_CLASS y FLEX_TEMPLATE_JAVA_CLASSPATH en el Dockerfile.

ENV Descripción Obligatorio
FLEX_TEMPLATE_JAVA_MAIN_CLASS Especifica qué clase de Java se ejecuta para iniciar la plantilla de Flex. SÍ
FLEX_TEMPLATE_JAVA_CLASSPATH Especifica la ubicación de los archivos de clase. SÍ
FLEX_TEMPLATE_JAVA_OPTIONS Especifica las opciones de Java que se pasarán mientras se inicia la plantilla de Flex. NO

Python

Especifica FLEX_TEMPLATE_PYTHON_PY_FILE en tu Dockerfile.

Para administrar dependencias de canalización, configura variables en tu Dockerfile, como las siguientes:

  • FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE
  • FLEX_TEMPLATE_PYTHON_PY_OPTIONS
  • FLEX_TEMPLATE_PYTHON_SETUP_FILE
  • FLEX_TEMPLATE_PYTHON_EXTRA_PACKAGES

Por ejemplo, las siguientes variables de entorno se configuran en el instructivo de transmisión en plantillas de Flex de Python en GitHub:

ENV FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE="${WORKDIR}/requirements.txt"
ENV FLEX_TEMPLATE_PYTHON_PY_FILE="${WORKDIR}/streaming_beam.py"
ENV Descripción Obligatorio
FLEX_TEMPLATE_PYTHON_PY_FILE Especifica qué archivo de Python se debe ejecutar para iniciar la plantilla de Flex. SÍ
FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE Especifica el archivo de requisitos con dependencias de canalización. Para obtener más información, consulta las dependencias de PyPI en la documentación de Apache Beam. NO
FLEX_TEMPLATE_PYTHON_SETUP_FILE Especifica la ruta al archivo “setup.py” del paquete de canalización. Para obtener más información, consulta Varias dependencias de archivos en la documentación de Apache Beam. NO
FLEX_TEMPLATE_PYTHON_EXTRA_PACKAGES

Especifica los paquetes que no están disponibles de forma pública. Para obtener información sobre cómo usar paquetes adicionales, lee Dependencias locales o que no son de PyPI.

 NO
FLEX_TEMPLATE_PYTHON_PY_OPTIONS Especifica las opciones de Python que se pasarán mientras se inicia la plantilla de Flex. NO

Dependencias de paquetes

Cuando una canalización de Python de Dataflow usa dependencias adicionales, es posible que debas configurar la plantilla de Flex para instalar dependencias adicionales en las VMs de trabajador de Dataflow.

Cuando ejecutas un trabajo de Dataflow de Python que usa plantillas de Flex en un entorno que restringe el acceso a Internet, debes empaquetar previamente las dependencias cuando creas la plantilla.

Usa una de las siguientes opciones para empaquetar previamente las dependencias de Python.

Si deseas obtener instrucciones para administrar dependencias de canalizaciones en canalizaciones de Java y Go, consulta Administra dependencias de canalizaciones en Dataflow.

Usa un archivo de requisitos y empaqueta previamente las dependencias con la plantilla

Si usas tu propio Dockerfile para definir la imagen de la plantilla de Flex, sigue estos pasos:

  1. Crea un archivo requirements.txt que enumere tus dependencias de canalización.

    COPY requirements.txt /template/
ENV FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE="/template/requirements.txt"

  2. Instala las dependencias en la imagen de la plantilla de Flex.

    RUN pip install --no-cache-dir -r $FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE

  3. Descarga las dependencias en la caché de requisitos locales, que se transfiere a los trabajadores de Dataflow cuando se inicia la plantilla.

    RUN pip download --no-cache-dir --dest /tmp/dataflow-requirements-cache -r $FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE

Cuando usas este enfoque, las dependencias del archivo requirements.txt se instalan en los trabajadores de Dataflow en el entorno de ejecución. Es posible que una estadística en la pestaña de recomendaciones de la consola de Google Cloud indique este comportamiento. Para evitar instalar dependencias durante el tiempo de ejecución, usa una imagen de contenedor personalizada.

La siguiente es una muestra de código que usa un archivo de requisitos en la plantilla de Flex.

# Copyright 2020 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#    http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

FROM gcr.io/dataflow-templates-base/python3-template-launcher-base

# Configure the Template to launch the pipeline with a --requirements_file option.
# See: https://beam.apache.org/documentation/sdks/python-pipeline-dependencies/#pypi-dependencies
ENV FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE="/template/requirements.txt"
ENV FLEX_TEMPLATE_PYTHON_PY_FILE="/template/streaming_beam.py"

COPY . /template

RUN apt-get update \
    # Install any apt packages if required by your template pipeline.
    && apt-get install -y libffi-dev git \
    && rm -rf /var/lib/apt/lists/* \
    # Upgrade pip and install the requirements.
    && pip install --no-cache-dir --upgrade pip \
    # Install dependencies from requirements file in the launch environment.
    && pip install --no-cache-dir -r $FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE \
    # When FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE  option is used,
    # then during Template launch Beam downloads dependencies
    # into a local requirements cache folder and stages the cache to workers.
    # To speed up Flex Template launch, pre-download the requirements cache
    # when creating the Template.
    && pip download --no-cache-dir --dest /tmp/dataflow-requirements-cache -r $FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE

# Set this if using Beam 2.37.0 or earlier SDK to speed up job submission.
ENV PIP_NO_DEPS=True

ENTRYPOINT ["/opt/google/dataflow/python_template_launcher"]

Estructura la canalización como un paquete y usa paquetes locales

Cuando usas varios archivos o módulos locales de Python, estructura tu canalización como un paquete. La estructura del archivo puede verse como el siguiente ejemplo:

main.py
pyproject.toml
setup.py
src/
  my_package/
    my_custom_dofns_and_transforms.py
    my_pipeline_launcher.py
    other_utils_and_helpers.py

  1. Coloca el punto de entrada de nivel superior, por ejemplo, el archivo main.py, en el directorio raíz. Coloca el resto de los archivos en una carpeta distinta en el directorio src, por ejemplo, my_package.

  2. Agrega los archivos de configuración del paquete al directorio raíz con los detalles y los requisitos del paquete.

    pyproject.toml

    [project]
name = "my_package"
version = "package_version"
dependencies = [
  # Add list of packages (and versions) that my_package depends on.
  # Example:
  "apache-beam[gcp]==2.54.0",
]

    setup.py

      """An optional setuptools configuration stub for the pipeline package.

  Use pyproject.toml to define the package. Add this file only if you must
  use the --setup_file pipeline option or the
  FLEX_TEMPLATE_PYTHON_SETUP_FILE configuration option.
  """

  import setuptools
  setuptools.setup()

    Para obtener más información sobre cómo configurar tu paquete local, consulta Empaqueta proyectos de Python.

  3. Cuando importes módulos o archivos locales para tu canalización, usa el nombre del paquete my_package como ruta de importación.

    from my_package import word_count_transform

  4. Instala el paquete de tu canalización en la imagen de la plantilla de Flex. El Dockerfile de tu plantilla de Flex podría incluir contenido similar al siguiente ejemplo:

    Dockerfile

    ENV FLEX_TEMPLATE_PYTHON_PY_FILE="${WORKDIR}/main.py"
ENV FLEX_TEMPLATE_PYTHON_SETUP_FILE="${WORKDIR}/setup.py"

# Copy pipeline, packages and requirements.
WORKDIR ${WORKDIR}
COPY main.py .
COPY pyproject.toml .
COPY setup.py .
COPY src src

# Install local package.
RUN pip install -e .

Cuando usas este enfoque, las dependencias del archivo requirements.txt se instalan en los trabajadores de Dataflow en el entorno de ejecución. Es posible que una estadística en la pestaña de recomendaciones de la consola de Google Cloud indique este comportamiento. Para evitar la instalación de dependencias en el entorno de ejecución, usa una imagen de contenedor personalizada.

Si quieres ver un ejemplo que sigue el enfoque recomendado, consulta el instructivo Plantilla de Flex para una canalización con dependencias y una imagen de contenedor personalizada en GitHub.

Usa un contenedor personalizado que instale previamente todas las dependencias

Para evitar la instalación de dependencias en el entorno de ejecución, usa contenedores personalizados. Se recomienda esta opción para las canalizaciones que se ejecutan en entornos sin acceso a Internet.

Sigue estos pasos para usar un contenedor personalizado:

  1. Compila una imagen de contenedor personalizada que preinstale las dependencias necesarias.

  2. Preinstala las mismas dependencias en el Dockerfile de la plantilla de Flex.

    Para evitar la instalación de dependencias en el entorno de ejecución, no uses las opciones FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE o FLEX_TEMPLATE_PYTHON_SETUP_FILE en la configuración de la plantilla de Flex.

    Una plantilla de Flex modificada Dockerfile podría verse como el siguiente ejemplo:

    FROM gcr.io/dataflow-templates-base/python3-template-launcher-base
ENV FLEX_TEMPLATE_PYTHON_PY_FILE="/template/main.py"
COPY . /template
# If you use a requirements file, pre-install the requirements.txt.
RUN pip install --no-cache-dir -r /template/requirements.txt
# If you supply the pipeline in a package, pre-install the local package and its dependencies.
RUN pip install -e /template

    Cuando uses este enfoque, sigue los siguientes pasos:

    • compila la imagen de la plantilla de Flex
    • compila la imagen de contenedor del SDK personalizada
    • instala las mismas dependencias en ambas imágenes

    Como alternativa, para reducir la cantidad de imágenes que se mantendrán, usa la imagen de contenedor personalizada como imagen base de la plantilla de Flex.

  3. Si usas la versión 2.49.0 o una anterior del SDK de Apache Beam, agrega la opción de canalización --sdk_location=container al selector de canalizaciones. Esta opción le indica a la canalización que use el SDK desde tu contenedor personalizado en lugar de descargarlo.

    options = PipelineOptions(beam_args, save_main_session=True, streaming=True, sdk_location="container")

  4. Configura el parámetro sdk_container_image en el comando flex-template run. Por ejemplo:

    gcloud dataflow flex-template run $JOB_NAME \
   --region=$REGION \
   --template-file-gcs-location=$TEMPLATE_PATH \
   --parameters=sdk_container_image=$CUSTOM_CONTAINER_IMAGE \
   --additional-experiments=use_runner_v2

    Para obtener más información, consulta Usa contenedores personalizados en Dataflow.

Elegir una imagen base

Puedes usar una imagen base proporcionada por Google para empaquetar las imágenes de contenedor de plantilla con Docker. Elige la etiqueta más reciente de las imágenes base de plantillas de Flex. Se recomienda usar una etiqueta de imagen específica en lugar de latest.

Especifica la imagen base en el siguiente formato:

gcr.io/dataflow-templates-base/IMAGE_NAME:TAG

Reemplaza lo siguiente:

Usa imágenes de contenedor personalizadas

Si tu canalización usa una imagen de contenedor personalizada, te recomendamos usar la imagen personalizada como una imagen base para la imagen de Docker de tu plantilla de Flex. Para ello, copia en tu imagen personalizada el objeto binario del selector de plantillas de Flex de la imagen base de plantillas que proporciona Google.

Un ejemplo de Dockerfile para una imagen que se puede usar como imagen de contenedor del SDK personalizada y como plantilla de Flex, podría verse de la siguiente manera:

FROM gcr.io/dataflow-templates-base/IMAGE_NAME:TAG as template_launcher
FROM apache/beam_python3.10_sdk:2.59.0

# RUN <...Make image customizations here...>
# See: https://cloud.google.com/dataflow/docs/guides/build-container-image

# Configure the Flex Template here.
COPY --from=template_launcher /opt/google/dataflow/python_template_launcher /opt/google/dataflow/python_template_launcher
COPY my_pipeline.py /template/
ENV FLEX_TEMPLATE_PYTHON_PY_FILE="/template/my_pipeline.py"

Reemplaza lo siguiente:

  • IMAGE_NAME: una imagen base que proporciona Google. Por ejemplo: python311-template-launcher-base
  • TAG: una etiqueta de versión para la imagen base, que se encuentra en la referencia sobre imágenes base de plantillas de Flex Para mejorar la estabilidad y la solución de problemas, evita usar latest. En su lugar, fija una etiqueta de versión específica.

Si deseas ver un ejemplo que sigue este enfoque, consulta el instructivo Plantilla de Flex para una canalización con dependencias y una imagen de contenedor personalizada.

Usa una imagen de un registro privado

Puedes compilar una imagen de plantilla de Flex almacenada en un registro de Docker privado si el registro privado usa HTTPS y tiene un certificado válido.

Para usar una imagen de un registro privado, especifica la ruta de acceso a la imagen y un nombre de usuario y una contraseña para el registro. El nombre de usuario y la contraseña se deben almacenar en el Administrador de secretos. Puedes proporcionar el secreto en uno de los siguientes formatos:

  • projects/{project}/secrets/{secret}/versions/{secret_version}
  • projects/{project}/secrets/{secret}

Si usas el segundo formato, porque no especifica la versión, Dataflow usa la última versión.

Si el registro usa un certificado autofirmado, también debes especificar la ruta de acceso al certificado autofirmado en Cloud Storage.

En la siguiente tabla, se describen las opciones de la CLI de gcloud que puedes usar para configurar un registro privado.

Parámetro Descripción
image La dirección del registro. Por ejemplo: gcp.repository.example.com:9082/registry/example/image:latest.
image-repository-username-secret-id El ID del secreto de Secret Manager para que el nombre de usuario se autentique en el registro privado. Por ejemplo: projects/example-project/secrets/username-secret.
image-repository-password-secret-id El ID del secreto de Secret Manager para que la contraseña se autentique en el registro privado. Por ejemplo: projects/example-project/secrets/password-secret/versions/latest.
image-repository-cert-path La URL completa de Cloud Storage para un certificado autofirmado del registro privado. Esto solo es necesario si el registro usa un certificado autofirmado. Por ejemplo: gs://example-bucket/self-signed.crt.

Este es un comando de Google Cloud CLI de ejemplo que compila una plantilla de Flex mediante una imagen en un registro privado con un certificado autofirmado.

gcloud dataflow flex-template build gs://example-bucket/custom-pipeline-private-repo.json
--sdk-language=JAVA
--image="gcp.repository.example.com:9082/registry/example/image:latest"
--image-repository-username-secret-id="projects/example-project/secrets/username-secret"
--image-repository-password-secret-id="projects/example-project/secrets/password-secret/versions/latest"
--image-repository-cert-path="gs://example-bucket/self-signed.crt"
--metadata-file=metadata.json

Para compilar tu propia plantilla de Flex, debes reemplazar los valores de ejemplo y es posible que debas especificar opciones adicionales o diferentes. Para obtener más información, consulta los siguientes recursos:

Especifica opciones de canalización

Para obtener más información sobre las opciones de canalización compatibles con las plantillas de Flex, consulta Opciones de canalización.

También puedes usar cualquier opción de canalización de Apache Beam de forma indirecta. Si usas un archivo metadata.json para el trabajo de plantilla flexible, incluye estas opciones de canalización en el archivo. Este archivo de metadatos debe seguir el formato de TemplateMetadata.

De lo contrario, cuando inicies el trabajo de la plantilla de Flex, pasa estas opciones de canalización mediante el campo de parámetros.

API

Incluye opciones de canalización mediante el campo parameters.

gcloud

Incluye opciones de canalización mediante la marca parameters.

Cuando pasas parámetros de tipo List o Map, es posible que debas definir parámetros en un archivo YAML y usar el flags-file. Para ver un ejemplo de este enfoque, consulta el paso “Crea un archivo con parámetros…” de esta solución.

Cuando usas plantillas de Flex, puedes configurar algunas opciones durante la inicialización de la canalización, pero otras opciones de canalización no se pueden cambiar. Si se reemplazan los argumentos de la línea de comandos requeridos por la plantilla flexible, el trabajo puede ignorar, anular o descartar las opciones de canalización que pasa el selector de plantillas. Es posible que el trabajo no se inicie o que se inicie un trabajo que no use la plantilla flexible. Para obtener más información, consulta No se pudo leer el archivo de trabajo.

Durante la inicialización de la canalización, no cambies las siguientes opciones de canalización:

Java

  • runner
  • project
  • jobName
  • templateLocation
  • region

Python

  • runner
  • project
  • job_name
  • template_location
  • region

Go

  • runner
  • project
  • job_name
  • template_location
  • region

Bloquea claves SSH del proyecto de las VM que usan claves SSH basadas en metadatos

Para evitar que las VM acepten claves SSH almacenadas en metadatos del proyecto, bloquea las claves SSH del proyecto desde las VM. Usa la marca additional-experiments con la opción de servicio block_project_ssh_keys:

--additional-experiments=block_project_ssh_keys

Para obtener más información, consulta Opciones de servicio de Dataflow.

Metadatos

Puedes ampliar tu plantilla con metadatos adicionales para que los parámetros personalizados se validen cuando se ejecute la plantilla. Si deseas crear metadatos para tu plantilla, sigue estos pasos:

  1. Crea un archivo metadata.json con los parámetros de Parámetros de metadatos.

    Para ver un ejemplo, consulta Archivo de metadatos de ejemplo.

  2. Almacena el archivo de metadatos en Cloud Storage en la misma carpeta que la plantilla.

Parámetros de metadatos

Clave de parámetro Obligatorio Descripción del valor
name Sí El nombre de tu plantilla
description No Un breve párrafo de texto que describe la plantilla
streaming No Si es true, esta plantilla admite la transmisión. El valor predeterminado es false.
supportsAtLeastOnce No Si es true, esta plantilla admite el procesamiento “al menos una vez”. El valor predeterminado es false. Establece este parámetro en true si la plantilla está diseñada para funcionar con el modo de transmisión “al menos una vez”.
supportsExactlyOnce No Si es true, esta plantilla admite el procesamiento de tipo exactamente una vez. El valor predeterminado es true.
defaultStreamingMode No El modo de transmisión predeterminado, para plantillas que admiten el modo al menos una vez y el modo "exactamente una vez". Usa uno de los siguientes valores: "AT_LEAST_ONCE", "EXACTLY_ONCE". Si no se especifica, el modo de transmisión predeterminado es “exactamente una vez”.
parameters No Un array de parámetros adicionales que usa la plantilla De forma predeterminada, se usa un array vacío.
name Sí El nombre del parámetro que se usa en tu plantilla.
label Sí Una string legible que se usa en la consola de Google Cloud para etiquetar el parámetro.
helpText Sí Un breve párrafo de texto que describe el parámetro.
isOptional No false si el parámetro es obligatorio y true si el parámetro es opcional A menos que se configure con un valor, isOptional se establece de forma predeterminada en false. Si no incluyes esta clave de parámetro en tus metadatos, estos se convierten en un parámetro obligatorio.
regexes No Un array de expresiones regulares POSIX-egrep en formato de string que se usará para validar el valor del parámetro. Por ejemplo, ["^[a-zA-Z][a-zA-Z0-9]+"] es una expresión regular individual que valida que el valor comienza con una letra y, luego, tiene uno o más caracteres. De forma predeterminada, se usa un array vacío.

Ejemplo de archivo de metadatos

Java

{
  "name": "Streaming Beam SQL",
  "description": "An Apache Beam streaming pipeline that reads JSON encoded messages from Pub/Sub, uses Beam SQL to transform the message data, and writes the results to a BigQuery",
  "parameters": [
    {
      "name": "inputSubscription",
      "label": "Pub/Sub input subscription.",
      "helpText": "Pub/Sub subscription to read from.",
      "regexes": [
        "[a-zA-Z][-_.~+%a-zA-Z0-9]{2,}"
      ]
    },
    {
      "name": "outputTable",
      "label": "BigQuery output table",
      "helpText": "BigQuery table spec to write to, in the form 'project:dataset.table'.",
      "isOptional": true,
      "regexes": [
        "[^:]+:[^.]+[.].+"
      ]
    }
  ]
}

Python

{
  "name": "Streaming beam Python flex template",
  "description": "Streaming beam example for python flex template.",
  "parameters": [
    {
      "name": "input_subscription",
      "label": "Input PubSub subscription.",
      "helpText": "Name of the input PubSub subscription to consume from.",
      "regexes": [
        "projects/[^/]+/subscriptions/[a-zA-Z][-_.~+%a-zA-Z0-9]{2,}"
      ]
    },
    {
      "name": "output_table",
      "label": "BigQuery output table name.",
      "helpText": "Name of the BigQuery output table name.",
      "isOptional": true,
      "regexes": [
        "([^:]+:)?[^.]+[.].+"
      ]
    }
  ]
}

Puedes descargar archivos de metadatos para las plantillas proporcionadas por Google desde el directorio de plantillas de Dataflow.

Información sobre la ubicación de la etapa de pruebas y la ubicación temporal

Google Cloud CLI proporciona las opciones --staging-location y --temp-location cuando ejecutas una plantilla flexible. Del mismo modo, la API de REST de Dataflow proporciona los campos stagingLocation y tempLocation para FlexTemplateRuntimeEnvironment.

Para las plantillas de Flex, la ubicación de etapa de pruebas es la URL de Cloud Storage en la que se escriben los archivos durante el paso de etapa de pruebas del lanzamiento de una plantilla. Dataflow lee estos archivos en etapa de pruebas para crear el grafo de plantilla. La ubicación temporal es la URL de Cloud Storage en la que se escriben los archivos temporales durante el paso de ejecución.

Actualiza un trabajo de plantilla de Flex

En la siguiente solicitud de ejemplo, se muestra cómo actualizar un trabajo de transmisión de una plantilla con el método projects.locations.flexTemplates.launch. Si deseas usar gcloud CLI, consulta Actualiza una canalización existente.

Si quieres actualizar una plantilla clásica, usa projects.locations.templates.launch en su lugar.

  1. Sigue los pasos para crear un trabajo de transmisión a partir de una plantilla de Flex. Envía la siguiente solicitud HTTP POST, con los valores modificados:

    POST https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/flexTemplates:launch
{
    "launchParameter": {
      "update": true
      "jobName": "JOB_NAME",
      "parameters": {
        "input_subscription": "projects/PROJECT_ID/subscriptions/SUBSCRIPTION_NAME",
        "output_table": "PROJECT_ID:DATASET.TABLE_NAME"
      },
    "containerSpecGcsPath": "STORAGE_PATH"
    },
}
    • Reemplaza PROJECT_ID con el ID del proyecto.
    • Reemplaza REGION por la región de Dataflow del trabajo que estás actualizando.
    • Reemplaza JOB_NAME por el nombre exacto del trabajo que deseas actualizar.
    • Establece parameters en la lista de pares clave-valor. Los parámetros enumerados son específicos de este ejemplo de plantilla. Si usas una plantilla personalizada, modifica los parámetros según sea necesario. Si usas la plantilla de ejemplo, reemplaza las siguientes variables.
      • Reemplaza SUBSCRIPTION_NAME por el nombre de tu suscripción de Pub/Sub.
      • Reemplaza DATASET por el nombre de tu conjunto de datos de BigQuery.
      • Reemplaza TABLE_NAME por el nombre de tu tabla de BigQuery.
    • Reemplaza STORAGE_PATH por la ubicación de Cloud Storage del archivo de plantilla. La ubicación debe comenzar con gs://.

  2. Usa el parámetro environment para cambiar la configuración del entorno. Para obtener más información, consulta FlexTemplateRuntimeEnvironment.

  3. Opcional: para enviar tu solicitud con curl (Linux, macOS o Cloud Shell), guarda la solicitud en un archivo JSON y, luego, ejecuta el siguiente comando:

    curl -X POST -d "@FILE_PATH" -H "Content-Type: application/json" -H "Authorization: Bearer $(gcloud auth print-access-token)"  https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/flexTemplates:launch

    Reemplaza FILE_PATH por la ruta de acceso al archivo JSON que contiene el cuerpo de la solicitud.

  4. Usa la interfaz de supervisión de Dataflow para verificar que se haya creado un trabajo nuevo con el mismo nombre. Este trabajo tiene el estado Actualizado.

Limitaciones

Se aplican las siguientes limitaciones a los trabajos de plantillas flexibles:

  • Debes usar una imagen base que proporciona Google para empaquetar tus contenedores con Docker. Para obtener una lista de imágenes aplicables, consulta Imágenes base de la plantilla flexible.
  • A fin de que la canalización se inicie, el programa que construye la canalización debe salir después de que se llame a run.
  • No se admiten waitUntilFinish (Java) ni wait_until_finish (Python).

Próximos pasos