Configurer les modèles Flex

Cette page répertorie les différentes options de configuration du modèle Flex Dataflow, y compris les suivantes :

Pour configurer un exemple de modèle Flex, consultez le tutoriel sur l'utilisation des modèles Flex.

Comprendre les autorisations liées aux modèles Flex

Lorsque vous travaillez avec des modèles Flex, vous avez besoin de trois jeux d'autorisations :

  • Autorisations de créer des ressources
  • Autorisations de créer un modèle Flex
  • Autorisations d'exécuter un modèle Flex

Autorisations de créer des ressources

Pour développer et exécuter un pipeline de modèle Flex, vous devez créer diverses ressources (par exemple, un bucket de préproduction). Pour les tâches de création de ressources ponctuelles, vous pouvez utiliser le rôle de propriétaire de base.

Autorisations de créer un modèle Flex

En tant que développeur d'un modèle Flex, vous devez le créer pour le mettre à la disposition des utilisateurs. La création implique d'importer une spécification de modèle dans un bucket Cloud Storage et de provisionner une image Docker avec le code et les dépendances nécessaires à l'exécution du pipeline. Pour créer un modèle Flex, vous devez disposer d'un accès en lecture et en écriture à Cloud Storage et d'un accès en tant que rédacteur Artifact Registry à votre dépôt Artifact Registry. Vous pouvez accorder ces autorisations en attribuant les rôles suivants :

  • Administrateur Storage (roles/storage.admin)
  • Éditeur Cloud Build (roles/cloudbuild.builds.editor)
  • Rédacteur Artifact Registry (roles/artifactregistry.writer)

Autorisations d'exécuter un modèle Flex

Lorsque vous exécutez un modèle Flex, Dataflow crée une tâche pour vous. Pour créer la tâche, le compte de service Dataflow doit disposer des autorisations suivantes :

  • dataflow.serviceAgent

Lorsque vous utilisez Dataflow pour la première fois, le service attribue ce rôle à votre place. Vous n'avez donc pas besoin d'accorder cette autorisation.

Par défaut, le compte de service Compute Engine est utilisé pour les VM de lanceur d'applications et les VM de nœud de calcul. Le compte de service requiert les rôles et fonctionnalités suivants :

  • Administrateur des objets de l'espace de stockage (roles/storage.objectAdmin)
  • Lecteur (roles/viewer)
  • Nœud de calcul Dataflow (roles/dataflow.worker)
  • Accès en lecture et en écriture au bucket de préproduction
  • Accès en lecture à l'image du modèle Flex

Pour accorder un accès en lecture et en écriture au bucket de préproduction, vous pouvez utiliser le rôle d'Administrateur des objets de l'espace de stockage (roles/storage.objectAdmin). Pour en savoir plus, consultez la page Rôles IAM pour Cloud Storage.

Pour accorder un accès en lecture à l'image du modèle Flex, vous pouvez utiliser le rôle Lecteur des objets de l'espace de stockage (roles/storage.objectViewer). Pour en savoir plus, consultez la section Configurer le contrôle des accès.

Définir les variables d'environnement requises dans le fichier Dockerfile

Si vous souhaitez créer votre propre fichier Dockerfile pour un job de modèle Flex, spécifiez les variables d'environnement suivantes :

Java

Spécifiez FLEX_TEMPLATE_JAVA_MAIN_CLASS et FLEX_TEMPLATE_JAVA_CLASSPATH dans le fichier Dockerfile.

ENV Description Obligatoire
FLEX_TEMPLATE_JAVA_MAIN_CLASS Spécifie la classe Java à exécuter afin de lancer le modèle Flex. OUI
FLEX_TEMPLATE_JAVA_CLASSPATH Spécifie l'emplacement des fichiers de classe. OUI
FLEX_TEMPLATE_JAVA_OPTIONS Spécifie les options Java à transmettre lors du lancement du modèle Flex. NON

Python

Spécifiez FLEX_TEMPLATE_PYTHON_PY_FILE dans votre fichier Dockerfile.

Pour gérer les dépendances de pipeline, définissez dans votre fichier Dockerfile des variables telles que les suivantes :

  • FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE
  • FLEX_TEMPLATE_PYTHON_PY_OPTIONS
  • FLEX_TEMPLATE_PYTHON_SETUP_FILE
  • FLEX_TEMPLATE_PYTHON_EXTRA_PACKAGES

Par exemple, les variables d'environnement suivantes sont définies dans le Tutoriel sur la diffusion dans les modèles Flex en langage Python dans GitHub :

