Déployer depuis un hôte alternatif

Par défaut, un seul poste admin déploie tout le parc (voir Déploiement). Un déployeur unique est un point de défaillance : s’il tombe, plus aucun just apply n’est possible. On peut promouvoir un hôte alternatif, typiquement un serveur puissant et souvent disponible, en déployeur de secours autonome capable de piloter le parc à la place du poste admin.

Le principe

Un déployeur ne repose que sur quatre éléments. Deux existent déjà sur chaque hôte, deux se préparent une fois.

Élément	Détail	À faire
Outillage	colmena, just, sops (via un profil admin)	Activer un drapeau
Cache binaire	harmonia propre au déployeur	Activer un service
Espace de travail	clone du dépôt (config + framework)	Cloner + synchroniser
Identité SSH nix	déjà autorisée sur tout le parc	Copier la clé privée

La topologie visée : deux déployeurs alimentés par une source commune, chacun capable de déployer le parc.

Activer l’outillage

Les outils de déploiement accompagnent un profil home admin (ex. nix-admin), mais restent masqués tant que l’hôte ne se déclare pas hôte d’administration. Activez ce drapeau sur l’hôte alternatif :

# usr/machines/<hôte>/features.nix
darkone.admin.nix.enable = true;

• L’utilisateur qui déploiera doit porter un profil home admin.
• Serveur sans bureau, les paquets graphiques du profil sont automatiquement exclus : l’outillage installé reste léger.

Garder le profil d’hôte serveur

Inutile de basculer l’hôte en profil admin-desktop, qui tirerait tout un bureau. Le seul drapeau darkone.admin.nix.enable suffit à débloquer colmena et just dans le home de l’utilisateur.

git refuse d’ouvrir le dépôt : safe.directory

darkone.admin.nix.enable installe l’outillage, mais colmena/nix évalue le flake sous l’utilisateur nix, pas celui qui a cloné /etc/nixos : git refuse alors d’ouvrir le dépôt (repository path ... is not owned by current user). Activez aussi :

# usr/machines/<hôte>/features.nix
darkone.console.git.enable = true;

Ce module déclare /etc/nixos en safe.directory dans /etc/gitconfig, lisible par tout utilisateur du système. Un hôte déjà en profil admin-desktop ou darkone.profile.advanced.enable l’a déjà : rien à faire de plus.

Adjoindre un cache binaire

Recommandé : donner au déployeur son propre cache binaire. Il compile le parc, puis re-sert ses dérivations aux autres hôtes.

etc/config.yaml

services:
  harmonia:
    global: true

• global: true rend le cache joignable cross-zone via le VPN, utile quand le déployeur et ses cibles ne sont pas dans la même zone.
• La clé de signature est déjà gérée par sops, commune à tout le réseau : rien de neuf à provisionner.

Déployeur nomade

Déployeur alternatif sur un portable qui change de zone ? Activez aussi le mode roaming du cache (darkone.service.nix-cache.roaming) : ses substituters suivent la zone où il est branché au lieu de rester figés sur sa zone déclarée.

Mettre en place

1. Déclarer et déployer. Depuis le poste admin, poser les deux options ci-dessus, régénérer, puis déployer l’hôte alternatif :

   just generate
   just apply <hôte>

2. Cloner l’espace de travail sur l’hôte alternatif, au même chemin que sur le poste admin, avec le sous-dépôt du framework au même endroit.

   Chemin verrouillé

   Le flake référence le framework par un chemin absolu (git+file:///etc/nixos/dnf). Le clone doit vivre exactement à cet emplacement, sinon l’évaluation échoue.

3. Partager la source. Un remote git commun, ou un pull régulier depuis le poste admin, tient les deux déployeurs alignés. Seul l’état committé est déployé.

4. Copier la clé privée de l’utilisateur de déploiement (nix) vers l’hôte alternatif, en 600 et propriété de nix :

   # sur l'hôte alternatif
   /home/nix/.ssh/id_ed25519

   Sa clé publique est déjà autorisée sur tout le parc, aucun redéploiement des accès n’est nécessaire.

5. Valider depuis l’hôte alternatif :

   colmena --version
   just apply <cible-témoin> test

Deux déployeurs, une règle d’or

Un seul déployeur à la fois

Chaque déployeur pousse depuis son propre clone. Deux apply concurrents peuvent appliquer deux états divergents au parc. Déployez toujours depuis un seul poste à la fois et gardez les clones synchronisés via le remote partagé.

Jusqu’où va ce déployeur

Usage	Clé admin sops
Déployer et inspecter (apply, exec, enter, reboot)	Non requise
Éditer ou faire tourner les secrets	Requise

Le déploiement seul n’a pas besoin de la clé admin : les secrets se déchiffrent sur chaque cible avec sa clé d’infra. Ne copiez la clé admin sur l’hôte alternatif que si vous voulez aussi y gérer les secrets.