Aller au contenu principal

V0.7.0 — Site installable sans le dépôt

Publiée le 17/10/2026.

Documentation fonctionnelle

Ce que change la version pour les collaborateurs

Pourquoi​

On ne pouvait lancer un Site qu’en clonant le dépôt et en construisant les images depuis les sources. Un Administrateur ne pouvait pas poser ArgOS sur une machine Ubuntu comme un produit, ni relire deux procédures distinctes (Mac local vs Ubuntu).

Ce qu'on peut faire maintenant​

  • Construire les quatre images du Site (api, web, pont, certificats) étiquetées ghcr.io/ulyssoulv/argos-…:0.7.0. Sur un Mac Apple Silicon vers Ubuntu amd64, le build se fait avec DOCKER_DEFAULT_PLATFORM=linux/amd64. Scénario 3 — Images étiquetées 0.7.0
  • Les sauver (docker save des quatre images, sans Postgres) et les charger sur Ubuntu (docker load). Scénario 4 — docker save
  • Installer un Site dans /opt/argos sans les sources : compose, .env (sans Sonar), script de Détection, dossier certificats vide pour que Compose démarre. Scénario 5 — /opt/argos après install
  • Relancer le Site avec systemd (argos.service) : restart, conteneur planté qui repart. Scénario 6 — systemd argos.service
  • Ouvrir https://\<IP du Site>, se connecter en Administrateur, voir Administration et Live (pas de Caméras simulées en prod). Scénario 7 — Connexion Scénario 7 — Administration Scénario 7 — Live
  • Activer le réseau des caméras (macvlan) une fois en terminal, comme aujourd’hui. Scénario 9 — macvlan
  • Mettre à jour en rechargeant les images et en relançant le service (scénario 8, sans capture).

Documentation technique

Spec versionnée : docs/specs/v0.7.0-site-installable-sans-le-depot.md

Issue parente : #96

V0.7.0 — Site installable sans le dépôt

Problem Statement​

Aujourd'hui on ne lance un Site qu'en clonant le dépôt : compose.yaml construit api, web et certificats depuis les sources, et le Pont monte un fichier du dépôt. Sans ce clone, pas d'installation, pas de mise à jour. Un Administrateur ne peut pas poser ArgOS sur une machine Ubuntu comme un produit, ni relire deux procédures distinctes (PC local vs machine Ubuntu) dans le README.

Solution​

On construit des images versionnées du Site dans le dépôt, et on fait tourner / mettre à jour un Site sans le dépôt.

Un seul compose.yaml à la racine porte à la fois image: (noms du registre de ce dépôt, ARGOS_VERSION) et build: (contextes du clone). Sur Mac, le lanceur actuel continue de construire. Sur Ubuntu, un script installe un dossier Compose dans /opt/argos (sans les sources), un compte système et une unité systemd qui relance au boot ; les images arrivent par docker save / load (le pull depuis le registre est la 0.7.2).

Le README documente Hébergement local (macOS) et Hébergement Ubuntu, chacun avec prérequis, configuration, installation / lancement.

L'API et l'UI du Site tournent dans les conteneurs : /opt/argos n'a pas besoin des sources api/ et web/. main reste l'unique branche source ; on ne scinde pas le git en staging / production allégée.

User Stories​

Images et compose​

  1. En tant que mainteneur, je veux que api, web, pont et certificats soient des images étiquetées ghcr.io/ulyssoulv/argos-\<service>:\<ARGOS_VERSION>, pour qu'un Site les désigne par une version et pas par un clone.
  2. En tant que mainteneur, je veux que le Pont embarque sa configuration dans l'image, pour qu'Ubuntu n'ait pas besoin du fichier mediamtx.yml du dépôt.
  3. En tant que mainteneur, je veux que Postgres reste l'image officielle épinglée, pour ne pas republier une base.
  4. En tant que développeur, je veux docker compose up --build depuis le clone, pour construire et étiqueter ces noms sans changer d'habitude.
  5. En tant qu'installateur sur Ubuntu, je veux docker compose up sans --build, pour démarrer uniquement avec les images déjà présentes.
  6. En tant qu'installateur, je veux ARGOS_VERSION dans .env, pour choisir quelle version d'images lancer.
  7. En tant que mainteneur, je veux que le service Compose du Pont garde le nom mediamtx, pour ne pas casser la stack existante.

Hébergement local (macOS)​

  1. En tant qu'Administrateur sur un Mac, je veux la procédure actuelle (Docker Desktop, lanceur, .env), pour poser un Site sur le PC devant moi.
  2. En tant qu'Administrateur sur un Mac, je veux que les Caméras simulées restent lancées avec le lanceur, pour essayer le Site sans caméra réelle.
  3. En tant que développeur, je veux une courte section README pour /t, uv et Node, distincte de l'hébergement local.

