Esegui un ambiente Airflow locale con lo strumento CLI Composer Local Development

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

Questa sezione descrive come creare, configurare ed eseguire un ambiente Airflow locale utilizzando lo strumento Composer Local Development CLI.

Se invece vuoi eseguire un ambiente Managed Airflow per scopi di sviluppo, valuta la possibilità di creare un ambiente in modalità di sviluppo, che puoi ibernare quando non lo utilizzi.

Informazioni sullo strumento CLI di sviluppo locale di Composer

Lo strumento CLI Composer Local Development semplifica lo sviluppo di DAG Apache Airflow per Managed Airflow eseguendo un ambiente Airflow in locale. Questo ambiente Airflow locale utilizza un'immagine di build di Airflow utilizzata da una versione di Managed Airflow specifica.

Puoi creare un ambiente Airflow locale basato su un ambiente Managed Airflow esistente. In questo caso, l'ambiente Airflow locale prende l'elenco dei pacchetti PyPI installati e i nomi variabile di ambiente dal tuo ambiente Managed Airflow.

Puoi utilizzare questo ambiente Airflow locale per scopi di test e sviluppo, ad esempio per testare il nuovo codice DAG, i pacchetti PyPI o le opzioni di configurazione di Airflow.

Prima di iniziare

  • Lo strumento CLI per lo sviluppo locale di Composer supporta le build di Airflow 3 nel seguente modo:

    • Airflow 3.3.1 e versioni successive sono supportate a partire da composer-3-airflow-3.3.1-build.0.
    • Airflow 3.2.2 è supportato a partire da composer-3-airflow-3.2.2-build.3.
    • Airflow 3.1.8 non è supportato.
    • Le build precedenti di Airflow 3 sono supportate a partire da composer-3-airflow-3.1.0-build.8.

  • Lo strumento CLI per lo sviluppo locale di Composer crea ambienti Airflow locali in una directory in cui esegui il comando composer-dev create. Per accedere in un secondo momento al tuo ambiente Airflow locale, esegui i comandi dello strumento nel percorso in cui hai creato inizialmente l'ambiente locale. Tutti i dati per l'ambiente locale vengono archiviati in una sottodirectory nel percorso in cui hai creato l'ambiente locale: ./composer/<local_environment_name>.

  • Il computer deve disporre di spazio su disco sufficiente per archiviare le immagini di build di Airflow. Lo strumento CLI di Composer Local Development archivia un file immagine per ogni build di Airflow. Ad esempio, se hai due ambienti Airflow locali con build Airflow diverse, lo strumento CLI Composer Local Development archivia due immagini di build Airflow.

  • Lo strumento dell'interfaccia a riga di comando per lo sviluppo locale di Composer utilizza un output colorato. Puoi disattivare l'output colorato con la variabile NO_COLOR=1: NO_COLOR=1 composer-dev <other commands>.

  • Se hai un solo ambiente locale, puoi omettere il nome dell'ambiente locale da tutti i comandi composer-dev, ad eccezione di run-airflow-cmd.

  • Installa le dipendenze dello strumento CLI di sviluppo locale di Composer:

  • Docker (Linux/macOS/Windows) o Podman (Linux o Windows) devono essere installati e in esecuzione sul computer.

    Per verificare che Docker o Podman siano in esecuzione, esegui un comando dell'interfaccia a riga di comando Docker o Podman, ad esempio docker ps o podman ps. Tutte le istruzioni si applicano sia a Docker che a Podman, se non diversamente specificato, e tutti i comandi Docker possono essere sostituiti da comandi Podman equivalenti.

Configura le credenziali

Se non l'hai ancora fatto, ottieni nuove credenziali utente da utilizzare per Credenziali predefinite dell'applicazione:

gcloud auth application-default login

Accedi a gcloud CLI utilizzando il tuo Account Google:

gcloud auth login

