Options de déploiement dlt

dlt s’exécute partout où Python s’exécute. Un pipeline qui fonctionne localement fonctionne en production sans modification de code — uniquement des changements de configuration. La commande dlt deploy génère un scaffolding de déploiement pour les plateformes courantes afin que vous n’ayez pas à écrire cette configuration depuis zéro.

La commande dlt deploy

dlt deploy prend votre script de pipeline et une plateforme cible, et génère une configuration de déploiement :

dlt deploy my_pipeline.py github-action --schedule "0 6 * * *"
dlt deploy my_pipeline.py airflow-composer --secrets-format env

Les fichiers générés ne sont pas magiques — ce sont des points de départ que vous pouvez modifier. Examinez-les avant de committer. Ils gèrent le boilerplate (installation des dépendances, injection des secrets, configuration du planificateur) pour que vous vous concentriez sur les ajustements spécifiques à la plateforme dont votre configuration a besoin.

GitHub Actions

GitHub Actions est le chemin de déploiement le plus simple pour les équipes déjà sur GitHub. Exécutez sur un planning avec les secrets injectés depuis les repository secrets :

dlt deploy my_pipeline.py github-action --schedule "0 6 * * *"

Cela génère un fichier de workflow dans .github/workflows/. Le workflow généré :

• Checkout le dépôt
• Installe Python et les dépendances dlt
• Configure les secrets depuis les repository secrets GitHub comme variables d’environnement
• Exécute le script de pipeline selon le planning cron spécifié

Stockez les credentials comme repository secrets GitHub, pas dans le fichier de workflow lui-même. Voir Gestion des secrets dlt pour les conventions de nommage des variables d’environnement attendues par dlt.

GitHub Actions est un choix de production raisonnable pour les pipelines qui s’exécutent rarement (toutes les heures ou moins) et n’ont pas besoin de gestion complexe des dépendances entre pipelines. C’est gratuit pour les dépôts publics et utilise les minutes GitHub standard pour les dépôts privés.

Airflow / Google Cloud Composer

Pour les équipes avec une infrastructure Airflow existante, dlt s’intègre via PipelineTasksGroup :

dlt deploy my_pipeline.py airflow-composer --secrets-format env

Le DAG généré utilise PipelineTasksGroup pour créer des tâches Airflow séparées par ressource dlt. Cela vous offre un parallélisme au niveau des ressources et un contrôle des réessais dans le graphe de tâches Airflow — chaque ressource devient une tâche qui peut échouer et réessayer indépendamment plutôt que l’ensemble du pipeline réussissant ou échouant comme une unité.

Google Cloud Composer est l’offre Airflow managé de Google. Si votre organisation exécute d’autres pipelines sur Composer, ajouter des pipelines dlt y garde votre orchestration centralisée. Le modèle de coût est différent de GitHub Actions — Composer est une infrastructure toujours active avec facturation horaire indépendamment de l’exécution ou non des pipelines. Voir Coût et capacités de Cloud Composer pour savoir quand ce coût est justifié.

Modal (Serverless)

Modal convient bien aux déploiements serverless où vous ne souhaitez pas gérer d’infrastructure :

import modal
import dlt

app = modal.App("my-dlt-pipeline")

@app.function(schedule=modal.Period(days=1))
def run_pipeline():
    pipeline = dlt.pipeline(destination="bigquery", dataset_name="api_data")
    pipeline.run(my_api_source())

Modal provisionne le calcul à la demande, exécute la fonction et le détruit. Pas d’infrastructure persistante. La facturation se fait à la seconde du temps de calcul réel, pas à l’heure de capacité réservée.

La contrepartie : les cold starts. Les fonctions Modal ont une latence de démarrage quand elles n’ont pas été exécutées récemment. Pour les pipelines qui s’exécutent toutes les heures, c’est négligeable. Pour les pipelines qui s’exécutent toutes les 5 minutes, la surcharge de cold start peut avoir de l’importance.

Le système de secrets de Modal s’intègre proprement avec la hiérarchie de configuration de dlt — stockez les credentials dans les secrets Modal, accédez-y comme variables d’environnement dans la fonction.

Google Cloud Run Jobs

Cloud Run Jobs est l’option serverless native GCP. Contrairement à Modal (tiers), Cloud Run Jobs s’exécute dans votre projet GCP et s’intègre directement avec IAM, Secret Manager et Cloud Scheduler.

Le pattern de déploiement est similaire à Cloud Run Jobs pour dbt — conteneurisez le pipeline, poussez vers Artifact Registry, créez un Cloud Run Job, planifiez avec Cloud Scheduler. La différence est que votre script de pipeline dlt devient le point d’entrée du conteneur plutôt qu’une commande dbt.

Pour les équipes GCP-natives utilisant déjà BigQuery comme destination, Cloud Run Jobs est souvent le choix le plus naturel opérationnellement : IAM contrôle l’accès, Secret Manager détient les credentials, Cloud Logging capture la sortie du pipeline, et Cloud Scheduler déclenche les exécutions — tout dans le même projet GCP que vos données.

Dagster

Dagster a une intégration native dlt via @dlt_assets. Si votre organisation utilise Dagster pour l’orchestration, les pipelines dlt deviennent des assets Dagster de première classe :

from dagster_dlt import DagsterDltResource, dlt_assets

@dlt_assets(dlt_source=my_api_source(), dlt_pipeline=pipeline)
def my_api_assets(context, dlt: DagsterDltResource):
    yield from dlt.run(context=context)

Cela vous offre le graphe d’assets de Dagster, le suivi de lignage et l’historique des exécutions pour vos pipelines dlt aux côtés de vos assets dbt. Pour les équipes utilisant Dagster pour l’orchestration dbt, ajouter des assets dlt garde l’ensemble du pipeline d’extraction vers transformation visible au même endroit.

Prefect

Prefect traite les pipelines dlt comme des flows ou des tâches dans des flows. L’intégration est simple :

from prefect import flow

@flow
def my_pipeline_flow():
    pipeline = dlt.pipeline(destination="bigquery", dataset_name="api_data")
    pipeline.run(my_api_source())

Planifiez le flow avec l’infrastructure de déploiement et de planificateur de Prefect.

Choisir une plateforme

La décision dépend généralement de ce que votre équipe utilise déjà et de la complexité opérationnelle que vous pouvez accepter :

Toutes ces options exécutent le même code Python. La plateforme de déploiement est un enjeu de configuration, pas de code.