Pour mieux tirer parti du succès et de la préférence croissante des clients pour les solutions OSS, Cloud Composer devient Service géré pour Apache Airflow. Ce changement de nom permet aux clients de mieux comprendre notre portefeuille et renforce notre engagement à être l'écosystème cloud le plus ouvert.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Migrer des environnements vers Airflow 3 (côte à côte)

Airflow géré (3e génération) | Airflow géré (2e génération) | Airflow géré (ancienne 1re génération)

Cette page explique comment transférer des DAG, des données et des configurations depuis votre environnement Managed Airflow (3e génération) existant avec Airflow 2 vers un environnement Managed Airflow (3e génération) avec Airflow 3.

Autres guides de migration

De	À	Méthode	Guide
Managed Airflow (3e génération), Airflow 2	Managed Airflow (3e génération), Airflow 3	Transfert manuel côte à côte	Ce guide
Managed Airflow (2e génération)	Managed Airflow (3e génération)	Parallèlement, à l'aide du script de migration	Guide de migration des scripts
Managed Airflow (2e génération)	Managed Airflow (3e génération)	Côte à côte, à l'aide d'instantanés	Guide de migration des instantanés
Managed Airflow (ancienne génération 1), Airflow 2	Managed Airflow (3e génération)	Côte à côte, à l'aide d'instantanés	Guide de migration des instantanés
Managed Airflow (ancienne génération 1), Airflow 2	Managed Airflow (2e génération)	Côte à côte, à l'aide d'instantanés	Guide de migration des instantanés
Managed Airflow (ancienne génération 1), Airflow 2	Managed Airflow (2e génération)	Transfert manuel côte à côte	Guide de migration manuelle
Managed Airflow (ancienne génération 1), Airflow 1	Managed Airflow (2e génération), Airflow 2	Côte à côte, à l'aide d'instantanés	Guide de migration des instantanés
Managed Airflow (ancienne génération 1), Airflow 1	Managed Airflow (2e génération), Airflow 2	Transfert manuel côte à côte	Guide de migration manuelle
Managed Airflow (ancienne génération 1), Airflow 1	Managed Airflow (ancienne génération 1), Airflow 2	Transfert manuel côte à côte	Guide de migration manuelle

Modifications apportées dans Airflow 3

Avant de commencer à utiliser les environnements Managed Airflow avec Airflow 3, prenez en compte les modifications apportées par Airflow 3 aux environnements Managed Airflow (3e génération).

Pour obtenir un aperçu des modifications apportées à la version communautaire d'Airflow 3, consultez Apache Airflow 3 est disponible dans sa version finale !.

Gestion des versions de DAG

Dans Airflow 3, un DAG s'exécute jusqu'à la fin en fonction de la version au début, même si une nouvelle version a été importée pendant l'exécution du DAG.
- Toutes les exécutions de DAG dans l'interface utilisateur Airflow sont désormais associées à la version de DAG correspondante (la version au moment de l'exécution). Cela inclut la structure des tâches et le code DAG.

Améliorations apportées aux remplissages

Airflow 3 introduit une refonte majeure de la façon dont les remplissages (réexécution de pipelines pour les données historiques) sont gérés. Les remplissages sont en train de passer d'un processus manuel à une fonctionnalité entièrement observable intégrée au moteur Airflow principal :

