Ejecuta un entorno de Airflow local con la herramienta de CLI de desarrollo local de Composer

Managed Airflow (3ª gen.) | Managed Airflow (2ª gen.) | Managed Airflow (1ª gen. heredada)

En esta sección, se describe cómo crear, configurar y ejecutar un entorno local de Airflow con la herramienta de la CLI de desarrollo local de Composer.

Si, en cambio, quieres ejecutar un entorno de Managed Airflow con fines de desarrollo, considera crear un entorno en modo de desarrollo, que puedes hibernar cuando no lo uses.

Acerca de la herramienta de CLI de desarrollo local de Composer

La herramienta de la CLI de desarrollo local de Composer optimiza el desarrollo de DAG de Apache Airflow para Managed Airflow ejecutando un entorno de Airflow de forma local. Este entorno local de Airflow usa una imagen de Managed Airflow que utiliza una versión específica de Managed Airflow.

Puedes crear un entorno de Airflow local basado en un entorno de Managed Airflow existente. En este caso, el entorno local de Airflow toma la lista de paquetes de PyPI instalados y los nombres de las variable de entorno de tu entorno de Managed Airflow.

Puedes usar este entorno local de Airflow para realizar pruebas y desarrollo, como probar código de DAG nuevo, paquetes de PyPI o las opciones de configuración de Airflow.

Antes de comenzar

  • La herramienta de CLI de desarrollo local de Composer crea entornos locales de Airflow en un directorio en el que ejecutas el comando composer-dev create. Para acceder a tu entorno de Airflow local más adelante, ejecuta los comandos de la herramienta en la ruta de acceso en la que creaste inicialmente el entorno local. Todos los datos del entorno local se almacenan en un subdirectorio en la ruta de acceso en la que creaste el entorno local: ./composer/<local_environment_name>.

  • Tu computadora debe tener suficiente espacio en el disco para almacenar las imágenes de Managed Airflow. La herramienta de la CLI de Composer Local Development almacena un archivo de imagen para cada versión de Managed Airflow. Por ejemplo, si tienes dos entornos locales de Airflow con diferentes versiones de Managed Airflow, la herramienta de la CLI de Composer Local Development almacena dos imágenes de Managed Airflow.

  • La herramienta de CLI de desarrollo local de Composer usa un resultado con colores. Puedes inhabilitar el resultado con color con la variable NO_COLOR=1: NO_COLOR=1 composer-dev <other commands>.

  • Si solo tienes un entorno local, puedes omitir el nombre del entorno local en todos los comandos composer-dev, excepto en run-airflow-cmd.

  • Instala las dependencias de la herramienta de la CLI de desarrollo local de Composer:

  • Docker (Linux/macOS/Windows) o Podman (Linux o Windows) deben estar instalados y en ejecución en tu computadora.

    Para verificar que Docker o Podman se estén ejecutando, ejecuta cualquier comando de la CLI de Docker o de Podman, como docker ps o podman ps. Todas las instrucciones se aplican tanto a Docker como a Podman, a menos que se especifique lo contrario, y cualquier comando de Docker se puede reemplazar por comandos equivalentes de Podman.

Configura las credenciales

Si aún no lo hiciste, obtén credenciales de usuario nuevas para usarlas como credenciales predeterminadas de la aplicación:

gcloud auth application-default login

Accede a gcloud CLI con tu Cuenta de Google:

gcloud auth login

Todas las llamadas a la API que realizan la herramienta de la CLI de Composer Local Development y los DAG se ejecutan desde la cuenta que usas en gcloud CLI. Por ejemplo, si un DAG en tu entorno local de Airflow lee el contenido de un bucket de Cloud Storage, esta cuenta debe tener permisos para acceder al bucket. Esto es diferente de los entornos de Managed Airflow, en los que la cuenta de servicio de un entorno realiza las llamadas.

Instala la herramienta de la CLI de desarrollo local de Composer

Clona el repositorio de la CLI de desarrollo local de Composer:

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

En el directorio de nivel superior del repositorio clonado, ejecuta lo siguiente:

pip install .