Tutte le chiamate API effettuate dallo strumento CLI di Composer Local Development e dai DAG vengono eseguite dall'account che utilizzi in gcloud CLI. Ad esempio, se un DAG nel tuo ambiente Airflow locale legge i contenuti di un bucket Cloud Storage, questo account deve disporre delle autorizzazioni per accedere al bucket. Questo è diverso dagli ambienti Managed Airflow, in cui le chiamate vengono effettuate dal account di servizio di un ambiente.

Installa lo strumento CLI di sviluppo locale di Composer

Clona il repository della CLI Composer Local Development:

git clone https://github.com/GoogleCloudPlatform/composer-local-dev.git

Nella directory di primo livello del repository clonato, esegui:

pip install .

A seconda della configurazione di pip, il percorso in cui è installato lo strumento potrebbe non essere nella variabile PATH. In questo caso, pip visualizza un messaggio di avviso. Puoi utilizzare le informazioni contenute in questo messaggio di avviso per aggiungere questa directory alla variabile PATH nel tuo sistema operativo.

(Podman) Configura Podman

Se utilizzi Podman, segui questi passaggi per configurarlo:

Linux

  1. Attiva il socket del servizio utente Podman.

    La CLI composer-dev comunica tramite chiamate API Docker standard. Devi attivare il wrapper del socket del servizio in background di Podman a livello di utente per simulare il daemon Docker.

    Innanzitutto, verifica se il socket a livello utente è già attivo:

    systemctl --user is-active podman.socket

    Se il comando restituisce inactive o failed, attiva e avvia il socket:

    # Enable and start Podman's user-level systemd socket
systemctl --user enable --now podman.socket

  2. Configura le variabili di ambiente per Podman.

    Aggiungi il seguente comando al file di configurazione della shell (ad esempio .bashrc o .zshrc):

    export DOCKER_HOST="unix:///run/user/$UID/podman/podman.sock"

Windows

  1. Imposta la configurazione di WSL 2 (.wslconfig). Prima di inizializzare la macchina Podman, verifica che WSL 2 abbia un limite di memoria e di swap definito. Senza questo, i deployment multi-container possono causare picchi di memoria durante l'estrazione delle immagini. È inoltre importante impostare una limitazione per il limite di download simultanei.

    Modifica o crea il file %USERPROFILE%\.wslconfig:

    [wsl2]
memory=4GB
swap=2GB

[registry]
max_concurrent_downloads = 2

  2. In PowerShell, inizializza la macchina Podman:

    podman machine init

  3. Avvia la macchina:

    podman machine start

Dopo aver eseguito questi passaggi, puoi utilizzare i comandi CLI di composer-dev. Lo strumento rileva automaticamente l'ambiente Podman su Windows e adatta le mappature dell'architettura.

Crea un ambiente Airflow locale con un'immagine di build Airflow

Per elencare le immagini di build di Airflow disponibili, esegui:

composer-dev list-available-versions --include-past-releases --limit 10

Per creare un ambiente Airflow locale con i parametri predefiniti, esegui:

composer-dev create \
  --from-image-version IMAGE_VERSION \
  LOCAL_ENVIRONMENT_NAME

Altri parametri:

composer-dev create LOCAL_ENVIRONMENT_NAME \
  --from-image-version IMAGE_VERSION \
  --project PROJECT_ID \
  --port WEB_SERVER_PORT \
  --dags-path LOCAL_DAGS_PATH \
  --plugins-path LOCAL_PLUGINS_PATH \
  --database DATABASE_ENGINE \
  --editable-dependencies EDITABLE_DEPENDENCY_PATH

