Ir al contenido
TipoDesbloqueadoEtapaFlotaDificultadModeradoTrabajoCompartir streamParaEquipos de desarrolloParaDevOps e infraServiciosPipePor qué HoodyHTTP nativoPor qué HoodyEconomía de contenedores
TipoDesbloqueadoEtapaFlotaDificultadModeradoTrabajoCompartir streamParaEquipos de desarrolloParaDevOps e infraServiciosPipePor qué HoodyHTTP nativoPor qué HoodyEconomía de contenedores
TipoDesbloqueadoEtapaFlotaDificultadModeradoTrabajoCompartir streamParaEquipos de desarrolloParaDevOps e infraServiciosPipePor qué HoodyHTTP nativoPor qué HoodyEconomía de contenedores
TipoDesbloqueadoEtapaFlotaDificultadModeradoTrabajoCompartir streamParaEquipos de desarrolloParaDevOps e infraServiciosPipePor qué HoodyHTTP nativoPor qué HoodyEconomía de contenedores
Volver a casos de uso
use-cases / push-one-build-to-thirty-ci-workers / hero
PIPE · FAN-OUT DE CI

Envía una build a treinta workers de CI a la vez

Tu CI matricial se reparte entre treinta runners de test. Cada uno necesita la misma imagen de 800 MB. Transmite el tarball a una sola ruta de pipe con ?n=30. Los treinta workers hacen curl a la misma URL. Los bytes salen una vez, el servidor no guarda nada y no se rotan credenciales de registry.

Lee la documentación de pipe
use-cases / push-one-build-to-thirty-ci-workers / mechanism

Cómo treinta curls se vuelven un solo stream

El pipe es un router de fan-out sin disco. El POST del emisor a /api/v1/pipe/[path]?n=30 se bloquea hasta que treinta receptores se conectan a la misma URL con el mismo n. Entonces los bytes fluyen del contenedor de build directo a cada runner, simultáneamente, a la velocidad del receptor más lento.

Tres pasos. Sin registry, sin S3, sin cache action.PIPE · ?n=30
01

La build se transmite una vez

tar c | curl -T - https://pipe/.../build?n=30

El contenedor de build canaliza el tarball directo a curl. Sin archivo escrito, sin push a registry.

02

El pipe espera a la flota

POST /api/v1/pipe/[path]?n=30

El servidor retiene al emisor hasta que los treinta receptores se conectan. Un n distinto devuelve 400. Los receptores pre-conectados están bien.

03

Los treinta tiran de la misma URL

curl https://pipe/.../build?n=30 | tar x

Cada runner recibe bytes idénticos. El backpressure fluye desde el receptor más lento, no desde el ancho de banda del emisor.

Nada persiste. Nada se cachea. El pipe corredora la conexión, luego se aparta. Cuando el runner más lento termina, la transferencia termina — y la URL desaparece.

use-cases / push-one-build-to-thirty-ci-workers / numbers

Lo que le cuesta a la matriz

Ingenuo: treinta pulls de registry del mismo tarball de 800 MB, treinta cachés frías, treinta idas y vueltas de red. Pipe: un egress, una transferencia, el receptor más lento marca el ritmo.

TIEMPO TOTAL

12 s

Un egress a velocidad de línea. El receptor más lento marca el ritmo, pero nadie re-descarga.

EGRESS

1× / build

Los bytes salen del builder una vez, fan-out en el pipe. Sin tarifas de S3 GET, sin pulls de Docker Hub.

ALMACENAMIENTO

0 bytes

El pipe no guarda nada en disco. Sin registry que limpiar, sin clave de caché que invalidar.

El tiempo total asume una matriz de 30 vías en la misma red regional que el contenedor de build; las transferencias entre regiones dependen del ancho de banda inter-regional, no del pipe.

use-cases / push-one-build-to-thirty-ci-workers / powers

Lo que desbloquea el fan-out

Una vez que la build es una URL y treinta curls, una pila de andamiaje de CI desaparece. Sin almacenamiento de artefactos que envejecer. Sin credenciales de registry que rotar. Sin cache action que depurar.

El receptor más lento marca el ritmo

El backpressure está integrado en el pipe. Los workers rápidos no malgastan una ida y vuelta de registry esperando al lento — esperan en el pipe, luego beben al mismo ritmo. Nadie re-descarga.

Sin credenciales de registry que rotar

Nada se sube a un registry, así que nada tiene que autenticarse contra uno. La URL misma es la credencial — efímera, limitada a una transferencia, expulsada cuando la build termina.

Sin factura de S3, sin sorpresa de egress

Los bytes salen del builder una vez. El pipe difunde. Pagas un egress por build en lugar de treinta pulls de registry por ejecución de matriz.

Sin clave de caché que invalidar

El pipe es por build, no por clave. No hay caché de GitHub Actions con el que fallar, ni misterio de capa de buildx, ni tarball viejo del main de la semana pasada.

Funciona para cualquier tarball, no solo imágenes

El mismo patrón maneja node_modules, .pnpm-store, target/, la caché de wheels, el shard del dataset. Si se transmite, se reparte en abanico.

use-cases / push-one-build-to-thirty-ci-workers / punchline

Un emisor. Treinta receptores. Cero facturas de S3.

Un push de 30 vías que tomaba noventa segundos y un golpe a S3 toma doce segundos y un solo egress. Nadie re-descarga. No se rotan credenciales de registry. La URL se expulsa sola cuando la matriz termina.

  • 1 EGRESS
  • 30 RECEPTORES
  • 0 ALMACENAMIENTO
  • 0 CREDENCIALES
Abre la API de pipe
use-cases / push-one-build-to-thirty-ci-workers / replaces

Lo que esto reemplaza

Las piezas que un flujo de CI matricial normalmente tiene que ensamblar — registry, cache action, mirror, paso de subida a medida. El pipe las pliega en una URL.

  • AWS S3 (almacenamiento de registry + egress)30× tarifas GET por build, política de eviction, rol IAM
  • Caché de GitHub ActionsTope de 10 GB, colisiones de claves, alcance por rama
  • Pulls de Docker HubCon rate limit, mirror de pago para evitar throttling
  • Mirror de registry npm / pnpmVerdaccio auto-alojado solo para evitar el registry público
  • Cache action de CI a medidaPegamento bash, SDK de S3, lógica de expiración, on-call cuando se rompe
  • Export de caché de capas BuildxParticularidades del formato de capa, fallos de caché entre runners
use-cases / push-one-build-to-thirty-ci-workers / cta

Deja de empujar el mismo tarball treinta veces. Empújalo una vez. Que treinta curls compartan el stream.

Lee la API de pipe
use-cases / push-one-build-to-thirty-ci-workers / related

Lee los otros