Exécuter un environnement Airflow local avec l'outil de CLI de développement local Composer

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

Cette section explique comment créer, configurer et exécuter un environnement Airflow local à l'aide de l'outil Composer Local Development CLI.

À propos de l'outil CLI de développement local Composer

L'outil CLI de développement local Composer simplifie le développement de DAG Apache Airflow pour Managed Airflow en exécutant un environnement Airflow en local. Cet environnement Airflow local utilise une image Managed Airflow utilisée par une version Managed Airflow spécifique.

Vous pouvez créer un environnement Airflow local basé sur un environnement Managed Airflow existant. Dans ce cas, l'environnement Airflow local récupère la liste des packages PyPI installés et les noms des variable d'environnement de votre environnement Managed Airflow.

Vous pouvez utiliser cet environnement Airflow local à des fins de test et de développement, par exemple pour tester un nouveau code DAG, des packages PyPI ou des options de configuration Airflow.

Avant de commencer

  • L'outil CLI de développement local Composer crée des environnements Airflow locaux dans un répertoire où vous exécutez la commande composer-dev create. Pour accéder ultérieurement à votre environnement Airflow local, exécutez les commandes de l'outil dans le chemin d'accès où vous avez créé l'environnement local. Toutes les données de l'environnement local sont stockées dans un sous-répertoire au chemin d'accès où vous avez créé l'environnement local : ./composer/<local_environment_name>.

  • Votre ordinateur doit disposer de suffisamment d'espace disque pour stocker les images Managed Airflow. L'outil CLI de développement local Composer stocke un fichier image pour chaque version de Managed Airflow. Par exemple, si vous disposez de deux environnements Airflow locaux avec des versions Managed Airflow différentes, l'outil CLI Composer Local Development stocke deux images Managed Airflow.

  • L'outil CLI de développement local Composer utilise une sortie colorée. Vous pouvez désactiver la sortie colorée avec la variable NO_COLOR=1 : NO_COLOR=1 composer-dev <other commands>.

  • Si vous n'avez qu'un seul environnement local, vous pouvez omettre son nom de toutes les commandes composer-dev, à l'exception de run-airflow-cmd.

  • Installez les dépendances de l'outil CLI de développement local Composer :

  • Docker (Linux/macOS/Windows) ou Podman (Linux ou Windows) doivent être installés et en cours d'exécution sur votre ordinateur.

    Pour vérifier que Docker ou Podman sont en cours d'exécution, exécutez n'importe quelle commande Docker CLI ou Podman CLI, telle que docker ps ou podman ps. Toutes les instructions s'appliquent à Docker et à Podman, sauf indication contraire. De plus, toutes les commandes Docker peuvent être remplacées par des commandes Podman équivalentes.

Configurer les identifiants

Si vous ne l'avez pas encore fait, obtenez de nouveaux identifiants utilisateur à utiliser comme identifiants par défaut de l'application :

gcloud auth application-default login

Connectez-vous à gcloud CLI à l'aide de votre compte Google :

gcloud auth login

Tous les appels d'API effectués par l'outil Composer Local Development CLI et les DAG sont exécutés à partir du compte que vous utilisez dans gcloud CLI. Par exemple, si un DAG de votre environnement Airflow local lit le contenu d'un bucket Cloud Storage, ce compte doit disposer des autorisations nécessaires pour accéder au bucket. Cela diffère des environnements Managed Airflow, où le compte de service d'un environnement effectue les appels.

Installer l'outil CLI de développement local Composer

Clonez le dépôt de l'outil CLI de développement local Composer :

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

Dans le répertoire de premier niveau du dépôt cloné, exécutez la commande suivante :

pip install .

Selon la configuration de votre pip, le chemin d'installation de l'outil peut ne pas se trouver dans la variable PATH. Dans ce cas, pip affiche un message d'avertissement. Vous pouvez utiliser les informations de ce message d'avertissement pour ajouter ce répertoire à la variable PATH de votre système d'exploitation.

(Podman) Configurer Podman

Si vous utilisez Podman, procédez comme suit pour le configurer :