Sostituisci:

  • LOCAL_ENVIRONMENT_NAME con il nome di questo ambiente Airflow locale.
  • IMAGE_VERSION con il nome dell'immagine di build di Airflow.
  • PROJECT_ID con l'ID progetto.
  • WEB_SERVER_PORT con la porta su cui il server web Airflow deve rimanere in ascolto.
  • LOCAL_DAGS_PATH con il percorso di una directory locale in cui si trovano i file DAG.
  • LOCAL_PLUGINS_PATH con il percorso di una directory locale in cui si trovano i file del plug-in.

  • DATABASE_ENGINE con il motore del database da utilizzare. I valori possibili sono postgresql (predefinito) e sqlite.

  • (Solo Linux/macOS) EDITABLE_DEPENDENCY_PATH con il percorso di una directory locale contenente un pacchetto Python da installare in modalità modificabile. Questo argomento non è supportato in Windows.

    I percorsi possono essere assoluti o relativi (i percorsi relativi vengono risolti rispetto alla directory di lavoro corrente). Questa directory deve essere accessibile dal motore del container.

    Per specificare più pacchetti modificabili, ripeti l'opzione. Esempio: --editable-dependencies ./pkg1 --editable-dependencies ./pkg2.

    L'installazione dei pacchetti con pip install -e applica immediatamente le modifiche a questi pacchetti all'interno del progetto.

Esempio:

composer-dev create \
  --from-image-version composer-3-airflow-2.11.1-build.20 \
  example-local-environment

Crea un ambiente Airflow locale da un ambiente Managed Airflow

Dall'ambiente Managed Airflow vengono prese solo le seguenti informazioni:

  • Build specifica di Airflow utilizzata dal tuo ambiente.

  • Elenco dei pacchetti PyPI personalizzati installati nel tuo ambiente.

  • Elenco commentato dei nomi delle variabili di ambiente impostate nel tuo ambiente.

Altre informazioni e parametri di configurazione dell'ambiente, come file DAG, cronologia delle esecuzioni dei DAG, variabili e connessioni Airflow, non vengono copiati dall'ambiente Managed Airflow.

Per creare un ambiente Airflow locale da un ambiente Managed Airflow esistente:

composer-dev create LOCAL_ENVIRONMENT_NAME \
    --from-source-environment ENVIRONMENT_NAME \
    --location LOCATION \
    --project PROJECT_ID \
    --port WEB_SERVER_PORT \
    --dags-path LOCAL_DAGS_PATH \
    --plugins-path LOCAL_PLUGINS_PATH \
    --database DATABASE_ENGINE \
    --editable-dependencies EDITABLE_DEPENDENCY_PATH

Sostituisci:

  • LOCAL_ENVIRONMENT_NAME con un nome per l'ambiente Airflow locale.
  • ENVIRONMENT_NAME con il nome dell'ambiente Managed Airflow.
  • LOCATION con la regione in cui si trova l'ambiente Managed Airflow.
  • PROJECT_ID con l'ID progetto.
  • WEB_SERVER_PORT con una porta per il server web Airflow locale.
  • LOCAL_DAGS_PATH con un percorso a una directory locale in cui si trovano i DAG.
  • LOCAL_PLUGINS_PATH con il percorso di una directory locale in cui si trovano i file dei plug-in.

  • DATABASE_ENGINE con il motore del database da utilizzare. I valori possibili sono postgresql (predefinito) e sqlite.

  • (Solo Linux/macOS) EDITABLE_DEPENDENCY_PATH con il percorso di una directory locale contenente un pacchetto Python da installare in modalità modificabile. Questo argomento non è supportato in Windows.

    I percorsi possono essere assoluti o relativi (i percorsi relativi vengono risolti rispetto alla directory di lavoro corrente). Questa directory deve essere accessibile dal motore del container.

    Per specificare più pacchetti modificabili, ripeti l'opzione. Esempio: --editable-dependencies ./pkg1 --editable-dependencies ./pkg2.

    L'installazione dei pacchetti con pip install -e applica immediatamente le modifiche a questi pacchetti all'interno del progetto.

Esempio:

composer-dev create example-local-environment \
  --from-source-environment example-environment \
  --location us-central1 \
  --project example-project \
  --port 8081 \
  --dags-path ./example_directory/dags \
  --plugins-path ./example_directory/plugins \
  --database postgresql \
  --editable-dependencies ./pkg1

Avvia un ambiente Airflow locale

Per avviare un ambiente Airflow locale, esegui:

composer-dev start LOCAL_ENVIRONMENT_NAME

Sostituisci:

  • LOCAL_ENVIRONMENT_NAME con il nome di un ambiente Airflow locale.