ENV FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE="${WORKDIR}/requirements.txt"
ENV FLEX_TEMPLATE_PYTHON_PY_FILE="${WORKDIR}/streaming_beam.py"
ENV Description Obligatoire
FLEX_TEMPLATE_PYTHON_PY_FILE Spécifie le fichier Python à exécuter pour lancer le modèle Flex. OUI
FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE Spécifie le fichier d'exigences avec les dépendances de pipeline. Pour plus d'informations, consultez la section Dépendances PyPI dans la documentation d'Apache Beam. NON
FLEX_TEMPLATE_PYTHON_SETUP_FILE Spécifie le chemin d'accès au fichier "setup.py" du package de pipeline. Pour plus d'informations, consultez la section Dépendances de fichiers multiples dans la documentation Apache Beam. NON
FLEX_TEMPLATE_PYTHON_EXTRA_PACKAGES

Spécifie les packages qui ne sont pas disponibles publiquement. Pour plus d'informations sur l'utilisation de packages supplémentaires, consultez la section Dépendances locales ou non PyPI.

 NON
FLEX_TEMPLATE_PYTHON_PY_OPTIONS Spécifie les options Python à transmettre lors du lancement du modèle Flex. NON

Dépendances de packages pour Python

Lorsqu'un pipeline Python Dataflow utilise des dépendances supplémentaires, vous devrez peut-être configurer le modèle Flex pour installer des dépendances supplémentaires sur les VM de nœud de calcul Dataflow.

Lorsque vous exécutez un job Python Dataflow qui utilise des modèles Flex dans un environnement qui limite l'accès à Internet, vous devez pré-empaqueter les dépendances lors de la création du modèle.

Utilisez l'une des options suivantes pour pré-empaqueter les dépendances Python.

Pour obtenir des instructions sur la gestion des dépendances de pipeline dans les pipelines Java et Go, consultez la page Gérer les dépendances de pipeline dans Dataflow.

Utiliser un fichier d'exigences et pré-empaqueter les dépendances avec le modèle

Si vous utilisez votre propre fichier Dockerfile pour définir l'image de modèle Flex, procédez comme suit :

  1. Créez un fichier requirements.txt qui répertorie les dépendances de votre pipeline.

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

  2. Installez les dépendances dans l'image de modèle Flex.

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

  3. Téléchargez les dépendances dans le cache d'exigences local, qui est appliqué en préproduction aux nœuds de calcul Dataflow lors du lancement du modèle.

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

Lorsque vous utilisez cette approche, les dépendances du fichier requirements.txt sont installées sur les nœuds de calcul Dataflow au moment de l'exécution. Un insight dans l'onglet "Recommandations" de la console Google Cloud peut indiquer ce comportement. Pour éviter d'installer des dépendances au moment de l'exécution, utilisez une image de conteneur personnalisée.

Vous trouverez ci-dessous un exemple de code qui utilise un fichier de spécifications dans le modèle 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"]

Structurer le pipeline en tant que package et utiliser des packages locaux

Lorsque vous utilisez plusieurs fichiers ou modules Python locaux, structurez votre pipeline en tant que package. La structure de fichiers peut ressembler à l'exemple suivant:

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. Placez le point d'entrée de premier niveau, par exemple le fichier main.py, dans le répertoire racine. Placez le reste des fichiers dans un dossier distinct du répertoire src, par exemple my_package.

  2. Ajoutez les fichiers de configuration du package au répertoire racine avec les détails et les exigences du package.

    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()

    Pour savoir comment configurer votre package local, consultez la section Packager des projets Python.

  3. Lorsque vous importez des modules ou des fichiers locaux pour votre pipeline, utilisez le nom du package my_package comme chemin d'importation.

    from my_package import word_count_transform

  4. Installez le package de votre pipeline dans l'image du modèle Flex. Le fichier Dockerfile de votre modèle Flex peut inclure du contenu semblable à l'exemple suivant:

    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 .

Lorsque vous utilisez cette approche, les dépendances du fichier requirements.txt sont installées sur les nœuds de calcul Dataflow au moment de l'exécution. Un insight dans l'onglet "Recommandations" de la console Google Cloud peut indiquer ce comportement. Pour éviter d'installer des dépendances au moment de l'exécution, utilisez une image de conteneur personnalisée.

Pour obtenir un exemple illustrant cette approche, consultez le tutoriel Modèle Flex pour un pipeline avec des dépendances et une image de conteneur personnalisée dans GitHub.

Utiliser un conteneur personnalisé qui préinstalle toutes les dépendances

Pour éviter l'installation de dépendances au moment de l'exécution, utilisez des conteneurs personnalisés. Cette option est préférable pour les pipelines exécutés dans des environnements sans accès Internet.

