Pular para o conteúdo
TipoDesbloqueadoEstágioProduçãoDificuldadeModeradoTrabalhoOtimizar custosParaDevOps & infraServiçosArquivosServiçosContêineresPor que HoodyEconomia de contêineresPor que HoodyHTTP-nativo
TipoDesbloqueadoEstágioProduçãoDificuldadeModeradoTrabalhoOtimizar custosParaDevOps & infraServiçosArquivosServiçosContêineresPor que HoodyEconomia de contêineresPor que HoodyHTTP-nativo
TipoDesbloqueadoEstágioProduçãoDificuldadeModeradoTrabalhoOtimizar custosParaDevOps & infraServiçosArquivosServiçosContêineresPor que HoodyEconomia de contêineresPor que HoodyHTTP-nativo
TipoDesbloqueadoEstágioProduçãoDificuldadeModeradoTrabalhoOtimizar custosParaDevOps & infraServiçosArquivosServiçosContêineresPor que HoodyEconomia de contêineresPor que HoodyHTTP-nativo
Voltar aos casos de uso
use-cases / ci-cache-without-s3 / hero
FILES · CACHE · COST-OPTIMIZE

O cache de CI que não é uma linha de fatura do S3

A maioria dos pipelines de CI queima dinheiro em tráfego de cache — push de artefatos para o S3, pull no próximo job, paga por armazenamento, paga por egress, paga de novo quando os runners trocam de região. Na Hoody, o cache é uma pasta no mesmo bare metal que roda seu contêiner de build. Push do tarball com curl. Pull com curl. Os bytes nunca saem da máquina.

Ler a Files API
use-cases / ci-cache-without-s3 / mechanism

Três curls e um cron

O cache de CI inteiro são três comandos e um job de limpeza. PUT para escrever um tarball. GET para ler. find -atime para podar. Não tem quarta peça — sem IAM policy, sem bucket lifecycle, sem cerimônia de signed URL.

WRITE

Comprimir e PUT

Após o install, o runner faz stream de node_modules por tar | zstd para um único PUT contra /files/cache. A Hoody escreve o body em disco como um único blob binário. Sem multipart, sem part-uploader, sem SDK.

# Após yarn install, push do artefatotar c node_modules | zstd -T0 | curl -T - https://files.containers.hoody.com/cache/$KEY.tar.zst
READ

GET e untar

O primeiro passo do próximo job é um curl. O body sai do NVMe na velocidade da linha porque o cache mora na mesma máquina física que o runner — sem hop de egress, sem pull cross-AZ, sem edge do CloudFront.

# Próximo job: pull e untar em uma linhacurl -fsS https://files.containers.hoody.com/cache/$KEY.tar.zst | tar x -I zstd
PRUNE

find -atime · noturno

O Hoody Cron dispara uma vez por noite. find /files/cache -atime +30 -delete joga fora qualquer coisa que nenhum job leu em um mês. Sem política de retenção, sem tier do Glacier, sem JSON de lifecycle para manter.

# Cron noturno — qualquer coisa não lida em 30d saifind /files/cache -atime +30 -delete

PUT escreve. GET lê. find poda. A Files API da Hoody é o servidor de cache, o motor de cleanup e o audit log — tudo atrás da mesma URL /files/[path].

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

Três poderes do cache-como-pasta

Empurrar o cache para um fornecedor separado fazia sentido quando armazenamento era escasso. Em um contêiner bare-metal, isso só adiciona um fornecedor.

ECONOMIA

Sem GB-mês, sem egress, sem requests

O S3 cobra três medidores: armazenamento, egress e por-request. O Hoody Files vem com o contêiner — o disco que você já paga é o disco onde o cache fica. Os bytes nunca cruzam fronteira de cobrança.

LATÊNCIA

NVMe em vez de cross-region

As leituras saem da mesma máquina física que roda o build. Não há endpoint S3 para resolver, sem TLS handshake para uma região, sem rate limit de throughput de prefixo. Um Rust target de 1,4 GB é desempacotado em segundos.

PROPRIEDADE

Uma relação com fornecedor, não duas

Seu runner e seu cache moram na mesma instância, faturados na mesma invoice, debugados com a mesma sessão SSH. Quando você desliga o contêiner, o cache é a imagem de disco — de volta online no momento em que você o inicia.

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

