Per promuovere con maggiore forza il successo e la crescente preferenza dei clienti per le soluzioni OSS, Cloud Composer si sta evolvendo in Managed Service per Apache Airflow. Questo cambio di nome migliora la comprensione del nostro portfolio da parte dei clienti e rafforza il nostro impegno a essere l'ecosistema cloud più aperto.

Migrazione degli ambienti ad Airflow 3 (affiancata)

Managed Airflow (Gen 3) | Managed Airflow (Gen 2) | Managed Airflow (Legacy Gen 1)

Questa pagina spiega come trasferire DAG, dati e configurazione dal tuo ambiente Managed Airflow (Gen 3) esistente con Airflow 2 a un ambiente Managed Airflow (Gen 3) con Airflow 3.

Altre guide alla migrazione

Da	A	Metodo	Guida
Managed Airflow (Gen 3), Airflow 2	Managed Airflow (Gen 3), Airflow 3	Trasferimento manuale affiancato	Questa guida
Managed Airflow (Gen 2)	Managed Airflow (Gen 3)	Affiancata, utilizzando lo script di migrazione	Guida alla migrazione degli script
Managed Airflow (Gen 2)	Managed Airflow (Gen 3)	Affiancate, utilizzando gli snapshot	Guida alla migrazione degli snapshot
Managed Airflow (legacy Gen 1), Airflow 2	Managed Airflow (Gen 3)	Affiancate, utilizzando gli snapshot	Guida alla migrazione degli snapshot
Managed Airflow (legacy Gen 1), Airflow 2	Managed Airflow (Gen 2)	Affiancate, utilizzando gli snapshot	Guida alla migrazione degli snapshot
Managed Airflow (legacy Gen 1), Airflow 2	Managed Airflow (Gen 2)	Trasferimento manuale affiancato	Guida alla migrazione manuale
Managed Airflow (Legacy Gen 1), Airflow 1	Managed Airflow (Gen 2), Airflow 2	Affiancate, utilizzando gli snapshot	Guida alla migrazione degli snapshot
Managed Airflow (Legacy Gen 1), Airflow 1	Managed Airflow (Gen 2), Airflow 2	Trasferimento manuale affiancato	Guida alla migrazione manuale
Managed Airflow (Legacy Gen 1), Airflow 1	Managed Airflow (legacy Gen 1), Airflow 2	Trasferimento manuale affiancato	Guida alla migrazione manuale

Modifiche introdotte in Airflow 3

Prima di iniziare a utilizzare gli ambienti Managed Airflow con Airflow 3, valuta le modifiche che Airflow 3 introduce negli ambienti Managed Airflow (Gen 3).

Per una panoramica delle modifiche introdotte nella versione community di Airflow 3, consulta Apache Airflow 3 è disponibile a livello generale.

Controllo delle versioni del DAG

In Airflow 3, un DAG verrà eseguito fino al completamento in base alla versione all'inizio, anche se è stata caricata una nuova versione durante l'esecuzione del DAG.
- Tutte le esecuzioni di DAG nell'interfaccia utente di Airflow sono ora associate alla versione DAG corrispondente (la versione al momento dell'esecuzione). Sono inclusi la struttura del task e il codice DAG.

Miglioramenti dei backfill

Airflow 3 introduce una revisione importante della gestione dei backfill (ri-esecuzione delle pipeline per i dati storici). I backfill stanno passando da un processo manuale a una funzionalità completamente osservabile integrata nel motore Airflow principale:

I backfill ora vengono gestiti direttamente nello scheduler Airflow, anziché essere trattati come processi manuali separati. Ciò porta a una migliore scalabilità e a un controllo più preciso.
Ora puoi attivare, interrompere e monitorare l'avanzamento del backfill direttamente tramite l'interfaccia utente o le chiamate API di Airflow, oltre che tramite la CLI di Airflow.
Lo scheduler Airflow offre una migliore visibilità sullo stato e sull'integrità delle esecuzioni di backfill storiche.
Sebbene siano stati richiesti a gran voce dalla community di machine learning (per il riaddestramento dei modelli sui dati precedenti), i miglioramenti del backfill si applicano a tutti i flussi di lavoro ETL/ELT.