Linux

  1. Activez le socket du service utilisateur Podman.

    L'CLI composer-dev communique via des appels d'API Docker standards. Vous devez activer le wrapper de socket du service d'arrière-plan de Podman au niveau de l'utilisateur pour imiter le daemon Docker.

    Tout d'abord, vérifiez si le socket au niveau de l'utilisateur est déjà actif :

    systemctl --user is-active podman.socket

    Si la commande renvoie inactive ou failed, activez et démarrez le socket :

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

  2. Configurez les variables d'environnement pour Podman.

    Ajoutez la commande suivante à votre fichier de configuration du shell (tel que .bashrc ou .zshrc) :

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

Windows

  1. Définissez la configuration WSL 2 (.wslconfig). Avant d'initialiser votre machine Podman, vérifiez que WSL 2 a une limite de mémoire et d'espace d'échange définie. Sans cela, les déploiements multiconteneurs peuvent entraîner des pics de mémoire lors de l'extraction d'images. Il est également important de définir une limite pour le nombre de téléchargements simultanés.

    Modifiez ou créez le fichier %USERPROFILE%\.wslconfig :

    [wsl2]
memory=4GB
swap=2GB

[registry]
max_concurrent_downloads = 2

  2. Dans PowerShell, initialisez la machine Podman :

    podman machine init

  3. Démarrez la machine :

    podman machine start

Une fois ces étapes effectuées, vous pouvez utiliser les commandes de la CLI composer-dev. L'outil détecte automatiquement votre environnement Podman sur Windows et adapte les mappages d'architecture.

Créer un environnement Airflow local avec une image Managed Airflow

Pour lister les images Managed Airflow disponibles, exécutez la commande suivante :

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

Pour créer un environnement Airflow local avec des paramètres par défaut, exécutez la commande suivante :

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

Autres paramètres :

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

Remplacez :

  • LOCAL_ENVIRONMENT_NAME par le nom de cet environnement Airflow local.
  • IMAGE_VERSION par le nom de l'image Managed Airflow.
  • PROJECT_ID par l'ID du projet.
  • WEB_SERVER_PORT avec le port sur lequel le serveur Web Airflow doit écouter.
  • LOCAL_DAGS_PATH par le chemin d'accès à un répertoire local où se trouvent les fichiers DAG.
  • LOCAL_PLUGINS_PATH par le chemin d'accès à un répertoire local où se trouvent les fichiers du plug-in.

  • DATABASE_ENGINE par le moteur de base de données à utiliser. Les valeurs possibles sont postgresql (par défaut) et sqlite.

  • (Linux/macOS uniquement) EDITABLE_DEPENDENCY_PATH avec le chemin d'accès à un répertoire local contenant un package Python à installer en mode édition. Cet argument n'est pas compatible avec Windows.

    Les chemins d'accès peuvent être absolus ou relatifs (les chemins relatifs sont résolus par rapport au répertoire de travail actuel). Ce répertoire doit être accessible par le moteur de conteneur.

    Pour spécifier plusieurs packages modifiables, répétez l'option. Exemple : --editable-dependencies ./pkg1 --editable-dependencies ./pkg2.

    L'installation des packages avec pip install -e applique immédiatement les modifications à ces packages dans le projet.

Exemple :

composer-dev create \
  --from-image-version composer-2.17.11-airflow-2.11.1 \
  example-local-environment

Créer un environnement Airflow local à partir d'un environnement Managed Airflow

Seules les informations suivantes sont extraites d'un environnement Managed Airflow :

  • Versions de Managed Airflow et d'Airflow utilisées dans votre environnement.

  • Liste des packages PyPI personnalisés installés dans votre environnement.

  • Liste commentée des noms des variables d'environnement définies dans votre environnement.

Les autres informations et paramètres de configuration de l'environnement, tels que les fichiers DAG, l'historique des exécutions de DAG, les variables Airflow et les connexions, ne sont pas copiés depuis votre environnement Managed Airflow.

Pour créer un environnement Airflow local à partir d'un environnement Managed Airflow existant :

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

