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.
Contêineres·Snapshots
TipoDesbloqueadoEstágioFrotaDificuldadeModeradoTrabalhoCompartilhar streamParaEquipes de desenvolvimentoParaDevOps & infraServiçosPipePor que HoodyHTTP-nativoPor que HoodyEconomia de contêineres
TipoDesbloqueadoEstágioFrotaDificuldadeModeradoTrabalhoCompartilhar streamParaEquipes de desenvolvimentoParaDevOps & infraServiçosPipePor que HoodyHTTP-nativoPor que HoodyEconomia de contêineres
use-cases / push-one-build-to-thirty-ci-workers / hero
PIPE · FAN-OUT DE CI
Envie um build para trinta workers de CI ao mesmo tempo
Sua matriz de CI se distribui em trinta runners de teste. Cada um precisa da mesma imagem de 800 MB. Envie o tarball para um caminho de pipe com ?n=30. Os trinta workers fazem curl na mesma URL. Os bytes passam uma vez, o servidor não retém nada e nenhuma credencial de registry é rotacionada.
builder.ci
1 remetente
# envie a imagem uma veztar c ./image.tar | curl -T - https://pipe.hoody.com/build-12af?n=30PUT /pipe1× egress
?n=30um stream
ci-fleet
30 receptores01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
todos conectados
GET /pipeUM REMETENTE À ESQUERDA. TRINTA RECEPTORES GET À DIREITA. O PIPE ESPERA ATÉ TODOS ESTAREM ESCUTANDO; AÍ OS BYTES PASSAM UMA VEZ.
use-cases / push-one-build-to-thirty-ci-workers / mechanism
Como trinta curls se tornam um stream
O pipe é um roteador de fan-out sem disco. O POST do remetente em /api/v1/pipe/[path]?n=30 bloqueia até trinta receptores se conectarem na mesma URL com o mesmo n. Aí os bytes fluem do contêiner do build direto para cada runner, simultaneamente, na velocidade do receptor mais lento.
Três passos. Sem registry, sem S3, sem cache action.PIPE · ?n=30
01
O build envia uma vez
tar c | curl -T - https://pipe/.../build?n=30O contêiner do build envia o tarball direto pelo curl. Nenhum arquivo escrito, nenhum push para registry.
02
O pipe espera a frota
POST /api/v1/pipe/[path]?n=30O servidor mantém o remetente até todos os trinta receptores se conectarem. n divergente retorna 400. Receptores pré-conectados estão ok.
03
Os trinta puxam a mesma URL
curl https://pipe/.../build?n=30 | tar xCada runner recebe os mesmos bytes. O backpressure flui do receptor mais lento, não da banda do remetente.
Nada persiste. Nada é cacheado. O pipe intermedia a conexão e sai do caminho. Quando o runner mais lento termina, a transferência termina — e a URL deixa de existir.
use-cases / push-one-build-to-thirty-ci-workers / numbers
Quanto isso custa para a matriz
Ingênuo: trinta pulls do registry do mesmo tarball de 800 MB, trinta caches frios, trinta round-trips de rede. Pipe: um egress, uma transferência, o receptor mais lento dita o ritmo.
TEMPO DE EXECUÇÃO
12s
Um egress na velocidade da linha. O receptor mais lento dita o ritmo, mas ninguém baixa de novo.
EGRESS
1× / build
Os bytes saem do builder uma vez e fazem fan-out no pipe. Sem taxas de GET no S3, sem pulls do Docker Hub.
ARMAZENAMENTO
0 bytes
O pipe não retém nada em disco. Sem registry para limpar, sem chave de cache para invalidar.
O número de tempo de execução assume uma matriz de 30 vias na mesma rede regional do contêiner do build; transferências entre regiões são limitadas pela banda inter-regional, não pelo pipe.
use-cases / push-one-build-to-thirty-ci-workers / powers
O que o fan-out destrava
Quando o build vira uma URL e trinta curls, uma pilha de andaimes de CI desaparece. Sem armazenamento de artefatos para envelhecer. Sem credenciais de registry para rotacionar. Sem cache action para depurar.
O receptor mais lento dita o ritmo
O backpressure já vem embutido no pipe. Os workers rápidos não desperdiçam um round-trip no registry esperando o lento — eles esperam no pipe e bebem na mesma velocidade. Ninguém baixa de novo.
Sem credenciais de registry para rotacionar
Nada é enviado para um registry, então nada precisa se autenticar em um. A URL em si é a credencial — efêmera, escopada para uma transferência, descartada quando o build termina.
Sem conta do S3, sem surpresa de egress
Os bytes saem do builder uma vez. O pipe transmite. Você paga um egress por build em vez de trinta pulls de registry por execução de matriz.
Sem chave de cache para invalidar
O pipe é por build, não por chave. Não tem cache do GitHub Actions para errar, mistério de camada do buildx, nem tarball obsoleto da main da semana passada.
Funciona para qualquer tarball, não só imagens
O mesmo padrão lida com node_modules, .pnpm-store, target/, o cache de wheels, o shard de dataset. Se faz streaming, faz fan-out.
use-cases / push-one-build-to-thirty-ci-workers / punchline
Um remetente. Trinta receptores. Zero contas de S3.
Um push de 30 vias que levava noventa segundos e um hit no S3 leva doze segundos e um único egress. Ninguém baixa de novo. Nenhuma credencial de registry é rotacionada. A URL se descarta quando a matriz termina.
- 1 EGRESS
- 30 RECEPTORES
- 0 ARMAZENAMENTO
- 0 CREDENCIAIS
use-cases / push-one-build-to-thirty-ci-workers / replaces
O que isto substitui
As peças que um fluxo de matriz de CI normalmente precisa montar — registry, cache action, mirror, etapa de upload customizada. O pipe junta tudo em uma URL.
- AWS S3 (armazenamento de registry + egress)30× taxas de GET por build, política de eviction, role IAM
- Cache do GitHub ActionsLimite de 10 GB, colisões de chave, escopo por branch
- Pulls do Docker HubRate-limited, mirror pago para evitar throttling
- Mirror de registry npm / pnpmVerdaccio self-hosted só para pular o registry público
- Cache action customizada de CICola em bash, SDK do S3, lógica de expiração, plantão quando quebra
- Export de cache de camadas do BuildxEsquisitices do formato de camada, cache misses entre runners
use-cases / push-one-build-to-thirty-ci-workers / cta
Pare de empurrar o mesmo tarball trinta vezes. Empurre uma vez. Deixe trinta curls dividirem o stream.
use-cases / push-one-build-to-thirty-ci-workers / related
Leia os outros