Maggiore sicurezza e affidabilità

In Airflow 3, le attività comunicano solo con il server API centrale tramite l'SDK Task (in Airflow 2 le attività potevano avere accesso diretto al database). Il server API raggruppa queste connessioni in modo efficiente. Il tuo database è protetto dai picchi di connessione, il che rende l'intero ambiente più stabile in condizioni di carico elevato.
Utilizzando una nuova interfaccia di esecuzione delle attività, Airflow 3 supporta un migliore isolamento tra le attività, impedendo a un'attività di interferire potenzialmente con i dati di un'altra attività o di accedervi.
L'interfaccia a riga di comando di Airflow 3 non consente più l'accesso diretto al database. Una nuova interfaccia a riga di comando airflowctl è un pacchetto separato progettato specificamente per l'accesso remoto tramite l'API. Anziché accedere direttamente al database, interagisce con Airflow tramite API, il che è più sicuro.

Pianificazione basata sugli eventi e asset di dati

I set di dati si sono evoluti in asset di dati. Gli asset di dati consentono ad Airflow di monitorare e reagire meglio ai dati creati o aggiornati da sistemi esterni ad Airflow.
In Airflow 3 è stato introdotto un nuovo concetto chiamato Watchers. Si tratta di componenti che monitorano le modifiche a un asset di dati, consentendo ad Airflow di attivare i workflow nel momento in cui arrivano i dati. Anziché eseguire il polling (controllare ogni minuto se esiste un file), un DAG può ora essere attivato immediatamente nel momento in cui un messaggio raggiunge una coda di messaggi.
Airflow 3 introduce una nuova sintassi incentrata sugli asset che utilizza i decoratori Python, rendendo il codice più pulito e intuitivo per gli sviluppatori.

UI di Airflow modernizzata

La UI di Airflow è stata riscritta da zero utilizzando React (frontend) e FastAPI (backend).
La nuova UI di Airflow esegue le operazioni tramite un'API REST standardizzata e un'API specializzata per le operazioni della UI.
Sostituendo l'implementazione di Flask con FastAPI, la UI di Airflow è molto più reattiva.
Le visualizzazioni Griglia e Grafico sono state unificate per un workflow più fluido, in modo da passare più facilmente dalle strutture DAG di alto livello ai log delle attività specifiche.

Modifiche che provocano errori in Airflow 3

Airflow 3 introduce alcune modifiche importanti, alcune delle quali sono incompatibili con le versioni precedenti:

Non è garantito che i DAG esistenti di Airflow 2 funzionino con Airflow 3. Devono essere testati e possibilmente modificati cambiando le importazioni, i parametri DAG e altri dettagli di implementazione.
Alcune opzioni di configurazione di Airflow 2 vengono rinominate o rimosse in Airflow 3. Per saperne di più sui parametri, consulta il riferimento alla configurazione di Airflow.
Nessun accesso diretto al database Airflow dal codice dell'attività:
- Il codice dell'attività non può più importare e utilizzare direttamente sessioni o modelli del database Airflow.
- Non è possibile utilizzare PostgresHook e PostgresOperator con la connessione airflow_db.
Alcuni pacchetti PyPI personalizzati potrebbero non essere compatibili con la nuova versione di Airflow e le relative dipendenze.
API REST (/api/v1) sostituita da /api/v2.
I SubDAG vengono sostituiti da TaskGroup, Asset e pianificazione basata sui dati.
I contratti di servizio sono deprecati e rimossi. Vengono sostituiti dagli avvisi sulle scadenze.
L'argomento subdir nei comandi CLI è stato rimosso.
Alcune variabili di contesto di Airflow sono state rimosse. Per saperne di più, consulta la sezione Modifiche sostanziali nella documentazione di Airflow.
Il parametro DAG catchup_by_default ora è False per impostazione predefinita.
La configurazione create_cron_data_intervals ora è False per impostazione predefinita. Ciò significa che per impostazione predefinita verrà utilizzato CronTriggerTimetable anziché CronDataIntervalTimetable.
Elenco delle modifiche per Airflow 3.0.0.
Elenco delle modifiche per Airflow 3.1.0.

