FerroAir
Apache Airflow 3.x-kompatibler Orchestrator
Ein self-managed Workflow-Orchestrator, den Sie auf Ihren eigenen Amazon EC2-Instances ausführen: ein einzelnes statisches Rust-Binary, das einen Apache Airflow 3.x-Scheduler, Webserver, REST API v2, Triggerer und DAG-Prozessor implementiert. Es ist wire-kompatibel mit der Apache Airflow 3.0 / 3.1 / 3.2 REST API v2-Oberfläche und dem AIP-72 Task-Execution-Interface; Task-Bodies werden weiter über airflow.sdk auf CPython ausgeführt.
FerroAir führt Apache Airflow 3.x-Workloads auf Ihrem eigenen EC2 aus (Apache Airflow ist ein Open-Source-Projekt, kein AWS-Service). Es stellt eine echte Web UI bereit (eine Leptos Single-Page-App, kein Node-Runtime) auf Port 8080 (DAG-List-, Graph-, Grid-, Gantt-, Calendar- und Task-Log-Ansichten), einen Metrics-&-Admin-Port 9080 mit Prometheus-Metrics und health / live / ready-Probes sowie AIP-72 auf Port 8081. Es synchronisiert DAGs aus Amazon S3, speichert Metadata in PostgreSQL oder SQLite und betreibt einen HA-Scheduler mit Leader Election. Scheduler, Webserver, Triggerer und DAG-Prozessor sind in einem statischen Binary unter einer gehärteten systemd-Unit vereint — statt eines Multi-Process-Python-Deployments.
Das Problem
Apache Airflow ist ein hervorragender Open-Source-Workflow-Orchestrator (es handelt sich nicht um einen AWS-Service), aber das übliche Deployment führt den Scheduler, Webserver, Triggerer und DAG-Processor als mehrere Python-Prozesse aus, was im Betrieb sehr aufwendig zu verwalten ist. Teams müssen am Ende einen Multi-Prozess-Stack — Metadaten-DB, Broker und Worker — manuell zusammenstellen und warten. Ziel ist es, die Airflow-Kompatibilität beizubehalten und gleichzeitig den Betrieb des Orchestration-Layers zu vereinfachen.
Funktionsweise
- 1
Läuft als einzelnes Rust-Binary
FerroAir implementiert den Apache Airflow 3.x Scheduler, Webserver, die REST API v2, den Triggerer und den DAG-Processor in einem einzigen statischen Rust-Binary, das vereinheitlicht unter einer gehärteten systemd-Unit ausgeführt wird. Es läuft auf Ihren eigenen Amazon EC2-Instanzen statt eines Multi-Prozess-Python-Deployments.
- 2
Tasks laufen weiterhin auf CPython
FerroAir übernimmt den Scheduler-Tick-Loop, den DAG-Ordner-Watcher, die REST API, den Metadatenzugriff, die Leader-Election und den Executor-Dispatch in Rust. Die Task-Bodys werden weiterhin auf CPython durch das Upstream-Paket airflow.sdk über die Apache Airflow AIP-72 Task-Execution-Schnittstelle ausgeführt.
- 3
Bindet sich an Ihren bestehenden Zustand an
DAGs synchronisieren sich aus einem Amazon S3-Bucket (oder von einer lokalen Festplatte) und Metadaten werden in PostgreSQL oder SQLite gespeichert. Die Web-UI wird auf Port 8080 bereitgestellt, Prometheus-Metriken und -Probes auf Port 9080 sowie AIP-72 auf Port 8081.
Highlights
Airflow 3.x-kompatibel: REST API v2 + AIP-72; Task-Bodies laufen weiter über airflow.sdk auf CPython.
Ein statisches Rust-Binary (Scheduler + Webserver + Triggerer + DAG-Prozessor) statt eines Multi-Process-Python-Deployments; eine echte Leptos Web UI (kein Node).
DAGs synchronisieren aus S3, Metadata in PostgreSQL / SQLite, HA-Scheduler mit Leader Election; CloudFormation Quick Start enthalten.
Lieferumfang
- Amazon Linux 2023 AMI (x86_64, läuft auf Instanzen der Klassen c7i / m7i)
- Ein einzelnes statisches Rust-Binary, das den Apache Airflow 3.x Scheduler, Webserver, die REST API v2, den Triggerer und den DAG-Processor implementiert (wire-kompatibel mit der Apache Airflow 3.0/3.1/3.2 REST API v2-Schnittstelle und der AIP-72 Task-Execution-Schnittstelle)
- Eine echte Web-UI, die als Leptos Single-Page-Application implementiert ist (keine Node-Runtime, Port 8080), mit Ansichten für DAG-Liste, Graph, Grid, Gantt, Kalender und Task-Logs
- Ein dedizierter Metrik- und Admin-Port 9080 (Prometheus-Metriken plus Health-, Live- und Ready-Probes) und der AIP-72-Port 8081 für den Python-Worker
- Amazon S3-DAG-Synchronisation, PostgreSQL- oder SQLite-Metadaten (Apache Airflow 3 Alembic-kompatibles Schema) und ein HA-Scheduler mit Leader-Election-Failover
- Ein Import-Tool für Connections, Variablen und Pools aus einem bestehenden Managed Apache Airflow-Deployment plus Dokumente nach dem Kauf mit Runbook, Kompatibilitätsmatrix und Validierung
- Keine separate Control Plane, kein Telemetrie-Home-Call und keine Lizenzschlüsselprüfung (Abrechnung pro Instanz und Stunde über Ihre AWS-Rechnung, mit einer jährlichen Option)
Anwendungsfälle
Ausführung von Apache Airflow-Workflows auf Ihrem eigenen Amazon EC2 als einzelnes, operativ einfacheres Binary
Teams, die ihre Orchestrierungsebene von einem Managed Apache Airflow-Deployment durch den Import von Connections, Variablen und Pools migrieren
Bestehende Workloads, die weiterhin mit ihren Apache Airflow REST API v2-Clients funktionieren müssen
Betrieb eines Orchestrators vollständig innerhalb Ihrer eigenen VPC, ohne separate Control Plane und ohne Telemetrie-Home-Call
FAQ
Wie kompatibel ist es mit Apache Airflow?
FerroAir ist wire-kompatibel mit der Apache Airflow 3.0, 3.1 und 3.2 REST API v2-Schnittstelle und dem Apache Airflow AIP-72 Task-Execution-Interface. Da die REST API v2-Schnittstelle implementiert ist, werden bestehende Apache Airflow REST API v2-Clients unterstützt. Die vollständige Kompatibilitätsmatrix finden Sie in der Produktdokumentation.
Läuft mein Python-Taskcode weiterhin?
Ja. Task-Bodys werden weiterhin auf CPython über das Upstream-airflow.sdk über die Apache Airflow AIP-72 Task-Execution-Schnittstelle ausgeführt. Das Rust-Binary übernimmt den Scheduler-Tick-Loop, den DAG-Ordner-Watcher, die REST API, den Metadatenzugriff, die Leader-Election und den Executor-Dispatch — die Task-Execution-Runtime selbst bleibt CPython.
Ist dies ein Ersatz für einen AWS-Service?
Apache Airflow ist ein Open-Source-Projekt und kein AWS-Service. FerroAir ist ein selbstverwalteter Workflow-Orchestrator, der diese Apache Airflow 3.x-Workloads auf Ihren eigenen Amazon EC2-Instanzen ausführt. Es wird als normale Amazon Linux 2023 AMI bereitgestellt, die Sie in Ihrer eigenen VPC ausführen.
Kann ich von einem bestehenden Airflow-Deployment migrieren?
Ja. FerroAir kann Connections, Variablen und Pools aus einem bestehenden verwalteten Apache Airflow-Deployment importieren und Ihren DAG-Ordner synchronisieren. Metadaten werden in PostgreSQL oder SQLite unter Verwendung eines mit Apache Airflow 3 Alembic-kompatiblen Schemas gespeichert. Die Dokumentation nach dem Kauf auf der AMI führt Sie durch das Import-Tool, das Runbook, die Kompatibilitätsmatrix und die Validierung.
Wie funktionieren HA und das Secrets-Handling?
Der HA-Scheduler führt ein Failover über eine Leader-Election (openraft) durch; führen Sie mehrere Instanzen aus, und die Leader-Election befördert eine Standby-Instanz. Secrets werden aus der Umgebung, dem AWS Secrets Manager, dem GCP Secret Manager, dem Azure Key Vault oder Vault aufgelöst, und Connections sowie Variablen werden mit Fernet verschlüsselt. Die Authentifizierung unterstützt FAB-Auth, OAuth, OIDC, SAML und LDAP.
Preismodell
Stündliche Softwaregebühr + EC2 (c7i / m7i-Klasse, x86). Abrechnung pro Instance-Typ, Jahresoption verfügbar.
Weitere S4-Produkte
S4 — Squished S3
Transparenter GPU S3-Komprimierungs-Gateway
S4 Logs
CloudWatch Logs nach zstd S3 archivieren
S4 Metrics
CloudWatch Metric-Cardinality steuern