Compose par projet

v0.0.1-alpha

Première version publique du Pier Agent — le démon que tu installes sur ton serveur pour le piloter à distance depuis le hub Pier. Voici tout ce qu'il sait faire.

#### Déploiement

Compose par projet : l'agent maintient un seul docker-compose.yml par projet sous <AppsDir>/<orgSlug>/<projectSlug>/. La commande deploy-app rend la stack du projet et (re)lance uniquement les services de l'app ciblée (<appSlug> + son <appSlug>-nginx) — les apps voisines du même projet ne sont jamais redémarrées. stop, restart et delete-app ciblent eux aussi les services de cette app dans le compose.
Build + push d'images : build-image construit l'image depuis le dépôt et la pousse vers le registre, avec une authentification fournie par le hub.
Étapes granulaires : pendant build-image et deploy-app, l'agent émet des events de stage (build → push → load → start, chacun running / succeeded / failed) pour un suivi étape par étape côté hub.
Logs live : la sortie du build et du docker compose up est streamée en temps réel au hub (même flux que l'attempt), au lieu de rester muette jusqu'à la fin.
Conf child-nginx : écrite dans <projectDir>/nginx/<appSlug>.conf (là où le compose la monte) ; les variables d'environnement sont inlinées directement dans le compose (pas de .env séparé).

#### Robustesse / auto-réparation

Conflit de nom de conteneur : si un conteneur portant le container_name cible existe déjà (orphelin, reliquat d'un ancien run), l'agent le retire (docker rm -f) puis relance le compose up au lieu d'échouer.
Conf nginx auto-créée en répertoire : si Docker avait créé <projectDir>/nginx/<appSlug>.conf en dossier (source de bind manquante lors d'un run antérieur), l'agent le supprime et réécrit un fichier — corrige l'erreur de mount « not a directory ».
Réseaux externes manquants : l'agent crée les réseaux external: true requis (ex. reverse-proxy-<org>) avant le compose up au lieu d'échouer.

#### Santé temps réel

Métriques hôte poussées toutes les 5 s sans intervention : CPU, mémoire, disque — en utilisé et en total.
Métriques par conteneur : CPU et mémoire de chaque conteneur (via docker stats).
Streaming activable/désactivable à distance depuis le hub (commande set-health-streaming) ; l'état est persisté côté hub et re-synchronisé à chaque connexion.

#### Cycle de vie & sécurité

Identité : l'agent dérive son empreinte sha256(token) ; le hub n'autorise que les empreintes enrôlées.
Mise à jour à distance, vérifiée GPG : commande update déclenchée par le client depuis le hub — le binaire téléchargé est vérifié (signature GPG) avant le swap. L'unité systemd accorde ReadWritePaths=/usr/local/bin pour permettre le self-update.
Agent révoqué : reste connecté (le hub peut toujours lui envoyer des commandes) mais cesse d'émettre (le hub coupe son streaming dès la connexion) et n'est jamais marqué online.
Abandon après refus d'auth répétés : si le hub rejette les credentials 10 fois de suite (HTTP 401/403 — empreinte inconnue ou révoquée), l'agent passe offline au lieu de spammer le gateway. Les pannes réseau transitoires (hub injoignable) ne comptent pas : l'agent continue de réessayer, et un handshake réussi remet le compteur à zéro. Pour le réactiver : corriger/ré-enrôler le token puis redémarrer l'agent.
Auto-destruction : la commande self-destruct (envoyée par le hub à la suppression du serveur) désinstalle complètement l'agent — binaire, unité systemd, config, état et logs — via un process détaché. Les conteneurs déjà déployés sont laissés intacts.

#### Installation & exploitation

Installeur : install.sh pose le binaire (/usr/local/bin/pierrr-agent), l'unité systemd et la config, puis enrôle l'agent auprès du hub.
Layout sur disque : config dans /etc/pierrr-agent/, état (apps, backups, last_ok_at) dans /var/lib/pierrr-agent/, logs dans /var/log/pierrr-agent/ (chemins surchargeables par env).
Désinstallation propre : pierrr-agent uninstall retire l'unité, les dossiers (config/état/logs) et le binaire — en respectant les chemins configurés — sans toucher aux conteneurs déployés.
Sonde de santé : pierrr-agent healthz est vert uniquement si l'agent a eu un échange WebSocket récent et réussi avec le hub (reflète « connecté », pas seulement « process up »).

> Installer / mettre à jour : exécuter install.sh sur le serveur, ou déclencher la mise à jour à distance depuis le hub (bouton « Mettre à jour ») une fois l'agent enrôlé.