Differenze tra gli ambienti con Airflow 3 e Airflow 2

Le principali differenze tra gli ambienti Managed Airflow con Airflow 2 e quelli con Airflow 3 sono:

Configurazione dei workload negli ambienti Airflow 3:
- La quantità minima di memoria per tutti i componenti di Airflow è 2 GB.
- Le configurazioni per i trigger e i worker di Airflow nei preset dell'ambiente vengono modificate rispetto agli ambienti Airflow 2.
- Il numero predefinito di CPU per i triggerer è 1.
- Il numero predefinito di memoria per i trigger è 2 GB.
Il calcolo automatico dell'opzione di configurazione [celery]worker_concurrency viene modificato per adattarsi alla memoria utilizzata diversa dai componenti di Airflow 3.
In Airflow 3, non è possibile accedere direttamente al database Airflow dal codice dell'attività.
Airflow 3 utilizza l'utilità a riga di comando airflowctl per eseguire i comandi dell'interfaccia a riga di comando di Airflow.
I pacchetti PyPI preinstallati sono diversi negli ambienti Airflow 3. Per un elenco dei pacchetti PyPI preinstallati, consulta il log delle modifiche dei pacchetti preinstallati.

Esegui la migrazione ad Airflow 3 affiancato

La procedura di migrazione affiancata prevede i seguenti passaggi:

Verifica la compatibilità con Airflow 3.
Crea un ambiente Airflow 3, trasferisci gli override della configurazione e le variabili di ambiente.
Installa i pacchetti PyPI nell'ambiente Airflow 3.
Trasferisci variabili, connessioni e pool ad Airflow 3.
Trasferisci altri dati dal bucket dell'ambiente Airflow 2.*.
Trasferisci utenti e ruoli.
Assicurati che i tuoi DAG siano pronti per Airflow 3.
Trasferisci i DAG all'ambiente Airflow 3.
Monitora l'ambiente Airflow 3.

Passaggio 1: controlla la compatibilità con Airflow 3

Per verificare la compatibilità con Airflow 3:

Verifica che il tuo ambiente utilizzi Airflow versione 2.7 o successive. Ti consigliamo di eseguire l'upgrade prima all'ultima versione di Airflow 2 e solo dopo eseguire la migrazione ad Airflow 3.
Verifica che l'ambiente sia integro e che funzioni senza problemi da un po' di tempo.
Assicurati che i tuoi DAG e la configurazione di Airflow non utilizzino funzionalità o funzioni rimosse in Airflow 3.
Leggi le istruzioni per modificare i DAG in modo che siano compatibili con Airflow 3 per verificare se saranno necessarie modifiche ai DAG durante la migrazione.
Controlla la compatibilità dei tuoi DAG Airflow utilizzando lo strumento ruff fornito dalla versione della community di Airflow. Per le istruzioni, consulta la sezione Controllare la compatibilità dei DAG di Airflow nella documentazione di Airflow.

Passaggio 2: crea un ambiente Airflow 3, trasferisci gli override della configurazione e le variabili di ambiente

In questo passaggio, crei un nuovo ambiente Managed Airflow (Gen 3) con Airflow 3 e inizi a trasferire i parametri di configurazione dal tuo ambiente Airflow 2:

Segui i passaggi per creare un ambiente Managed Airflow (Gen 3) e fai quanto segue:

Quando selezioni una build Airflow, scegli una build con Airflow 3.
Copia tutti gli override delle opzioni di configurazione di Airflow compatibili dal tuo ambiente Airflow 2.