Remplacez :

  • LOCAL_ENVIRONMENT_NAME par le nom de l'environnement Airflow local.
  • ENVIRONMENT_NAME par le nom de l'environnement Managed Airflow.
  • LOCATION par la région dans laquelle se trouve l'environnement Managed Airflow.
  • PROJECT_ID par l'ID du projet.
  • WEB_SERVER_PORT avec un port pour le serveur Web Airflow local.
  • LOCAL_DAGS_PATH par le chemin d'accès à un répertoire local où se trouvent les DAG.
  • LOCAL_PLUGINS_PATH par le chemin d'accès à un répertoire local où se trouvent les fichiers de plug-ins.

  • DATABASE_ENGINE par le moteur de base de données à utiliser. Les valeurs possibles sont postgresql (par défaut) et sqlite.

  • (Linux/macOS uniquement) EDITABLE_DEPENDENCY_PATH avec le chemin d'accès à un répertoire local contenant un package Python à installer en mode édition. Cet argument n'est pas compatible avec Windows.

    Les chemins d'accès peuvent être absolus ou relatifs (les chemins relatifs sont résolus par rapport au répertoire de travail actuel). Ce répertoire doit être accessible par le moteur de conteneur.

    Pour spécifier plusieurs packages modifiables, répétez l'option. Exemple : --editable-dependencies ./pkg1 --editable-dependencies ./pkg2.

    L'installation des packages avec pip install -e applique immédiatement les modifications à ces packages dans le projet.

Exemple :

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

Démarrer un environnement Airflow local

Pour démarrer un environnement Airflow local, exécutez la commande suivante :

composer-dev start LOCAL_ENVIRONMENT_NAME

Remplacez :

  • LOCAL_ENVIRONMENT_NAME par le nom d'un environnement Airflow local.

Arrêter ou redémarrer un environnement Airflow local

Lorsque vous redémarrez un environnement Airflow local, l'outil CLI de développement local Composer redémarre le conteneur Docker dans lequel l'environnement s'exécute. Tous les composants Airflow sont arrêtés, puis redémarrés. Par conséquent, toutes les exécutions de DAG qui ont lieu lors d'un redémarrage sont marquées comme ayant échoué .

Pour redémarrer ou démarrer un environnement Airflow local arrêté, exécutez la commande suivante :

composer-dev restart LOCAL_ENVIRONMENT_NAME

Remplacez :

  • LOCAL_ENVIRONMENT_NAME par le nom d'un environnement Airflow local.

Pour arrêter un environnement Airflow local, exécutez la commande suivante :

composer-dev stop LOCAL_ENVIRONMENT_NAME

Ajouter et mettre à jour des DAG

Les DAG sont stockés dans le répertoire que vous avez spécifié dans le paramètre --dags-path lorsque vous avez créé votre environnement Airflow local. Par défaut, ce répertoire est ./composer/<local_environment_name>/dags. Vous pouvez obtenir le répertoire utilisé par votre environnement avec la commande describe.

Pour ajouter et mettre à jour des DAG, modifiez les fichiers de ce répertoire. Vous n'avez pas besoin de redémarrer votre environnement Airflow local.

Afficher les journaux de l'environnement Airflow local

Vous pouvez afficher les journaux récents d'un conteneur Docker qui exécute votre environnement Airflow local. Vous pouvez ainsi surveiller les événements liés aux conteneurs et vérifier les journaux Airflow pour détecter les erreurs telles que les conflits de dépendances causés par l'installation de packages PyPI.

Pour afficher les journaux d'un conteneur Docker qui exécute votre environnement Airflow local, exécutez la commande suivante :

composer-dev logs LOCAL_ENVIRONMENT_NAME --max-lines 10

Pour suivre le flux de journaux, omettez l'argument --max-lines :

composer-dev logs LOCAL_ENVIRONMENT_NAME

Exécuter une commande de CLI Airflow

Vous pouvez exécuter des commandes de CLI Airflow dans votre environnement Airflow local.

Pour exécuter une commande de CLI Airflow :

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

Exemple :

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

Configurer des environnements Airflow locaux

L'outil CLI de développement local Composer stocke les paramètres de configuration d'un environnement Airflow local, tels que les variables d'environnement et les exigences concernant les packages PyPI, dans le répertoire de l'environnement local (./composer/<local_environment_name>).

La configuration est appliquée lorsqu'un environnement Airflow local est démarré. Par exemple, si vous ajoutez des exigences de package PyPI conflictuelles, l'outil de ligne de commande Composer Local Development signale des erreurs lorsque vous démarrez l'environnement local.