Hébergement Ubuntu​

  1. En tant qu'installateur, je veux une commande qui crée le Site sur Ubuntu : Docker, .env (compte Administrateur), Détection, compose up sans simulation.
  2. En tant qu'installateur, je veux que cette commande pose le projet Compose dans /opt/argos, pour un emplacement usuel sur la machine.
  3. En tant qu'installateur, je veux un compte système argos (groupe docker) propriétaire de ce dossier, pour ne pas lancer Compose en root.
  4. En tant qu'installateur, je veux une unité systemd installée (enable --now), pour que le Site reparte au boot.
  5. En tant qu'Administrateur, je veux qu'un conteneur planté reparte tout seul (restart: unless-stopped).
  6. En tant qu'Administrateur, je veux qu'un compose up qui échoue au démarrage (Docker pas prêt) soit retenté par systemd (Restart=on-failure).
  7. En tant qu'installateur, je veux que /opt/argos ne contienne que compose, .env, le script de Détection, un dossier certificats vide (bind du certificat fourni) et l'unité — pas le clone, pas la simulation, pas Sonar.
  8. En tant qu'installateur, je veux charger les quatre images par docker load après un docker save depuis le dépôt, tant que le registre n'est pas publié.
  9. En tant qu'Administrateur, je veux que le réseau des caméras déjà livré (macvlan) puisse être activé sur Ubuntu comme aujourd'hui.
  10. En tant qu'Administrateur, je veux ouvrir https://\<IP du Site> après l'installation Ubuntu et me connecter, pour vérifier que l'UI et l'API sont bien ce Site (conteneurs), sans sources sur disque.

README​

  1. En tant qu'installateur, je veux le README en deux parties — Hébergement local et Hébergement Ubuntu — chacune avec prérequis, configuration, installation / lancement.
  2. En tant qu'installateur Ubuntu, je veux que le README décrive save / load des images, le script, /opt/argos et systemd.

Mise à jour (cette version)​

  1. En tant qu'Administrateur Ubuntu, je veux mettre à jour le Site en chargeant de nouvelles images puis en relançant Compose, en changeant ARGOS_VERSION si besoin.

Implementation Decisions​

  • Vocabulaire : Site, images du Site, dépôt. Pas de terme glossaire Serveur. Titres README : Hébergement local, Hébergement Ubuntu.
  • Images ArgOS : api, web, pont (FROM MediaMTX officiel + configuration cuite), certificats. Noms : ghcr.io/ulyssoulv/argos-\<service>:$\{ARGOS_VERSION\}. Publication au registre = 0.7.2 ; en 0.7.0 on étiquette seulement.
  • Compose : un fichier à la racine, image: et build: ensemble. Overlay simulation inchangé, Mac seulement. Ubuntu : compose de prod seul.
  • ADR 0009 : une branche main, images de ce dépôt, compose autonome — pas deux git (staging / production allégée). La promotion d'une image déjà verte (même digest) vers les Sites Ubuntu est le job de 0.7.2 (à noter sur la feuille via /afr).
  • Ubuntu : script d'installation sous scripts/ (pas de .deb). Cible /opt/argos. Unité systemd installée dans /etc/systemd/system/argos.service. After=docker.service network-online.target, WantedBy=multi-user.target, Restart=on-failure. Conteneurs : restart: unless-stopped (déjà).
  • Transfert 0.7.0 : docker save / load des quatre images, documenté. Pas de build sur la machine Ubuntu.
  • .env du Site : ARGOS_VERSION ; les clés Sonar restent au clone, pas copiées dans /opt/argos.
  • Windows, reverse proxy / VPN internet : hors périmètre.

Testing Decisions​

Un bon test vérifie un comportement observable (compose valide, script d'installation, lanceur Mac, stack avec simulation inchangée), pas le détail d'un Dockerfile.

Seams (les plus hauts déjà là) :

  • docker compose -f compose.yaml config : compose de prod autonome, interpolation ARGOS_VERSION, pas de simulation.
  • tests/scripts/ (prior art : lanceur Mac, configurer-detection) : script d'installation dans un préfixe factice (création du dossier, copie des fichiers, contenu de l'unité systemd) ; pas besoin d'un Ubuntu réel en CI.
  • Image du Pont : la configuration MediaMTX est dans l'image (plus de bind du dépôt pour le compose de prod).
  • tests/api/ et tests/web/ via tests/stack_compose.py : overlay simulation inchangé ; la stack de tests reste clone + --build.
  • Tests humains : hébergement local Mac (lanceur) ; procédure Ubuntu autant que possible (save/load + script, ou lecture guidée du README si pas de machine Ubuntu sous la main).

Out of Scope​

  • CI des PR (0.7.1).
  • Publication au registre GitHub, docker compose pull, promotion d'une image staging vers les Sites Ubuntu (0.7.2).
  • Isolation VLAN / caméras sans internet (0.7.2).
  • Serveur de temps des Caméras (0.7.3).
  • Windows comme hébergement local.
  • Accès distant par VPN / reverse proxy depuis internet (Plus tard).
  • Paquet .deb / apt.
  • Branche git production sans sources ; renommer main en staging.
  • Bugs #86 et #95.

Changements apportés aux versions antérieures​

VersionÉlémentAvantAprèsÀ annoter
0.3.0PontImage MediaMTX officielle + fichier du dépôt montéImage ArgOS du Pont, configuration cuitev0.3.0, ADR 0001
0.4.0systemd LinuxExemple dans la doc, rien d'installé par ArgOSScript d'installation, unité activéev0.4.0, doc réseau et Détection
0.1.0–0.6.4LancementClone obligatoire, build: seulClone pour construire ; Site Ubuntu sans sourcesREADME, compose.yaml

Further Notes​

  • Le Site héberge déjà l'API et l'UI : elles s'exécutent dans les conteneurs api et web. Un futur client, ou un accès depuis internet, parlera à cette API (https://\<IP du Site>/api).
  • Compte argos : aligné avec l'exemple déjà écrit dans la doc réseau (0.4.0), désormais installé pour de bon.