Importante: alcune opzioni di configurazione utilizzano un nome e una sezione diversi in Airflow 3. Questa pagina fornisce un elenco non esaustivo di queste opzioni.
Copia tutte le variabili di ambiente dall'ambiente Airflow 2.
Procedi alla creazione di un ambiente con Airflow 3.

La tabella seguente elenca alcune modifiche alle opzioni di configurazione di Airflow. L'elenco non è esaustivo. Per ulteriori informazioni sulle modifiche alle opzioni di configurazione di Airflow, consulta Riferimento alla configurazione di Airflow e Note di rilascio di Airflow nella documentazione di Airflow.

Opzione Airflow 2	Opzione 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`	Deprecato
`[api]auth_backend=airflow.api.auth.backend.deny_all`	Deprecato
`[api]auth_backends=airflow.api.auth.backend.deny_all`	Deprecato
`[api]composer_auth_user_registration_role`	Deprecato

Passaggio 3: installa i pacchetti PyPI nell'ambiente Airflow 3

Dopo aver creato l'ambiente Airflow 3, installa i pacchetti PyPI:

Copia i requisiti dei pacchetti PyPI dal tuo ambiente Airflow 2.
Avvia l'operazione di aggiornamento dei pacchetti PyPI e attendi che l'ambiente venga aggiornato.

Poiché gli ambienti Airflow 3 utilizzano un insieme diverso di pacchetti preinstallati, potresti riscontrare conflitti tra i pacchetti PyPI durante l'operazione di aggiornamento. Per maggiori informazioni sulla risoluzione dei problemi relativi ai conflitti tra pacchetti PyPI, consulta Conflitti con i pacchetti PyPI preinstallati.

Passaggio 4: esporta variabili, connessioni e pool da Airflow 2

Se non hai variabili o connessioni, salta i rispettivi comandi di esportazione e importazione.

Devi trasferire i pool solo se hai pool personalizzati diversi da default_pool. In caso contrario, ignora i comandi che esportano e importano i pool.

Esporta le variabili dall'ambiente Airflow 2:
```
gcloud composer environments run AIRFLOW_2_ENV \
    --location AIRFLOW_2_LOCATION \
    variables -- export /home/airflow/gcs/data/variables.json
```
Sostituisci quanto segue:
- AIRFLOW_2_ENV: il nome del tuo ambiente Airflow 2.
- AIRFLOW_2_LOCATION: la regione in cui si trova l'ambiente Airflow 2.
Esporta le connessioni dal tuo ambiente Airflow 2:
```
gcloud composer environments run AIRFLOW_2_ENV \
    --location AIRFLOW_2_LOCATION \
    connections -- export /home/airflow/gcs/data/connections.json
```
Sostituisci quanto segue:
- AIRFLOW_2_ENV: il nome del tuo ambiente Airflow 2.
- AIRFLOW_2_LOCATION: la regione in cui si trova l'ambiente Airflow 2.
Esporta i pool dal tuo ambiente Airflow 2:
```
gcloud composer environments run AIRFLOW_2_ENV \
    --location AIRFLOW_2_LOCATION \
    pools -- export /home/airflow/gcs/data/pools.json
```
Sostituisci quanto segue:
- AIRFLOW_2_ENV: il nome del tuo ambiente Airflow 2.
- AIRFLOW_2_LOCATION: la regione in cui si trova l'ambiente Airflow 2.
Ottieni il nome del bucket dell'ambiente Airflow 2:
```
gcloud composer environments describe AIRFLOW_2_ENV \
    --location AIRFLOW_2_LOCATION \
    --format="value(storageConfig.bucket)"
