Aller au contenu
TypeDéverrouilléÉtapeParcDifficultéModéréTravailPartager un fluxPourÉquipes de devPourDevOps & infraServicesPipePourquoi HoodyHTTP-natifPourquoi HoodyÉconomie des conteneurs
TypeDéverrouilléÉtapeParcDifficultéModéréTravailPartager un fluxPourÉquipes de devPourDevOps & infraServicesPipePourquoi HoodyHTTP-natifPourquoi HoodyÉconomie des conteneurs
TypeDéverrouilléÉtapeParcDifficultéModéréTravailPartager un fluxPourÉquipes de devPourDevOps & infraServicesPipePourquoi HoodyHTTP-natifPourquoi HoodyÉconomie des conteneurs
TypeDéverrouilléÉtapeParcDifficultéModéréTravailPartager un fluxPourÉquipes de devPourDevOps & infraServicesPipePourquoi HoodyHTTP-natifPourquoi HoodyÉconomie des conteneurs
Retour aux cas d'utilisation
use-cases / push-one-build-to-thirty-ci-workers / hero
PIPE · FAN-OUT CI

Diffusez un build à trente workers CI en même temps

Votre matrix CI s'étale sur trente runners de test. Chacun a besoin de la même image de 800 Mo. Streamez le tarball dans un seul chemin pipe avec ?n=30. Les trente workers font curl sur la même URL. Les octets passent une fois, le serveur ne retient rien et aucun identifiant de registry n'est rotationné.

Lire la doc pipe
use-cases / push-one-build-to-thirty-ci-workers / mechanism

Comment trente curl deviennent un seul flux

Le pipe est un routeur de fan-out sans disque. Le POST de l'émetteur sur /api/v1/pipe/[path]?n=30 bloque jusqu'à ce que trente récepteurs se connectent à la même URL avec le même n. Ensuite les octets vont du conteneur de build directement vers chaque runner, simultanément, à la vitesse du récepteur le plus lent.

Trois étapes. Pas de registry, pas de S3, pas de cache action.PIPE · ?n=30
01

Le build streame une fois

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

Le conteneur de build envoie le tarball directement dans curl. Aucun fichier écrit, aucun registry poussé.

02

Le pipe attend la flotte

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

Le serveur retient l'émetteur jusqu'à ce que les trente récepteurs se connectent. Un n incohérent retourne 400. Les récepteurs déjà connectés sont acceptés.

03

Les trente tirent la même URL

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

Chaque runner reçoit des octets identiques. Le backpressure vient du récepteur le plus lent, pas de la bande passante de l'émetteur.

Rien ne persiste. Rien n'est mis en cache. Le pipe orchestre la connexion, puis s'efface. Quand le runner le plus lent termine, le transfert termine — et l'URL disparaît.

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

Ce que cela coûte à la matrix

Naïf : trente pulls de registry du même tarball de 800 Mo, trente caches froids, trente allers-retours réseau. Pipe : un egress, un transfert, le récepteur le plus lent fixe le rythme.

TEMPS RÉEL

12 s

Un seul egress à plein débit. Le récepteur le plus lent fixe le rythme, mais personne ne re-télécharge.

EGRESS

1× / build

Les octets quittent le builder une seule fois, fan-out au pipe. Pas de frais GET S3, pas de pulls Docker Hub.

STOCKAGE

0 octet

Le pipe ne retient rien sur disque. Pas de registry à nettoyer, pas de clé de cache à invalider.

Le temps réel suppose une matrix à 30 voies sur le même réseau régional que le conteneur de build ; les transferts inter-régions sont limités par la bande passante inter-régions, pas par le pipe.

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

Ce que le fan-out débloque

Une fois que le build est une URL et trente curl, toute une pile d'échafaudage CI disparaît. Pas de stockage d'artefacts à expirer. Pas d'identifiants de registry à rotationner. Pas de cache action à débugger.

Le récepteur le plus lent fixe le rythme

Le backpressure est intégré au pipe. Les workers rapides ne gaspillent pas un aller-retour de registry à attendre le lent — ils attendent au pipe, puis boivent au même rythme. Personne ne re-télécharge.

Pas d'identifiants de registry à rotationner

Rien n'est poussé vers un registry, donc rien n'a besoin de s'y authentifier. L'URL elle-même est l'identifiant — éphémère, limitée à un transfert, évincée à la fin du build.

Pas de facture S3, pas de surprise d'egress

Les octets quittent le builder une seule fois. Le pipe diffuse. Vous payez un egress par build au lieu de trente pulls de registry par exécution de matrix.

Pas de clé de cache à invalider

Le pipe est par-build, pas par-clé. Pas de cache GitHub Actions à mal-cibler, pas de mystère de couches buildx, pas de tarball obsolète de la main de la semaine dernière.

Fonctionne pour tout tarball, pas que les images

Le même pattern gère node_modules, .pnpm-store, target/, le cache de wheels, le shard de dataset. Si ça streame, ça fait du fan-out.

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

Un émetteur. Trente récepteurs. Zéro facture S3.

Un push à 30 voies qui prenait quatre-vingt-dix secondes et un hit S3 prend douze secondes et un seul egress. Personne ne re-télécharge. Aucun identifiant de registry n'est rotationné. L'URL s'évince elle-même quand la matrix se termine.

  • 1 EGRESS
  • 30 RÉCEPTEURS
  • 0 STOCKAGE
  • 0 IDENTIFIANT
Ouvrir l'API pipe
use-cases / push-one-build-to-thirty-ci-workers / replaces

Ce que cela remplace

Les pièces qu'un flux matrix-CI doit normalement assembler — registry, cache action, miroir, étape d'upload custom. Le pipe les regroupe en une seule URL.

  • AWS S3 (stockage de registry + egress)30× frais GET par build, politique d'éviction, rôle IAM
  • Cache GitHub ActionsPlafond 10 Go, collisions de clés, scope par branche
  • Pulls Docker HubLimité en débit, miroir payant pour éviter le throttling
  • Miroir de registry npm / pnpmVerdaccio auto-hébergé juste pour éviter le registry public
  • Cache action CI customGlue Bash, SDK S3, logique d'expiration, on-call quand ça casse
  • Export de cache de couches BuildxBizarreries de format de couches, miss de cache cross-runner
use-cases / push-one-build-to-thirty-ci-workers / cta

Arrêtez de pousser le même tarball trente fois. Poussez-le une fois. Laissez trente curl partager le flux.

Lire l'API pipe
use-cases / push-one-build-to-thirty-ci-workers / related

Découvrez les autres