Según tu configuración de pip, es posible que la ruta de acceso en la que se instala la herramienta no esté en la variable PATH. Si este es el caso, pip muestra un mensaje de advertencia. Puedes usar la información de este mensaje de advertencia para agregar este directorio a la variable PATH en tu sistema operativo.

(Podman) Configura Podman

Si usas Podman, sigue estos pasos para configurarlo:

Linux

  1. Habilita el socket del servicio de usuario de Podman.

    La CLI de composer-dev se comunica a través de llamadas a la API de Docker estándar. Debes activar el wrapper de socket del servicio en segundo plano de Podman a nivel del usuario para imitar el daemon de Docker.

    Primero, verifica si el socket a nivel de usuario ya está activo:

    systemctl --user is-active podman.socket

    Si el comando devuelve inactive o failed, habilita e inicia el socket:

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

  2. Configura las variables de entorno para Podman.

    Agrega el siguiente comando a tu archivo de configuración de shell (como .bashrc o .zshrc):

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

Windows

  1. Establece la configuración de WSL 2 (.wslconfig). Antes de inicializar tu máquina de Podman, verifica que WSL 2 tenga un límite de memoria y de intercambio definidos. Sin ella, las implementaciones de varios contenedores pueden causar picos de memoria durante la extracción de imágenes. También es importante establecer una restricción para el límite de descargas simultáneas.

    Cambia o crea el archivo %USERPROFILE%\.wslconfig:

    [wsl2]
memory=4GB
swap=2GB

[registry]
max_concurrent_downloads = 2

  2. En PowerShell, inicializa la máquina de Podman:

    podman machine init

  3. Inicia la máquina:

    podman machine start

Después de realizar estos pasos, puedes trabajar con los comandos de la CLI de composer-dev. La herramienta detecta automáticamente tu entorno de Podman en Windows y adapta las asignaciones de arquitectura.

Crea un entorno de Airflow local con una imagen de Managed Airflow

Para enumerar las imágenes de Managed Airflow disponibles, ejecuta el siguiente comando:

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

Para crear un entorno de Airflow local con parámetros predeterminados, ejecuta lo siguiente:

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

Otros parámetros:

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

Reemplaza lo siguiente:

  • LOCAL_ENVIRONMENT_NAME por el nombre de este entorno local de Airflow.
  • IMAGE_VERSION por el nombre de la imagen de Managed Airflow.
  • PROJECT_ID por el ID del proyecto.
  • WEB_SERVER_PORT por el puerto en el que debe escuchar el servidor web de Airflow.
  • LOCAL_DAGS_PATH por la ruta de acceso a un directorio local en el que se encuentran los archivos del DAG.
  • LOCAL_PLUGINS_PATH por la ruta de acceso a un directorio local en el que se encuentran los archivos del complemento.

  • DATABASE_ENGINE por el motor de base de datos que se usará. Los valores posibles son postgresql (predeterminado) y sqlite.

  • (Solo para Linux/macOS) EDITABLE_DEPENDENCY_PATH con la ruta de acceso a un directorio local que contenga un paquete de Python para instalar en modo editable. Este argumento no es compatible con Windows.

    Las rutas de acceso pueden ser absolutas o relativas (las rutas de acceso relativas se resuelven en función del directorio de trabajo actual). El motor de contenedores debe poder acceder a este directorio.

    Para especificar varios paquetes editables, repite la opción. Ejemplo: --editable-dependencies ./pkg1 --editable-dependencies ./pkg2.

    Cuando instalas los paquetes con pip install -e, se aplican de inmediato los cambios en estos paquetes dentro del proyecto.

Ejemplo:

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

Crea un entorno de Airflow local a partir de un entorno de Managed Airflow

Solo se toma la siguiente información de un entorno de Managed Airflow:

  • Son las versiones de Managed Airflow y Airflow que se usan en tu entorno.

  • Es la lista de paquetes de PyPI personalizados instalados en tu entorno.

  • Lista comentada de nombres de variables de entorno establecidas en tu entorno.

No se copian otros parámetros de información y configuración del entorno, como los archivos de DAG, el historial de ejecución de DAG, las variables de Airflow y las conexiones, desde tu entorno de Managed Airflow.

