Exploitation et mises à jour

Identifier l’installationCopier le lien du titre

Conservez le dossier privé créé par le lanceur : workspace.json identifie le projet Docker, workspace.env contient ses secrets et image.json son image. Ces fichiers ne vont jamais sur GitHub. Conservez une copie sécurisée séparée de la machine.

Les commandes ci-dessous s’exécutent depuis le kit correspondant à la version actuellement installée, avec les dépendances Python de backend/requirements-dev.txt. Remplacez CHEMIN_PRIVE par le dossier privé de cette installation.

Sauvegarder et vérifier une restaurationCopier le lien du titre

Attendez la fin des calculs et suspendez les nouvelles modifications. Puis :

python scripts/database_backup.py --workspace CHEMIN_PRIVE backup --output backups/before-upgrade.dump
python scripts/database_backup.py --workspace CHEMIN_PRIVE restore backups/before-upgrade.dump

La sauvegarde sélectionne le projet et la base de ce dossier, refuse d’écraser un fichier existant et vérifie que le schéma correspond à l’application utilisée. Les sessions de connexion ne sont pas conservées. La restauration crée une nouvelle base isolée et affiche son nom ; elle ne remplace jamais la base en service. Après vérification de la copie, basculez dessus avec l’option --cutover-to du lanceur.

Copiez les sauvegardes vers un stockage privé indépendant. Planification, chiffrement, purge des anciennes archives, bascule et effacement des données sont décrits dans Sauvegarde et restauration.

Mettre à jour l’applicationCopier le lien du titre

Laissez les travaux en cours se terminer, puis lancez une seule commande avec la nouvelle image construite :

python3 scripts/start_server.py --directory CHEMIN_PRIVE --upgrade-image NOUVELLE_IMAGE

start_local.py accepte la même option pour un espace local. Le lanceur vérifie que l’image existe, écrit une sauvegarde dans CHEMIN_PRIVE/backups/before-upgrade-*.dump, arrête l’API et le worker, enregistre la nouvelle image et la précédente, puis démarre l’ensemble. Setup applique d’abord les migrations ; en cas d’échec, l’API et le worker restent arrêtés et la base est préservée. Certaines migrations demandent une action dans l’application après la mise à jour, par exemple renseigner les horaires hebdomadaires des véhicules : voir Mise à jour.

Vérifiez connexion, langue du compte, données existantes et calcul représentatif avant de rouvrir l’accès. Ne supprimez pas les volumes et ne relancez pas le premier provisionnement. Le retour arrière et la procédure manuelle pour une installation Compose sans lanceur figurent dans Mise à jour.

Supervision et alertesCopier le lien du titre

Définissez MONITOR_TOKEN (au moins 32 caractères aléatoires) pour activer GET /api/v1/metrics : des métriques Prometheus au format texte pour un outil de supervision qui envoie Authorization: Bearer <jeton>. Sans ce réglage, le point d’accès n’existe pas (404). Il est indépendant des comptes utilisateurs et ne donne que des compteurs de l’installation, jamais de données de livraison ou d’utilisateur : disponibilité de la base, état du worker et du routage, calculs en attente et en cours, attente la plus longue, réussites et échecs de la dernière heure, et ancienneté du dernier calcul réussi. Les métriques s’appellent tournevia_*, par exemple tournevia_database_ready et tournevia_jobs_queued.

scrape_configs:
  - job_name: tournevia
    scheme: https
    metrics_path: /api/v1/metrics
    authorization: { type: Bearer, credentials_file: /etc/prometheus/tournevia-token }
    static_configs: [{ targets: ['planner.example.com'] }]

Le fichier deploy/prometheus-alerts.example.yml du kit contient des règles d’alerte de départ : planificateur injoignable, base non prête, worker arrêté, routage indisponible, calculs en attente depuis plus de dix minutes et échecs répétés. Elles utilisent les nouveaux noms de métriques et attendent la tâche de collecte ci-dessus, nommée tournevia. Ajoutez les alertes d’espace disque et d’ancienneté des sauvegardes avec l’outil de supervision de la machine.

Exploitation HTTPS et routageCopier le lien du titre

Renouvelez les certificats avant expiration. Après vérification du certificat et de sa clé, redémarrez uniquement le proxy HTTPS avec la configuration Compose de cette installation. La clé doit rester lisible par le proxy (UID 101) avec des droits restreints.

Surveillez les calculs en échec et leur identifiant, l’espace disque, les sauvegardes et la disponibilité du routage. Un fond de carte visible ne prouve pas que le moteur répond. Une nouvelle donnée routière doit être identifiée par son extrait et sa date.

Avant l’usage opérationnelCopier le lien du titre

Le manuel ne remplace pas les essais d’installation et de restauration, le canal privé de sécurité ni un pilote supervisé. Vérifiez vos contraintes réelles et vos itinéraires avant de recommander l’utilisation en exploitation. Voir Sécurité.

Construire un kit candidatCopier le lien du titre

Cette étape s’adresse au mainteneur qui prépare une distribution, pas à l’exploitant qui rejoint une instance existante.

1. Partez d’une copie du code applicatif propre, testée et commitée.
2. Choisissez la version du candidat et lancez la commande d’empaquetage ci-dessous.
3. Signez le ZIP avec la clé SSH du signataire ; après la construction d’une image, signez aussi ses nomenclatures logicielles.
4. Distribuez le ZIP, sa somme SHA-256 et son .sig par votre canal de confiance, et publiez la clé publique du signataire par un canal indépendant. Le kit exclut secrets, bases de données et graphes routiers.
5. Vérifiez l’installation et la restauration à partir de ce kit avant d’en faire une version supportée.

python scripts/release.py pack --version 0.8.0-rc.1
python scripts/release.py sign --key ~/.ssh/tournevia-release deploy/runtime/releases/france-vrp-0.8.0-rc.1-REVISION.zip

La signature écrit FICHIER.sig à côté de chaque fichier ; elle ne crée jamais de clé et n’écrase jamais une signature. Les destinataires la vérifient avec ssh-keygen -Y verify, un fichier allowed_signers et l’espace de noms tournevia-release (-n tournevia-release) avant d’extraire le kit. release.py build écrit aussi deux nomenclatures logicielles CycloneDX dans deploy/runtime/sbom : les paquets Debian et Python de l’image, et les paquets npm de production de l’interface. Les images de conteneur sont construites localement et ne sont pas publiées : aucune signature d’image n’est produite.

La version ci-dessus est un exemple d’étiquette de candidat, pas l’annonce d’une publication.