Pour utiliser un conteneur personnalisé, procédez comme suit :

  1. Créez un conteneur personnalisé qui préinstalle les dépendances nécessaires.

  2. Préinstallez les mêmes dépendances dans le fichier Dockerfile du modèle Flex.

    Pour éviter l'installation de dépendances au moment de l'exécution, n'utilisez pas les options FLEX_TEMPLATE_PYTHON_REQUIREMENTS_FILE ou FLEX_TEMPLATE_PYTHON_SETUP_FILE dans la configuration de votre modèle Flex.

    Un fichier Dockerfile de modèle Flex modifié peut ressembler à l'exemple suivant:

    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

    Lorsque vous utilisez cette approche, procédez comme suit:

    • créez l'image du modèle Flex
    • créez l'image de conteneur du SDK personnalisé
    • installez les mêmes dépendances dans les deux images

    Pour réduire le nombre d'images à gérer, utilisez également votre image de conteneur personnalisée comme image de base pour le modèle Flex.

  3. Si vous utilisez le SDK Apache Beam version 2.49.0 ou antérieure, ajoutez l'option de pipeline --sdk_location=container dans votre lanceur de pipeline. Cette option indique à votre pipeline d'utiliser le SDK de votre conteneur personnalisé plutôt que de télécharger le SDK.

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

  4. Définissez le paramètre sdk_container_image dans la commande flex-template run. Exemple :

    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

    Pour en savoir plus, consultez la page Utiliser des conteneurs personnalisés dans Dataflow.

Choisir une image de base

Vous pouvez utiliser une image de base fournie par Google pour empaqueter vos images de conteneurs de modèles à l'aide de Docker. Choisissez le tag le plus récent parmi les images de base des modèles Flex. Il est recommandé d'utiliser un tag d'image spécifique au lieu de latest.

Spécifiez l'image de base au format suivant :

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

Remplacez l'élément suivant :

Utiliser des images de conteneurs personnalisées

Si votre pipeline utilise une image de conteneur personnalisée, nous vous recommandons d'utiliser l'image personnalisée comme image de base pour votre image Docker de modèle Flex. Pour ce faire, copiez le fichier binaire du lanceur de modèles Flex à partir de l'image de base de modèle fournie par Google sur votre image personnalisée.

Voici un exemple de fichier Dockerfile pour une image pouvant être utilisée à la fois comme image de conteneur de SDK personnalisé et comme modèle Flex :

FROM gcr.io/dataflow-templates-base/IMAGE_NAME:TAG as template_launcher
FROM apache/beam_python3.10_sdk:2.61.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"

Remplacez les éléments suivants :

  • IMAGE_NAME : image de base fournie par Google. Exemple : python311-template-launcher-base.
  • TAG : tag de version de l'image de base, disponible dans la documentation de référence sur les images de base des modèles Flex. Pour améliorer la stabilité et simplifier le dépannage, évitez d'utiliser latest. Au lieu de cela, épinglez à un tag de version spécifique.

Pour obtenir un exemple illustrant cette approche, consultez le tutoriel Modèle Flex pour un pipeline avec des dépendances et une image de conteneur personnalisée.

Utiliser une image d'un registre privé

Vous pouvez créer une image de modèle Flex stockée dans un registre Docker privé, à condition que ce dernier utilise HTTPS et qu'il dispose d'un certificat valide.

Pour utiliser une image d'un registre privé, spécifiez le chemin d'accès à l'image, ainsi qu'un nom d'utilisateur et un mot de passe pour le registre. Le nom d'utilisateur et le mot de passe doivent être stockés dans Secret Manager. Vous pouvez fournir le secret dans l'un des formats suivants :

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

Si vous utilisez le deuxième format, Dataflow ne spécifie pas la version et utilise la dernière version.

Si le registre utilise un certificat autosigné, vous devez également spécifier le chemin d'accès au certificat autosigné dans Cloud Storage.

Le tableau suivant décrit les options de gcloud CLI que vous pouvez utiliser pour configurer un registre privé.

Paramètre Description
image Adresse du registre. Par exemple : gcp.repository.example.com:9082/registry/example/image:latest.
image-repository-username-secret-id ID de secret Secret Manager permettant au nom d'utilisateur de s'authentifier auprès du registre privé. Par exemple : projects/example-project/secrets/username-secret.
image-repository-password-secret-id ID de secret Secret Manager pour l'authentification du mot de passe dans le registre privé. Par exemple : projects/example-project/secrets/password-secret/versions/latest.
image-repository-cert-path URL complète Cloud Storage d'un certificat autosigné pour le registre privé. Cette valeur n'est requise que si le registre utilise un certificat autosigné. Par exemple : gs://example-bucket/self-signed.crt.

