4
andeerc
4 min de leitura ·

Pitch: Sparrow: o orquestrador que comecei a construir porque cansei do buraco entre Docker Compose, Swarm e Kubernetes

Vou ser bem direto: eu acho que existe um espaço mal resolvido no mundo de containers.

De um lado, temos o docker compose, que é ótimo para desenvolvimento, projetos pequenos e setups locais. Mas quando começa a falar de cluster, HA, rolling update, autoscale, proxy por domínio, alertas e operação real, ele naturalmente não foi feito para isso.

Do outro lado, temos Kubernetes.

Kubernetes é poderoso. Resolve problemas grandes. É praticamente o padrão da indústria.

Mas também é complexo. Muito complexo.

Para muita empresa pequena, sistema interno, SaaS enxuto, servidor próprio, VPS ou time de 2 a 30 pessoas, Kubernetes vira um custo operacional desproporcional. Você não está só “subindo containers”. Você está operando um ecossistema inteiro.

E no meio disso existia o Docker Swarm.

Simples.
Direto.
Fácil de entender.
Bom o suficiente para muita coisa.

Só que o Swarm ficou em modo de manutenção e, na prática, deixou um vazio.

Foi desse incômodo que nasceu o Sparrow.

A ideia não é reinventar Kubernetes.

A ideia é tentar responder uma pergunta mais simples:

e se existisse um orquestrador para quem quer rodar containers em produção sem carregar um control plane gigante nas costas?

O que é o Sparrow

O Sparrow é um orquestrador de containers escrito em Rust, usando Podman como runtime.

A proposta é ser:

  • simples como o Swarm
  • seguro como o Podman rootless
  • rápido e previsível como Rust
  • preparado para automação moderna com MCP

Exemplo básico:

curl -sfL https://codeberg.org/andeerc/sparrow/raw/main/install.sh | bash

sparrow cluster init --name prod --listen 0.0.0.0:7443

sparrow service create \
  --name web \
  --image nginx:alpine \
  --replicas 3 \
  --port 80:80

A ideia é essa: instalar, iniciar cluster, subir serviço.

Sem etcd externo.
Sem kube-apiserver.
Sem dezenas de componentes antes de colocar uma aplicação no ar.

Por que Podman?

A escolha pelo Podman não foi por moda.

Foi por causa do modelo operacional.

O Podman é daemonless e permite trabalhar com containers rootless. Isso reduz superfície de ataque e evita depender de um daemon central privilegiado controlando tudo.

Na prática, isso combina muito com a proposta do Sparrow:

  • menos privilégio
  • menos acoplamento
  • menos mágica
  • mais previsibilidade
  • compatibilidade com o ecossistema Docker/OCI

Arquitetura

O projeto é um workspace Rust com 6 crates:

  • sparrow-core: CLI, estado local, deploy YAML, autoscale, vault e alertas
  • sparrow-podman: integração com o runtime Podman
  • sparrow-raft: cluster multi-node com consenso via openraft
  • sparrow-api: API HTTP com axum, reverse proxy e dashboard embutido
  • sparrow-mcp: servidor MCP com SSE/JSON-RPC
  • sparrow-proto: tipos compartilhados

A stack hoje envolve:

CamadaTecnologia
RuntimePodman rootless
CLIclap
APIaxum
EstadoSQLite WAL
Clusteropenraft
SegurançaAES-256-GCM
MétricasPrometheus /metrics
AlertasTelegram + SMTP
UIDashboard SPA embutido

O diferencial que mais me interessa: MCP nativo

Essa talvez seja a parte mais diferente do Sparrow.

Ele já nasce com MCP Server embutido.

Ou seja, agentes compatíveis com MCP podem controlar o cluster usando ferramentas expostas pelo próprio Sparrow.

Exemplo de configuração no OpenCode:

{
  "mcp": {
    "sparrow": {
      "type": "command",
      "command": "sparrow",
      "args": ["mcp", "--stdio"],
      "enabled": true
    }
  }
}

Com isso, a ideia é permitir coisas como:

  • criar serviços
  • escalar réplicas
  • consultar logs
  • verificar estado do cluster
  • ajustar autoscale
  • listar serviços
  • inspecionar containers

Mas de uma forma estruturada, não com um agente inventando comando shell aleatório.

Eu acredito bastante que agentes de IA vão operar infraestrutura. A questão é se isso vai ser feito de qualquer jeito, com prompts gerando bash, ou com ferramentas bem definidas, permissões e limites claros.

O Sparrow tenta ir pelo segundo caminho.

Autoscale

Um exemplo de serviço com autoscale:

apiVersion: sparrow/v1
kind: Service
metadata:
  name: web
spec:
  image: nginx:alpine
  replicas: 3
  ports:
    - published: 80
      target: 80
  autoscale:
    min_replicas: 2
    max_replicas: 10
    cpu_target_percent: 70
    cooldown_seconds: 60

A ideia é ter autoscale simples, mas útil:

  • alvo por CPU/memória
  • cooldown configurável
  • proteção contra flapping
  • múltiplas políticas por serviço

Nada de tentar competir com todo o ecossistema Kubernetes. O foco é resolver bem o caso comum.

Cluster multi-node

Exemplo:

# líder
sparrow cluster init --name prod --listen 0.0.0.0:7443

# workers
sparrow cluster join 192.168.1.10:7443 --token SPAJOIN-a1b2c3d4

O estado do cluster usa Raft via openraft e SQLite WAL.

A proposta é manter o setup simples: sem banco externo, sem etcd, sem dependência gigante para começar.

Para quem eu imagino esse projeto

O Sparrow faz sentido para:

  • quem está grande demais para docker compose
  • quem acha Kubernetes pesado demais para o próprio cenário
  • quem roda 1 a 10 servidores
  • quem tem time pequeno
  • quem quer deploy, rollback, autoscale, proxy e alertas sem montar uma plataforma inteira
  • quem quer testar agentes de IA operando infraestrutura via MCP

Não acho que ele faça sentido para:

  • ambientes multi-cloud grandes
  • centenas de microservices
  • times que já possuem plataforma interna madura
  • empresas que precisam de todo o ecossistema Kubernetes

Estado atual

O projeto ainda é novo, mas já tem uma base considerável:

  • Rust
  • Podman rootless
  • openraft
  • axum
  • SQLite WAL
  • AES-256-GCM
  • dashboard embutido
  • MCP Server
  • CI com clippy, fmt, audit, build e testes
  • licença Apache 2.0

Código:

https://codeberg.org/andeerc/sparrow

Instalação:

curl -sfL https://codeberg.org/andeerc/sparrow/raw/main/install.sh | bash

Fechando

O Sparrow nasceu mais de uma irritação acumulada do que de uma ideia bonita.

Eu sentia falta de uma opção no meio.

Algo mais forte que Compose.
Mais vivo que Swarm.
Menos pesado que Kubernetes.
E já preparado para um cenário em que agentes de IA também vão operar infraestrutura.

Ainda tem muita coisa para evoluir, mas a direção está clara.

Quero construir um orquestrador simples, poderoso e auditável para quem precisa colocar container em produção sem transformar isso em um projeto de plataforma de seis meses.

Sugestões, críticas, issues e PRs são bem-vindos.

Repositório:

https://codeberg.org/andeerc/sparrow

Carregando publicação patrocinada...