Para crear un entorno de Airflow local a partir de un entorno de Managed Airflow existente, sigue estos pasos:

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

Reemplaza lo siguiente:

  • LOCAL_ENVIRONMENT_NAME por un nombre para el entorno local de Airflow.
  • ENVIRONMENT_NAME por el nombre del entorno de Managed Airflow.
  • LOCATION por la región en la que se encuentra el entorno de Managed Airflow.
  • PROJECT_ID por el ID del proyecto.
  • WEB_SERVER_PORT por un puerto para el servidor web local de Airflow.
  • LOCAL_DAGS_PATH por una ruta de acceso a un directorio local en el que se encuentran los DAG.
  • LOCAL_PLUGINS_PATH por la ruta de acceso a un directorio local en el que se encuentran los archivos de los complementos.

  • DATABASE_ENGINE por el motor de base de datos que se usará. Los valores posibles son postgresql (predeterminado) y sqlite.

  • (Solo para Linux/macOS) EDITABLE_DEPENDENCY_PATH con la ruta de acceso a un directorio local que contenga un paquete de Python para instalar en modo editable. Este argumento no es compatible con Windows.

    Las rutas de acceso pueden ser absolutas o relativas (las rutas de acceso relativas se resuelven en función del directorio de trabajo actual). El motor de contenedores debe poder acceder a este directorio.

    Para especificar varios paquetes editables, repite la opción. Ejemplo: --editable-dependencies ./pkg1 --editable-dependencies ./pkg2.

    Cuando instalas los paquetes con pip install -e, se aplican de inmediato los cambios en estos paquetes dentro del proyecto.

Ejemplo:

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

Inicia un entorno de Airflow local

Para iniciar un entorno de Airflow local, ejecuta lo siguiente:

composer-dev start LOCAL_ENVIRONMENT_NAME

Reemplaza lo siguiente:

  • LOCAL_ENVIRONMENT_NAME por el nombre de un entorno de Airflow local.

Detén o reinicia un entorno local de Airflow

Cuando reinicias un entorno local de Airflow, la herramienta de la CLI de desarrollo local de Composer reinicia el contenedor de Docker en el que se ejecuta el entorno. Todos los componentes de Airflow se detienen y se vuelven a iniciar. Como resultado, todas las ejecuciones de DAG que se realizan durante un reinicio se marcan como fallidas .

Para reiniciar o iniciar un entorno de Airflow local detenido, ejecuta lo siguiente:

composer-dev restart LOCAL_ENVIRONMENT_NAME

Reemplaza lo siguiente:

  • LOCAL_ENVIRONMENT_NAME por el nombre de un entorno de Airflow local.

Para detener un entorno de Airflow local, ejecuta el siguiente comando:

composer-dev stop LOCAL_ENVIRONMENT_NAME

Agregar y actualizar DAG

Los DAG se almacenan en el directorio que especificaste en el parámetro --dags-path cuando creaste tu entorno local de Airflow. De forma predeterminada, este directorio es ./composer/<local_environment_name>/dags. Puedes obtener el directorio que usa tu entorno con el comando describe.

Para agregar y actualizar DAG, cambia los archivos de este directorio. No es necesario que reinicies tu entorno local de Airflow.

Consulta los registros del entorno de Airflow local

Puedes ver los registros recientes de un contenedor de Docker que ejecuta tu entorno local de Airflow. De esta manera, puedes supervisar los eventos relacionados con los contenedores y verificar los registros de Airflow en busca de errores, como conflictos de dependencias causados por la instalación de paquetes de PyPI.

Para ver los registros de un contenedor de Docker que ejecuta tu entorno local de Airflow, ejecuta el siguiente comando:

composer-dev logs LOCAL_ENVIRONMENT_NAME --max-lines 10

Para seguir el flujo de registros, omite el argumento --max-lines:

composer-dev logs LOCAL_ENVIRONMENT_NAME

Ejecuta un comando de la CLI de Airflow

Puedes ejecutar comandos de la CLI de Airflow en tu entorno local de Airflow.

Para ejecutar un comando de la CLI de Airflow, haz lo siguiente:

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