Les connexions Airflow sont stockées dans la base de données de l'environnement Airflow local. Vous pouvez les configurer en exécutant une commande CLI Airflow ou en stockant les paramètres de connexion dans des variables d'environnement. Pour en savoir plus sur la création et la configuration des connexions, consultez Gérer les connexions dans la documentation Airflow.

Obtenir la liste et l'état des environnements Airflow locaux

Pour lister tous les environnements Airflow locaux disponibles et afficher leur état :

composer-dev list

Pour décrire un environnement spécifique et obtenir des informations telles que la version de l'image, le chemin d'accès aux DAG et l'URL du serveur Web d'un environnement :

composer-dev describe LOCAL_ENVIRONMENT_NAME

Remplacez :

  • LOCAL_ENVIRONMENT_NAME par le nom de l'environnement Airflow local.

Lister les images utilisées par les environnements Airflow locaux

Pour lister toutes les images utilisées par l'outil CLI de développement local Composer, exécutez la commande suivante :

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

Installer des plug-ins et modifier des données

Les plug-ins et les données d'un environnement Airflow local sont extraits des répertoires de l'environnement local : ./composer/<local_environment_name>/data et ./composer/<local_environment_name>/plugins.

Pour modifier le contenu des répertoires /data et /plugins, ajoutez ou supprimez des fichiers dans ces répertoires. Docker propage automatiquement les modifications apportées aux fichiers à votre environnement Airflow local.

L'outil CLI de développement local Composer ne permet pas de spécifier un répertoire différent pour les données et les plug-ins.

Configurer les variables d'environnement

Pour configurer les variables d'environnement, modifiez le fichier variables.env dans le répertoire de l'environnement : ./composer/<local_environment_name>/variables.env.

Le fichier variables.env doit contenir des définitions clé/valeur, une ligne pour chaque variable d'environnement. Pour modifier les options de configuration Airflow, utilisez le format AIRFLOW__SECTION__KEY. Pour en savoir plus sur les variables d'environnement disponibles, consultez la documentation de référence sur la configuration d'Airflow.

EXAMPLE_VARIABLE=True
ANOTHER_VARIABLE=test
AIRFLOW__WEBSERVER__DAG_DEFAULT_VIEW=graph

Pour appliquer les modifications, redémarrez votre environnement Airflow local.

Installer ou supprimer des packages PyPI

Pour installer ou supprimer des packages PyPI, modifiez le fichier requirements.txt dans le répertoire de l'environnement : ./composer/<local_environment_name>/requirements.txt.

Les exigences doivent respecter le format spécifié dans PEP-508, où chaque exigence est spécifiée en minuscules et consiste en un nom de package avec des options et des spécificateurs de version facultatifs.

Pour appliquer les modifications, redémarrez votre environnement Airflow local.

Passer à une autre image Managed Airflow

Vous pouvez utiliser n'importe quelle image Managed Airflow avec l'outil CLI Composer Local Development et passer d'une image à l'autre. Cette approche est différente de la mise à niveau de votre environnement Managed Airflow, car les paramètres de configuration de votre environnement Airflow local sont appliqués au démarrage.

Par exemple, après la sortie d'une nouvelle version de Managed Airflow, vous pouvez faire passer votre environnement à cette version tout en conservant la configuration existante de l'environnement Airflow local. Par exemple, vous pouvez basculer entre différentes versions d'Airflow au sein d'une version spécifique de Managed Airflow.

Pour modifier l'image de l'environnement utilisée par votre environnement Airflow local :

  1. Modifiez le fichier de configuration de l'environnement local : ./composer/<local_environment_name>/config.json.

  2. Modifiez la valeur du paramètre composer_image_version. Pour afficher les valeurs disponibles, vous pouvez lister les images disponibles.

  3. Pour appliquer les modifications, redémarrez votre environnement Airflow local.

Supprimer un environnement Airflow local

Attention : Assurez-vous d'avoir enregistré toutes les données requises de l'environnement, telles que les journaux et la configuration.

Pour supprimer un environnement Airflow local, exécutez la commande suivante :

composer-dev remove LOCAL_ENVIRONMENT_NAME