Arresta o riavvia un ambiente Airflow locale

Quando riavvii un ambiente Airflow locale, lo strumento Composer Local Development CLI riavvia il container Docker in cui viene eseguito l'ambiente. Tutti i componenti Airflow vengono arrestati e riavviati. Di conseguenza, tutte le esecuzioni dei DAG eseguite durante un riavvio vengono contrassegnate come non riuscite .

Per riavviare o avviare un ambiente Airflow locale arrestato, esegui:

composer-dev restart LOCAL_ENVIRONMENT_NAME

Sostituisci:

  • LOCAL_ENVIRONMENT_NAME con il nome di un ambiente Airflow locale.

Per arrestare un ambiente Airflow locale, esegui:

composer-dev stop LOCAL_ENVIRONMENT_NAME

Aggiungi e aggiorna i DAG

I DAG sono archiviati nella directory specificata nel parametro --dags-path quando hai creato l'ambiente Airflow locale. Per impostazione predefinita, questa directory è ./composer/<local_environment_name>/dags. Puoi ottenere la directory utilizzata dal tuo ambiente con il comando describe.

Per aggiungere e aggiornare i DAG, modifica i file in questa directory. Non è necessario riavviare l'ambiente Airflow locale.

Visualizza i log dell'ambiente Airflow locale

Puoi visualizzare i log recenti di un container Docker che esegue l'ambiente Airflow locale. In questo modo, puoi monitorare gli eventi correlati ai container e controllare i log di Airflow per errori come i conflitti di dipendenza causati dall'installazione dei pacchetti PyPI.

Per visualizzare i log di un container Docker che esegue l'ambiente Airflow locale, esegui:

composer-dev logs LOCAL_ENVIRONMENT_NAME --max-lines 10

Per seguire il flusso di log, ometti l'argomento --max-lines:

composer-dev logs LOCAL_ENVIRONMENT_NAME

Esegui un comando dell'interfaccia a riga di comando di Airflow

Puoi eseguire i comandi dell'interfaccia a riga di comando di Airflow nel tuo ambiente Airflow locale.

Per eseguire un comando dell'interfaccia a riga di comando di Airflow:

composer-dev run-airflow-cmd LOCAL_ENVIRONMENT_NAME \
  SUBCOMMAND SUBCOMMAND_ARGUMENTS

Esempio:

composer-dev run-airflow-cmd example-local-environment dags list -o table

Configura gli ambienti Airflow locali

Lo strumento CLI di sviluppo locale di Composer archivia i parametri di configurazione per un ambiente Airflow locale, come le variabili di ambiente e i requisiti dei pacchetti PyPI nella directory dell'ambiente locale (./composer/<local_environment_name>).

La configurazione viene applicata all'avvio di un ambiente Airflow locale. Ad esempio, se aggiungi requisiti dei pacchetti PyPI in conflitto, lo strumento CLI di sviluppo locale di Composer segnala errori quando avvii l'ambiente locale.

Le connessioni Airflow vengono archiviate nel database dell'ambiente Airflow locale. Puoi configurarle eseguendo un comando dell'interfaccia a riga di comando di Airflow o memorizzando i parametri di connessione nelle variabili di ambiente. Per saperne di più sui modi per creare e configurare le connessioni, consulta Gestione delle connessioni nella documentazione di Airflow.

Visualizzare un elenco e lo stato degli ambienti Airflow locali

Per elencare tutti gli ambienti Airflow locali disponibili e visualizzarne lo stato:

composer-dev list

Per descrivere un ambiente specifico e ottenere dettagli come la versione immagine, il percorso dei DAG e l'URL del server web di un ambiente:

composer-dev describe LOCAL_ENVIRONMENT_NAME

Sostituisci:

  • LOCAL_ENVIRONMENT_NAME con il nome dell'ambiente Airflow locale.

Elenca le immagini utilizzate dagli ambienti Airflow locali

Per elencare tutte le immagini utilizzate dallo strumento CLI di sviluppo locale di Composer, esegui:

docker images --filter=reference='*/cloud-airflow-releaser/*/*'

