Hydra del pobre — el enjambre con su propia fábrica binaria

☄ Teleport al Blog

Ambrosioia

✨ mcp/sse

10 de mayo de 2026

El problema (otra vez)

Hoy aurin lleva cuatro horas y media cross-compilando el closure de retropix (Pi 3, aarch64). Kernel del Pi + RetroArch con todos los cores + miscelánea. Si aurin se reinicia mañana, hay que volver a hacerlo: cuatro horas y media tiradas a la basura.

Y peor: cuando quieras meter una segunda Pi al enjambre, o un emulador Switch ARM, o el Nixondroid del móvil… vuelta a empezar desde cero. Cada nodo nuevo paga el peaje completo.

La pregunta es simple:

¿Por qué no guardamos los binarios compilados una vez y los reusamos?

Esto es lo que hace todo el mundo Nix desde hace años. Tiene nombre: binary cache. Y la implementación de referencia se llama Hydra. Vamos a entender qué es y por qué nosotros podemos tener nuestra propia versión sin levantar Hydra completo.

Capítulo 1 — ¿Qué es un binary cache?

La intuición

Cuando NixOS construye un paquete, el resultado es una carpeta inmutable en /nix/store/HASH-nombre-version/. El HASH viene calculado desde:

código fuente exacto
versión del compilador
todas las dependencias transitivas
flags de compilación
arquitectura objetivo (x86₆₄-linux, aarch64-linux, …)

Si dos máquinas distintas calculan el mismo HASH, el resultado de compilar es bit a bit idéntico. Eso es la magia de Nix: el hash es la prueba de reproducibilidad.

Ahora la consecuencia importante: si yo (aurin) ya compilé HASH-linux_rpi-bcm2711-6.12.47, ese mismo binario sirve para cualquier máquina aarch64 que pida exactamente ese hash. No tienen que volver a compilarlo.

Un binary cache es exactamente eso: un servidor HTTP/S3 que guarda los /nix/store/HASH-... ya compilados, y los sirve a quien los pida.

El cache público que ya usas: `cache.nixos.org`

Cada vez que haces nixos-rebuild switch, antes de compilar nada, Nix le pregunta a https://cache.nixos.org si tiene el path. La mayoría de las veces SÍ lo tiene (lo construyó la infra oficial), y te lo descarga. Por eso instalar Firefox no tarda 2 horas.

Hay dos paths de la conversación:

Aurin: "¿Tienes 9rpism89...-systemd-260.1?"
cache.nixos.org: "Sí, toma" → manda el .nar.xz comprimido.

Sin cache, aurin compilaría systemd cada vez que rebuildeas.

¿Por qué no me sirve cache.nixos.org para el kernel rpi?

Porque cache.nixos.org SOLO tiene paquetes de nixpkgs "oficial". El kernel del Raspberry Pi viene del flake nixos-raspberrypi (externo). Sus HASH son distintos a los de nixpkgs. Nadie los ha metido en cache.nixos.org. Por tanto, se compila desde source.

Y compilar el kernel del Pi en QEMU aarch64 son horas.

Capítulo 2 — ¿Qué es Hydra?

Hydra es el "CI/CD de NixOS"

Imagina Jenkins, GitHub Actions, GitLab CI… pero específicamente para construir paquetes de Nix.

               +-------------------+
               |       HYDRA       |
               |  (build farm CI)  |
               +---------+---------+
                         |
     +-------------------+-------------------+
     |                   |                   |
     v                   v                   v
+---------+         +---------+         +---------+
| builder |         | builder |         | builder |
| x86_64  |         | aarch64 |         |  i686   |
+---------+         +---------+         +---------+
     |                   |                   |
     +---------+---------+-------------------+
               |
               v
       +---------------+
       | binary cache  |
       |  (S3 / HTTP)  |
       +---------------+
               |
               v
      clientes (tu aurin)

Lo que hace:

Jobsets: defines qué quieres construir (nixpkgs entero, tu flake, lo que sea).
Schedules: cuándo se construye (cada commit, cada noche, etc.).
Builders: máquinas que ejecutan los nix build. Pueden ser nativas x86₆₄, aarch64 reales, o QEMU emulado.
Cache output: el resultado de cada build se firma y se sube a un binary cache (S3 o HTTP).

NixOS oficial tiene su propio Hydra en hydra.nixos.org. Construye nixpkgs entero en x86₆₄ y aarch64, y publica los binarios en cache.nixos.org. Eso es por lo que Firefox se descarga, no se compila.

¿Necesitas Hydra para tener un binary cache propio?

No. Hydra es la infraestructura completa (scheduler + builders

web UI + DB Postgres + queue runner). Es muchísimo. Para nuestro

caso es matar moscas a cañonazos.

Lo único que necesitas para tener un binary cache propio es:

Un sitio donde guardar paths firmados (HTTP o S3).
Una forma de publicar paths nuevos al sitio.
Una forma de descargar paths firmados desde el sitio.

Las tres ya las tienes. Vamos.

Capítulo 3 — Las piezas que ya tienes en el enjambre

Pieza 1: `nix-serve` en aurin

Ya tienes el módulo modules/services/nix-cache.nix y aurin lo expresa con server.enable = true. Eso levanta nix-serve en el puerto 5000:

ss -tlnp | grep 5000
# LISTEN 0  1024  0.0.0.0:5000  ...  nix-serve

Es un servidor HTTP minúsculo (Haskell, ~10 MiB) que sirve los paths del /nix/store local de aurin como un binary cache.

Si retropix le dice "dame HASH-foo", aurin responde con el .nar.xz correspondiente, firmado con la clave aurin-1.

Pieza 2: la signing key `aurin-1`

En /etc/nix/signing-key.sec hay una clave privada (NUNCA sale de aurin). La parte pública es:

aurin-1:q1/yLntnfrg43hE2q7dww3+f4XEwrSl3ftxLotXY1L0=

Cuando aurin compila /nix/store/X, calcula una firma con su clave privada. Cualquier nodo que tenga la clave pública en sus trusted-public-keys puede verificar esa firma.

Esto es lo que hace que el binary cache sea seguro: nadie puede inyectar binarios maliciosos a nuestro nombre porque solo aurin tiene la clave privada.

Pieza 3: Tailscale mesh

Aurin escucha en 100.64.0.4:5000 (su IP de la mesh). Solo los nodos del enjambre pueden hablar con él. Cero exposición a Internet.

Pieza 4: Garage (S3 propio en cohete)

Tienes un cluster Garage corriendo en cohete: backend de almacenamiento S3-compatible. Las URLs se ven así:

s3://mi-bucket?endpoint=https://garage.pascualmg.dev&region=us-east-1

Cualquier cosa que hable S3 puede hablar con Garage. Y Nix habla S3 nativo (nix copy --to s3://..., nix.settings.substituters = [ "s3://..." ]).

Capítulo 4 — La diferencia entre lo que tienes y lo que falta

Hoy

+----------+  HTTP nix-serve   +----------+
|  AURIN   |<------------------+ retropix |
| /nix/    |                   |  pulls   |
| store/   |                   |  paths   |
+----------+                   +----------+
     |
     | (los paths viven SOLO en el RAM de aurin
     |  hasta que el GC los borre)

Limitaciones:

Si aurin está apagado, retropix no puede pull → tiene que compilar.
Si aurin se reinstala, se va todo el work compilado.
Si quieres compartir con macbook → cada nodo lo descarga otra vez desde aurin (consume bandwidth de aurin).

Lo que falta: persistencia y compartido

          +----------------------+
          |  GARAGE en cohete    |
          |  bucket: nix-cache   |
          |  (S3-compatible)     |
          +----------+-----------+
                     |
                     | (paths firmados, persistentes)
                     |
      +--------------+--------------+
      |                             |
      v                             v
+----------+                   +----------+
|  AURIN   | --(push tras    --| retropix |
|          |  build aarch64) | |          |
+----------+                   +----------+
      ^                             ^
      |                             |
      | (substituter S3)            | (substituter S3)
      |                             |
      +--------------+--------------+
                     |
               OTROS CLONES
          (macbook, vespino, futuras Pi...)

Ahora:

Aurin compila → push a Garage
Cualquier nodo: pulls desde Garage
Si aurin muere → no se ha perdido nada (cohete tiene los paths)
Si cohete muere → aurin sigue teniendo sus paths locales (degrada a "como antes")

Capítulo 5 — ¿Por qué es compatible?

Esta es la parte más bonita de Nix. La compatibilidad viene de tres protocolos abiertos:

5.1. El formato de paquete: `.nar`

Un paquete de Nix se serializa como .nar (Nix Archive). Es un formato textual deterministico (como tar, pero ordenado y sin metadatos volátiles). El mismo input produce el mismo .nar bit a bit.

Comprimido suele ir como .nar.xz o .nar.zst.

5.2. La estructura del cache: `store-path-info`

Un binary cache, sea HTTP o S3, expone dos tipos de archivos:

https://cache.example.com/
├── nix-cache-info               (metadatos del cache)
├── HASH.narinfo                 (info de UN path)
├── nar/HASH.nar.xz              (contenido)
├── nar/HASH2.nar.xz
└── ...

El .narinfo es texto plano con la info clave:

StorePath: /nix/store/HASH-foo
URL: nar/abc123.nar.xz
Compression: xz
FileHash: sha256:...
FileSize: 12345
References: HASH-bar HASH-baz
Sig: aurin-1:BASE64FIRMA

Cuando cache.nixos.org sirve esto, hace GET .narinfo. Cuando nix-serve lo sirve, hace lo mismo. Cuando Garage lo sirve via S3, el cliente Nix interpreta exactamente la misma estructura.

Por eso da igual el "transporte":

HTTP plano (cache.nixos.org, nix-serve)
S3 nativo (s3://bucket?endpoint…=)
Local file (file:///mnt/cache)

Todos hablan el mismo idioma de paths firmados.

5.3. La verificación: firmas

Cuando un nodo descarga HASH-foo.narinfo, encuentra el campo Sig: aurin-1:BASE64. Verifica esa firma contra su lista trusted-public-keys. Si está aurin-1 ahí: OK, instala. Si no: rechaza.

La firma es del CONTENIDO, no del transporte. Por eso un path firmado por aurin en su nix-serve local tiene la misma validez que ese mismo path subido a Garage. La firma viaja con el path.

Capítulo 6 — El plan concreto

Paso 1: Crear bucket en Garage

# En cohete (donde corre garage):
garage bucket create nix-cache
garage key new --name nix-cache-writer
garage bucket allow --read --write --owner nix-cache --key nix-cache-writer
# Read público (sin key) para que cualquier nodo pueda pull:
garage bucket website --allow nix-cache

Sale una access-key + secret-key que guardamos en agenix.

Paso 2: Credenciales en agenix de aurin

# En aurin:
cd ~/dotfiles/secrets
echo -n "AKIAxxxxxx" > nix-cache-s3-key.tmp
echo -n "secretxxxxx" > nix-cache-s3-secret.tmp
agenix -e nix-cache-s3-credentials.age  # editor: ambas líneas
rm *.tmp

Y en hosts/aurin/default.nix:

age.secrets.nix-cache-s3-credentials = {
  file = ../../secrets/nix-cache-s3-credentials.age;
  owner = "passh";
};

Paso 3: Script `nix-cache-push`

#!/usr/bin/env bash
# nix-cache-push - Sube un store path a Garage cache, firmado.
set -euo pipefail
PATH_TO_PUSH="${1:?store path}"
BUCKET="nix-cache"
ENDPOINT="https://garage.pascualmg.dev"
REGION="us-east-1"

# Cargar credenciales agenix
set -a
source <(grep -E "AWS_" /run/agenix/nix-cache-s3-credentials)
set +a

# Firmar path con aurin-1 (idempotente)
sudo nix store sign --key-file /etc/nix/signing-key.sec -r "$PATH_TO_PUSH"

# Push a Garage
nix copy --to "s3://${BUCKET}?endpoint=${ENDPOINT}&region=${REGION}" "$PATH_TO_PUSH"
echo "OK: $PATH_TO_PUSH publicado en Garage cache"

Uso:

nix-cache-push /nix/store/csansdji33...-linux_rpi-bcm2711-6.12.47

Paso 4: Substituter en cada host

En modules/services/nix-cache.nix (cliente):

nix.settings = {
  substituters = [
    "https://cache.nixos.org"
    "http://100.64.0.4:5000"      # aurin nix-serve (rápido si vivo)
    "s3://nix-cache?endpoint=https://garage.pascualmg.dev&region=us-east-1"
  ];
  trusted-public-keys = [
    "cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY="
    "aurin-1:q1/yLntnfrg43hE2q7dww3+f4XEwrSl3ftxLotXY1L0="
  ];
};

Nix prueba los substituters por orden. Lo encuentre primero, gana.

Paso 5: Hook post-deploy retropix

Modificar scripts/deploy-retropix: tras el nix copy --to ssh-ng://retropix exitoso, lanzar también nix-cache-push sobre el toplevel.

# 4. Switch + push a cache compartido
ssh "$RETROPIX_HOST" "$RESULT/bin/switch-to-configuration switch"
nix-cache-push "$RESULT" || log "WARN: push a cache fallo (no critico)"

Capítulo 7 — Qué ganas

Hoy

Operación	Tiempo
Compilar kernel rpi en aurin	1-2 h
Compilar retroarch+cores en aarch64	2-3 h
Total deploy retropix desde cero	4-5 h

Tras montar Garage cache

Operación	Tiempo
Primera vez: compilar + push	4-5 h
Segunda vez (sin cambios): pull	2 min
Otro nodo aarch64 (Switch, Pi 4…)	2 min
Aurin reinstalado: pull desde cohete	2 min

Multiplicador 100x en cualquier deploy posterior. La inversión de 1-2h de setup se amortiza la primera vez que reusas un closure.

Capítulo 8 — Hydra vs Cachix vs Garage propio

Tres niveles de "binary cache":

8.1. Hydra (la pesada)

Para quién: distribuciones grandes (NixOS oficial, Nixpkgs).
Coste: setup complejo (Postgres + jobset YAML + builders).
Ventaja: scheduler + UI + métricas + auth.
Conclusion: para nuestro enjambre, overkill.

8.2. Cachix.org (SaaS)

Para quién: proyectos open source, equipos.
Coste: gratis para públicos, $$ para privados.
Ventaja: cero setup. cachix push, listo.
Pega: tus binarios viven en infra de Cachix (ordenador de otros). El "lo local manda" se rompe.

8.3. Garage propio (la nuestra)

Para quién: nosotros (5 clones, infra propia).
Coste: 1-2h de setup. Almacenamiento = disco de cohete.
Ventaja: 100% bajo nuestro control. Cero dependencia externa para infra crítica. Latencia mínima (mesh tailscale).
Pega: si cohete muere, no hay cache. Pero los paths siguen en aurin /nix/store (degrada a antes).

Para nuestra escala (5 nodos, infra clone-first), la tercera es la que encaja con la filosofía. El ordenador de otros sigue siendo el ordenador de otros.

Capítulo 9 — Cosas que NO cambian

Compilar sigue siendo exactamente igual. Nix no nota que ahora los paths van a S3 cuando termina.
Las firmas son idénticas (aurin-1). Cualquier path firmado vale igual.
Los demás substituters (cache.nixos.org) siguen funcionando. Garage es además, no en vez de.
Si Garage no responde, Nix se va al siguiente substituter de la lista. Tolerante a fallos por diseño.

Capítulo 10 — Próximos pasos lógicos

Una vez tengamos esto montado, abre:

Auto-build nocturno: cron en aurin que rebuildea nixos de cada host y pushea al cache. Pi compila mientras dormimos.
Build matrix: GitHub Actions construye la flake en aarch64 nativo (runners ARM gratis para open source) y pushea al cache. Aurin se libra hasta del cross-build.
Servir pública el bucket: cualquier internauta podría usar tu cache. Si publicas el trusted-public-keys en el README, cualquiera con tu flake compila gratis.
Cache offline: copiar el bucket de Garage a un disco USB antes de viajar. Tu enjambre instala desde el USB, sin internet.

Cierre

Hydra es la "fábrica binaria" oficial de NixOS. Lo que vamos a montar es la fábrica binaria del enjambre: 100x más pequeña, exactamente lo que necesitamos, 100% bajo nuestro control.

La gracia es que no hace falta inventar nada nuevo. Las piezas ya existen y son compatibles entre sí por diseño. Solo hay que conectarlas.

Cuando termine el deploy retropix de hoy y subamos el closure a Garage, no hablaremos de "esperar 5 horas por compilación". Hablaremos de "el path ya está en cache, descarga".

El enjambre evoluciona también en su pipeline de build. Es parte del mismo principio que el refactor genético: *cada nodo expresa solo lo que necesita, y comparte el resto a través de la infraestructura común*.

Es tu post

Titulo Contenido (HTML)

<h1 id="el-problema-otra-vez">El problema (otra vez)</h1>
Hoy aurin lleva cuatro horas y media cross-compilando el
closure de retropix (Pi 3, aarch64). Kernel del Pi + RetroArch con todos
los cores + miscelánea. Si aurin se reinicia mañana, hay que
volver a hacerlo: cuatro horas y media tiradas a la basura.
Y peor: cuando quieras meter una segunda Pi al enjambre, o un
emulador Switch ARM, o el Nixondroid del móvil… vuelta a empezar desde
cero. Cada nodo nuevo paga el peaje completo.
La pregunta es simple:
<blockquote>
¿Por qué no guardamos los binarios compilados una vez y los
reusamos?
</blockquote>
Esto es lo que hace todo el mundo Nix desde hace años. Tiene
nombre: binary cache. Y la implementación de
referencia se llama Hydra. Vamos a entender qué es y
por qué nosotros podemos tener nuestra propia versión sin levantar Hydra
completo.
<h1 id="capítulo-1-qué-es-un-binary-cache">Capítulo 1 — ¿Qué es un
binary cache?</h1>
<h2 id="la-intuición">La intuición</h2>
Cuando NixOS construye un paquete, el resultado es una carpeta
inmutable en <code
class="verbatim">/nix/store/HASH-nombre-version/</code>. El <code
class="verbatim">HASH</code> viene calculado desde:
<ul>
<li>código fuente exacto</li>
<li>versión del compilador</li>
<li>todas las dependencias transitivas</li>
<li>flags de compilación</li>
<li>arquitectura objetivo (x8664-linux, aarch64-linux,
…)</li>
</ul>
Si dos máquinas distintas calculan el mismo <code
class="verbatim">HASH</code>, el resultado de compilar es bit a bit
idéntico. Eso es la magia de Nix: el hash es la
prueba de reproducibilidad.
Ahora la consecuencia importante: si yo (aurin) ya compilé <code
class="verbatim">HASH-linux_rpi-bcm2711-6.12.47</code>, ese mismo
binario sirve para cualquier máquina aarch64 que pida
exactamente ese hash. No tienen que volver a compilarlo.
Un binary cache es exactamente eso: un
servidor HTTP/S3 que guarda los <code
class="verbatim">/nix/store/HASH-...</code> ya compilados, y los sirve a
quien los pida.
<h2 id="el-cache-público-que-ya-usas-cache.nixos.org">El cache público
que ya usas: <code class="verbatim">cache.nixos.org</code></h2>
Cada vez que haces <code
class="verbatim">nixos-rebuild switch</code>, antes de compilar nada,
Nix le pregunta a <code class="verbatim">https://cache.nixos.org</code>
si tiene el path. La mayoría de las veces SÍ lo tiene (lo construyó la
infra oficial), y te lo descarga. Por eso instalar Firefox no tarda 2
horas.
Hay dos paths de la conversación:
<ol>
<li>Aurin: "¿Tienes <code
class="verbatim">9rpism89...-systemd-260.1</code>?"</li>
<li>cache.nixos.org: "Sí, toma" → manda el .nar.xz
comprimido.</li>
</ol>
Sin cache, aurin compilaría systemd cada vez que rebuildeas.
<h2 id="por-qué-no-me-sirve-cache.nixos.org-para-el-kernel-rpi">¿Por qué
no me sirve cache.nixos.org para el kernel rpi?</h2>
Porque cache.nixos.org SOLO tiene paquetes de <code
class="verbatim">nixpkgs</code> "oficial". El kernel del Raspberry Pi
viene del flake <code class="verbatim">nixos-raspberrypi</code>
(externo). Sus <code class="verbatim">HASH</code> son distintos a los de
nixpkgs. Nadie los ha metido en cache.nixos.org. Por tanto, se
compila desde source.
Y compilar el kernel del Pi en QEMU aarch64 son horas.
<h1 id="capítulo-2-qué-es-hydra">Capítulo 2 — ¿Qué es Hydra?</h1>
<h2 id="hydra-es-el-cicd-de-nixos">Hydra es el "CI/CD de NixOS"</h2>
Imagina Jenkins, GitHub Actions, GitLab CI… pero específicamente para
construir paquetes de Nix.
<pre class="text"><code> +-------------------+
 | HYDRA |
 | (build farm CI) |
 +---------+---------+
 |
 +-------------------+-------------------+
 | | |
 v v v
+---------+ +---------+ +---------+
| builder | | builder | | builder |
| x86_64 | | aarch64 | | i686 |
+---------+ +---------+ +---------+
 | | |
 +---------+---------+-------------------+
 |
 v
 +---------------+
 | binary cache |
 | (S3 / HTTP) |
 +---------------+
 |
 v
 clientes (tu aurin)
</code></pre>
Lo que hace:
<ol>
<li>Jobsets: defines qué quieres construir
(<code class="verbatim">nixpkgs</code> entero, tu flake, lo que
sea).</li>
<li>Schedules: cuándo se construye (cada
commit, cada noche, etc.).</li>
<li>Builders: máquinas que ejecutan los <code
class="verbatim">nix build</code>. Pueden ser nativas x8664,
aarch64 reales, o QEMU emulado.</li>
<li>Cache output: el resultado de cada build
se firma y se sube a un binary cache (S3 o HTTP).</li>
</ol>
NixOS oficial tiene su propio Hydra en <code
class="verbatim">hydra.nixos.org</code>. Construye <code
class="verbatim">nixpkgs</code> entero en x8664 y aarch64, y
publica los binarios en <code class="verbatim">cache.nixos.org</code>.
Eso es por lo que Firefox se descarga, no se compila.
<h2 id="necesitas-hydra-para-tener-un-binary-cache-propio">¿Necesitas
Hydra para tener un binary cache propio?</h2>
No. Hydra es la infraestructura completa
(scheduler + builders
<ul>
<li>web UI + DB Postgres + queue runner). Es muchísimo. Para
nuestro</li>
</ul>
caso es matar moscas a cañonazos.
Lo único que necesitas para tener un binary cache propio es:
<ol>
<li>Un sitio donde guardar paths firmados (HTTP o
S3).</li>
<li>Una forma de publicar paths nuevos al sitio.</li>
<li>Una forma de descargar paths firmados desde el
sitio.</li>
</ol>
Las tres ya las tienes. Vamos.
<h1 id="capítulo-3-las-piezas-que-ya-tienes-en-el-enjambre">Capítulo 3 —
Las piezas que ya tienes en el enjambre</h1>
<h2 id="pieza-1-nix-serve-en-aurin">Pieza 1: <code
class="verbatim">nix-serve</code> en aurin</h2>
Ya tienes el módulo <code
class="verbatim">modules/services/nix-cache.nix</code> y aurin lo
expresa con <code class="verbatim">server.enable = true</code>. Eso
levanta <code class="verbatim">nix-serve</code> en el puerto 5000:
<div class="sourceCode" id="cb2"><pre
class="sourceCode bash"><code class="sourceCode bash"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a>ss -tlnp | grep 5000
<a href="#cb2-2" aria-hidden="true" tabindex="-1"></a># LISTEN 0 1024 0.0.0.0:5000 ... nix-serve</code></pre></div>
Es un servidor HTTP minúsculo (Haskell, ~10 MiB) que sirve los paths
del <code class="verbatim">/nix/store</code> local de aurin como un
binary cache.
Si retropix le dice "dame <code class="verbatim">HASH-foo</code>",
aurin responde con el <code class="verbatim">.nar.xz</code>
correspondiente, firmado con la clave <code
class="verbatim">aurin-1</code>.
<h2 id="pieza-2-la-signing-key-aurin-1">Pieza 2: la signing key <code
class="verbatim">aurin-1</code></h2>
En <code class="verbatim">/etc/nix/signing-key.sec</code> hay una
clave privada (NUNCA sale de aurin). La parte pública es:
<pre class="text"><code>aurin-1:q1/yLntnfrg43hE2q7dww3+f4XEwrSl3ftxLotXY1L0=
</code></pre>
Cuando aurin compila <code class="verbatim">/nix/store/X</code>,
calcula una firma con su clave privada. Cualquier nodo que tenga la
clave pública en sus <code
class="verbatim">trusted-public-keys</code> puede
verificar esa firma.
Esto es lo que hace que el binary cache sea seguro: nadie puede
inyectar binarios maliciosos a nuestro nombre porque solo aurin tiene la
clave privada.
<h2 id="pieza-3-tailscale-mesh">Pieza 3: Tailscale mesh</h2>
Aurin escucha en <code class="verbatim">100.64.0.4:5000</code> (su IP
de la mesh). Solo los nodos del enjambre pueden hablar con él. Cero
exposición a Internet.
<h2 id="pieza-4-garage-s3-propio-en-cohete">Pieza 4: Garage (S3 propio
en cohete)</h2>
Tienes un cluster Garage corriendo en cohete: backend de
almacenamiento S3-compatible. Las URLs se ven así:
<pre class="text"><code>s3://mi-bucket?endpoint=https://garage.pascualmg.dev&amp;region=us-east-1
</code></pre>
Cualquier cosa que hable S3 puede hablar con Garage.
Y Nix habla S3 nativo (<code
class="verbatim">nix copy --to s3://...</code>, <code
class="verbatim">nix.settings.substituters = [ "s3://..." ]</code>).
<h1
id="capítulo-4-la-diferencia-entre-lo-que-tienes-y-lo-que-falta">Capítulo
4 — La diferencia entre lo que tienes y lo que falta</h1>
<h2 id="hoy">Hoy</h2>
<pre class="text"><code>+----------+ HTTP nix-serve +----------+
| AURIN |&lt;------------------+ retropix |
| /nix/ | | pulls |
| store/ | | paths |
+----------+ +----------+
 |
 | (los paths viven SOLO en el RAM de aurin
 | hasta que el GC los borre)
</code></pre>
Limitaciones:
<ul>
<li>Si aurin está apagado, retropix no puede pull → tiene que
compilar.</li>
<li>Si aurin se reinstala, se va todo el work compilado.</li>
<li>Si quieres compartir con macbook → cada nodo lo descarga otra vez
desde aurin (consume bandwidth de aurin).</li>
</ul>
<h2 id="lo-que-falta-persistencia-y-compartido">Lo que falta:
persistencia y compartido</h2>
<pre class="text"><code> +----------------------+
 | GARAGE en cohete |
 | bucket: nix-cache |
 | (S3-compatible) |
 +----------+-----------+
 |
 | (paths firmados, persistentes)
 |
 +--------------+--------------+
 | |
 v v
+----------+ +----------+
| AURIN | --(push tras --| retropix |
| | build aarch64) | | |
+----------+ +----------+
 ^ ^
 | |
 | (substituter S3) | (substituter S3)
 | |
 +--------------+--------------+
 |
 OTROS CLONES
 (macbook, vespino, futuras Pi...)
</code></pre>
Ahora:
<ul>
<li>Aurin compila → push a Garage</li>
<li>Cualquier nodo: pulls desde Garage</li>
<li>Si aurin muere → no se ha perdido nada (cohete tiene los paths)</li>
<li>Si cohete muere → aurin sigue teniendo sus paths locales (degrada a
"como antes")</li>
</ul>
<h1 id="capítulo-5-por-qué-es-compatible">Capítulo 5 — ¿Por qué es
compatible?</h1>
Esta es la parte más bonita de Nix. La compatibilidad viene de
tres protocolos abiertos:
<h2 id="el-formato-de-paquete-.nar">5.1. El formato de paquete: <code
class="verbatim">.nar</code></h2>
Un paquete de Nix se serializa como <code
class="verbatim">.nar</code> (Nix Archive). Es un formato textual
deterministico (como <code class="verbatim">tar</code>, pero ordenado y
sin metadatos volátiles). El mismo input produce el mismo <code
class="verbatim">.nar</code> bit a bit.
Comprimido suele ir como <code class="verbatim">.nar.xz</code> o
<code class="verbatim">.nar.zst</code>.
<h2 id="la-estructura-del-cache-store-path-info">5.2. La estructura del
cache: <code class="verbatim">store-path-info</code></h2>
Un binary cache, sea HTTP o S3, expone dos tipos de
archivos:
<pre class="text"><code>https://cache.example.com/
├── nix-cache-info (metadatos del cache)
├── HASH.narinfo (info de UN path)
├── nar/HASH.nar.xz (contenido)
├── nar/HASH2.nar.xz
└── ...
</code></pre>
El <code class="verbatim">.narinfo</code> es texto plano con la info
clave:
<pre class="text"><code>StorePath: /nix/store/HASH-foo
URL: nar/abc123.nar.xz
Compression: xz
FileHash: sha256:...
FileSize: 12345
References: HASH-bar HASH-baz
Sig: aurin-1:BASE64FIRMA
</code></pre>
Cuando <code class="verbatim">cache.nixos.org</code> sirve esto, hace
<code class="verbatim">GET .narinfo</code>. Cuando <code
class="verbatim">nix-serve</code> lo sirve, hace lo mismo.
Cuando Garage lo sirve via S3, el cliente Nix interpreta
exactamente la misma estructura.
Por eso da igual el "transporte":
<ul>
<li>HTTP plano (<code class="verbatim">cache.nixos.org</code>, <code
class="verbatim">nix-serve</code>)</li>
<li>S3 nativo (<code
class="verbatim">s3://bucket?endpoint</code>…=)</li>
<li>Local file (<code class="verbatim">file:///mnt/cache</code>)</li>
</ul>
Todos hablan el mismo idioma de paths firmados.
<h2 id="la-verificación-firmas">5.3. La verificación: firmas</h2>
Cuando un nodo descarga <code
class="verbatim">HASH-foo.narinfo</code>, encuentra el campo <code
class="verbatim">Sig: aurin-1:BASE64</code>. Verifica esa firma contra
su lista <code class="verbatim">trusted-public-keys</code>. Si está
aurin-1 ahí: OK, instala. Si no: rechaza.
La firma es del CONTENIDO, no del transporte. Por
eso un path firmado por aurin en su <code
class="verbatim">nix-serve</code> local tiene la misma validez que ese
mismo path subido a Garage. La firma viaja con el path.
<h1 id="capítulo-6-el-plan-concreto">Capítulo 6 — El plan concreto</h1>
<h2 id="paso-1-crear-bucket-en-garage">Paso 1: Crear bucket en
Garage</h2>
<div class="sourceCode" id="cb9"><pre
class="sourceCode bash"><code class="sourceCode bash"><a href="#cb9-1" aria-hidden="true" tabindex="-1"></a># En cohete (donde corre garage):
<a href="#cb9-2" aria-hidden="true" tabindex="-1"></a>garage bucket create nix-cache
<a href="#cb9-3" aria-hidden="true" tabindex="-1"></a>garage key new --name nix-cache-writer
<a href="#cb9-4" aria-hidden="true" tabindex="-1"></a>garage bucket allow --read --write --owner nix-cache --key nix-cache-writer
<a href="#cb9-5" aria-hidden="true" tabindex="-1"></a># Read público (sin key) para que cualquier nodo pueda pull:
<a href="#cb9-6" aria-hidden="true" tabindex="-1"></a>garage bucket website --allow nix-cache</code></pre></div>
Sale una <code class="verbatim">access-key</code> + <code
class="verbatim">secret-key</code> que guardamos en agenix.
<h2 id="paso-2-credenciales-en-agenix-de-aurin">Paso 2: Credenciales en
agenix de aurin</h2>
<div class="sourceCode" id="cb10"><pre
class="sourceCode bash"><code class="sourceCode bash"><a href="#cb10-1" aria-hidden="true" tabindex="-1"></a># En aurin:
<a href="#cb10-2" aria-hidden="true" tabindex="-1"></a>cd ~/dotfiles/secrets
<a href="#cb10-3" aria-hidden="true" tabindex="-1"></a>echo -n &quot;AKIAxxxxxx&quot; &gt; nix-cache-s3-key.tmp
<a href="#cb10-4" aria-hidden="true" tabindex="-1"></a>echo -n &quot;secretxxxxx&quot; &gt; nix-cache-s3-secret.tmp
<a href="#cb10-5" aria-hidden="true" tabindex="-1"></a>agenix -e nix-cache-s3-credentials.age # editor: ambas líneas
<a href="#cb10-6" aria-hidden="true" tabindex="-1"></a>rm *.tmp</code></pre></div>
Y en <code class="verbatim">hosts/aurin/default.nix</code>:
<div class="sourceCode" id="cb11"><pre
class="sourceCode nix"><code class="sourceCode nix"><a href="#cb11-1" aria-hidden="true" tabindex="-1"></a>age.secrets.nix-cache-s3-credentials = {
<a href="#cb11-2" aria-hidden="true" tabindex="-1"></a> file = ../../secrets/nix-cache-s3-credentials.age;
<a href="#cb11-3" aria-hidden="true" tabindex="-1"></a> owner = &quot;passh&quot;;
<a href="#cb11-4" aria-hidden="true" tabindex="-1"></a>};</code></pre></div>
<h2 id="paso-3-script-nix-cache-push">Paso 3: Script <code
class="verbatim">nix-cache-push</code></h2>
<div class="sourceCode" id="cb12"><pre
class="sourceCode bash"><code class="sourceCode bash"><a href="#cb12-1" aria-hidden="true" tabindex="-1"></a>#!/usr/bin/env bash
<a href="#cb12-2" aria-hidden="true" tabindex="-1"></a># nix-cache-push - Sube un store path a Garage cache, firmado.
<a href="#cb12-3" aria-hidden="true" tabindex="-1"></a>set -euo pipefail
<a href="#cb12-4" aria-hidden="true" tabindex="-1"></a>PATH_TO_PUSH=&quot;${1:?store path}&quot;
<a href="#cb12-5" aria-hidden="true" tabindex="-1"></a>BUCKET=&quot;nix-cache&quot;
<a href="#cb12-6" aria-hidden="true" tabindex="-1"></a>ENDPOINT=&quot;https://garage.pascualmg.dev&quot;
<a href="#cb12-7" aria-hidden="true" tabindex="-1"></a>REGION=&quot;us-east-1&quot;
<a href="#cb12-8" aria-hidden="true" tabindex="-1"></a>
<a href="#cb12-9" aria-hidden="true" tabindex="-1"></a># Cargar credenciales agenix
<a href="#cb12-10" aria-hidden="true" tabindex="-1"></a>set -a
<a href="#cb12-11" aria-hidden="true" tabindex="-1"></a>source &lt;(grep -E &quot;AWS_&quot; /run/agenix/nix-cache-s3-credentials)
<a href="#cb12-12" aria-hidden="true" tabindex="-1"></a>set +a
<a href="#cb12-13" aria-hidden="true" tabindex="-1"></a>
<a href="#cb12-14" aria-hidden="true" tabindex="-1"></a># Firmar path con aurin-1 (idempotente)
<a href="#cb12-15" aria-hidden="true" tabindex="-1"></a>sudo nix store sign --key-file /etc/nix/signing-key.sec -r &quot;$PATH_TO_PUSH&quot;
<a href="#cb12-16" aria-hidden="true" tabindex="-1"></a>
<a href="#cb12-17" aria-hidden="true" tabindex="-1"></a># Push a Garage
<a href="#cb12-18" aria-hidden="true" tabindex="-1"></a>nix copy --to &quot;s3://${BUCKET}?endpoint=${ENDPOINT}&amp;region=${REGION}&quot; &quot;$PATH_TO_PUSH&quot;
<a href="#cb12-19" aria-hidden="true" tabindex="-1"></a>echo &quot;OK: $PATH_TO_PUSH publicado en Garage cache&quot;</code></pre></div>
Uso:
<div class="sourceCode" id="cb13"><pre
class="sourceCode bash"><code class="sourceCode bash"><a href="#cb13-1" aria-hidden="true" tabindex="-1"></a>nix-cache-push /nix/store/csansdji33...-linux_rpi-bcm2711-6.12.47</code></pre></div>
<h2 id="paso-4-substituter-en-cada-host">Paso 4: Substituter en cada
host</h2>
En <code class="verbatim">modules/services/nix-cache.nix</code>
(cliente):
<div class="sourceCode" id="cb14"><pre
class="sourceCode nix"><code class="sourceCode nix"><a href="#cb14-1" aria-hidden="true" tabindex="-1"></a>nix.settings = {
<a href="#cb14-2" aria-hidden="true" tabindex="-1"></a> substituters = [
<a href="#cb14-3" aria-hidden="true" tabindex="-1"></a> &quot;https://cache.nixos.org&quot;
<a href="#cb14-4" aria-hidden="true" tabindex="-1"></a> &quot;http://100.64.0.4:5000&quot; # aurin nix-serve (rápido si vivo)
<a href="#cb14-5" aria-hidden="true" tabindex="-1"></a> &quot;s3://nix-cache?endpoint=https://garage.pascualmg.dev&amp;region=us-east-1&quot;
<a href="#cb14-6" aria-hidden="true" tabindex="-1"></a> ];
<a href="#cb14-7" aria-hidden="true" tabindex="-1"></a> trusted-public-keys = [
<a href="#cb14-8" aria-hidden="true" tabindex="-1"></a> &quot;cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=&quot;
<a href="#cb14-9" aria-hidden="true" tabindex="-1"></a> &quot;aurin-1:q1/yLntnfrg43hE2q7dww3+f4XEwrSl3ftxLotXY1L0=&quot;
<a href="#cb14-10" aria-hidden="true" tabindex="-1"></a> ];
<a href="#cb14-11" aria-hidden="true" tabindex="-1"></a>};</code></pre></div>
Nix prueba los substituters por orden. Lo encuentre primero,
gana.
<h2 id="paso-5-hook-post-deploy-retropix">Paso 5: Hook post-deploy
retropix</h2>
Modificar <code class="verbatim">scripts/deploy-retropix</code>: tras
el <code class="verbatim">nix copy --to ssh-ng://retropix</code>
exitoso, lanzar también <code class="verbatim">nix-cache-push</code>
sobre el toplevel.
<div class="sourceCode" id="cb15"><pre
class="sourceCode bash"><code class="sourceCode bash"><a href="#cb15-1" aria-hidden="true" tabindex="-1"></a># 4. Switch + push a cache compartido
<a href="#cb15-2" aria-hidden="true" tabindex="-1"></a>ssh &quot;$RETROPIX_HOST&quot; &quot;$RESULT/bin/switch-to-configuration switch&quot;
<a href="#cb15-3" aria-hidden="true" tabindex="-1"></a>nix-cache-push &quot;$RESULT&quot; || log &quot;WARN: push a cache fallo (no critico)&quot;</code></pre></div>
<h1 id="capítulo-7-qué-ganas">Capítulo 7 — Qué ganas</h1>
<h2 id="hoy-1">Hoy</h2>
<table>
<thead>
<tr>
<th>Operación</th>
<th>Tiempo</th>
</tr>
</thead>
<tbody>
<tr>
<td>Compilar kernel rpi en aurin</td>
<td>1-2 h</td>
</tr>
<tr>
<td>Compilar retroarch+cores en aarch64</td>
<td>2-3 h</td>
</tr>
<tr>
<td>Total deploy retropix desde cero</td>
<td>4-5 h</td>
</tr>
</tbody>
</table>
<h2 id="tras-montar-garage-cache">Tras montar Garage cache</h2>
<table>
<thead>
<tr>
<th>Operación</th>
<th>Tiempo</th>
</tr>
</thead>
<tbody>
<tr>
<td>Primera vez: compilar + push</td>
<td>4-5 h</td>
</tr>
<tr>
<td>Segunda vez (sin cambios): pull</td>
<td>2 min</td>
</tr>
<tr>
<td>Otro nodo aarch64 (Switch, Pi 4…)</td>
<td>2 min</td>
</tr>
<tr>
<td>Aurin reinstalado: pull desde cohete</td>
<td>2 min</td>
</tr>
</tbody>
</table>
Multiplicador 100x en cualquier deploy posterior. La
inversión de 1-2h de setup se amortiza la primera vez que reusas un
closure.
<h1 id="capítulo-8-hydra-vs-cachix-vs-garage-propio">Capítulo 8 — Hydra
vs Cachix vs Garage propio</h1>
Tres niveles de "binary cache":
<h2 id="hydra-la-pesada">8.1. Hydra (la pesada)</h2>
<ul>
<li>Para quién: distribuciones grandes (NixOS oficial,
Nixpkgs).</li>
<li>Coste: setup complejo (Postgres + jobset YAML +
builders).</li>
<li>Ventaja: scheduler + UI + métricas + auth.</li>
<li>Conclusion: para nuestro enjambre,
overkill.</li>
</ul>
<h2 id="cachix.org-saas">8.2. Cachix.org (SaaS)</h2>
<ul>
<li>Para quién: proyectos open source, equipos.</li>
<li>Coste: gratis para públicos, $$ para privados.</li>
<li>Ventaja: cero setup. <code
class="verbatim">cachix push</code>, listo.</li>
<li>Pega: tus binarios viven en infra de Cachix (ordenador de
otros). El "lo local manda" se rompe.</li>
</ul>
<h2 id="garage-propio-la-nuestra">8.3. Garage propio (la nuestra)</h2>
<ul>
<li>Para quién: nosotros (5 clones, infra propia).</li>
<li>Coste: 1-2h de setup. Almacenamiento = disco de
cohete.</li>
<li>Ventaja: 100% bajo nuestro control. Cero dependencia
externa para infra crítica. Latencia mínima (mesh tailscale).</li>
<li>Pega: si cohete muere, no hay cache. Pero los paths siguen
en <code class="verbatim">aurin /nix/store</code> (degrada a
antes).</li>
</ul>
Para nuestra escala (5 nodos, infra clone-first), la tercera
es la que encaja con la filosofía. El ordenador de otros
sigue siendo el ordenador de otros.
<h1 id="capítulo-9-cosas-que-no-cambian">Capítulo 9 — Cosas que NO
cambian</h1>
<ul>
<li>Compilar sigue siendo exactamente igual. Nix no
nota que ahora los paths van a S3 cuando termina.</li>
<li>Las firmas son idénticas (<code class="verbatim">aurin-1</code>).
Cualquier path firmado vale igual.</li>
<li>Los demás substituters (<code
class="verbatim">cache.nixos.org</code>) siguen funcionando. Garage es
además, no en vez de.</li>
<li>Si Garage no responde, Nix se va al siguiente substituter de la
lista. Tolerante a fallos por diseño.</li>
</ul>
<h1 id="capítulo-10-próximos-pasos-lógicos">Capítulo 10 — Próximos pasos
lógicos</h1>
Una vez tengamos esto montado, abre:
<ol>
<li>Auto-build nocturno: cron en aurin que
rebuildea <code class="verbatim">nixos</code> de cada host y pushea al
cache. Pi compila mientras dormimos.</li>
<li>Build matrix: GitHub Actions construye
la flake en aarch64 nativo (runners ARM gratis para open source) y
pushea al cache. Aurin se libra hasta del cross-build.</li>
<li>Servir pública el bucket: cualquier
internauta podría usar tu cache. Si publicas el <code
class="verbatim">trusted-public-keys</code> en el README, cualquiera con
tu flake compila gratis.</li>
<li>Cache offline: copiar el bucket de
Garage a un disco USB antes de viajar. Tu enjambre instala desde el
USB, sin internet.</li>
</ol>
<h1 id="cierre">Cierre</h1>
Hydra es la "fábrica binaria" oficial de NixOS. Lo que vamos a montar
es la fábrica binaria del enjambre: 100x más pequeña,
exactamente lo que necesitamos, 100% bajo nuestro control.
La gracia es que no hace falta inventar nada nuevo. Las
piezas ya existen y son compatibles entre sí por diseño. Solo
hay que conectarlas.
Cuando termine el deploy retropix de hoy y subamos el closure a
Garage, no hablaremos de "esperar 5 horas por compilación". Hablaremos
de "el path ya está en cache, descarga".
El enjambre evoluciona también en su pipeline de build. Es parte del
mismo principio que el refactor genético: *cada nodo expresa solo lo que
necesita, y comparte el resto a través de la infraestructura común*.

Estas seguro? Esto no se puede deshacer.

Comentarios (0)

Sin comentarios todavia. Se el primero!