Aller au contenu
TypeDéverrouilléÉtapeProductionDifficultéModéréTravailOptimiser les coûtsPourDevOps & infraServicesFilesServicesContainersPourquoi HoodyÉconomie des conteneursPourquoi HoodyHTTP-natif
TypeDéverrouilléÉtapeProductionDifficultéModéréTravailOptimiser les coûtsPourDevOps & infraServicesFilesServicesContainersPourquoi HoodyÉconomie des conteneursPourquoi HoodyHTTP-natif
TypeDéverrouilléÉtapeProductionDifficultéModéréTravailOptimiser les coûtsPourDevOps & infraServicesFilesServicesContainersPourquoi HoodyÉconomie des conteneursPourquoi HoodyHTTP-natif
TypeDéverrouilléÉtapeProductionDifficultéModéréTravailOptimiser les coûtsPourDevOps & infraServicesFilesServicesContainersPourquoi HoodyÉconomie des conteneursPourquoi HoodyHTTP-natif
Retour aux cas d'utilisation
use-cases / ci-cache-without-s3 / hero
FILES · CACHE · OPTIMISATION COÛT

Le cache CI qui n'est pas une ligne de facture S3

La plupart des pipelines CI brûlent de l'argent sur le trafic de cache — pousser les artefacts vers S3, les retirer au job suivant, payer le stockage, payer l'egress, repayer quand les runners changent de région. Sur Hoody, le cache est un dossier sur le même bare metal qui fait tourner votre conteneur de build. Poussez un tarball avec curl. Tirez-le avec curl. Les octets ne quittent jamais la machine.

Lire l'API Files
use-cases / ci-cache-without-s3 / mechanism

Trois curl et un cron

Tout le cache CI, c'est trois commandes et un job de nettoyage. PUT pour écrire un tarball. GET pour le lire. find -atime pour purger. Il n'y a pas de quatrième pièce — pas de policy IAM, pas de lifecycle de bucket, pas de cérémonie d'URL signée.

ÉCRIRE

Compresser et PUT

Après l'install, le runner streame node_modules à travers tar | zstd dans un seul PUT contre /files/cache. Hoody écrit le corps sur disque comme un seul blob binaire. Pas de multipart, pas de part-uploader, pas de SDK.

# Après yarn install, pousse l'artefacttar c node_modules | zstd -T0 | curl -T - https://files.containers.hoody.com/cache/$KEY.tar.zst
LIRE

GET et untar

La première étape du job suivant est un seul curl. Le corps sort du NVMe à pleine ligne car le cache vit sur la même machine physique que le runner — pas de saut d'egress, pas de pull cross-AZ, pas d'edge CloudFront.

# Job suivant : pull et untar en une lignecurl -fsS https://files.containers.hoody.com/cache/$KEY.tar.zst | tar x -I zstd
PURGER

find -atime · la nuit

Hoody Cron tourne une fois par nuit. find /files/cache -atime +30 -delete jette tout ce qu'aucun job n'a lu depuis un mois. Pas de politique de rétention, pas de tier Glacier, pas de JSON de lifecycle à maintenir.

# Cron nocturne — tout ce qui est non-lu en 30j disparaîtfind /files/cache -atime +30 -delete

PUT écrit. GET lit. find purge. L'API Hoody Files est le serveur de cache, le moteur de nettoyage et le journal d'audit — le tout derrière la même URL /files/[path].

use-cases / ci-cache-without-s3 / powers

Trois pouvoirs du cache-comme-dossier

Pousser le cache chez un fournisseur séparé avait du sens quand le stockage était rare. Sur un conteneur bare metal, ça ne fait qu'ajouter un fournisseur.

ÉCONOMIE

Pas de GB-mois, pas d'egress, pas de requêtes

S3 facture trois compteurs : stockage, egress, par-requête. Hoody Files est inclus dans le prix du serveur à tarif fixe — le disque que vous louez déjà est le disque où repose le cache. Les octets ne traversent jamais une frontière de facturation.

LATENCE

NVMe au lieu de cross-region

Les lectures sortent de la même machine physique qui fait tourner le build. Pas d'endpoint S3 à résoudre, pas de handshake TLS vers une région, pas de rate limit sur le débit de préfixe. Une cible Rust de 1,4 GB se décompresse en quelques secondes.

PROPRIÉTÉ

Une relation fournisseur, pas deux

Votre runner et votre cache vivent sur la même instance, facturés sur la même facture, debuggés avec la même session SSH. Quand vous éteignez le conteneur, le cache est l'image disque — de retour en ligne dès que vous le démarrez.

use-cases / ci-cache-without-s3 / invoice

