FerroAir
Orchestrateur compatible Apache Airflow 3.x
Un orchestrateur de workflows autogéré que vous exécutez sur vos propres instances Amazon EC2 : un binaire Rust statique unique qui implémente le scheduler, le webserver, la REST API v2, le triggerer et le processeur DAG d’Apache Airflow 3.x. Il est compatible filaire avec la surface REST API v2 d’Apache Airflow 3.0 / 3.1 / 3.2 et l’interface d’exécution de tâches AIP-72, tandis que les corps de tâches continuent de s’exécuter sur CPython via airflow.sdk.
FerroAir exécute les workloads Apache Airflow 3.x sur votre propre EC2 (Apache Airflow est un projet open-source, pas un service AWS). Il sert une vraie web UI (une single-page app Leptos, sans runtime Node) sur le port 8080 (vues DAG list, graph, grid, gantt, calendar et task-log), un port metrics & admin 9080 avec des métriques Prometheus et des probes health / live / ready, ainsi qu’AIP-72 sur le port 8081. Il synchronise les DAG depuis Amazon S3, stocke les métadonnées dans PostgreSQL ou SQLite, et exécute un scheduler HA avec leader election. Le scheduler, le webserver, le triggerer et le processeur DAG sont unifiés dans un binaire statique sous une unité systemd durcie — au lieu d’un déploiement Python multi-processus.
Le problème
Apache Airflow est un excellent orchestrateur de flux de travail open-source (ce n'est pas un service AWS), mais le déploiement habituel exécute le scheduler, le webserver, le triggerer et le processeur de DAG sous la forme de plusieurs processus Python, ce qui est lourd à gérer sur le plan opérationnel. Les équipes finissent par assembler et maintenir manuellement une stack multi-processus — base de données de métadonnées, broker et workers. Le besoin est de maintenir la compatibilité avec Airflow tout en simplifiant l'exécution de la couche d'orchestration.
Fonctionnement
- 1
S'exécute sous la forme d'un unique binaire Rust
FerroAir implémente le scheduler, le webserver, l'API REST v2, le triggerer et le processeur de DAG d'Apache Airflow 3.x dans un unique binaire Rust statique, fonctionnant de manière unifiée sous une unité systemd sécurisée. Il s'exécute sur vos propres instances Amazon EC2 au lieu d'un déploiement Python multi-processus.
- 2
Les tâches s'exécutent toujours sur CPython
FerroAir gère en Rust la boucle de tick du scheduler, la surveillance du dossier DAG, l'API REST, l'accès aux métadonnées, l'élection du leader et le dispatch de l'exécuteur. Le corps des tâches continue de s'exécuter sur CPython via le sdk airflow.sdk amont sur l'interface d'exécution de tâches Apache Airflow AIP-72.
- 3
S'intègre à votre état existant
Les DAG se synchronisent depuis un bucket Amazon S3 (ou un disque local) et les métadonnées sont stockées dans PostgreSQL ou SQLite. L'interface web est servie sur le port 8080, les métriques et sondes Prometheus sur le port 9080, et AIP-72 sur le port 8081.
Points forts
Compatible Airflow 3.x : REST API v2 + AIP-72 ; les corps de tâches continuent de s’exécuter sur CPython via airflow.sdk.
Un binaire Rust statique (scheduler + webserver + triggerer + processeur DAG) au lieu d’un déploiement Python multi-processus ; une vraie web UI Leptos (sans Node).
Les DAG se synchronisent depuis S3, métadonnées dans PostgreSQL / SQLite, scheduler HA avec leader election ; CloudFormation Quick Start inclus.
Ce qui est inclus
- AMI Amazon Linux 2023 (x86_64, s'exécute sur des instances de classe c7i / m7i)
- Un binaire Rust statique unique implémentant le scheduler, le webserver, l'API REST v2, le triggerer et le processeur de DAG d'Apache Airflow 3.x (compatible au niveau réseau avec la surface de l'API REST v2 d'Apache Airflow 3.0/3.1/3.2 et l'interface d'exécution de tâches AIP-72)
- Une véritable interface web construite comme une application monopage Leptos (sans runtime Node, port 8080) avec des vues liste de DAG, graphe, grille, gantt, calendrier et logs de tâches
- Un port dédié aux métriques et à l'administration 9080 (métriques Prometheus plus sondes de santé health, live et ready) et le port AIP-72 8081 pour le worker Python
- Synchronisation des DAG depuis Amazon S3, métadonnées PostgreSQL ou SQLite (schéma compatible Alembic Apache Airflow 3) et un scheduler HA avec basculement par élection de leader
- Un outil d'importation des connexions, variables et pools depuis un déploiement Apache Airflow managé existant, ainsi que la documentation après-achat comprenant le runbook, la matrice de compatibilité et les procédures de validation
- Pas de plan de contrôle séparé, pas d'appel de télémétrie vers l'extérieur (home-call), et pas de vérification de clé de licence (facturation par instance et par heure via votre facture AWS, avec une option annuelle)
Cas d'usage
L'exécution de flux de travail Apache Airflow sur vos propres instances Amazon EC2 sous la forme d'un binaire unique et plus simple à exploiter
Les équipes migrant leur couche d'orchestration depuis un déploiement Apache Airflow managé en important les connexions, les variables et les pools
Les workloads existants devant continuer à fonctionner avec leurs clients d'API REST v2 Apache Airflow
L'exécution d'un orchestrateur entièrement au sein de votre propre VPC, sans plan de contrôle séparé ni appel de télémétrie vers l'extérieur
FAQ
Dans quelle mesure est-il compatible avec Apache Airflow ?
FerroAir est compatible au niveau réseau avec la surface de l'API REST v2 d'Apache Airflow 3.0, 3.1 et 3.2 ainsi qu'avec l'interface d'exécution de tâches Apache Airflow AIP-72. Du fait de l'implémentation de la surface de l'API REST v2, les clients de l'API REST v2 d'Apache Airflow existants sont pris en charge. Consultez la documentation du produit pour obtenir la matrice de compatibilité complète.
Mon code de tâche Python s'exécute-t-il toujours ?
Oui. Les corps de tâche continuent de s'exécuter sur CPython via l'airflow.sdk en amont sur l'interface d'exécution de tâche Apache Airflow AIP-72. Le binaire Rust gère la boucle de tick du scheduler, la surveillance du dossier DAG, l'API REST, l'accès aux métadonnées, l'élection du leader et le dispatch de l'exécuteur — le runtime d'exécution de tâche lui-même reste CPython.
S'agit-il d'un remplacement pour un service AWS ?
Apache Airflow est un projet open-source et n'est pas un service AWS. FerroAir est un orchestrateur de workflow autogéré qui exécute ces workloads Apache Airflow 3.x sur vos propres instances Amazon EC2. Il est fourni sous la forme d'une AMI Amazon Linux 2023 normale que vous exécutez dans votre propre VPC.
Puis-je migrer depuis un déploiement Airflow existant ?
Oui. FerroAir peut importer les connexions, les variables et les pools depuis un déploiement Apache Airflow managé existant et synchroniser votre dossier DAG. Les métadonnées sont stockées dans PostgreSQL ou SQLite à l'aide d'un schéma compatible Alembic d'Apache Airflow 3. La documentation post-achat sur l'AMI présente l'outil d'importation, le runbook, la matrice de compatibilité et la validation.
Comment fonctionnent la HA et la gestion des secrets ?
Le planificateur HA effectue le basculement via l'élection de leader (openraft) ; lancez plusieurs instances et l'élection de leader promeut un standby. Les secrets sont résolus depuis l'environnement, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault ou Vault, et les connexions ainsi que les variables sont chiffrées avec Fernet. L'authentification prend en charge FAB auth, OAuth, OIDC, SAML et LDAP.
Modèle de tarification
Frais logiciel horaires + EC2 (classe c7i / m7i, x86). Facturation à l’usage par type d’instance, option annuelle disponible.
Autres produits S4
S4 — Squished S3
Gateway transparent de compression S3 par GPU
S4 Logs
Archiver CloudWatch Logs vers S3 zstd
S4 Metrics
Gouverner la cardinalité des métriques CloudWatch