Passer wgautomesh en prod #9

Merged

lx merged 11 commits from wgautomesh into main

2023-03-24 11:05:29 +00:00

lx commented

2023-03-17 16:35:39 +00:00

Owner

wgautomesh semble fonctionner correctement sur staging, on pourrait envisager de le déployer en prod.

Problème: Le build du paquet NixOS met un peu de temps car il y a pas mal de Rust à compiler (j'ai essayé de minimiser mais Rust c'est comme ça, on a pas trop le choix). Sur staging les noeuds utilisent nix.web.deuxfleurs.fr comme cache, mais c'est un peu casse-gueule de le mettre comme cache sur la prod :

si Garage est pas dispo, on peut potentiellement plus rebuild NixOS (mais apparament il y a un flag --fallback qui permet de dire que si le cache est pas dispo, on compile les sources, ce qui serait ok dans notre cas, juste un peu plus lent quand y'a une màj de wgautomesh)
plus facile de faire une supply chain attack si quelqu'un arrive à infiltrer un mauvais binaire dans le bucket nix

Quelle stratégie adopter ?

Option 1 : on build sur tous les noeuds, c'est long pour le premier deploy mais c'est ok
Option 2 : on met nix.web.deuxfleurs.fr en cache sur les machines de prod
Option 3 : on compile un binaire statique qu'on envoie sur gitea dans les releases, et on download ça dans le paquet NixOS plutôt que de compiler from source
Option 4 : on met un cache Nix ailleurs sur une machine ultra fiable quelque part
Option 5 : attendre la stabilisation de https://github.com/NixOS/nix/pull/7188

L'option 3 m'a l'air possiblement la meilleure

`wgautomesh` semble fonctionner correctement sur staging, on pourrait envisager de le déployer en prod. **Problème:** Le build du paquet NixOS met un peu de temps car il y a pas mal de Rust à compiler (j'ai essayé de minimiser mais Rust c'est comme ça, on a pas trop le choix). Sur staging les noeuds utilisent `nix.web.deuxfleurs.fr` comme cache, mais c'est un peu casse-gueule de le mettre comme cache sur la prod : - si Garage est pas dispo, on peut potentiellement plus rebuild NixOS (mais apparament il y a un flag `--fallback` qui permet de dire que si le cache est pas dispo, on compile les sources, ce qui serait ok dans notre cas, juste un peu plus lent quand y'a une màj de wgautomesh) - plus facile de faire une supply chain attack si quelqu'un arrive à infiltrer un mauvais binaire dans le bucket `nix` Quelle stratégie adopter ? - Option 1 : on build sur tous les noeuds, c'est long pour le premier deploy mais c'est ok - Option 2 : on met nix.web.deuxfleurs.fr en cache sur les machines de prod - Option 3 : on compile un binaire statique qu'on envoie sur gitea dans les releases, et on download ça dans le paquet NixOS plutôt que de compiler from source - Option 4 : on met un cache Nix ailleurs sur une machine ultra fiable quelque part - Option 5 : attendre la stabilisation de <https://github.com/NixOS/nix/pull/7188> L'option 3 m'a l'air possiblement la meilleure

lx added 5 commits 2023-03-17 16:35:40 +00:00