Les remplissages sont désormais gérés directement dans le planificateur Airflow, au lieu d'être traités comme des processus manuels distincts. Cela permet une meilleure évolutivité et un contrôle plus précis.
Vous pouvez désormais déclencher, arrêter et surveiller la progression du remplissage directement depuis l'UI ou les appels d'API Airflow, en plus de la CLI Airflow.
Le programmateur Airflow offre une meilleure visibilité sur l'état et l'intégrité des exécutions de remplissage historique.
Bien que les améliorations du remplissage soient fortement demandées par la communauté du machine learning (pour réentraîner les modèles sur d'anciennes données), elles s'appliquent à tous les workflows ETL/ELT.

Sécurité et fiabilité améliorées

Dans Airflow 3, les tâches ne communiquent qu'avec le serveur d'API central via le SDK de tâches (dans Airflow 2, les tâches pouvaient avoir un accès direct à la base de données). Le serveur d'API regroupe ces connexions de manière efficace. Votre base de données est protégée contre les pics de connexion, ce qui rend l'ensemble de l'environnement plus stable en cas de charge importante.
Grâce à une nouvelle interface d'exécution des tâches, Airflow 3 offre une meilleure isolation entre les tâches, ce qui empêche une tâche d'interférer potentiellement avec les données d'une autre tâche ou d'y accéder.
L'interface de ligne de commande d'Airflow 3 s'éloigne de l'accès direct à la base de données. Une nouvelle interface de ligne de commande airflowctl est un package distinct conçu spécifiquement pour l'accès à distance via l'API. Au lieu d'accéder directement à la base de données, il interagit avec Airflow via des API, ce qui est plus sécurisé.

Planification basée sur les événements et composants de données

Les ensembles de données sont devenus des éléments de données. Les composants de données permettent à Airflow de mieux suivre les données créées ou mises à jour par des systèmes externes à Airflow et d'y réagir.
Un nouveau concept appelé Watchers a été introduit dans Airflow 3. Il s'agit de composants qui surveillent les modifications apportées à un ensemble de données, ce qui permet à Airflow de déclencher des workflows dès que les données arrivent. Au lieu d'interroger (vérifier toutes les minutes si un fichier existe), un DAG peut désormais être déclenché instantanément dès qu'un message atteint une file d'attente de messages.
Airflow 3 introduit une nouvelle syntaxe axée sur les composants à l'aide de décorateurs Python, ce qui rend le code plus clair et plus intuitif pour les développeurs.

Interface utilisateur Airflow modernisée

L'UI Airflow a été entièrement réécrite à l'aide de React (frontend) et de FastAPI (backend).
La nouvelle interface utilisateur Airflow effectue ses opérations via une API REST standardisée et une API spécialisée pour les opérations d'interface utilisateur.
En remplaçant l'implémentation Flask par FastAPI, l'UI Airflow est beaucoup plus réactive.
Les vues Grille et Graphique ont été unifiées pour un workflow plus fluide, ce qui permet de passer plus facilement des structures DAG de haut niveau aux journaux de tâches spécifiques.

Modifications destructives dans Airflow 3

Airflow 3 introduit des modifications majeures, dont certaines introduisent une rupture :

Il n'est pas garanti que les DAG existants d'Airflow 2 fonctionnent avec Airflow 3. Ils doivent être testés et éventuellement ajustés en modifiant les importations, les paramètres DAG et d'autres détails d'implémentation.
Certaines options de configuration Airflow 2 ont été renommées ou supprimées dans Airflow 3. Pour en savoir plus sur les paramètres, consultez la documentation de référence sur la configuration d'Airflow.
Aucun accès direct à la base de données Airflow depuis le code de la tâche :
- Le code de la tâche ne peut plus importer ni utiliser directement les sessions ou les modèles de la base de données Airflow.
- Il n'est pas possible d'utiliser PostgresHook et PostgresOperator avec la connexion airflow_db.
Certains packages PyPI personnalisés peuvent être incompatibles avec la nouvelle version d'Airflow et ses dépendances.
L'API REST (/api/v1) a été remplacée par /api/v2.
Les sous-DAG sont remplacés par des TaskGroups, des Assets et la planification basée sur les données.
Les SLA sont obsolètes et ont été supprimés. Elles sont remplacées par les Alertes de date limite.
L'argument "subdir" a été supprimé des commandes CLI.
Certaines variables de contexte Airflow ont été supprimées. Pour en savoir plus, consultez la section Breaking Changes (Changements cassants) dans la documentation Airflow.
Le paramètre DAG catchup_by_default est désormais False par défaut.
La configuration create_cron_data_intervals est désormais False par défaut. Cela signifie que CronTriggerTimetable sera utilisé par défaut au lieu de CronDataIntervalTimetable.
Liste des modifications pour Airflow 3.0.0.
Liste des modifications pour Airflow 3.1.0.

Différences entre les environnements Airflow 3 et Airflow 2

Voici les principales différences entre les environnements Managed Airflow avec Airflow 2 et ceux avec Airflow 3 :

Configuration des charges de travail dans les environnements Airflow 3 :
- La quantité de mémoire minimale pour tous les composants Airflow est de 2 Go.
- Les configurations des déclencheurs et des nœuds de calcul Airflow dans les préréglages d'environnement ont été modifiées par rapport aux environnements Airflow 2.
- Le nombre de processeurs par défaut pour les déclencheurs est de 1.
- La quantité de mémoire par défaut pour les déclencheurs est de 2 Go.
Le calcul automatique de l'option de configuration [celery]worker_concurrency est modifié pour s'adapter à la différente utilisation de la mémoire par les composants Airflow 3.
Dans Airflow 3, il n'est pas possible d'accéder directement à la base de données Airflow à partir du code de la tâche.
Airflow 3 utilise l'utilitaire de ligne de commande airflowctl pour exécuter les commandes Airflow CLI.
Les packages PyPI préinstallés sont différents dans les environnements Airflow 3. Pour obtenir la liste des packages PyPI préinstallés, consultez le journal des modifications des packages préinstallés.

Migrer vers Airflow 3 côte à côte

Le processus de migration côte à côte comprend les étapes suivantes :

Vérifiez la compatibilité avec Airflow 3.
Créez un environnement Airflow 3, transférez les remplacements de configuration et les variables d'environnement.
Installez les packages PyPI dans l'environnement Airflow 3.
Transférez les variables, les connexions et les pools vers Airflow 3.
Transférez d'autres données à partir du bucket de votre environnement Airflow 2.*.
Transférez les utilisateurs et les rôles.
Assurez-vous que vos DAG sont prêts pour Airflow 3.
Transférez les DAG vers l'environnement Airflow 3.
Surveillez votre environnement Airflow 3.

Étape 1 : Vérifier la compatibilité avec Airflow 3

Pour vérifier la compatibilité avec Airflow 3 :

Vérifiez que votre environnement utilise Airflow version 2.7 ou ultérieure. Nous vous recommandons de passer d'abord à la dernière version d'Airflow 2, puis de migrer vers Airflow 3.
Vérifiez que l'environnement est sain et qu'il fonctionne correctement depuis un certain temps.
Assurez-vous que vos DAG et votre configuration Airflow n'utilisent aucune fonctionnalité supprimée dans Airflow 3.
Consultez les instructions pour rendre vos DAG compatibles avec Airflow 3 afin de déterminer si des modifications seront nécessaires dans vos DAG lors du processus de migration.
Vérifiez la compatibilité de vos DAG Airflow à l'aide de l'outil ruff fourni par la version communautaire d'Airflow. Pour obtenir des instructions, consultez Vérifier la compatibilité de vos DAG Airflow dans la documentation Airflow.

Étape 2 : Créez un environnement Airflow 3, remplacez les remplacements de configuration et les variables d'environnement

Dans cette étape, vous allez créer un environnement Managed Airflow (3e génération) avec Airflow 3 et commencer à transférer les paramètres de configuration de votre environnement Airflow 2 :

Suivez la procédure de création d'un environnement Managed Airflow (3e génération) et procédez comme suit :

Lorsque vous sélectionnez une compilation Airflow, choisissez-en une avec Airflow 3.
Copiez tous les remplacements d'options de configuration Airflow compatibles depuis votre environnement Airflow 2.

Important : Certaines options de configuration utilisent un nom et une section différents dans Airflow 3. Cette page fournit une liste non exhaustive de ces options.
Copiez toutes les variables d'environnement à partir de votre environnement Airflow 2.
Créez un environnement avec Airflow 3.

Le tableau suivant liste quelques modifications apportées aux options de configuration Airflow. Cette liste n'est pas exhaustive. Pour en savoir plus sur les modifications apportées aux options de configuration d'Airflow, consultez la documentation de référence sur la configuration d'Airflow et les notes de version d'Airflow.

Option Airflow 2	Option Airflow 3
`[scheduler]min_file_process_interval`	`[dag_processor]min_file_process_interval`
`[webserver]rbac_user_registration_role`	`[api]rbac_user_registration_role`
`[core]dag_file_processor_timeout`	`[dag_processor]dag_file_processor_timeout`
`[scheduler]dag_dir_list_interval`	`[dag_processor]refresh_interval`
`[scheduler]max_threads`	`[dag_processor]parsing_processes`
`[scheduler]parsing_processes`	`[dag_processor]parsing_processes`
`[webserver]instance_name`	`[api]instance_name`
`[scheduler]scheduler_zombie_task_threshold`	`[scheduler]task_instance_heartbeat_timeout`
`[webserver]rbac`	Obsolète
`[api]auth_backend=airflow.api.auth.backend.deny_all`	Obsolète
`[api]auth_backends=airflow.api.auth.backend.deny_all`	Obsolète
`[api]composer_auth_user_registration_role`	Obsolète

Étape 3 : Installez les packages PyPI dans l'environnement Airflow 3

Une fois l'environnement Airflow 3 créé, installez-y les packages PyPI :

Copiez les exigences de package PyPI à partir de votre environnement Airflow 2.
Démarrez l'opération de mise à jour des packages PyPI et attendez que l'environnement soit mis à jour.

Étant donné que les environnements Airflow 3 utilisent un ensemble différent de packages préinstallés, vous pouvez rencontrer des conflits de packages PyPI lors de l'opération de mise à jour. Pour en savoir plus sur la résolution des conflits de packages PyPI, consultez Conflits avec les packages PyPI préinstallés.

Étape 4 : Exportez les variables, les connexions et les pools depuis Airflow 2

Si vous n'avez pas de variables ni de connexions, ignorez les commandes d'exportation et d'importation correspondantes.

Vous ne devez transférer des pools que si vous disposez de pools personnalisés autres que default_pool. Sinon, ignorez les commandes qui exportent et importent des pools.

Exportez les variables depuis votre environnement Airflow 2 :
```
gcloud composer environments run AIRFLOW_2_ENV \
    --location AIRFLOW_2_LOCATION \
    variables -- export /home/airflow/gcs/data/variables.json
```
Remplacez les éléments suivants :
- AIRFLOW_2_ENV : nom de votre environnement Airflow 2.
- AIRFLOW_2_LOCATION : région où se trouve l'environnement Airflow 2.
Exportez les connexions depuis votre environnement Airflow 2 :
```
gcloud composer environments run AIRFLOW_2_ENV \
    --location AIRFLOW_2_LOCATION \
    connections -- export /home/airflow/gcs/data/connections.json
```
Remplacez les éléments suivants :
- AIRFLOW_2_ENV : nom de votre environnement Airflow 2.
- AIRFLOW_2_LOCATION : région où se trouve l'environnement Airflow 2.
Exportez des pools à partir de votre environnement Airflow 2 :
```
gcloud composer environments run AIRFLOW_2_ENV \
    --location AIRFLOW_2_LOCATION \
    pools -- export /home/airflow/gcs/data/pools.json
```
Remplacez les éléments suivants :
- AIRFLOW_2_ENV : nom de votre environnement Airflow 2.
- AIRFLOW_2_LOCATION : région où se trouve l'environnement Airflow 2.
Obtenez le nom du bucket de votre environnement Airflow 2 :
```
gcloud composer environments describe AIRFLOW_2_ENV \
    --location AIRFLOW_2_LOCATION \
    --format="value(storageConfig.bucket)"
```
Remplacez les éléments suivants :
- AIRFLOW_2_ENV : nom de votre environnement Airflow 2.
- AIRFLOW_2_LOCATION : région où se trouve l'environnement Airflow 2.
Téléchargez les fichiers variables.json, connections.json et pools.json depuis le répertoire /data du bucket de votre environnement Airflow 2 vers un répertoire local :
```
gcloud storage cp gs://AIRFLOW_2_BUCKET/data/variables.json ./variables.json
gcloud storage cp gs://AIRFLOW_2_BUCKET/data/connections.json ./connections.json
gcloud storage cp gs://AIRFLOW_2_BUCKET/data/pools.json ./pools.json
```
Remplacez les éléments suivants :
- AIRFLOW_2_BUCKET : nom du bucket de votre environnement Airflow 2, obtenu à l'étape précédente.

Étape 5 : Importez des variables, des connexions et des pools dans Airflow 3

Si vous n'avez pas de variables ni de connexions, ignorez les commandes d'exportation et d'importation correspondantes.

Vous ne devez transférer des pools que si vous disposez de pools personnalisés autres que default_pool. Sinon, ignorez les commandes qui exportent et importent des pools.

Configurez airflowctl pour exécuter les commandes Airflow CLI pour l'environnement Airflow 3.

Importez des variables, des connexions et des pools dans l'environnement Airflow 3 à l'aide de airflowctl :

airflowctl variables import ./variables.json
airflowctl connections import ./connections.json
airflowctl pools import ./pools.json

Vérifiez que les variables, les connexions et les pools sont importés dans l'environnement Airflow 3 :
```
airflowctl variables list
airflowctl connections list
airflowctl pools list
```

Nettoyez les fichiers JSON :

gcloud storage rm gs://AIRFLOW_2_BUCKET/data/variables.json
gcloud storage rm gs://AIRFLOW_2_BUCKET/data/connections.json
gcloud storage rm gs://AIRFLOW_2_BUCKET/data/pools.json
rm ./variables.json
rm ./connections.json
rm ./pools.json

Remplacez les éléments suivants :

AIRFLOW_2_BUCKET : nom du bucket de votre environnement Airflow 2.

Étape 6 : Transférez d'autres données à partir du bucket de votre environnement Airflow 2

À cette étape, vous allez transférer les données restantes du bucket de votre environnement Airflow 2.

Obtenez le nom du bucket de votre environnement Airflow 3 :
```
gcloud composer environments describe AIRFLOW_3_ENV \
    --location AIRFLOW_3_LOCATION \
    --format="value(storageConfig.bucket)"
```
Remplacez les éléments suivants :
- AIRFLOW_3_ENV : nom de votre environnement Airflow 3.
- AIRFLOW_3_LOCATION : région où se trouve l'environnement Airflow 3.
Exportez les plug-ins du bucket de votre environnement Airflow 2 vers le répertoire /plugins du bucket de votre environnement Airflow 3 :
```
gcloud composer environments storage plugins export \
  --destination=AIRFLOW_3_BUCKET/plugins \
  --environment=AIRFLOW_2_ENV \
  --location=AIRFLOW_2_LOCATION
```
Remplacez les éléments suivants :
- AIRFLOW_3_BUCKET : nom du bucket de votre environnement Airflow 3, obtenu à l'étape précédente.
- AIRFLOW_2_ENV : nom de votre environnement Airflow 2.
- AIRFLOW_2_LOCATION : région où se trouve l'environnement Airflow 2.
Vérifiez que le répertoire /plugins a bien été importé :
```
gcloud composer environments storage plugins list \
  --environment=AIRFLOW_3_ENV \
  --location=AIRFLOW_3_LOCATION
```
Remplacez les éléments suivants :
- AIRFLOW_3_ENV : nom de votre environnement Airflow 3.
- AIRFLOW_3_LOCATION : région où se trouve l'environnement Airflow 3.
Exportez le répertoire /data de votre environnement Airflow 2 vers l'environnement Airflow 3 :
```
gcloud composer environments storage data export \
  --destination=AIRFLOW_3_BUCKET/data \
  --environment=AIRFLOW_2_ENV \
  --location=AIRFLOW_2_LOCATION
```
Remplacez les éléments suivants :
- AIRFLOW_3_BUCKET : nom du bucket de votre environnement Airflow 3, obtenu à l'étape précédente.
- AIRFLOW_2_ENV : nom de votre environnement Airflow 2.
- AIRFLOW_2_LOCATION : région où se trouve l'environnement Airflow 2.
Vérifiez que le dossier /data a bien été importé :
```
gcloud composer environments storage data list \
  --environment=AIRFLOW_3_ENV \
  --location=AIRFLOW_3_LOCATION
```
Remarque : si vous avez des plug-ins qui utilisent des vues Flask-AppBuilder (appbuilder_views), des éléments de menu Flask-AppBuilder (appbuilder_menu_items) ou des plans Flask (flask_blueprints), envisagez de les convertir en applications FastAPI. Si vous ne les convertissez pas, ils fonctionneront toujours dans Airflow 3, car le fournisseur FAB est préinstallé dans Managed Airflow et dispose d'une couche de rétrocompatibilité pour Airflow 3. Toutefois, nous vous recommandons toujours de convertir vos plug-ins en interface de plug-in Airflow 3 : vues externes (external_views), applications Fast API (fastapi_apps) et middlewares FastAPI (fastapi_root_middlewares).

Étape 7 : Transférer les utilisateurs et les rôles

Il n'est pas possible de migrer les utilisateurs et les rôles, car airflowctl ne prend pas encore en charge les commandes users et roles.

Étape 8 : Assurez-vous que vos DAG sont prêts pour Airflow 3

Ajustez vos DAG Airflow pour les rendre compatibles avec Airflow 3.
Examinez les tâches écrites sur mesure pour l'accès direct à la base de données Airflow :

Dans Airflow 3, les opérateurs ne peuvent pas accéder directement à la base de données de métadonnées Airflow à l'aide de sessions de base de données. Si vous avez des opérateurs personnalisés, examinez votre code pour vous assurer qu'il n'y a pas d'appels d'accès direct à la base de données.

Vous pouvez utiliser l'une des approches alternatives pour migrer depuis l'accès direct à la base de données Airflow dans les tâches :
- Accès à la base de données Airflow en exportant le contenu de la base de données Airflow vers une instance Cloud SQL.
- Utilisez le client Python Airflow. Le client Python fourni par la version communautaire d'Airflow comporte des API définies pour la majorité des tables, telles que DagRuns, TaskInstances, Variables, Connections et XComs. Le package apache-airflow-client est déjà préinstallé dans les versions Airflow 3 de Managed Airflow.
- Exécutez airflowctl via BashOperator à partir d'un DAG.
Si l'interrogation de la base de données Airflow exportée n'est pas une option pour votre cas d'utilisation et que le client Python Airflow et airflowctl ne fournissent pas la fonctionnalité requise, envisagez de demander de nouveaux points de terminaison d'API ou des fonctionnalités du SDK Task dans la version communautaire d'Airflow.

Remarque : La solution de contournement utilisant DbApiHook décrite dans la documentation Airflow ne peut pas être utilisée pour accéder à la base de données Airflow dans Managed Airflow, car les nœuds de calcul (tâches) Airflow ne peuvent pas communiquer avec la base de données Airflow.
Si vous avez des tâches KubernetesExecutor, ajustez leurs définitions d'opérateur en remplaçant queue="kubernetes" par executor="KubernetesExecutor".

Exemple de tâche KubernetesExecutor dans Airflow 3 :
```
PythonOperator(
task_id="airflow3_kubernetes_executor_task",
dag=dag,
python_callable=f,
executor="KubernetesExecutor",
)
```
Si vous utilisez la variable d'environnement AIRFLOW__WEBSERVER__BASE_URL dans le code des tâches, remplacez-la par l'option de configuration Airflow [api]base_url.

Exemple d'obtention de cette valeur dans Airflow 3 :
```
from airflow.configuration import conf

webserver_base_url = conf.get("api", "base_url")
```

Étape 9 : Transférez les DAG vers l'environnement Airflow 3

Les problèmes potentiels suivants peuvent se produire lorsque vous transférez des DAG entre les environnements :

Si un DAG est activé (non suspendu) dans les deux environnements, chaque environnement exécute sa propre copie du DAG, comme prévu. Cela peut entraîner des exécutions DAG simultanées pour les mêmes données et le même temps d'exécution.
En raison du rattrapage du DAG, Airflow planifie des exécutions DAG supplémentaires, à compter de la date de début spécifiée dans vos DAG. En effet, la nouvelle instance Airflow ne prend pas en compte l'historique des exécutions de DAG à partir de l'environnement Airflow 2. Cela peut entraîner un grand nombre d'exécutions DAG planifiées à compter de la date de début spécifiée.

Empêcher les exécutions DAG simultanées

Dans votre environnement Airflow 3, remplacez l'option de configuration Airflow dags_are_paused_at_creation. Une fois la modification effectuée, tous les nouveaux DAG sont mis en pause par défaut.

Section	Clé	Valeur
`core`	`dags_are_paused_at_creation`	`True`

Empêcher les exécutions supplémentaires ou manquantes des DAG

Spécifiez une nouvelle date de début statique dans les DAG que vous transférez vers votre environnement Airflow 3.

Pour éviter les écarts et les chevauchements de dates logiques, la première exécution du DAG doit se produire dans l'environnement Airflow 3 à la prochaine occurrence de l'intervalle de planification. Pour ce faire, définissez la nouvelle date de début dans votre DAG sur une date antérieure à la dernière exécution dans l'environnement Airflow 2.

Par exemple, si votre DAG s'exécute à 15h00, 17h00 et 21h00 chaque jour dans l'environnement Airflow 2, que le dernier DAG a été exécuté à 15h00 et que vous prévoyez de transférer le DAG à 15h15, la date de début de l'environnement Airflow 3 peut être aujourd'hui à 14h45. Une fois le DAG activé dans l'environnement Airflow 3, Airflow planifie une exécution du DAG à 17h00.

Autre exemple : si votre DAG s'exécute chaque jour à 00h00 dans l'environnement Airflow 2, que le dernier DAG a été exécuté le 26 mars 2026 à 00h00 et que vous envisagez de transférer le DAG à 13h00 le 26 mars 2026, la date de début de l'environnement Airflow 3 peut être 23h45 le 25 mars 2026. Une fois le DAG activé dans l'environnement Airflow 3, Airflow planifie une exécution du DAG pour 00h00 le 27 mars 2026.

Transférez vos DAG un par un vers l'environnement Airflow 3

Pour chaque DAG, suivez la procédure suivante pour le transférer :

Assurez-vous que la nouvelle date de début dans le DAG est définie comme décrit dans la section précédente.
Importez le DAG mis à jour dans l'environnement Airflow 3. Ce DAG est mis en pause dans l'environnement Airflow 3 en raison du remplacement de la configuration, donc aucune exécution du DAG n'est encore planifiée.
Dans l'interface Web Airflow, accédez aux DAG et recherchez les erreurs de syntaxe des DAG signalés.
Au moment où vous prévoyez de transférer le DAG :
1. Suspendez le DAG dans votre environnement Airflow 2.
2. Réactivez le DAG dans votre environnement Airflow 3.
3. Vérifiez que la nouvelle exécution du DAG est planifiée au bon moment.
4. Attendez que l'exécution du DAG se produise dans l'environnement Airflow 3 et vérifiez si l'exécution réussit.
Selon que l'exécution du DAG réussit ou non, procédez comme suit :
- Si l'exécution du DAG réussit, vous pouvez continuer et utiliser le DAG à partir de votre environnement Airflow 3. Enfin, envisagez de supprimer la version Airflow 2 du DAG.
- Si l'exécution du DAG échoue, essayez de résoudre les problèmes liés au DAG jusqu'à ce qu'il aboutisse dans Airflow 3.
  
  Si nécessaire, vous pouvez toujours revenir à la version Airflow 2 du DAG :
  1. Suspendez le DAG dans votre environnement Airflow 3.
  2. Réactivez le DAG dans votre environnement Airflow 3. Cela planifie une nouvelle exécution du DAG pour la même date et la même heure que l'exécution du DAG qui a échoué.
  3. Lorsque vous êtes prêt à continuer avec la version Airflow 3 du DAG, ajustez la date de début, importez la nouvelle version du DAG dans votre environnement Airflow 3, puis répétez la procédure.

Étape 10 : Surveiller votre environnement Airflow 3

Une fois que vous avez transféré tous les DAG et la configuration vers l'environnement Airflow 3, surveillez-les pour détecter les problèmes potentiels, les exécutions de DAG ayant échoué et l'état général de l'environnement. Si l'environnement Airflow 3 ne présente aucun problème pendant une période suffisante, vous pouvez supprimer l'environnement Airflow 2.