Si l'environnement est en cours d'exécution, ajoutez l'indicateur --force pour forcer sa suppression.

Supprimer des images Docker

Pour supprimer toutes les images téléchargées par l'outil CLI de développement local Composer, exécutez la commande suivante :

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

Configuration et dépannage supplémentaires

Cette section fournit des solutions aux problèmes courants et des étapes de configuration supplémentaires pour configurer l'interaction de l'outil CLI de développement local Composer avec d'autres outils et services.

Complétion par tabulation dans le shell

La CLI composer-dev est compatible avec la saisie semi-automatique pour les shells Bash, Zsh et Fish. Vous pouvez utiliser la saisie semi-automatique pour découvrir les sous-commandes et les options disponibles sans consulter le texte d'aide.

Zsh

Générez le script de saisie semi-automatique et sourcez-le dans votre ~/.zshrc :

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

Ajoutez-le ensuite à votre ~/.zshrc :

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

Bash

Générez le script de saisie semi-automatique et sourcez-le dans votre ~/.bashrc :

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

Ajoutez-le ensuite à votre ~/.bashrc :

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

Poisson

Générez le script de saisie semi-automatique et enregistrez-le dans le répertoire de saisie semi-automatique Fish :

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

Interagir avec les clusters Kubernetes

Par défaut, le fichier ~/.kube/config n'est pas monté. Vous pouvez spécifier le chemin d'accès au fichier de configuration Kubernetes en exportant la variable d'environnement KUBECONFIG avant de démarrer l'environnement.

export KUBECONFIG=~/.kube/config

Interagir avec d'autres services sur la machine hôte

Dans un environnement Managed Airflow, localhost pointe vers le conteneur lui-même, et non vers la machine hôte, en raison du fonctionnement du réseau sur les conteneurs Docker ou Podman. Pour plus de commodité, l'outil de CLI composer-dev configure le réseau du conteneur pour accéder à la machine via l'alias de domaine host.docker.internal. Exemples :

  • Redis : utilisez host.docker.internal:6379 au lieu de localhost:6379 si Redis s'exécute sur le port 6379.
  • PostgreSQL : utilisez host.docker.internal:25432 au lieu de localhost:25432 si PostgreSQL s'exécute sur le port 25432.
  • Tout autre service : Suivez ce modèle : host.docker.internal:<PORT>

Impossible de démarrer un environnement local sur macOS

Si vous avez installé le package composer-dev dans un répertoire auquel Docker ne peut pas accéder, il est possible que votre environnement local ne démarre pas.

Par exemple, si Python est installé dans le répertoire /opt, comme lorsque vous l'installez avec la configuration Homebrew par défaut sur macOS, le package composer-dev est également installé dans le répertoire /opt. Étant donné que Docker respecte les règles du bac à sable d'Apple, le répertoire /opt n'est pas disponible par défaut. De plus, vous ne pouvez pas l'ajouter via l'interface utilisateur (Paramètres > Ressources > Partage de fichiers).

Dans ce cas, l'outil Composer Local Development CLI génère un message d'erreur semblable à l'exemple suivant :

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...")

Vous pouvez utiliser l'une des solutions suivantes :

  • Installez Python ou le package composer-dev dans un autre répertoire afin que Docker puisse accéder au package.
  • Modifiez manuellement le fichier ~/Library/Group\ Containers/group.com.docker/settings.json et ajoutez /opt à filesharingDirectories.

Accès des utilisateurs du conteneur aux fichiers et répertoires montés depuis l'hôte

Par défaut, le conteneur de l'environnement Managed Airflow s'exécute en tant qu'utilisateur airflow avec l'UID 999. L'utilisateur doit avoir accès aux fichiers et répertoires montés depuis l'hôte, par exemple ~/.config/gcloud/application_default_credentials.json.

Problèmes connus :

  • google.auth.exceptions.DefaultCredentialsError: Your default credentials were not found : peut être généré lors de l'exécution du conteneur avec l'utilisateur par défaut airflow (999) et lorsque l'autorisation d'exécution pour l'utilisateur est manquante dans le répertoire hôte ~/.config/gcloud/.
  • [Errno 13] Permission denied: '/home/airflow/.config/gcloud/application_default_credentials.json' : peut être généré lorsque vous exécutez le conteneur avec l'utilisateur par défaut airflow (999) et que le fichier hôte ~/.config/gcloud/application_default_credentials.json ne dispose pas de l'autorisation de lecture pour l'utilisateur.

