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

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

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

Acerca de la herramienta de CLI de desarrollo local de Composer

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

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 desarrollar, por ejemplo, para probar código de DAG nuevo, paquetes de PyPI o opciones de configuración de Airflow.

Antes de comenzar

  • La herramienta de CLI de desarrollo local de Composer admite compilaciones de Airflow 3 de la siguiente manera:

    • Airflow 3.3.1 y las versiones posteriores son compatibles a partir de composer-3-airflow-3.3.1-build.0.
    • Airflow 3.2.2 es compatible a partir de composer-3-airflow-3.2.2-build.3.
    • No se admite Airflow 3.1.8.
    • Las compilaciones anteriores de Airflow 3 se admiten a partir de composer-3-airflow-3.1.0-build.8.

  • 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 local de Airflow 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 imágenes de compilación de Airflow. La herramienta de CLI de desarrollo local de Composer almacena un archivo de imagen para cada compilación de Airflow. Por ejemplo, si tienes dos entornos locales de Airflow con diferentes compilaciones de Airflow, la herramienta de CLI de Composer Local Development almacena dos imágenes de compilación de Airflow.

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

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

  • Instala las dependencias de la herramienta de 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 la CLI 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 usar con las 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 CLI de desarrollo local de Composer 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 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 el siguiente comando:

pip install .

Según la configuración de pip, es posible que la ruta en la que se instala la herramienta no esté en la variable PATH. Si es así, pip mostrará 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 del socket del servicio en segundo plano de Podman a nivel del usuario para simular el daemon de Docker.

    Primero, verifica si el socket a nivel del 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. Configura 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 él, las implementaciones de varios contenedores pueden provocar 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 seguir estos pasos, podrás 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 local de Airflow con una imagen de compilación de Airflow

Para enumerar las imágenes de compilación de Airflow disponibles, ejecuta el siguiente comando:

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

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

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 compilación de Airflow.
  • PROJECT_ID por el ID del proyecto.
  • WEB_SERVER_PORT con el puerto en el que debe escuchar el servidor web de Airflow.
  • LOCAL_DAGS_PATH con la ruta de acceso a un directorio local en el que se encuentran los archivos DAG.
  • LOCAL_PLUGINS_PATH con la ruta de acceso a un directorio local en el que se encuentran los archivos del complemento.

  • DATABASE_ENGINE con 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 contiene 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 relativas se resuelven en relación con el 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.

    La instalación de los paquetes con pip install -e aplica los cambios de inmediato a estos paquetes dentro del proyecto.

Ejemplo:

composer-dev create \
  --from-image-version composer-3-airflow-2.11.1-build.18 \
  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:

  • Es la compilación específica de Airflow que usa tu entorno.

  • Lista de paquetes personalizados de PyPI instalados en tu entorno.

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

No se copian otros parámetros de configuración e información del entorno, como los archivos 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 local de Airflow a partir de un entorno existente de Managed Airflow, haz lo siguiente:

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 con un puerto para el servidor web de Airflow local.
  • LOCAL_DAGS_PATH con una ruta de acceso a un directorio local en el que se encuentran los DAGs
  • LOCAL_PLUGINS_PATH con la ruta de acceso a un directorio local en el que se encuentran los archivos de complementos.

  • DATABASE_ENGINE con 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 contiene 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 relativas se resuelven en relación con el 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.

    La instalación de los paquetes con pip install -e aplica los cambios de inmediato a 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 local de Airflow

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

composer-dev start LOCAL_ENVIRONMENT_NAME

Reemplaza lo siguiente:

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

Cómo detener o reiniciar un entorno local de Airflow

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

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

composer-dev restart LOCAL_ENVIRONMENT_NAME

Reemplaza lo siguiente:

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

Para detener un entorno local de Airflow, 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 DAGs, cambia los archivos en este directorio. No es necesario que reinicies tu entorno local de Airflow.

Consulta los registros del entorno local de Airflow

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 el contenedor 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 registro, 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 parámetros de configuración para un entorno local de Airflow, como variables de entorno y 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 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 configurarlos 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 Administración de 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 CLI de desarrollo local de Composer, ejecuta el siguiente comando:

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 ellos. Docker propaga automáticamente los cambios en los archivos a tu entorno local de Airflow.

La herramienta de CLI de desarrollo local de Composer no admite la especificación de 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, donde 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.

Cómo cambiar a otra imagen de compilación de Airflow

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

Por ejemplo, después de que se lanza una nueva compilación de Airflow, puedes cambiar tu entorno para que la use y conservar la configuración existente del entorno local de Airflow.

Para cambiar la imagen del entorno que usa tu entorno local de Airflow, haz lo siguiente:

  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 listar las imágenes disponibles.

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

Borra un entorno local de Airflow

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 CLI de desarrollo local de Composer, ejecuta el siguiente comando:

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

Configuración y solución de problemas adicionales

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

Autocompletado de pestañas de Shell

La CLI de composer-dev admite el autocompletado con tabulador para los shells de Bash, Zsh y Fish. Puedes usar la función de completar con tabulador para descubrir los subcomandos y las opciones disponibles sin consultar el texto de ayuda.

Zsh

Genera la secuencia de comandos de finalización y ejecútala en tu ~/.zshrc:

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

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

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

Bash

Genera la secuencia de comandos de finalización y ejecútala en tu ~/.bashrc:

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

Luego, agrégalo 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

Cómo interactuar con clústeres de Kubernetes

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

export KUBECONFIG=~/.kube/config

Interacción con otros servicios en la máquina anfitrión

El 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 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 está instalado 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. Dado que Docker cumple con las reglas de 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 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 que se hayan activado 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 del host ~/.config/gcloud/application_default_credentials.json no tiene permiso de lectura para el usuario.

En Linux o macOS, se recomienda que ejecutes el contenedor como el usuario host actual 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 montados en el host para permitir el acceso del usuario dentro del contenedor.

(Podman) Se corrigieron 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 provoca errores de lchown: invalid argument o de permisos), debes enviar manualmente tus rangos subordinados por encima del bloque de 4 millones.

  1. Abre /etc/subuid y /etc/subgid con privilegios de administrador (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 el siguiente comando para aplicar las nuevas reglas de asignación de espacios de nombres a Podman:

    podman system migrate

(Podman) Cómo quitar archivos atascados y resolver 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 a la fuerza el gráfico de almacenamiento local con privilegios de administrador a nivel del host:

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

(Podman) Soluciona errores de DNS ("Name or service not known")

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

Vacía los estados de tiempo de ejecución y fuerza a netavark y aardvark-dns a regenerar 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 del motor

Para verificar que Podman esté administrando tu flujo de trabajo sin privilegios de administrador y que no esté omitiendo tu configuración en el 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. Verifica la asignación de la propiedad del proceso. Con tu entorno en ejecución, verifica el propietario del proceso host:

    ps -ef | grep -i "postgres"

    La columna más a la izquierda debe mostrar un número de UID alto (como 4000069) que corresponda a tu rango de mapa de subUID, lo que demuestra que se ejecuta completamente sin privilegios de administrador.

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

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

  1. Para detener tu máquina de Podman y tu máquina virtual de WSL 2, ejecuta el siguiente comando en PowerShell:

    podman machine stop
wsl --shutdown

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

  3. Para iniciar tu máquina de Podman, ejecuta el siguiente comando:

    podman machine start

Si encuentras errores, puedes intentar restablecer por completo la pila de virtualización y redes 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?