Installare plug-in e modificare i dati

I plug-in e i dati per un ambiente Airflow locale vengono presi dalla directory dell'ambiente locale: ./composer/<local_environment_name>/data e ./composer/<local_environment_name>/plugins).

Per modificare i contenuti delle directory /data e /plugins, aggiungi o rimuovi i file in queste directory. Docker propaga automaticamente le modifiche ai file all'ambiente Airflow locale.

Lo strumento CLI di Composer Local Development non supporta la specifica di una directory diversa per dati e plug-in.

Configura le variabili di ambiente

Per configurare le variabili di ambiente, modifica il file variables.env nella directory dell'ambiente: ./composer/<local_environment_name>/variables.env.

Il file variables.env deve contenere definizioni coppia chiave-valore, una riga per ogni variabile di ambiente. Per modificare le opzioni di configurazione di Airflow, utilizza il formato AIRFLOW__SECTION__KEY. Per saperne di più sulle variabili di ambiente disponibili, consulta il riferimento alla configurazione di Airflow.

EXAMPLE_VARIABLE=True
ANOTHER_VARIABLE=test
AIRFLOW__WEBSERVER__DAG_DEFAULT_VIEW=graph

Per applicare le modifiche, riavvia l'ambiente Airflow locale.

Installa o rimuovi i pacchetti PyPI

Per installare o rimuovere i pacchetti PyPI, modifica il file requirements.txt nella directory dell'ambiente: ./composer/<local_environment_name>/requirements.txt.

I requisiti devono seguire il formato specificato in PEP-508, in cui ogni requisito è specificato in lettere minuscole ed è costituito dal nome del pacchetto con extra facoltativi e specificatori di versione.

Per applicare le modifiche, riavvia l'ambiente Airflow locale.

Passa a un'altra immagine di build di Airflow

Puoi utilizzare qualsiasi immagine di build di Airflow con lo strumento CLI di sviluppo locale di Composer e passare da un'immagine all'altra. Questo approccio è diverso dall'upgrade dell'ambiente Managed Airflow, perché i parametri di configurazione dell'ambiente Airflow locale vengono applicati all'avvio.

Ad esempio, dopo il rilascio di una nuova build di Airflow, puoi cambiare l'ambiente in modo che la utilizzi e mantenere la configurazione dell'ambiente Airflow locale esistente.

Per modificare l'immagine dell'ambiente utilizzata dal tuo ambiente Airflow locale:

  1. Modifica il file di configurazione dell'ambiente locale: ./composer/<local_environment_name>/config.json.

  2. Modifica il valore del parametro composer_image_version. Per visualizzare i valori disponibili, puoi elencare le immagini disponibili.

  3. Per applicare le modifiche, riavvia l'ambiente Airflow locale.

Elimina un ambiente Airflow locale

Attenzione:assicurati di aver salvato tutti i dati richiesti dall'ambiente, come log e configurazione.

Per eliminare un ambiente Airflow locale, esegui questo comando:

composer-dev remove LOCAL_ENVIRONMENT_NAME

Se l'ambiente è in esecuzione, aggiungi il flag --force per forzarne la rimozione.

Elimina le immagini Docker

Per eliminare tutte le immagini scaricate dallo strumento CLI Composer Local Development, esegui:

docker rmi $(docker images --filter=reference='*/cloud-airflow-releaser/*/*' -q)

Configurazione aggiuntiva e risoluzione dei problemi

Questa sezione fornisce soluzioni ai problemi comuni e passaggi di configurazione aggiuntivi per configurare l'interazione dello strumento CLI Composer Local Development con altri strumenti e servizi.

Completamento della scheda della shell

La CLI composer-dev supporta il completamento tramite tasto Tab per le shell Bash, Zsh e Fish. Puoi utilizzare il completamento automatico per scoprire le opzioni e i sottocomandi disponibili senza consultare il testo della guida.

Zsh

Genera lo script di completamento e inseriscilo nel tuo ~/.zshrc:

_COMPOSER_DEV_COMPLETE=zsh_source composer-dev > ~/.composer-dev-complete.zsh

Poi aggiungilo al tuo ~/.zshrc:

echo 'source ~/.composer-dev-complete.zsh' >> ~/.zshrc

Bash

Genera lo script di completamento e inseriscilo in ~/.bashrc:

_COMPOSER_DEV_COMPLETE=bash_source composer-dev > ~/.composer-dev-complete.bash

Poi aggiungilo al tuo ~/.bashrc:

echo 'source ~/.composer-dev-complete.bash' >> ~/.bashrc

Pesci

Genera lo script di completamento e salvalo nella directory dei completamenti di Fish:

_COMPOSER_DEV_COMPLETE=fish_source composer-dev > ~/.config/fish/completions/composer-dev.fish

Interazione con i cluster Kubernetes

Per impostazione predefinita, il file ~/.kube/config non è montato. Puoi specificare il percorso del file di configurazione di Kubernetes esportando la variabile di ambiente KUBECONFIG prima di avviare l'ambiente.

export KUBECONFIG=~/.kube/config

Interazione con altri servizi sulla macchina host

localhost in un ambiente Managed Airflow punta al container stesso, non alla macchina host, a causa del funzionamento della rete sui container Docker o Podman. Per comodità, lo strumento CLI composer-dev configura la rete del container per accedere alla macchina tramite l'alias di dominio host.docker.internal. Esempi:

  • Redis: utilizza host.docker.internal:6379 anziché localhost:6379 se Redis è in esecuzione sulla porta 6379.
  • PostgreSQL: Utilizza host.docker.internal:25432 anziché localhost:25432 se PostgreSQL è in esecuzione sulla porta 25432.
  • Qualsiasi altro servizio: Segui questo pattern: host.docker.internal:<PORT>

Impossibile avviare un ambiente locale su macOS

Se hai installato il pacchetto composer-dev in una directory a cui Docker non può accedere, l'ambiente locale potrebbe non avviarsi.

Ad esempio, se Python è installato nella directory /opt, come quando lo installi con la configurazione Homebrew predefinita su macOS, anche il pacchetto composer-dev viene installato nella directory /opt. Poiché Docker è conforme alle regole della sandbox di Apple, la directory /opt non è disponibile per impostazione predefinita. Inoltre, non puoi aggiungerlo tramite l'interfaccia utente (Impostazioni > Risorse > Condivisione file).

In questo caso, lo strumento CLI Composer Local Development genera un messaggio di errore simile al seguente esempio:

