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 para 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 CLI de desarrollo local de Composer optimiza el desarrollo de DAG de Apache Airflow para Managed Airflow, ya que ejecuta un entorno de Airflow de forma local. Este entorno local de Airflow usa una imagen de Managed 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.

Advertencia: Usa entornos locales de Airflow solo para pruebas y desarrollo. Managed Airflow no admite el uso de imágenes de Managed Airflow implementadas de forma local para fines de producción.

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 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 las imágenes de Managed Airflow. La herramienta de CLI de desarrollo local de Composer 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 CLI de Composer Local Development almacena dos imágenes de Managed Airflow.

• La herramienta de CLI de desarrollo local de Composer usa resultados 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 su nombre 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:

  • Versiones de Python de 3.8 a 3.11 con pip
  • Google Cloud CLI

• Docker (Linux/macOS/Windows) o Podman (Linux o Windows) deben estar instalados y ejecutándose 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 de Podman equivalentes.

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 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 CLI de desarrollo local de Composer

Clona el repositorio de la herramienta de 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 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 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, 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 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 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 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 DAG.
• LOCAL_PLUGINS_PATH con 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.

  Nota: Si quieres usar LocalExecutor como ejecutor principal de Airflow, establece DATABASE_ENGINE en postgresql. Esto es necesario para que el LocalExecutor funcione correctamente.

• (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 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.

  Instalar los paquetes con pip install -e aplica de inmediato los cambios a estos paquetes dentro del proyecto.

Ejemplo:

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

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

Precaución: La herramienta de CLI de desarrollo local de Composer no produce una copia local de tu 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.

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

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

  Importante: Managed Airflow no copia los valores de las variables de entorno. Puedes quitar los comentarios de las variables de entorno de forma manual en el archivo de configuración y establecer sus valores, según sea necesario.

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, no se copian desde tu entorno de Managed Airflow.

Para crear un entorno de Airflow local a partir de un entorno de Managed Airflow existente, 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 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 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.

  Nota: Si quieres usar LocalExecutor como ejecutor principal de Airflow, establece DATABASE_ENGINE en postgresql. Esto es necesario para que el LocalExecutor funcione correctamente.

• (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 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.

  Instalar los paquetes con pip install -e aplica de inmediato los cambios 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 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 Composer Local Development 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 ejecutan durante un reinicio se marcan como con errores .

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 de Airflow local.

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

composer-dev stop LOCAL_ENVIRONMENT_NAME

Nota: El comando stop no borra el entorno local de Airflow.

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

Nota: La herramienta de CLI de desarrollo local de Composer no escribe registros de tareas ni de ejecuciones de DAG en archivos. Puedes ver estos registros en la IU de Airflow de tu entorno local de Airflow.

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.

Nota: La sintaxis del comando es diferente de la sintaxis de Google Cloud CLI para los comandos de la CLI 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 la CLI de Composer Local Development informa errores cuando inicias el entorno local.

Importante: La herramienta de la CLI de Composer Local Development no almacena el archivo airflow.cfg en este directorio. Este archivo se encuentra en la imagen de Docker del entorno. Puedes cambiar las opciones de configuración de Airflow configurando las variables de entorno.

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/*/*'

Instalar complementos y cambiar 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 desarrollo local de Composer 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.

Precaución: Como medida de seguridad, los valores de las variables de entorno no se copian de tu entorno de Managed Airflow, y la lista de nombres de variables se comenta. Por ejemplo, es posible que desees especificar valores diferentes para que tus DAG no interactúen con tus entornos de producción o para omitir la configuración de algunas de las variables.

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.

Cómo cambiar a otra imagen de Managed Airflow

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 al de actualizar 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 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 alternar 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, 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 Composer Local Development, ejecuta el siguiente comando:

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

Completado con tabulador 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 autocompletado con la tecla Tab 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 agrégala a 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

Interactúa 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 exportando 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

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 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>

Nota: Si ejecutas tu servicio de destino dentro de otro contenedor de Docker, asegúrate de que el puerto también esté expuesto a la máquina host.

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 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 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 privilegios de administrador 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.

Advertencia: Si ejecutas el siguiente comando, se quitarán todos tus volúmenes. Ten cuidado si tienes otro trabajo almacenado.

Borra por la fuerza 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) Soluciona errores de DNS ("Name or service not known")

Si tu contenedor de Airflow genera un mensaje 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 del entorno de ejecución y fuerza a netavark y aardvark-dns a volver a generar tablas de enrutamiento limpias.

Advertencia: Los siguientes comandos quitarán todas las redes. Ten cuidado si tienes otro trabajo almacenado.

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 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 que se encuentra más a 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 los 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. 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 los 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?

• Escribir DAG
• Prueba, sincroniza y, luego, implementa tus DAG desde GitHub