Sur Linux ou macOS, il est recommandé d'exécuter le conteneur en tant qu'utilisateur hôte actuel en ajoutant COMPOSER_CONTAINER_RUN_AS_HOST_USER=True à composer/<LOCAL_ENVIRONMENT_NAME>/variables.env. Cette fonctionnalité n'est pas disponible sur Windows. Vous devrez peut-être mettre à jour les autorisations des fichiers et répertoires montés sur l'hôte pour autoriser l'accès par l'utilisateur à l'intérieur du conteneur.

(Podman) Corriger les erreurs d'autorisation ou lchown pour les utilisateurs professionnels

Pour empêcher Podman sans racine d'allouer automatiquement des espaces de noms utilisateur qui se chevauchent avec votre ID utilisateur professionnel principal (entraînant des erreurs lchown: invalid argument ou d'autorisation), vous devez envoyer manuellement vos plages subordonnées au-dessus du bloc de 4 millions.

  1. Ouvrez /etc/subuid et /etc/subgid avec les droits racine (par exemple, sudo nano /etc/subuid).

  2. Mettez à jour ou ajoutez votre nom d'utilisateur pour qu'il ressemble exactement à ceci :

    YOUR_USERNAME:4000000:3000000

  3. Enregistrez les deux fichiers et exécutez la commande suivante pour appliquer les nouvelles règles de mappage de l'espace de noms à Podman :

    podman system migrate

(Podman) Supprimer les fichiers bloqués et les erreurs d'autorisation refusée

Si vous avez mis à jour vos plages subuid alors que d'anciens conteneurs existaient, votre espace de noms actuel ne pourra pas accéder à son propre cache de données.

Effacez de force le graphique de stockage local à l'aide des droits racine au niveau de l'hôte :

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

(Podman) Corriger les échecs DNS ("Nom ou service inconnus")

Si votre conteneur Airflow génère un psycopg2.OperationalError indiquant qu'il ne peut pas traduire ni résoudre le nom d'hôte du conteneur de base de données (your-environment-name), cela signifie que le réseau de pont virtuel interne de Podman est désynchronisé.

Videz les états d'exécution et forcez netavark et aardvark-dns à régénérer des tables de routage propres.

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) Vérifier l'état de votre moteur

Pour vérifier que Podman gère votre workflow sans racine et ne contourne pas votre configuration dans Docker système :

  1. Vérifiez le backend DNS du réseau :

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

    Le résultat doit contenir backend: netavark et un chemin d'accès exécutable valide vers aardvark-dns.

  2. Vérifiez le mappage de la propriété des processus. Une fois votre environnement en cours d'exécution, vérifiez le propriétaire du processus hôte :

    ps -ef | grep -i "postgres"

    La colonne la plus à gauche doit afficher un numéro UID élevé (tel que 4000069) correspondant à votre plage de mappage subuid, ce qui prouve qu'il s'exécute entièrement sans racine.

(Podman, Windows) Corriger les erreurs de canalisation lors du déploiement

Si le conteneur de base de données ou Airflow se ferme immédiatement avec des erreurs de canalisation lors du déploiement, il est possible que Podman atteigne une limite de mémoire. Pour résoudre ce problème, vous pouvez essayer d'augmenter les limites de mémoire et d'échange dans le fichier .wslconfig :

  1. Arrêtez votre machine Podman et votre machine virtuelle WSL2 en exécutant la commande suivante dans PowerShell :

    podman machine stop
wsl --shutdown

  2. Modifiez le fichier %USERPROFILE%\.wslconfig pour adapter vos limites de swap et de mémoire. Pour référence, consultez la documentation de référence sur la configuration WSL.

  3. Démarrez votre machine Podman en exécutant la commande suivante :

    podman machine start

Si vous rencontrez des erreurs, vous pouvez essayer de réinitialiser complètement la pile de virtualisation et de mise en réseau Windows. Pour ce faire, ouvrez PowerShell en tant qu'administrateur et exécutez la commande suivante :

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

Étapes suivantes