Provisionner des ressources

Cette page explique comment provisionner des ressources pour vos pipelines.

À propos du provisionnement de ressources dans Orchestration Pipelines

Orchestration Pipelines utilise une approche IaC (Infrastructure as Code) pour gérer Google Cloud les ressources utilisées par vos pipelines de données, ce qui présente les avantages suivants :

  • Contrôle des versions Les modifications de l'infrastructure sont suivies dans Git.
  • Reproductibilité Les environnements peuvent être recréés de manière fiable.
  • Collaboration Les membres de l'équipe peuvent examiner les définitions d'infrastructure et y contribuer.
  • Automatisation Intégration dans les pipelines CI/CD.
  • Facultatif et coexistence Le framework de provisionnement de ressources est facultatif. Si vous utilisez déjà Terraform ou d'autres pratiques IaC établies pour le provisionnement de ressources, vous pouvez continuer à le faire. Vous pouvez gérer un sous-ensemble de ressources pertinentes pour un pipeline ou une application spécifique, en coexistence potentielle avec des ressources gérées par d'autres outils.

Dans Orchestration Pipelines, votre projet peut comporter un ou plusieurs environnements de déploiement. La configuration de chaque environnement de déploiement définit la manière dont les pipelines et les ressources appartenant à cet environnement sont déployés. Par exemple, vous pouvez avoir un environnement de déploiement pour le développement et un autre pour la production.

Exemple de configuration d'un environnement de déploiement. Les ressources provisionnées sont définies dans le mappage resources.

environments:
  dev:
    project: example-dev-project
    region: us-central1
    variables:
      dataset_name: marketing_analytics_dev
    secrets:
      dts_api_key: "projects/example-dev-project/secrets/dev-dts-key/versions/latest"
    resources:
      - type: dataproc.cluster
        name: example-static-cluster-resource
        definition:
          clusterName: example-static-cluster

Lorsque vous déployez votre pipeline, Orchestration Pipelines utilise un modèle "créer ou mettre à jour" sans état pour provisionner les ressources que vous avez définies :

  • Si une ressource est définie, mais n'existe pas, Orchestration Pipelines la crée.

  • Si une ressource existe :

    • (Par défaut) Mettez à jour la configuration de la ressource pour qu'elle corresponde à la définition.

    • Si vous définissez ce comportement dans la configuration de la ressource, Orchestration Pipelines peut ignorer les modifications ou recréer une ressource.

  • Si vous supprimez la définition d'une ressource de la configuration, cela n'entraîne pas la suppression de la ressource. Cette approche privilégie la sécurité et évite les pertes de données accidentelles.

  • Si vous renommez une ressource existante, Orchestration Pipelines crée une ressource avec le nouveau nom et conserve la ressource d'origine.

Ressources provisionnées par rapport aux profils de ressources

Les profils de ressources sont des fichiers modèles contenant la définition d'une ou de plusieurs Google Cloud ressources. Ils sont différents des ressources provisionnées et peuvent être utilisés conjointement :

  • Avec les ressources provisionnées : au lieu de définir la même configuration de ressource en ligne dans chaque environnement de développement de votre fichier deployment.yaml, vous pouvez la définir une seule fois dans un profil, puis la référencer. Les ressources provisionnées sont compatibles avec un large éventail de types de ressources pouvant être définis dans des profils de ressources.

  • Avec les actions de pipeline : vous pouvez utiliser des profils de ressources dans les actions où les ressources sont provisionnées pendant la durée d'une action. En utilisant un profil de ressources au lieu de spécifier la configuration de la ressource en ligne, vous pouvez séparer la configuration de la ressource de l'action de pipeline et réutiliser une configuration pour plusieurs actions de pipeline. Les actions de pipeline ne sont compatibles avec les profils de ressources que pour les ressources Managed Service pour Apache Spark, par exemple lors de l'exécution d'actions de pipeline dans un cluster éphémère.

Afficher les types de ressources disponibles

Consultez Types de ressources.

Vous pouvez également afficher toutes les ressources disponibles dans gcloud CLI à l'aide de la commande suivante :

gcloud beta orchestration-pipelines resource-types list

Ajouter une ressource

