FerroAir
Orquestador compatible con Apache Airflow 3.x
Orquestador de workflows autogestionado que ejecutas en tus propias instancias Amazon EC2: un único binario Rust estático que implementa scheduler, webserver, REST API v2, triggerer y procesador de DAG de Apache Airflow 3.x. Es compatible a nivel wire con la superficie REST API v2 de Apache Airflow 3.0 / 3.1 / 3.2 y la interfaz de ejecución de tareas AIP-72, y los cuerpos de las tareas siguen ejecutándose en CPython mediante airflow.sdk.
FerroAir ejecuta workloads Apache Airflow 3.x en tu propio EC2 (Apache Airflow es un proyecto open-source, no un servicio de AWS). Sirve una web UI real (una single-page app Leptos, sin runtime Node) en el puerto 8080 (vistas DAG list, graph, grid, gantt, calendar y task-log), un puerto de métricas y administración 9080 con métricas Prometheus y probes health / live / ready, y AIP-72 en el puerto 8081. Sincroniza DAGs desde Amazon S3, almacena metadatos en PostgreSQL o SQLite y ejecuta un scheduler HA con leader election. Scheduler, webserver, triggerer y procesador de DAG se unifican en un binario estático bajo una unidad systemd endurecida — en lugar de un despliegue Python multiproceso.
El problema
Apache Airflow es un excelente orquestador de flujos de trabajo de código abierto (no es un servicio de AWS), pero el despliegue habitual ejecuta el scheduler, el webserver, el triggerer y el procesador de DAG como varios procesos de Python, lo que resulta operativamente pesado de gestionar. Los equipos terminan ensamblando y manteniendo a mano una pila multiproceso — base de datos de metadatos, broker y workers. La necesidad consiste en mantener la compatibilidad con Airflow a la vez que se simplifica la ejecución de la capa de orquestación.
Cómo funciona
- 1
Se ejecuta como un único binario de Rust
FerroAir implementa el scheduler, el webserver, la API REST v2, el triggerer y el procesador de DAG de Apache Airflow 3.x en un único binario estático de Rust, que se ejecuta de forma unificada bajo una unidad de systemd endurecida. Se ejecuta en sus propias instancias de Amazon EC2 en lugar de en un despliegue de Python multiproceso.
- 2
Las tareas se siguen ejecutando en CPython
FerroAir gestiona en Rust el bucle de ticks del scheduler, el monitor de la carpeta de DAG, la API REST, el acceso a los metadatos, la elección de líder y el despacho del executor. El cuerpo de las tareas se sigue ejecutando en CPython a través del airflow.sdk upstream sobre la interfaz de ejecución de tareas AIP-72 de Apache Airflow.
- 3
Se conecta con su estado existente
Los DAG se sincronizan desde un bucket de Amazon S3 (o disco local) y los metadatos se almacenan en PostgreSQL o SQLite. La interfaz web se sirve en el puerto 8080, las métricas y sondas de Prometheus en el puerto 9080, y AIP-72 en el puerto 8081.
Características destacadas
Compatible con Airflow 3.x: REST API v2 + AIP-72; los cuerpos de las tareas siguen ejecutándose en CPython mediante airflow.sdk.
Un binario Rust estático (scheduler + webserver + triggerer + procesador de DAG) en lugar de un despliegue Python multiproceso; una web UI Leptos real (sin Node).
Los DAGs se sincronizan desde S3, metadatos en PostgreSQL / SQLite, scheduler HA con leader election; CloudFormation Quick Start incluido.
Qué incluye
- AMI de Amazon Linux 2023 (x86_64, se ejecuta en instancias de las clases c7i / m7i)
- Un único binario estático de Rust que implementa el scheduler, el webserver, la API REST v2, el triggerer y el procesador de DAG de Apache Airflow 3.x (compatible a nivel de protocolo con la interfaz de la API REST v2 de Apache Airflow 3.0/3.1/3.2 y la interfaz de ejecución de tareas AIP-72)
- Una interfaz web real construida como una aplicación de página única de Leptos (sin runtime de Node, puerto 8080) con vistas de lista de DAG, grafo, cuadrícula, Gantt, calendario y logs de tareas
- Un puerto dedicado de administración y métricas 9080 (métricas de Prometheus más sondas de health, live y ready) y el puerto 8081 de AIP-72 para el worker de Python
- Sincronización de DAG desde Amazon S3, metadatos en PostgreSQL o SQLite (esquema compatible con Alembic de Apache Airflow 3) y un scheduler de alta disponibilidad (HA) con failover mediante elección de líder
- Una herramienta de importación para conexiones, variables y pools de un despliegue gestionado existente de Apache Airflow, más documentación poscompra con el runbook, la matriz de compatibilidad y la validación
- Sin plano de control independiente, sin llamadas de telemetría salientes y sin verificación de clave de licencia (facturado por hora de instancia a través de su factura de AWS, con una opción anual)
Casos de uso
Ejecución de flujos de trabajo de Apache Airflow en su propio Amazon EC2 como un único binario operativamente más simple
Equipos que migran su capa de orquestación desde un despliegue gestionado de Apache Airflow importando conexiones, variables y pools
Cargas de trabajo existentes que necesitan seguir funcionando con sus clientes de la API REST v2 de Apache Airflow
Ejecución de un orquestador completamente dentro de su propia VPC, sin plano de control independiente y sin llamadas de telemetría salientes
Preguntas frecuentes
¿Qué nivel de compatibilidad tiene con Apache Airflow?
FerroAir es compatible a nivel de protocolo con la interfaz de la API REST v2 de Apache Airflow 3.0, 3.1 y 3.2 y la interfaz de ejecución de tareas AIP-72 de Apache Airflow. Debido a que se implementa la interfaz de la API REST v2, se admiten los clientes existentes de la API REST v2 de Apache Airflow. Consulte la documentación del producto para ver la matriz de compatibilidad completa.
¿Sigue ejecutándose el código Python de mi tarea?
Sí. Los cuerpos de las tareas se siguen ejecutando en CPython a través de airflow.sdk upstream sobre la interfaz de ejecución de tareas Apache Airflow AIP-72. El binario en Rust gestiona el bucle de ticks del planificador, el monitor de la carpeta de DAG, la REST API, el acceso a metadatos, la elección de líder y el despacho del ejecutor — el propio entorno de ejecución de tareas sigue siendo CPython.
¿Es esto un reemplazo para un servicio de AWS?
Apache Airflow es un proyecto de código abierto y no es un servicio de AWS. FerroAir es un orquestador de flujos de trabajo autogestionado que ejecuta esas cargas de trabajo de Apache Airflow 3.x en sus propias instancias de Amazon EC2. Se distribuye como una AMI normal de Amazon Linux 2023 que se ejecuta dentro de su propia VPC.
¿Puedo migrar desde un despliegue de Airflow existente?
Sí. FerroAir puede importar conexiones, variables y pools desde un despliegue de Apache Airflow gestionado existente y sincronizar su carpeta de DAG. Los metadatos se almacenan en PostgreSQL o SQLite utilizando un esquema de Apache Airflow 3 compatible con Alembic. La documentación posterior a la compra en la AMI le guiará a través de la herramienta de importación, el runbook, la matriz de compatibilidad y la validación.
¿Cómo funcionan la HA y la gestión de secretos?
El planificador de HA realiza el failover mediante elección de líder (openraft); ejecute varias instancias y la elección de líder promoverá un standby. Los secretos se resuelven desde el entorno, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault o Vault, y las conexiones y variables se cifran con Fernet. La autenticación es compatible con FAB auth, OAuth, OIDC, SAML y LDAP.
Modelo de precios
Tarifa horaria de software + EC2 (clase c7i / m7i, x86). Medición por tipo de instancia, opción anual disponible.
Otros productos S4
S4 — Squished S3
Gateway transparente de compresión S3 con GPU
S4 Logs
Archiva CloudWatch Logs en S3 con zstd
S4 Metrics
Gobierna la cardinalidad de métricas de CloudWatch