
Sessenta contêineres em um servidor
Uma caixa bare-metal executa dezenas a centenas de contêineres Hoody. KSM e BTRFS dedup fazem o custo marginal próximo a zero.
Um colega bate num bug que você não consegue reproduzir. Pule o arquivo. pg_dump no seu notebook entra direto no psql dele em staging — sem upload, sem link, sem download. O pipe roteia os bytes.
A Hoody Pipe API mantém um pipe não estabelecido por até cinco minutos enquanto espera o outro lado conectar. Quando os dois conectam, os bytes fluem. Nada é escrito em disco no servidor.
# do seu notebook de devpg_dump --format=custom dev \ | curl -T - \ https://pipe.containers.hoody.com/api/v1/pipe/dev-snapshot[INFO] Waiting for 1 receiver to connect…[INFO] Streaming to 1 receiver…[INFO] Transfer complete.
PUT (ou POST) com corpo em streaming. O servidor imprime mensagens de status no seu terminal conforme o pipe se estabelece — útil para você ver quando o outro lado realmente conectou.
# no shell de staging delecurl https://pipe.containers.hoody.com/api/v1/pipe/dev-snapshot \ | pg_restore -d staging# linhas importadas · staging agora bate com dev
GET no mesmo caminho bloqueia até o remetente conectar. Os bytes que o remetente escreve aparecem como o corpo da resposta. Mande para pg_restore (ou psql) e o dump cai direto no banco — nunca em arquivo.
Se você quer ver o progresso sem consumir um slot de receptor, aponte um terceiro curl para o mesmo caminho com ?progress e ganha um dashboard HTML ao vivo mostrando bytes transferidos, velocidade e ETA.
Os quatro movimentos para colocar um banco de dev no staging do colega sem nada tocar disco em servidor.
“pode me mandar seu banco de dev?”Ontem isso teria virado pg_dump, bucket S3, URL pré-assinada e um link no Slack.
pg_dump dev | curl -T - …/pipe/dev-snapshotSeu terminal imprime “Waiting for 1 receiver to connect…” e fica parado. Nenhum arquivo é criado localmente também.
curl …/pipe/dev-snapshot | pg_restoreO pipe se estabelece no momento em que ele conecta. Os bytes começam a fluir do seu pg_dump direto para o pg_restore dele.
Transfer complete · 0 bytes no servidorO uso de disco do lado do servidor fica em zero. O caminho do pipe esquece que a transferência aconteceu no momento em que os dois lados desconectam.
É o mesmo número de comandos que você digitaria para um round-trip de S3 — menos o bucket, a credencial, o upload, o download e a limpeza.
O Hoody Pipe é um intermediário de streaming, não um serviço de arquivos. O dump existe no seu disco e no dele; entre os dois, são só bytes em voo. Nada para limpar, nada para vazar.
Não tem barra de progresso de upload para babá porque não tem upload. Um dump de 40 GB se move na velocidade que sua rede e o pg_restore do colega aguentam — o pipe só encaminha.
Abra o mesmo caminho com ?progress numa terceira URL e veja bytes transferidos, velocidade e ETA em tempo real. Até 50 espectadores por pipe, nenhum consome um slot de receptor.
Estado de banco de dados era um anexo. Agora é um caminho.
Arquivos são estado em repouso. Caminhos são estado em movimento. O Hoody Pipe deixa um snapshot de banco ser o segundo — endereçável, efêmero e nunca parado num servidor que você precisa limpar depois.
A maioria das ferramentas que usávamos para compartilhar um banco de dev é resquício de quando não dava para fazer streaming de bytes entre dois terminais por HTTP. O pipe torna tudo isso desnecessário.
Dois curls. Um caminho. O staging dele agora bate com seu dev.