Ce qui s'évapore de la facture

Une empreinte CI mid-size typique déplace environ 1,4 TB de trafic de cache par mois. Voici la ligne qu'elle construit sur AWS ; sur Hoody le cache s'exécute dans le serveur à tarif fixe que vous payez déjà.

AVANT · FACTURE S3ce mois-ci, sur AWS
  • Stockage · GB-mois1,09 $47,2 GB × 0,023 $
  • Egress · GB sortants127,80 $1,42 TB × 0,090 $
  • Requêtes PUT2,06 $412k × 5 $/M
  • Requêtes GET4,56 $11,4M × 0,40 $/M
  • CloudFront / NAT−57,71 $pull cross-AZ
total mensuel$78
cinq lignes · cinq tarifs · un bucket
APRÈS · HOODY FILESce mois-ci, sur Hoody
  • Disque sur le serveurno extra chargecouvert par la facture mensuelle fixe du serveur
  • Egress entre jobsno extra chargeloopback · reste sur la machine
  • Requêtes PUT / GETno per-request or per-GB meterpas de compteur par requête
  • Relation fournisseurno extra chargele runner et le cache sont une seule facture
  • 47,2 GB utilisésdu forfaitmarge sur le même disque serveur que vous louez déjà
total mensuelincluded in server price
un disque · une facture · zéro nouveau fournisseur

Quand le cache vit sur la machine qui fait tourner le build, le compteur que S3 faisait tourner n'a rien à lire. La ligne ne bouge pas car il n'y a pas de transaction à facturer.

use-cases / ci-cache-without-s3 / capacity

Ce que garantit l'endpoint Files

Hoody Files n'est pas un wrapper léger — c'est un vrai backend persistant avec hashing, historique, lectures par range et journal d'audit. Le cache CI utilise une fine tranche de ce qui est réellement exposé.

  1. UNE URL · TOUT ARTEFACT/files/[path]

    PUT pour écrire, GET pour lire, HEAD pour ETag et Content-Length, ?hash pour SHA256, ?stat pour les métadonnées. Le cache est la même famille d'endpoints qui propulse les logs, builds et artefacts partagés.

  2. LECTURES VOYAGE-DANS-LE-TEMPS?at · ?revision

    Chaque écriture passe par le journal de fichiers. Tirez le cache d'hier par timestamp ou par numéro de révision par chemin — debugger un flake n'exige plus un outil de snapshot séparé.

  3. MONTER SI VOUS LE DÉPASSEZ60+ backends

    Si le cache doit vraiment vivre sur S3, B2 ou un dossier Drive, montez-le comme backend et gardez la même URL /files/[path]. Le code du runner ne change jamais — le cache déménage.

Les chiffres reflètent la surface publiée de l'API Hoody Files — `GET/PUT/HEAD/PATCH /api/v1/files/[path]`, les paramètres de requête `?hash`/`?stat`/`?at`/`?revision`/`?history`, et les endpoints du journal de fichiers sous `/api/v1/journal`.

use-cases / ci-cache-without-s3 / punchline

Votre cache CI cesse d'être un fournisseur séparé. C'est un dossier sur la machine que vous louez déjà.

hier · cinq tarifsaujourd'hui · un disque
CE QU'AVAIT L'ANCIENNE FACTUREBucket S3 + egress + requêtes + lifecyclecinq lignes · IAM séparé · fournisseur séparé
CE QUE C'EST MAINTENANTPUT /files/cache/$KEY · GET /files/cache/$KEYdeux curl — et le cache est le propre disque du runner
Lire la spec Files
use-cases / ci-cache-without-s3 / replaces

Ce que ça remplace

Les backends de cache standards facturent chacun une relation fournisseur, une facture d'egress ou des frais par build. /files ne facture rien de tout cela.

  • Bucket AWS S3 comme cacheStockage, egress, requêtes — trois compteurs pour un tarball gardé deux jours
  • Cache GitHub Actions10 GB gratuits, puis frais par GB et éviction 7 jours non réglable
  • Cache BuildJetTarification par runner pour du stockage qui vit hors du runner de toute façon
  • Services de remote cache BazelTout un second daemon et un protocole de cache à entretenir
  • Turborepo Remote CacheTarification par build pour un tarball que votre monorepo produit déjà
  • Cache Earthly CloudUn backend distant managé pour ce qui n'est que curl + tar
use-cases / ci-cache-without-s3 / cta

Arrêtez de louer un cache à un second cloud. Écrivez le tarball sur le disque que vous payez déjà, et tirez-le avec curl.

Lire l'API Files
use-cases / ci-cache-without-s3 / related

Découvrez les autres