Voici un exemple de commande Google Cloud CLI qui crée un modèle Flex à l'aide d'une image située dans un registre privé en utilisant un certificat autosigné.

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

Pour créer votre propre modèle Flex, vous devez remplacer les exemples de valeurs, et vous devrez peut-être spécifier des options différentes ou supplémentaires. Pour en savoir plus, consultez les ressources suivantes :

Spécifier les options de pipeline

Pour en savoir plus sur les options de pipeline directement compatibles avec les modèles Flex, consultez la page Options de pipeline.

Vous pouvez également utiliser indirectement toutes les options de pipeline Apache Beam. Si vous utilisez un fichier metadata.json pour votre job de modèle Flex, incluez ces options de pipeline dans le fichier. Ce fichier de métadonnées doit respecter le format spécifié dans TemplateMetadata.

Sinon, lorsque vous lancez la tâche du modèle Flex, transmettez ces options de pipeline à l'aide du champ de paramètres.

API

Incluez des options de pipeline à l'aide du champ parameters.

gcloud

Incluez les options de pipeline à l'aide de l'option parameters.

Lorsque vous transmettez des paramètres de type List ou Map, vous devrez peut-être définir les paramètres dans un fichier YAML et utiliser flags-file. Pour voir un exemple de cette approche, consultez l'étape "Créez un fichier en incluant les paramètres..." dans cette solution.

Lorsque vous utilisez des modèles Flex, vous pouvez configurer certaines options de pipeline lors de l'initialisation du pipeline, mais les autres options de pipeline ne peuvent pas être modifiées. Si les arguments de ligne de commande requis par le modèle Flex sont écrasés, la tâche peut ignorer, remplacer ou supprimer les options de pipeline transmises par le lanceur de modèles. La tâche peut échouer au lancement ou une tâche qui n'utilise pas le modèle Flex peut être lancée. Pour en savoir plus, consultez la section Failed to read the job file (Échec de la lecture du fichier de tâche).

Lors de l'initialisation du pipeline, ne modifiez pas les options de pipeline suivantes :

Java

  • runner
  • project
  • jobName
  • templateLocation
  • region

Python

  • runner
  • project
  • job_name
  • template_location
  • region

Go

  • runner
  • project
  • job_name
  • template_location
  • region

Bloquer les clés SSH de projet à partir de VM qui utilisent des clés SSH basées sur les métadonnées

Vous pouvez empêcher les VM d'accepter les clés SSH stockées dans les métadonnées du projet en bloquant les clés SSH du projet provenant des VM. Utilisez l'option additional-experiments avec l'option de service block_project_ssh_keys :

--additional-experiments=block_project_ssh_keys

Pour en savoir plus, consultez la page Options du service Dataflow.

Métadonnées

Vous pouvez étendre votre modèle en ajoutant des métadonnées afin de valider des paramètres personnalisés lors de l'exécution du modèle. Si vous souhaitez créer des métadonnées pour votre modèle, procédez comme suit :

  1. Créez un fichier metadata.json à l'aide des paramètres de Paramètres de métadonnées.

    Pour afficher un exemple, consultez la section Exemple de fichier de métadonnées.

  2. Stockez le fichier de métadonnées dans le même dossier Cloud Storage que le modèle.

Paramètres de métadonnées

Clé du paramètre Obligatoire Description de la valeur
name Oui Nom du modèle.
description Non Court paragraphe de texte décrivant le modèle.
streaming Non Si la valeur est true, ce modèle est compatible avec le streaming. La valeur par défaut est false.
supportsAtLeastOnce Non Si la valeur est true, ce modèle accepte le traitement de type "au moins une fois". La valeur par défaut est false. Définissez ce paramètre sur true si le modèle est conçu pour fonctionner avec le mode de traitement en flux continu "au moins une fois".
supportsExactlyOnce Non Si la valeur est true, ce modèle est compatible avec le traitement de type "exactement une fois". La valeur par défaut est true.
defaultStreamingMode Non Mode de traitement en flux continu par défaut, pour les modèles compatibles avec les modes "au moins une fois" et "exactement une fois". Utilisez l'une des valeurs suivantes : "AT_LEAST_ONCE", "EXACTLY_ONCE". Si cette option n'est pas spécifiée, le mode de diffusion par défaut est "exactement une fois".
parameters Non Tableau de paramètres supplémentaires utilisés par le modèle. Un tableau vide est utilisé par défaut.
name Oui Nom du paramètre utilisé dans le modèle.
label Oui Chaîne au format lisible utilisée dans la console Google Cloud pour étiqueter le paramètre.
helpText Oui Court paragraphe de texte décrivant le paramètre.
isOptional Non false si le paramètre est requis et true s'il est facultatif. À moins qu'une valeur ne soit définie, isOptional est défini par défaut sur false. Si vous n'incluez pas cette clé de paramètre pour vos métadonnées, les métadonnées deviennent un paramètre obligatoire.
regexes Non Tableau d'expressions régulières POSIX-egrep sous forme de chaînes qui permettent de valider la valeur du paramètre. Par exemple : ["^[a-zA-Z][a-zA-Z0-9]+"] est une expression régulière unique qui vérifie que la valeur commence par une lettre, puis comporte un ou plusieurs caractères. Un tableau vide est utilisé par défaut.