Ejemplo:

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

Configura entornos locales de Airflow

La herramienta de CLI de desarrollo local de Composer almacena los parámetros de configuración de un entorno de Airflow local, como las variables de entorno y los requisitos de paquetes de PyPI, en el directorio del entorno local (./composer/<local_environment_name>).

La configuración se aplica cuando se inicia un entorno local de Airflow. Por ejemplo, si agregas requisitos de paquetes de PyPI en conflicto, la herramienta de la CLI de Composer Local Development informa errores cuando inicias el entorno local.

Las conexiones de Airflow se almacenan en la base de datos del entorno local de Airflow. Puedes configurarlas ejecutando un comando de la CLI de Airflow o almacenando los parámetros de conexión en variables de entorno. Para obtener más información sobre las formas de crear y configurar conexiones, consulta Administra conexiones en la documentación de Airflow.

Obtén una lista y el estado de los entornos locales de Airflow

Para enumerar todos los entornos locales de Airflow disponibles y mostrar su estado, haz lo siguiente:

composer-dev list

Para describir un entorno específico y obtener detalles como la versión de la imagen, la ruta de acceso de los DAG y la URL del servidor web de un entorno, haz lo siguiente:

composer-dev describe LOCAL_ENVIRONMENT_NAME

Reemplaza lo siguiente:

  • LOCAL_ENVIRONMENT_NAME por el nombre del entorno local de Airflow.

Enumera las imágenes que usan los entornos locales de Airflow

Para enumerar todas las imágenes que usa la herramienta de la CLI de desarrollo local de Composer, ejecuta lo siguiente:

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

Instala complementos y cambia datos

Los complementos y los datos de un entorno local de Airflow se toman del directorio del entorno local: ./composer/<local_environment_name>/data y ./composer/<local_environment_name>/plugins).

Para cambiar el contenido de los directorios /data y /plugins, agrega o quita archivos en estos directorios. Docker propaga automáticamente los cambios de archivos a tu entorno local de Airflow.

La herramienta de la CLI de Composer Local Development no admite especificar un directorio diferente para los datos y los complementos.

Configure las variables de entorno

Para configurar las variables de entorno, edita el archivo variables.env en el directorio del entorno: ./composer/<local_environment_name>/variables.env.

El archivo variables.env debe contener definiciones de clave-valor, una línea para cada variable de entorno. Para cambiar las opciones de configuración de Airflow, usa el formato AIRFLOW__SECTION__KEY. Para obtener más información sobre las variables de entorno disponibles, consulta la referencia de configuración de Airflow.

EXAMPLE_VARIABLE=True
ANOTHER_VARIABLE=test
AIRFLOW__WEBSERVER__DAG_DEFAULT_VIEW=graph

Para aplicar los cambios, reinicia tu entorno local de Airflow.

Instala o quita paquetes de PyPI

Para instalar o quitar paquetes de PyPI, modifica el archivo requirements.txt en el directorio del entorno: ./composer/<local_environment_name>/requirements.txt.

Los requisitos deben seguir el formato especificado en PEP-508, en el que cada requisito se especifica en minúsculas y consta del nombre del paquete con extras opcionales y especificadores de versión.

Para aplicar los cambios, reinicia tu entorno local de Airflow.

Cambia a una imagen de Managed Airflow diferente

Puedes usar cualquier imagen de Managed Airflow con la herramienta de la CLI de Composer Local Development y cambiar entre las imágenes. Este enfoque es diferente de actualizar tu entorno de Managed Airflow, ya que los parámetros de configuración de tu entorno local de Airflow se aplican cuando se inicia.

Por ejemplo, después de que se lance una nueva versión de Managed Airflow, puedes cambiar tu entorno para usarla y mantener la configuración existente del entorno local de Airflow. Como otro ejemplo, puedes cambiar entre diferentes versiones de Airflow dentro de una versión específica de Managed Airflow.

Para cambiar la imagen del entorno que usa tu entorno local de Airflow, sigue estos pasos:

  1. Edita el archivo de configuración del entorno local: ./composer/<local_environment_name>/config.json.

  2. Cambia el valor del parámetro composer_image_version. Para ver los valores disponibles, puedes enumerar las imágenes disponibles.

  3. Para aplicar los cambios, reinicia tu entorno local de Airflow.