Pour ajouter une ressource provisionnée à la configuration de l'environnement de déploiement, ajoutez sa définition comme suit :

  1. Dans la configuration de votre environnement de déploiement, ajoutez un élément à la liste environments.DEVELOPMENT_ENVIRONMENT.resources.

  2. Spécifiez les clés suivantes :

    • type : type de ressource à provisionner. Google Cloud Exemples : bigquery.dataset, dataform.repository. Vous pouvez afficher les types de ressources disponibles à l'aide d'une commande gcloud CLI.

    • name : nom logique de la ressource dans le fichier deployment.yaml.

    • parent : spécifie une ressource parente pour les types de ressources qui en nécessitent une. Définissez le name de la ressource parente comme valeur.

    • updateAction : spécifie l'action à effectuer lorsqu'une modification est détectée dans la configuration de la ressource :

      • (Par défaut) patch : mettez à jour les propriétés de la ressource qui ont été modifiées.

        L'opération de mise à jour ne modifie que les propriétés spécifiées dans la configuration de la ressource (YAML), en laissant les autres propriétés existantes inchangées. Vous pouvez utiliser ce comportement, par exemple, pour ne gérer que les propriétés importantes pour l'exécution du pipeline et conserver les autres propriétés configurées manuellement.

        Si les modifications affectent des champs immuables ou si la ressource est immuable, le déploiement échoue. Dans ce cas, nous vous recommandons d'ajuster la définition pour ne modifier que les champs modifiables. Si cela n'est pas possible, vous pouvez remplacer l'action de mise à jour par recreate.

      • skip : ignorez les modifications et ne mettez pas à jour la configuration de la ressource.

        Nous vous recommandons d'utiliser cette option lorsque vous souhaitez gérer l'existence de la ressource, mais effectuer les modifications et mises à jour de la configuration par d'autres moyens, par exemple manuellement.

      • recreate: si des modifications sont détectées, supprimez la ressource existante, puis créez-en une en fonction de la définition actuelle de la ressource.

        Nous vous recommandons d'utiliser cette option pour les ressources entièrement immuables ou lorsque des modifications sont apportées à des champs qui ne peuvent pas être mis à jour sur place.

    • definition: spécification de la ressource, sous forme de mappage qui reflète la structure de configuration de la ressource dans l'API de la ressource.

    • (Facultatif) metadata : métadonnées spécifiques à Orchestration Pipelines. Certains types de ressources utilisent des champs de métadonnées pour configurer la ressource dans Google Cloud Par exemple, le metadata.location champ peut être utilisé pour créer des ressources zonales.

  3. Validez et déployez votre pipeline. Orchestration Pipelines provisionnera la nouvelle ressource lors du déploiement du pipeline.

Exemple : Ressources de longue durée

Cet exemple montre comment ajouter une ressource de longue durée, en l'occurrence un cluster Managed Service pour Apache Spark statique. Une fois provisionné, il peut être utilisé dans les actions de pipeline. Nous vous recommandons d'utiliser cette approche générale lorsque vos pipelines utilisent des ressources persistantes.

L'exemple suivant ajoute un cluster Managed Service pour Apache Spark statique nommé example-static-cluster à l'environnement de déploiement dev. La définition de la ressource est fournie en fonction de l'API Dataproc.

environments:
  dev:
    project: "example-project"
    region: "us-central1"
    # A runner environment for executing pipeline actions
    composer_environment: "example-runner-environment"

    resources:
      - type: dataproc.cluster
        name: example-static-cluster
        updateAction: patch
        definition:
          config:
            masterConfig:
              numInstances: 1
              machineTypeUri: n1-standard-4
            workerConfig:
              numInstances: 3
              machineTypeUri: n1-standard-4

Ce cluster peut être utilisé dans les actions de pipeline comme d'habitude. Il n'y a aucune différence d'utilisation par rapport à un cluster créé manuellement, par exemple.

modelVersion: "1.0"
pipelineId: "example-dataproc-pipeline"
...
actions:
  - pyspark:
      name: "run-pyspark-with-pyfiles-on-existing-cluster"
      engine:
        dataprocOnGce:
          existingCluster:
            clusterName: "example-static-cluster"
            location: {{ region }}
            projectId: {{ project }}
      mainFilePath: "scripts/my_spark_job_with_pyfiles.py"
      pyFiles:
        - "scripts/lib1.py"

Exemple : Processus automatisé de compilation et de publication pour Dataform

