Déploiement GCP Dagster

Dagster+ offre deux modes de déploiement sur GCP. Le choix dépend de si on veut que Dagster gère entièrement le calcul, ou si l’exécution doit rester dans sa propre infrastructure.

Mode Serverless

Dagster héberge tout. Le code s’exécute sur l’infrastructure de Dagster. On pousse le code, Dagster gère le déploiement, la mise à l’échelle et l’exécution.

Idéal pour : les workloads qui orchestrent des services externes plutôt que d’exécuter des calculs intensifs. Si le pipeline Dagster dit principalement à BigQuery d’exécuter des requêtes (via dbt), déclenche des synchronisations Fivetran et écrit des métadonnées, le calcul réel est minimal — BigQuery et Fivetran font le travail intensif. Dagster Serverless gère la couche d’orchestration à faible coût.

Limites :

• Limité à 4 CPU par nœud. Pour la plupart des workflows dbt + BigQuery, c’est suffisant, puisque le travail intensif se passe dans BigQuery, pas dans Dagster.
• Le code et les données transitent par l’infrastructure de Dagster. Si les exigences de sécurité imposent que toute l’exécution reste dans le VPC, Serverless ne convient pas.
• Les coûts de calcul Serverless (0,005 $/minute) s’ajoutent à la tarification basée sur les crédits.

Configuration : minimale. Connecter le dépôt Git, configurer les ressources pointant vers le projet GCP, et Dagster fait le reste. Pas de cluster GKE, pas de chart Helm, pas d’infrastructure à gérer.

Pour les équipes d’analytics engineering sur dbt + BigQuery où le pipeline est principalement de l’orchestration (planification des builds dbt, coordination des synchronisations Fivetran, déclenchement des rafraîchissements en aval), Serverless est le chemin le plus simple vers un déploiement en production.

Mode Hybrid

Dagster héberge le plan de contrôle. L’exécution se passe dans votre infrastructure. Le plan de contrôle Dagster+ gère l’UI web, la planification, l’évaluation des capteurs et la coordination des exécutions. Le calcul réel — exécuter dbt, les assets Python, les appels API externes — se passe sur un agent Kubernetes dans le projet GCP.

Idéal pour : les équipes avec des exigences de sécurité (les données restent dans le VPC), des besoins de calcul intensif (plus de 4 CPU), ou une infrastructure GKE existante à réutiliser.

Déploiement GKE

Le déploiement Hybrid standard exécute un agent Dagster sur Google Kubernetes Engine en utilisant le chart Helm officiel de Dagster :

helm repo add dagster https://dagster-io.github.io/helm
helm install dagster dagster/dagster \
  --set dagsterCloud.deployment=prod \
  --set dagsterCloud.agentToken=$DAGSTER_AGENT_TOKEN

Le chart Helm déploie :

• Pod agent qui interroge Dagster+ pour les exécutions à effectuer
• Pods worker qui démarrent pour chaque exécution, exécutent le code, et s’arrêtent
• Configuration pour les limites de ressources, les comptes de service et les secrets

Authentification : Workload Identity

Le pattern d’authentification recommandé pour GCP utilise Workload Identity, qui mappe un compte de service Kubernetes à un compte de service GCP. Les pods de l’agent Dagster s’authentifient à BigQuery, GCS et autres services GCP sans clés de compte de service.

# Valeurs Helm pour Workload Identity
serviceAccount:
  create: true
  annotations:
    iam.gke.io/gcp-service-account: dagster-agent@my-project.iam.gserviceaccount.com

Côté GCP, lier le compte de service GCP au compte de service Kubernetes :

gcloud iam service-accounts add-iam-policy-binding \
  dagster-agent@my-project.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:my-project.svc.id.goog[dagster/dagster-agent]"

Cela suit le même pattern de résolution ADC utilisé dans les Cloud Run Jobs. Le compte de service nécessite :

• roles/bigquery.dataEditor et roles/bigquery.jobUser pour l’exécution dbt
• roles/storage.objectViewer pour la lecture depuis GCS (si le pipeline utilise GCS en staging)
• Tous les rôles supplémentaires requis par les assets Python

Stockage : Cloud SQL + GCS

Dagster nécessite un stockage persistant pour l’historique des exécutions, les journaux d’événements et les métadonnées des assets. En mode Hybrid, on le fournit soi-même :

• Cloud SQL PostgreSQL pour le stockage des exécutions et des journaux d’événements. Une petite instance Cloud SQL (db-f1-micro ou db-g1-small) gère la plupart des workloads à 10-30 $/mois.
• Bucket GCS pour la persistance de l’I/O manager — quand des assets transfèrent des données entre étapes, les données sérialisées vivent dans GCS.

# Valeurs Helm pour Cloud SQL
postgresql:
  enabled: false  # Ne pas déployer PostgreSQL dans le cluster
dagsterDaemon:
  env:
    DAGSTER_PG_HOST: /cloudsql/my-project:us-central1:dagster-db
    DAGSTER_PG_DB: dagster
    DAGSTER_PG_USER: dagster
    DAGSTER_PG_PASSWORD:
      secretKeyRef:
        name: dagster-db-credentials
        key: password

Pour la connectivité Cloud SQL, utiliser le Cloud SQL Auth Proxy comme conteneur sidecar dans le pod de l’agent Dagster. Cela gère des connexions chiffrées sans exposer la base de données à internet public.

Option Cloud Run (communautaire)

Un package dagster-contrib-gcp maintenu par la communauté prend en charge l’exécution des exécutions Dagster comme Cloud Run jobs plutôt que des pods GKE. C’est intéressant pour les équipes qui préfèrent le calcul serverless et veulent éviter de gérer un cluster Kubernetes.

Les compromis par rapport à GKE :

• Infrastructure plus simple. Pas de cluster GKE à gérer.
• Latence de démarrage à froid. Les Cloud Run jobs prennent quelques secondes pour démarrer, ce qui s’ajoute au temps d’exécution.
• Moins de contrôle. Kubernetes offre une configuration des ressources plus fine, de la planification et de l’affinité des pods que Cloud Run ne prend pas en charge.
• Maintenu par la communauté. Pas une intégration officielle Dagster, donc le support et la maintenance dépendent des contributeurs communautaires.

Pour les petites équipes exécutant des workflows dbt + BigQuery où la couche d’orchestration est légère, l’exécution Cloud Run est un choix raisonnable. Pour les équipes avec des besoins de calcul intensif ou des besoins d’infrastructure complexes, GKE est plus robuste.

Choisir un mode

Pour les équipes d’analytics engineering natives GCP, la décision se résume aux exigences de sécurité et d’infrastructure. Si les données peuvent transiter par l’infrastructure de Dagster et que les besoins de calcul sont modestes, Serverless est l’option la plus simple. Si les données doivent rester dans un VPC ou si GKE est déjà utilisé pour d’autres workloads, Hybrid sur GKE est un choix naturel.

La note sur la tarification couvre les implications de coût de chaque mode, et le cadre d’orchestration GCP positionne Dagster par rapport aux alternatives natives GCP.