O que evapora da fatura

Uma pegada típica de CI de tamanho médio movimenta cerca de 1,4 TB de tráfego de cache por mês. Aqui está o item de linha que isso cria na AWS, e o item de linha que cria na Hoody.

ANTES · FATURA S3este mês, na AWS
  • Armazenamento · GB-mês$1,0947,2 GB × $0,023
  • Egress · GB out$127,801,42 TB × $0,090
  • PUT requests$2,06412k × $5/M
  • GET requests$4,5611,4M × $0,40/M
  • CloudFront / NAT−$57,71pull cross-AZ
total mensal$78
cinco itens de linha · cinco taxas · um bucket
DEPOIS · HOODY FILESeste mês, na Hoody
  • Disco no contêinerno extra chargejá pago no plano do contêiner
  • Egress entre jobsno extra chargeloopback · fica na máquina
  • Requests PUT / GETno per-request or per-GB metersem medidor por-request
  • Relação com fornecedorno extra chargeo runner e o cache são uma fatura
  • 47,2 GB usadosdo planofolga do mesmo disco que roda o contêiner
total mensalincluded in server price
um disco · uma fatura · zero novo fornecedor

Quando o cache mora na máquina que roda o build, o medidor que o S3 estava rodando não tem nada para ler. O item de linha não se mexe porque não há transação para cobrar.

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

O que o endpoint Files garante

O Hoody Files não é um wrapper fino — é um backend persistente real com hashing, histórico, range reads e um journal de auditoria. O cache de CI usa uma fatia fina do que de fato está exposto.

  1. UMA URL · QUALQUER ARTEFATO/files/[path]

    PUT para escrever, GET para ler, HEAD para ETag e Content-Length, ?hash para SHA256, ?stat para metadata. O cache é a mesma família de endpoint que alimenta logs, builds e artefatos compartilhados.

  2. LEITURAS NO TEMPO?at · ?revision

    Toda escrita passa pelo journal de arquivos. Pull do cache de ontem por timestamp ou por número de revisão por path — debugar um flake para de exigir uma ferramenta de snapshot separada.

  3. MONTE QUANDO PASSAR DO LIMITE60+ backends

    Se o cache realmente precisar morar no S3, B2 ou em uma pasta do Drive, monte como backend e mantenha a mesma URL /files/[path]. O código do runner nunca muda — o cache só muda.

Os números refletem a superfície publicada da Files API da Hoody — `GET/PUT/HEAD/PATCH /api/v1/files/[path]`, os parâmetros de query `?hash`/`?stat`/`?at`/`?revision`/`?history` e os endpoints de journal de arquivos sob `/api/v1/journal`.

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

Seu cache de CI deixa de ser um fornecedor separado. É uma pasta na máquina que você já aluga.

ontem · cinco taxashoje · um disco
O QUE A FATURA ANTIGA TINHABucket S3 + egress + requests + lifecyclecinco itens de linha · IAM separado · fornecedor separado
O QUE É AGORAPUT /files/cache/$KEY · GET /files/cache/$KEYdois curls — e o cache é o próprio disco do runner
Ler a spec do Files
use-cases / ci-cache-without-s3 / replaces

O que isso substitui

Os backends de cache padrão cada um cobra de você uma relação de fornecedor, uma conta de egress ou uma taxa por build. O /files não cobra nenhum desses.

  • Bucket S3 da AWS como cacheArmazenamento, egress, requests — três medidores para um tarball que você guarda dois dias
  • Cache do GitHub Actions10 GB grátis, depois taxas por GB e uma eviction de 7 dias que você não pode ajustar
  • BuildJet cachePreço por runner para armazenamento que mora fora do runner mesmo assim
  • Serviços de remote cache do BazelUm daemon inteiro a mais e um protocolo de cache para babá
  • Turborepo Remote CachePreço por build para um tarball que seu monorepo já produziu
  • Earthly Cloud cacheUm backend remoto gerenciado para o que é só curl + tar
use-cases / ci-cache-without-s3 / cta

Pare de alugar um cache de uma segunda nuvem. Escreva o tarball no disco que você já paga, e curl de volta.

Ler a Files API
use-cases / ci-cache-without-s3 / related

Leia os outros