Exemple de fichier de métadonnées

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": [
        "([^:]+:)?[^.]+[.].+"
      ]
    }
  ]
}

Vous pouvez télécharger des fichiers de métadonnées pour les modèles fournis par Google à partir du répertoire de modèles de Dataflow.

Comprendre les emplacements de préproduction et temporaires

Google Cloud CLI fournit les options --staging-location et --temp-location lorsque vous exécutez un modèle Flex. De même, l'API REST Dataflow fournit des champs stagingLocation et tempLocation pour FlexTemplateRuntimeEnvironment.

Pour les modèles Flex, l'emplacement de préproduction est l'URL Cloud Storage dans laquelle les fichiers sont écrits lors de l'étape de préproduction du lancement d'un modèle. Dataflow lit ces fichiers intermédiaires pour créer le graphique de modèle. L'emplacement temporaire est l'URL de Cloud Storage dans laquelle les fichiers temporaires sont écrits lors de l'étape d'exécution.

Mettre à jour un job de modèle Flex

L'exemple de requête suivant montre comment mettre à jour un job par flux à partir d'un modèle à l'aide de la méthode projects.locations.flexTemplates.launch. Si vous souhaitez utiliser gcloud CLI, consultez la page Mettre à jour un pipeline existant.

Si vous souhaitez mettre à jour un modèle classique, utilisez plutôt projects.locations.templates.launch.

  1. Suivez les étapes pour créer un job par flux à partir d'un modèle Flex. Envoyez la requête HTTP POST suivante avec les valeurs modifiées :

    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"
    },
}
    • Remplacez PROJECT_ID par l'ID du projet.
    • Remplacez REGION par la région Dataflow du job que vous mettez à jour.
    • Remplacez JOB_NAME par le nom exact du job que vous souhaitez mettre à jour.
    • Définissez parameters sur votre liste de paires clé/valeur. Les paramètres répertoriés sont spécifiques à cet exemple de modèle. Si vous utilisez un modèle personnalisé, modifiez les paramètres selon vos besoins. Si vous utilisez le modèle d'exemple, remplacez les variables suivantes.
      • Remplacez SUBSCRIPTION_NAME par le nom de votre abonnement Pub/Sub.
      • Remplacez DATASET par le nom de votre ensemble de données BigQuery.
      • Remplacez TABLE_NAME par le nom de votre table BigQuery.
    • Remplacez STORAGE_PATH par l'emplacement Cloud Storage du fichier de modèle. L'emplacement doit commencer par gs://.

  2. Utilisez le paramètre environment pour modifier les paramètres de l'environnement. Pour en savoir plus, consultez la section FlexTemplateRuntimeEnvironment.

  3. Facultatif : Pour envoyer votre requête à l'aide de curl (Linux, macOS ou Cloud Shell), enregistrez la requête dans un fichier JSON, puis exécutez la commande suivante :

    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

    Remplacez FILE_PATH par le chemin d'accès au fichier JSON contenant le corps de la requête.

  4. Utilisez l'interface de surveillance de Dataflow pour vérifier qu'un nouveau job portant le même nom a été créé. Ce job est associé à l'état Updated (Mis à jour).

Limites

Les limites suivantes s'appliquent aux tâches de modèles Flex :

  • Vous devez utiliser une image de base fournie par Google pour empaqueter vos conteneurs à l'aide de Docker. Pour obtenir la liste des images applicables, consultez la section Images de base des modèles Flex.
  • Le programme qui construit le pipeline doit se fermer après l'appel de run afin que le pipeline puisse démarrer.
  • waitUntilFinish (Java) et wait_until_finish (Python) ne sont pas acceptés.

Étapes suivantes