Cet exemple illustre un processus automatisé de compilation et de publication pour Dataform. Dans le scénario d'exemple :

  1. Un dépôt Dataform est connecté à un dépôt GitHub via Developer Connect.

  2. Vous transférez les modifications vers le dépôt GitHub.

  3. Une fois les modifications transférées, vous déployez le pipeline.

  4. Dataform extrait le code du dépôt GitHub, crée un résultat de compilation et le prépare à l'exécution.

  5. Une configuration de workflow est ensuite utilisée pour exécuter des workflows avec cette version compilée automatiquement.

L'exemple de code suivant définit un dépôt Dataform, une configuration de version et une configuration de workflow pour celui-ci dans l'environnement de déploiement dev :

  • La ligne gitCommitish: "{{ COMMIT_SHA }}" lie la configuration de version au commit Git spécifique en cours de déploiement. Le COMMIT_SHA est une variable qui correspond au SHA du commit du bundle de pipeline déployé.
  • La clé codeCompilationConfig.pipelineConfig.path pointe vers un sous-dossier contenant des éléments de pipeline. Vous pouvez ainsi conserver plusieurs pipelines Dataform dans un seul dépôt.

  • Définir releaseCompilationResult sur auto dans la définition de releaseConfig demande à Orchestration Pipelines de déclencher une compilation Dataform une fois la ressource releaseConfig créée ou mise à jour avec le nouveau gitCommitish :

    1. Le framework insère (met à jour ou crée) d'abord la ressource releaseConfig pour qu'elle pointe vers le commit spécifié.
    2. Ensuite, en raison du paramètre auto, il appelle l'API Dataform pour créer un résultat de compilation basé sur le code de ce commit.
    3. Le releaseConfig est à nouveau mis à jour pour pointer vers l'ID du résultat de compilation nouvellement créé, ce qui fait de cette version la version "active".
environments:
  dev:
    project: example-project
    region: us-central1
    composer_environment: example-runner-environment
    artifact_storage:
      bucket: example-bucket
      path_prefix: initialized-artifact-bucket
    pipelines:
      - source: initialized-pipeline.yaml
      - source: dataform_local_pipeline.yaml
      - source: dataform_service_pipeline.yaml
    resources:
      - name: {{ repository_name }}
        type: dataform.repository
        definition:
          labels:
            bigquery-deployment: preview
      - type: dataform.repository.releaseConfig
        name: subfolder-release
        parent: {{ repository_name }}
        definition:
          gitCommitish: {{ COMMIT_SHA }}
          releaseCompilationResult: auto
          codeCompilationConfig:
            pipelineConfig:
              pipelineType: DATAFORM
              path: weather_dataform
      - type: dataform.repository.workflowConfig
        name: {{ workflow_config_name }}
        parent: {{ repository_name }}
        definition:
          releaseConfig: subfolder-release
          invocationConfig:
            serviceAccount: {{ service_account }}
    variables:
      service_account: example-account@example-project.iam.gserviceaccount.com
      network_uri: projects/example-project/global/networks/default
      subnetwork_uri: projects/example-project/regions/us-central1/subnetworks/default
      region: us-central1
      repository_name: weather-aggregation-repo
      workflow_config_name: updated-subfolder-workflow

Exemple d'action de pipeline qui exécute un workflow avec la configuration de workflow créée :

modelVersion: '1.0'
pipelineId: dataform_service_pipeline
description: Updated run Dataform pipeline via Dataform Service
runner: airflow
owner: data-eng-team

defaults:
  projectId: {{ project }}
  location: {{ region }}
  executionConfig:
    retries: 1

actions:
  - pipeline:
      name: run_dataform_service
      framework:
        dataform:
          dataformService:
            location: {{ region }}
            projectId: {{ project }}
            repositoryId: {{ repository_name }}
            workflowInvocation:
              workflowConfig: projects/{{ project }}/locations/{{ region }}/repositories/{{
                repository_name }}/workflowConfigs/{{ workflow_config_name }}
  - python:
      name: fibonacci_python
      mainFilePath: scripts/fibonacci.py
      pythonCallable: fibonacciTen
      engine:
        local: {}
  - sql:
      name: dummy_bq_query
      engine:
        bigquery:
          location: {{ region }}
      query:
        inline: 'SELECT COUNT(*) FROM `{{ project }}.weather_data.sensor_readings`'
tags:
  - job:datacloud:vscode