```
Sostituisci quanto segue:
- AIRFLOW_2_ENV: il nome del tuo ambiente Airflow 2.
- AIRFLOW_2_LOCATION: la regione in cui si trova l'ambiente Airflow 2.
Scarica i file variables.json, connections.json e pools.json dalla directory /data del bucket dell'ambiente Airflow 2 in una directory locale:
```
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
```
Sostituisci quanto segue:
- AIRFLOW_2_BUCKET: il nome del bucket dell'ambiente Airflow 2, ottenuto nel passaggio precedente.

Passaggio 5: importa variabili, connessioni e pool in Airflow 3

Se non hai variabili o connessioni, salta i rispettivi comandi di esportazione e importazione.

Devi trasferire i pool solo se hai pool personalizzati diversi da default_pool. In caso contrario, ignora i comandi che esportano e importano i pool.

Configura airflowctl per eseguire i comandi della CLI di Airflow per l'ambiente Airflow 3.

Importa variabili, connessioni e pool nell'ambiente Airflow 3 utilizzando airflowctl:

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

Verifica che le variabili, le connessioni e i pool siano importati nell'ambiente Airflow 3:
```
airflowctl variables list
airflowctl connections list
airflowctl pools list
```

Libera spazio nei file 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

Sostituisci quanto segue:

AIRFLOW_2_BUCKET: il nome del bucket dell'ambiente Airflow 2.

Passaggio 6: trasferisci altri dati dal bucket dell'ambiente Airflow 2

In questo passaggio, trasferisci i dati rimanenti dal bucket dell'ambiente Airflow 2.

Ottieni il nome del bucket dell'ambiente Airflow 3:
```
gcloud composer environments describe AIRFLOW_3_ENV \
    --location AIRFLOW_3_LOCATION \
    --format="value(storageConfig.bucket)"
```
Sostituisci quanto segue:
- AIRFLOW_3_ENV: il nome del tuo ambiente Airflow 3.
- AIRFLOW_3_LOCATION: la regione in cui si trova l'ambiente Airflow 3.
Esporta i plug-in dal bucket dell'ambiente Airflow 2 alla directory /plugins nel bucket dell'ambiente Airflow 3:
```
gcloud composer environments storage plugins export \
  --destination=AIRFLOW_3_BUCKET/plugins \
  --environment=AIRFLOW_2_ENV \
  --location=AIRFLOW_2_LOCATION
```
Sostituisci quanto segue:
- AIRFLOW_3_BUCKET: il nome del bucket dell'ambiente Airflow 3, ottenuto nel passaggio precedente.
- AIRFLOW_2_ENV: il nome del tuo ambiente Airflow 2.
- AIRFLOW_2_LOCATION: la regione in cui si trova l'ambiente Airflow 2.
Verifica che la directory /plugins sia stata importata correttamente:
```
gcloud composer environments storage plugins list \
  --environment=AIRFLOW_3_ENV \
  --location=AIRFLOW_3_LOCATION
```
Sostituisci quanto segue:
- AIRFLOW_3_ENV: il nome del tuo ambiente Airflow 3.
- AIRFLOW_3_LOCATION: la regione in cui si trova l'ambiente Airflow 3.
Esporta la directory /data dall'ambiente Airflow 2 all'ambiente Airflow 3:
```
gcloud composer environments storage data export \
  --destination=AIRFLOW_3_BUCKET/data \
  --environment=AIRFLOW_2_ENV \
  --location=AIRFLOW_2_LOCATION
```
Sostituisci quanto segue:
- AIRFLOW_3_BUCKET: il nome del bucket dell'ambiente Airflow 3, ottenuto nel passaggio precedente.
- AIRFLOW_2_ENV: il nome del tuo ambiente Airflow 2.
- AIRFLOW_2_LOCATION: la regione in cui si trova l'ambiente Airflow 2.
Verifica che la cartella /data sia stata importata correttamente:
```
gcloud composer environments storage data list \
  --environment=AIRFLOW_3_ENV \
  --location=AIRFLOW_3_LOCATION
