Pular para o conteúdo
TipoDesbloqueado
EstágioFrota
DificuldadeModerado
TarefaCompartilhar stream
ParaEquipes de desenvolvimento
ParaDevOps e infra
ServiçosPipe
Por que HoodyHTTP-nativo
Por que HoodyEconomia de contêineres
TipoDesbloqueado
EstágioFrota
DificuldadeModerado
TarefaCompartilhar stream
ParaEquipes de desenvolvimento
ParaDevOps e infra
ServiçosPipe
Por que HoodyHTTP-nativo
Por que HoodyEconomia de contêineres
TipoDesbloqueado
EstágioFrota
DificuldadeModerado
TarefaCompartilhar stream
ParaEquipes de desenvolvimento
ParaDevOps e infra
ServiçosPipe
Por que HoodyHTTP-nativo
Por que HoodyEconomia de contêineres
TipoDesbloqueado
EstágioFrota
DificuldadeModerado
TarefaCompartilhar stream
ParaEquipes de desenvolvimento
ParaDevOps e infra
ServiçosPipe
Por que HoodyHTTP-nativo
Por que HoodyEconomia de contêineres
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.

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=30

O 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=30

O 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 x

Cada 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.

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.

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.

Um remetente. Trinta receptores. Zero contas de S3.

Um push de 30 vias que antes entrava em gargalo em um round-trip S3 agora flui por um pipe e uma única saída. Ninguém faz re-download. Nenhuma credencial de registro rotaciona. A URL se remove quando a matriz termina.

  • 1 EGRESS
  • 30 RECEPTORES
  • 0 ARMAZENAMENTO
  • 0 CREDENCIAIS
Abrir a pipe API

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

Pare de empurrar o mesmo tarball trinta vezes. Empurre uma vez. Deixe trinta curls dividirem o stream.

Ler a pipe API

Leia os outros