Borra un entorno de Airflow local

Precaución: Asegúrate de haber guardado todos los datos necesarios del entorno, como los registros y la configuración.

Para borrar un entorno local de Airflow, ejecuta el siguiente comando:

composer-dev remove LOCAL_ENVIRONMENT_NAME

Si el entorno se está ejecutando, agrega la marca --force para forzar su eliminación.

Borra imágenes de Docker

Para borrar todas las imágenes descargadas por la herramienta de la CLI de desarrollo local de Composer, ejecuta lo siguiente:

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

Configuración adicional y solución de problemas

En esta sección, se proporcionan soluciones a problemas habituales y pasos de configuración adicionales para configurar la interacción de la herramienta de la CLI de Composer Local Development con otras herramientas y servicios.

Completado de línea de comandos de shell

La CLI de composer-dev admite el completado de línea de comandos para las shells de Bash, Zsh y Fish. Puedes usar el completado de línea de comandos para descubrir los subcomandos y las opciones disponibles sin consultar el texto de ayuda.

Zsh

Genera la secuencia de comandos de finalización y agrégala a tu ~/.zshrc:

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

Luego, agrégala a tu ~/.zshrc:

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

Bash

Genera la secuencia de comandos de finalización y agrégala a tu ~/.bashrc:

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

Luego, agrégala a tu ~/.bashrc:

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

Pescado

Genera la secuencia de comandos de finalización y guárdala en el directorio de finalizaciones de Fish:

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

Interactúa con clústeres de Kubernetes

De forma predeterminada, el archivo ~/.kube/config no está activado. Puedes especificar la ruta de acceso al archivo de configuración de Kubernetes exportando la variable de entorno KUBECONFIG antes de iniciar el entorno.

export KUBECONFIG=~/.kube/config

Interactúa con otros servicios en la máquina anfitrión

La localhost en un entorno de Managed Airflow apunta al contenedor en sí, no a la máquina anfitrión, debido a cómo funciona la red en los contenedores de Docker o Podman. Para mayor comodidad, la herramienta de la CLI de composer-dev configura la red del contenedor para acceder a la máquina a través del alias de dominio host.docker.internal. Ejemplos:

  • Redis: Usa host.docker.internal:6379 en lugar de localhost:6379 si Redis se ejecuta en el puerto 6379.
  • PostgreSQL: Usa host.docker.internal:25432 en lugar de localhost:25432 si PostgreSQL se ejecuta en el puerto 25432.
  • Cualquier otro servicio: Sigue este patrón: host.docker.internal:<PORT>

No se puede iniciar un entorno local en macOS

Si instalaste el paquete composer-dev en un directorio al que Docker no puede acceder, es posible que tu entorno local no se inicie.

Por ejemplo, si Python se instala en el directorio /opt, como cuando lo instalas con la configuración predeterminada de Homebrew en macOS, el paquete composer-dev también se instala en el directorio /opt. Debido a que Docker cumple con las reglas de la zona de pruebas de Apple, el directorio /opt no está disponible de forma predeterminada. Además, no puedes agregarlo a través de la IU (Configuración > Recursos > Uso compartido de archivos).

En este caso, la herramienta de la CLI de Composer Local Development genera un mensaje de error similar al siguiente ejemplo:

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

Puedes usar una de las siguientes soluciones:

  • Instala Python o el paquete composer-dev en un directorio diferente para que Docker pueda acceder al paquete.
  • Edita manualmente el archivo ~/Library/Group\ Containers/group.com.docker/settings.json y agrega /opt a filesharingDirectories.

Acceso del usuario del contenedor a los archivos y directorios activados desde el host

De forma predeterminada, el contenedor del entorno de Managed Airflow se ejecuta como el usuario airflow con el UID 999. El usuario debe tener acceso a los archivos y directorios activados desde el host, por ejemplo, ~/.config/gcloud/application_default_credentials.json.

