Ce hub couvre le déploiement de dbt Core sur Google Cloud Functions — une option serverless pour exécuter dbt sur un planning sans gérer de conteneurs ni de serveurs. Il couvre le chemin complet d’un projet dbt existant jusqu’à une fonction planifiée.
Prérequis
Avant de commencer, vous avez besoin :
- D’un projet dbt Core fonctionnel connecté à BigQuery (voir dbt Project Structure and Naming pour les conventions de structure de projet)
- D’un accès à un projet GCP avec la facturation activée
- Du CLI
gcloudinstallé et authentifié localement
Le chemin d’installation
Étape 1 : Décider si Cloud Functions est adapté à votre cas.
Cloud Functions comme environnement d’exécution dbt compare Cloud Functions à Cloud Run Jobs et explique quand chacun a du sens. En résumé : Cloud Functions est plus rapide à configurer mais a un plafond de délai d’attente de 60 minutes et installe les packages dbt à chaque exécution. Si votre projet est petit et que vous souhaitez un planning fonctionnel aujourd’hui, Cloud Functions est un point de départ raisonnable.
Étape 2 : Restructurer le dépôt.
Cloud Functions attend main.py et requirements.txt à la racine de votre répertoire source. Cela entre en conflit avec la structure standard des projets dbt, donc vous déplacez les fichiers dbt dans un sous-répertoire. dbt Repository Structure for Cloud Function Deployment couvre la structure cible, le code du point d’entrée main.py, et la configuration profiles.yml avec method: oauth.
Étape 3 : Configurer le compte de service.
dbt a besoin de permissions IAM pour lire les projets sources et écrire dans le projet de transformation. Si vos données s’étendent sur plusieurs projets GCP, les permissions doivent être accordées dans chacun. dbt Service Account Setup for Multi-Project GCP Architectures contient le script gcloud complet pour créer le compte de service et attribuer les bons rôles dans les projets sources, le projet de transformation et le projet Cloud Functions.
Étape 4 : Déployer la Cloud Function.
Depuis la racine de votre dépôt, déployez avec :
gcloud functions deploy dbt_run \ --region=europe-west1 \ --service-account=dbt-transform-sa@projectid.iam.gserviceaccount.com \ --gen2 \ --runtime=python310 \ --entry-point=run_dbt \ --trigger-http \ --timeout=3500 \ --memory=1GUtilisez les fonctions gen2 (2e génération) — elles supportent des délais d’attente plus longs et une meilleure observabilité que gen1. Choisissez une région où gen2 est disponible ; la documentation GCP contient la liste actuelle.
Après le déploiement, la sortie de gcloud functions describe inclut l’URL du déclencheur HTTP dont vous aurez besoin pour l’étape 5.
Étape 5 : Planifier avec Cloud Scheduler.
Authentification OIDC Cloud Scheduler pour les déclencheurs HTTP couvre comment configurer un job Cloud Scheduler qui s’authentifie auprès de la Cloud Function en utilisant des tokens OIDC. Le compte de service a besoin de roles/iam.serviceAccountTokenCreator sur lui-même et de roles/cloudfunctions.invoker sur la fonction.
Ce que cela produit
Un projet dbt s’exécutant sur un planning, avec des logs dans Cloud Logging, des coûts mesurés en centimes par mois, et aucune infrastructure persistante. La fonction ne s’exécute que lorsqu’elle est déclenchée. La surface opérationnelle est un fichier Python, une liste de dépendances et un job Cloud Scheduler. Quand quelque chose échoue, les logs sont dans Cloud Logging et la cause racine est généralement une permission IAM ou une incompatibilité de version de package.
Si le projet dépasse Cloud Functions — le temps d’exécution dépasse 45 minutes, ou les packages doivent être intégrés plutôt qu’installés à l’exécution — Cloud Run Jobs pour dbt est le chemin de migration. Le projet dbt dans dbt_transform/ reste inchangé ; seul le wrapper d’exécution change. Le cadre de décision d’orchestration dbt pour GCP cartographie toutes les options GCP et leurs compromis.