FerroAir
Orquestrador compatível com Apache Airflow 3.x
Um orquestrador de workflows autogerenciado que você executa nas suas próprias instâncias Amazon EC2: um único binário Rust estático que implementa scheduler, webserver, REST API v2, triggerer e processador de DAG do Apache Airflow 3.x. Ele é compatível no wire protocol com a superfície REST API v2 do Apache Airflow 3.0 / 3.1 / 3.2 e com a interface de execução de tarefas AIP-72, e os corpos das tarefas continuam executando em CPython via airflow.sdk.
FerroAir executa workloads Apache Airflow 3.x no seu próprio EC2 (Apache Airflow é um projeto open-source, não um serviço da AWS). Ele serve uma UI web real (um single-page app Leptos, sem runtime Node) na porta 8080 (views de lista, grafo, grid, gantt, calendário e log de tarefas de DAG), uma porta de métricas e admin 9080 com métricas Prometheus e probes health / live / ready, e AIP-72 na porta 8081. Ele sincroniza DAGs a partir do Amazon S3, armazena metadados em PostgreSQL ou SQLite e executa um scheduler HA com eleição de líder. Scheduler, webserver, triggerer e processador de DAG são unificados em um binário estático sob uma unidade systemd hardened — em vez de uma implantação Python multiprocessos.
O problema
O Apache Airflow é um excelente orquestrador de workflows open source (não é um serviço AWS), mas a implantação padrão executa o scheduler, webserver, triggerer e o processador de DAG como múltiplos processos Python, o que é operacionalmente complexo de gerenciar. As equipes acabam tendo de montar e manter manualmente uma pilha de múltiplos processos — banco de dados de metadados, broker e workers. A necessidade é manter a compatibilidade com o Airflow, mas tornando a execução da camada de orquestração mais simples.
Como funciona
- 1
Executado como um único binário Rust
O FerroAir implementa o scheduler, webserver, REST API v2, triggerer e o processador de DAG do Apache Airflow 3.x em um único binário Rust estático, executado de forma unificada em uma unidade systemd protegida. Ele roda nas suas próprias instâncias do Amazon EC2, em vez de uma implantação Python multiprocesso.
- 2
As tarefas ainda são executadas no CPython
O FerroAir executa o loop de ticks do scheduler, o monitor de pasta de DAGs, a REST API, o acesso aos metadados, a eleição de líder e o despacho do executor em Rust. Os corpos das tarefas continuam sendo executados no CPython por meio do airflow.sdk upstream através da interface de execução de tarefas AIP-72 do Apache Airflow.
- 3
Conecta-se ao seu estado existente
As DAGs sincronizam a partir de um bucket do Amazon S3 (ou disco local) e os metadados são armazenados no PostgreSQL ou SQLite. A web UI é servida na porta 8080, as métricas e probes do Prometheus na porta 9080 e o AIP-72 na porta 8081.
Destaques
Compatível com Airflow 3.x: REST API v2 + AIP-72; corpos das tarefas continuam rodando em CPython via airflow.sdk.
Um binário Rust estático (scheduler + webserver + triggerer + processador de DAG) em vez de uma implantação Python multiprocessos; uma UI web Leptos real (sem Node).
DAGs sincronizam a partir do S3, metadados em PostgreSQL / SQLite, scheduler HA com eleição de líder; CloudFormation Quick Start incluído.
O que está incluído
- AMI do Amazon Linux 2023 (x86_64, roda em instâncias das classes c7i / m7i)
- Um único binário Rust estático que implementa o scheduler, webserver, REST API v2, triggerer e processador de DAG do Apache Airflow 3.x (compatível a nível de rede com a superfície de REST API v2 do Apache Airflow 3.0/3.1/3.2 e a interface de execução de tarefas AIP-72)
- Uma web UI autêntica construída como uma single-page application Leptos (sem runtime Node, porta 8080) com visualizações de lista de DAGs, gráfico, grid, gantt, calendário e logs de tarefas
- Uma porta dedicada de administração e métricas 9080 (métricas do Prometheus mais probes de health, live e ready) e a porta AIP-72 8081 para o worker Python
- Sincronização de DAGs com o Amazon S3, metadados em PostgreSQL ou SQLite (schema do Apache Airflow 3 compatível com Alembic) e um scheduler HA com failover por eleição de líder
- Uma ferramenta de importação para conexões, variables e pools de uma implantação gerenciada do Apache Airflow existente, além de documentação pós-compra contendo o runbook, matriz de compatibilidade e validação
- Sem control plane separado, sem envio de telemetria externa (home-call) e sem validação de chave de licença (tarifado por hora de instância através da sua fatura AWS, com opção anual)
Casos de uso
Execução de workflows do Apache Airflow em seu próprio Amazon EC2 como um binário único e de operação mais simples
Equipes que estão migrando sua camada de orquestração de uma implantação gerenciada do Apache Airflow por meio da importação de conexões, variáveis e pools
Workloads existentes que precisam continuar funcionando com seus clientes da REST API v2 do Apache Airflow
Execução de um orquestrador inteiramente dentro da sua própria VPC, sem control plane separado e sem envio de telemetria externa (home-call)
FAQ
Qual é o nível de compatibilidade com o Apache Airflow?
O FerroAir é compatível a nível de rede (wire-compatible) com a superfície de REST API v2 do Apache Airflow 3.0, 3.1 e 3.2 e com a interface de execução de tarefas AIP-72 do Apache Airflow. Como a superfície da REST API v2 está implementada, os clientes existentes da REST API v2 do Apache Airflow são suportados. Consulte a documentação do produto para ver a matriz de compatibilidade completa.
O código Python da minha tarefa ainda é executado?
Sim. Os corpos das tarefas continuam sendo executados no CPython através do airflow.sdk upstream na interface de execução de tarefas Apache Airflow AIP-72. O binário Rust controla o loop de ticks do agendador, o monitor de pastas DAG, a REST API, o acesso a metadados, a eleição de líder e o despacho do executor — o próprio runtime de execução de tarefas continua sendo CPython.
Isso substitui um serviço da AWS?
O Apache Airflow é um projeto de código aberto e não é um serviço da AWS. O FerroAir é um orquestrador de fluxo de trabalho autogerenciado que executa essas cargas de trabalho do Apache Airflow 3.x em suas próprias instâncias do Amazon EC2. Ele é fornecido como uma AMI padrão do Amazon Linux 2023 que você executa dentro de sua própria VPC.
Posso migrar de uma implantação existente do Airflow?
Sim. O FerroAir pode importar conexões, variáveis e pools de uma implantação gerenciada existente do Apache Airflow e sincronizar sua pasta DAG. Os metadados são armazenados no PostgreSQL ou SQLite usando um esquema compatível com Alembic do Apache Airflow 3. A documentação pós-compra na AMI orienta sobre a ferramenta de importação, o runbook, a matriz de compatibilidade e a validação.
Como funcionam a HA e o gerenciamento de segredos?
O agendador de HA realiza failover via eleição de líder (openraft); execute várias instâncias e a eleição de líder promove um standby. Os segredos são resolvidos a partir do ambiente, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault ou Vault, e as conexões e variáveis são criptografadas com Fernet. A autenticação oferece suporte a autenticação FAB, OAuth, OIDC, SAML e LDAP.
Modelo de precificação
Taxa horária de software + EC2 (classe c7i / m7i, x86). Medição por tipo de instância, opção anual disponível.
Outros produtos S4
S4 — Squished S3
Gateway transparente de compressão S3 com GPU
S4 Logs
Arquive CloudWatch Logs em S3 com zstd
S4 Metrics
Controle a cardinalidade de métricas do CloudWatch