Problemas conocidos:

  • google.auth.exceptions.DefaultCredentialsError: Your default credentials were not found: Se puede generar cuando se ejecuta el contenedor con el usuario predeterminado airflow (999) y el directorio del host ~/.config/gcloud/ no tiene el permiso de ejecución para el usuario.
  • [Errno 13] Permission denied: '/home/airflow/.config/gcloud/application_default_credentials.json': Se puede generar cuando ejecutas el contenedor con el usuario predeterminado airflow (999) y el archivo hosts ~/.config/gcloud/application_default_credentials.json no tiene el permiso de lectura para el usuario.

En Linux o macOS, se recomienda que ejecutes el contenedor como el usuario actual del host agregando COMPOSER_CONTAINER_RUN_AS_HOST_USER=True a composer/<LOCAL_ENVIRONMENT_NAME>/variables.env.Esta función no está disponible en Windows, por lo que es posible que debas actualizar los permisos de los archivos y directorios activados en el host para permitir el acceso del usuario dentro del contenedor.

(Podman) Corrige los errores de permisos o lchown para los usuarios corporativos

Para evitar que Podman sin raíz asigne automáticamente espacios de nombres de usuario que se superpongan con tu ID de usuario corporativo principal (lo que causa errores de lchown: invalid argument o de permisos), debes enviar de forma manual tus rangos subordinados por encima del bloque de 4 millones.

  1. Abre /etc/subuid y /etc/subgid con privilegios de raíz (por ejemplo: sudo nano /etc/subuid).

  2. Actualiza o agrega tu entrada de nombre de usuario para que se vea exactamente así:

    YOUR_USERNAME:4000000:3000000

  3. Guarda ambos archivos y ejecuta lo siguiente para aplicar las nuevas reglas de asignación de espacios de nombres a Podman:

    podman system migrate

(Podman) Quita archivos bloqueados y errores de denegación de permisos

Si actualizaste tus rangos de subuid mientras existían contenedores antiguos, se bloqueará el acceso de tu espacio de nombres actual a su propia caché de datos.

Borra de forma forzosa el gráfico de almacenamiento local con privilegios de raíz a nivel del host:

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

(Podman) Corrige las fallas de DNS ("Name or service not known")

Si tu contenedor de Airflow genera un psycopg2.OperationalError que indica que no puede traducir ni resolver el nombre de host del contenedor de la base de datos (your-environment-name), la red de puente virtual interna de Podman no está sincronizada.

Vacía los estados del entorno de ejecución y fuerza a netavark y aardvark-dns a volver a generar tablas de enrutamiento limpias.

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 el estado de tu motor

Para verificar que Podman administre tu flujo de trabajo sin raíz y no omita tu configuración en Docker del sistema, haz lo siguiente:

  1. Verifica el backend de DNS de la red:

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

    El resultado debe contener backend: netavark y una ruta de acceso ejecutable válida a aardvark-dns.

  2. Verificar la asignación de propiedad de los procesos Con tu entorno en ejecución, verifica el propietario del proceso del host:

    ps -ef | grep -i "postgres"

    La columna de la izquierda debería mostrar un número de UID alto (como 4000069) que corresponda al rango de asignación de subuid, lo que demuestra que se ejecuta por completo sin raíz.

(Podman, Windows) Corrige errores de canalización durante la implementación

Si la base de datos o el contenedor de Airflow se cierran de inmediato con errores de canalización durante la implementación, es posible que Podman esté alcanzando un límite de memoria. Para solucionarlo, puedes intentar aumentar los límites de memoria y de intercambio en el archivo .wslconfig:

  1. Detén tu máquina de Podman y la máquina virtual de WSL 2 ejecutando el siguiente comando en PowerShell:

    podman machine stop
wsl --shutdown

  2. Realiza cambios en el archivo %USERPROFILE%\.wslconfig para adaptar los límites de intercambio y memoria. Para obtener más información, consulta la referencia de configuración de WSL.

  3. Ejecuta el siguiente comando para iniciar tu máquina de Podman:

    podman machine start

Si encuentras errores, puedes intentar restablecer por completo la pila de red y virtualización de Windows. Para ello, abre PowerShell como administrador y ejecuta lo siguiente:

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

¿Qué sigue?