Failed to create container with an error: 400 Client Error for ...
Bad Request ("invalid mount config for type "bind": bind source path does not exist:
/opt/homebrew/lib/python3.9/site-packages/composer_local_dev/docker_files/entrypoint.sh

Possible reason is that composer-dev was installed in the path that is
not available to Docker. See...")

Puoi utilizzare una delle seguenti soluzioni:

  • Installa Python o il pacchetto composer-dev in una directory diversa, in modo che Docker possa accedere al pacchetto.
  • Modifica manualmente il file ~/Library/Group\ Containers/group.com.docker/settings.json e aggiungi /opt a filesharingDirectories.

Accesso dell'utente del container a file e directory montati dall'host

Per impostazione predefinita, il container dell'ambiente Managed Airflow viene eseguito come utente airflow con UID 999. L'utente deve avere accesso ai file e alle directory montati dall'host, ad esempio ~/.config/gcloud/application_default_credentials.json.

Problemi noti:

  • google.auth.exceptions.DefaultCredentialsError: Your default credentials were not found: può essere generato quando il contenitore viene eseguito con l'utente predefinito airflow (999) e la directory host ~/.config/gcloud/ non dispone dell'autorizzazione di esecuzione per l'utente.
  • [Errno 13] Permission denied: '/home/airflow/.config/gcloud/application_default_credentials.json': può essere generato quando esegui il container con l'utente predefinito airflow (999) e il file host ~/.config/gcloud/application_default_credentials.json non dispone dell'autorizzazione di lettura per l'utente.

Su Linux o macOS, è consigliabile eseguire il container come utente host corrente aggiungendo COMPOSER_CONTAINER_RUN_AS_HOST_USER=True a composer/<LOCAL_ENVIRONMENT_NAME>/variables.env.Questa funzionalità non è disponibile su Windows, quindi potrebbe essere necessario aggiornare le autorizzazioni dei file e delle directory montati sull'host per consentire l'accesso da parte dell'utente all'interno del container.

(Podman) Correggi gli errori di autorizzazione o lchown per gli utenti aziendali

Per impedire che Podman senza privilegi di root allochi automaticamente spazi dei nomi utente che si sovrappongono al tuo ID utente aziendale principale (causando errori lchown: invalid argument o di autorizzazione), devi eseguire il push manuale degli intervalli secondari sopra il blocco di 4 milioni.

  1. Apri /etc/subuid e /etc/subgid con privilegi root (ad esempio: sudo nano /etc/subuid).

  2. Aggiorna o aggiungi la voce del nome utente in modo che sia esattamente così:

    YOUR_USERNAME:4000000:3000000

  3. Salva entrambi i file ed esegui il comando seguente per applicare le nuove regole di mapping dello spazio dei nomi a Podman:

    podman system migrate

(Podman) Rimuovi i file bloccati e gli errori di autorizzazione negata

Se hai aggiornato gli intervalli subuid mentre esistevano i vecchi contenitori, lo spazio dei nomi attuale non potrà accedere alla propria cache di dati.

Forza la cancellazione del grafico di archiviazione locale utilizzando i privilegi di root a livello di host:

podman rm -fa
podman volume rm --all --force
podman system migrate

(Podman) Correggi gli errori DNS ("Nome o servizio sconosciuto")

Se il container Airflow genera un errore psycopg2.OperationalError che indica che non è possibile tradurre o risolvere il nome host per il container del database (your-environment-name), la rete bridge virtuale interna di Podman non è sincronizzata.

Svuota gli stati di runtime e forza la rigenerazione di netavark e aardvark-dns per creare tabelle di routing pulite.

podman rm -fa
podman network prune --force

rm -rf /run/user/$UID/containers/*
rm -rf /run/user/$UID/netavark/*
rm -rf COMPOSER_LOCAL_DEV_PATH/composer/*

podman system migrate

(Podman) Verifica lo stato del motore

Per verificare che Podman gestisca il tuo workflow senza privilegi root e non ignori la tua configurazione in Docker di sistema:

  1. Verifica il backend DNS della rete:

    podman info | grep -A 3 -i "dns"

    L'output deve contenere backend: netavark e un percorso eseguibile valido per aardvark-dns.

  2. Verifica la mappatura della proprietà dei processi. Con l'ambiente in esecuzione, controlla il proprietario del processo host:

    ps -ef | grep -i "postgres"

    La colonna più a sinistra deve mostrare un numero UID elevato (ad esempio 4000069) corrispondente all'intervallo della mappa subuid, a dimostrazione che viene eseguito interamente senza root.

(Podman, Windows) Correggi gli errori di pipe durante il deployment

Se il database o il container Airflow esce immediatamente con errori di pipe durante il deployment, Podman potrebbe raggiungere un limite di memoria. Per risolvere il problema, puoi provare ad aumentare i limiti di memoria e swap nel file .wslconfig:

  1. Arresta la macchina Podman e la macchina virtuale WSL 2 eseguendo il seguente comando in PowerShell:

    podman machine stop
wsl --shutdown

  2. Apporta modifiche al file %USERPROFILE%\.wslconfig per adattare i limiti di swap e di memoria. Per riferimento, consulta Riferimento alla configurazione di WSL.

  3. Avvia la macchina Podman eseguendo:

    podman machine start

Se si verificano errori, puoi provare a eseguire il riavvio forzato dello stack di virtualizzazione e di rete di Windows. Per farlo, apri PowerShell come amministratore ed esegui:

Restart-Service -Name vmms -Force
Restart-Service -Name hns -Force
wsl --shutdown

Passaggi successivi