```
Nota: se hai plug-in che utilizzano viste Flask-AppBuilder (appbuilder_views), voci di menu Flask-AppBuilder (appbuilder_menu_items) o blueprint Flask (flask_blueprints), valuta la possibilità di convertirli in app FastAPI. Se non li converti, continueranno a funzionare in Airflow 3 perché il provider FAB è preinstallato in Managed Airflow e dispone di un livello di compatibilità con le versioni precedenti per Airflow 3. Tuttavia, ti consigliamo comunque di convertire i plug-in nell'interfaccia Airflow 3 Plugin: viste esterne (external_views), app Fast API (fastapi_apps) e middleware FastAPI (fastapi_root_middlewares).

Passaggio 7: trasferisci utenti e ruoli

Non è possibile eseguire la migrazione di utenti e ruoli perché airflowctl non supporta ancora i comandi users e roles.

Passaggio 8: assicurati che i DAG siano pronti per Airflow 3

Modifica i DAG Airflow per renderli compatibili con Airflow 3.
Rivedi le attività scritte personalizzate per l'accesso diretto al database Airflow:

In Airflow 3, gli operatori non possono accedere direttamente al database dei metadati Airflow utilizzando le sessioni del database. Se hai operatori personalizzati, rivedi il codice per assicurarti che non ci siano chiamate di accesso diretto al database.

Puoi utilizzare uno degli approcci alternativi per eseguire la migrazione dall'accesso diretto al database Airflow nelle attività:
- Accesso al database Airflow tramite l'esportazione dei contenuti del database Airflow in un'istanza Cloud SQL.
- Utilizza il client Python di Airflow. Il client Python fornito dalla versione community di Airflow dispone di API definite per la maggior parte delle tabelle, ad esempio DagRuns, TaskInstances, Variables, Connections, XComs. Il pacchetto apache-airflow-client è già preinstallato nelle build Airflow 3 di Managed Airflow.
- Esegui airflowctl fino a BashOperator da un DAG.
Se l'interrogazione del database Airflow esportato non è un'opzione per il tuo caso d'uso e sia il client Python di Airflow sia airflowctl non forniscono la funzionalità richiesta, valuta la possibilità di richiedere nuovi endpoint API o funzionalità dell'SDK Task nella versione community di Airflow.

Nota: la soluzione alternativa di utilizzare DbApiHook descritta nella documentazione di Airflow non può essere utilizzata per accedere al database Airflow in Managed Airflow perché i worker (attività) di Airflow non possono comunicare con il database Airflow.
Se hai attività KubernetesExecutor, modifica le definizioni degli operatori sostituendo queue="kubernetes" con executor="KubernetesExecutor".

Esempio di attività KubernetesExecutor in Airflow 3:
```
PythonOperator(
task_id="airflow3_kubernetes_executor_task",
dag=dag,
python_callable=f,
executor="KubernetesExecutor",
)
```
Se utilizzi la variabile di ambiente AIRFLOW__WEBSERVER__BASE_URL nel codice delle attività, sostituiscila con l'opzione di configurazione [api]base_url di Airflow.

Esempio di ottenimento di questo valore in Airflow 3:
```
from airflow.configuration import conf

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

Passaggio 9: trasferisci i DAG all'ambiente Airflow 3

Quando trasferisci i DAG tra ambienti, potrebbero verificarsi i seguenti problemi potenziali:

Se un DAG è abilitato (non in pausa) in entrambi gli ambienti, ogni ambiente esegue la propria copia del DAG, come pianificato. Ciò potrebbe comportare esecuzioni simultanee di DAG per gli stessi dati e lo stesso tempo di esecuzione.
A causa del recupero dei DAG, Airflow pianifica esecuzioni aggiuntive dei DAG, a partire dalla data di inizio specificata nei DAG. Ciò accade perché la nuova istanza di Airflow non tiene conto della cronologia delle esecuzioni DAG dell'ambiente Airflow 2. Ciò potrebbe comportare un numero elevato di esecuzioni DAG pianificate a partire dalla data di inizio specificata.

Impedire l'esecuzione simultanea di DAG

Nel tuo ambiente Airflow 3, esegui l'override dell'opzione di configurazione di Airflow dags_are_paused_at_creation. Dopo aver apportato questa modifica, tutti i nuovi DAG vengono sospesi per impostazione predefinita.

Sezione	Chiave	Valore
`core`	`dags_are_paused_at_creation`	`True`

Evitare esecuzioni di DAG aggiuntive o mancanti

Specifica una nuova data di inizio statica nei DAG che trasferisci al tuo ambiente Airflow 3.

Per evitare lacune e sovrapposizioni nelle date logiche, la prima esecuzione del DAG deve avvenire nell'ambiente Airflow 3 alla successiva occorrenza dell'intervallo di pianificazione. A questo scopo, imposta la nuova data di inizio nel DAG in modo che sia precedente alla data dell'ultima esecuzione nell'ambiente Airflow 2.

Ad esempio, se il tuo DAG viene eseguito alle 15:00, alle 17:00 e alle 21:00 ogni giorno nell'ambiente Airflow 2, l'ultima esecuzione del DAG è avvenuta alle 15:00 e prevedi di trasferire il DAG alle 15:15, la data di inizio per l'ambiente Airflow 3 può essere oggi alle 14:45. Dopo aver abilitato il DAG nell'ambiente Airflow 3, Airflow pianifica un'esecuzione del DAG per le ore 17:00.

Come altro esempio, se il tuo DAG viene eseguito alle 00:00 ogni giorno nell'ambiente Airflow 2, l'ultima esecuzione del DAG è avvenuta alle 00:00 del 26 marzo 2026 e prevedi di trasferire il DAG alle 13:00 del 26 marzo 2026, la data di inizio per l'ambiente Airflow 3 può essere le 23:45 del 25 marzo 2026. Dopo aver abilitato il DAG nell'ambiente Airflow 3, Airflow pianifica un'esecuzione del DAG per le ore 00:00 del 27 marzo 2026.

Trasferisci i DAG uno alla volta all'ambiente Airflow 3

Per ogni DAG, segui questa procedura per trasferirlo:

Assicurati che la nuova data di inizio nel DAG sia impostata come descritto nella sezione precedente.
Carica il DAG aggiornato nell'ambiente Airflow 3. Questo DAG è in pausa nell'ambiente Airflow 3 a causa dell'override della configurazione, quindi non sono ancora state pianificate esecuzioni del DAG.
Nell'interfaccia web di Airflow, vai a DAG e verifica la presenza di errori di sintassi del DAG segnalati.
Al momento del trasferimento del DAG:
1. Metti in pausa il DAG nell'ambiente Airflow 2.
2. Riattiva il DAG nell'ambiente Airflow 3.
3. Controlla che la nuova esecuzione del DAG sia pianificata all'ora corretta.
4. Attendi l'esecuzione del DAG nell'ambiente Airflow 3 e verifica se l'esecuzione è andata a buon fine.
A seconda che l'esecuzione DAG vada a buon fine:
- Se l'esecuzione del DAG va a buon fine, puoi procedere e utilizzare il DAG dal tuo ambiente Airflow 3. Infine, valuta la possibilità di eliminare la versione Airflow 2 del DAG.
- Se l'esecuzione del DAG non è riuscita, prova a risolvere i problemi del DAG finché non viene eseguito correttamente in Airflow 3.
  
  Se necessario, puoi sempre eseguire il fallback alla versione Airflow 2 del DAG:
  1. Metti in pausa il DAG nell'ambiente Airflow 3.
  2. Riattiva il DAG nell'ambiente Airflow 3. In questo modo viene pianificata una nuova esecuzione del DAG per la stessa data e ora dell'esecuzione del DAG non riuscita.
  3. Quando è tutto pronto per continuare con la versione 3 di Airflow del DAG, modifica la data di inizio, carica la nuova versione del DAG nell'ambiente Airflow 3 e ripeti la procedura.

Passaggio 10: monitora l'ambiente Airflow 3

Dopo aver trasferito tutti i DAG e la configurazione all'ambiente Airflow 3, monitoralo per rilevare potenziali problemi, esecuzioni di DAG non riuscite e l'integrità generale dell'ambiente. Se l'ambiente Airflow 3 funziona senza problemi per un periodo di tempo sufficiente, puoi rimuovere l'ambiente Airflow 2.