Services et exploitation quotidienne
Cette page décrit une installation native en fonctionnement. Utilisez Installation pour la créer, Mise à jour pour changer de version et Installation Docker pour Compose. N'ajoutez pas de CRON doublonnant les timers.
Unités natives
| Unité | Rôle | Planification fournie |
|---|---|---|
lbt-web.service | Application web | Continu |
lbt-pipeline.service / .timer | Téléchargement, ingestion, traitement automatique et intersections d'emprises, dans l'ordre | Après démarrage puis chaque heure, avec délai aléatoire court |
lbt-integration.service / .timer | Contrôle ou intégration selon la configuration | 03 h 30 Europe/Paris, plus au maximum 5 minutes |
lbt-segmentation.service / .timer | Découpage nocturne optionnel | 04 h 15 Europe/Paris, plus au maximum 5 minutes |
lbt-cleaning.service / .timer | Nettoyage des caches et métadonnées pris en charge | 05 h 30 Europe/Paris, plus au maximum 5 minutes |
lbt-email-digests.service / .timer | Examen des synthèses email échues | Cinq minutes après démarrage / fin du passage précédent |
L'intégration demande aussi le découpage après son exécution. Les directives d'ordre ne lancent pas elles-mêmes le pipeline et ne prouvent pas l'existence de nouveautés. L'unité installée et ses surcharges locales déterminent l'horaire effectif. Le fuseau du compte utilisateur n'agit pas sur les timers.
Le timer d'intégration ne rattrape pas automatiquement un passage à l'activation (Persistent=false). Ceux du découpage et du nettoyage sont persistants. Un service oneshot inactif après succès est normal ; consultez son résultat et son timer.
Lire états et journaux
sudo systemctl list-timers --all 'lbt-*'
sudo systemctl show lbt-integration.service -p Result -p ExecMainStatus
sudo journalctl -u lbt-integration.service -n 100 --no-pager
sudo journalctl -u lbt-segmentation.service -n 100 --no-pager
sudo journalctl -u lbt-pipeline.service -n 100 --no-pager
L'unité d'intégration accepte le code 2 comme résultat métier. Contrôlez outcome, les blocages et commit_confirmed dans le rapport. Le succès systemd ne prouve pas l'intégration de toutes les racines. Le découpage possède son propre résultat, même lorsqu'il est appelé par l'unité d'intégration.
Configuration et fichiers
.env.production.local: configuration de production protégée, commune au web et aux traitements..env.development.local: environnement de développement uniquement..env.local: métadonnées publiques de version générées, pas un stockage de secrets..env.db: complément Docker pour la base et Compose.osm/integration/runs/: preuves d'intégration et de découpage, sous le répertoire applicatif.
Utilisez les valeurs littérales décrites dans Installation ; ne sourcez pas le fichier env comme un script shell. Réappliquez les droits documentés après remplacement d'un build ou des dépendances. La procédure native actuelle ne nécessite pas de fichier env distinct pour les emails.
Nettoyage et conservation
Le nettoyage supprime les métadonnées inutilisées éligibles de contributeurs/changesets en conservant les références des changements courants et de l'historique. Côté fichiers, il se limite aux anciens .log de log/, .xml de osm/changeset/ et .osc de osm/osc_update/, selon les durées configurées.
Il ne purge pas osm/source/, les fichiers de réplication ni osm/integration/runs/. Prévoyez séparément surveillance d'espace et archivage des preuves. Un paramètre de conservation ne signifie pas que tous les répertoires sont automatiquement purgés.
Routine d'exploitation
Contrôlez progression de réplication, intégrations échouées/incertaines, anciens blocages, fraîcheur du découpage, activité email et espace libre. Sauvegardez base et configuration protégée avec les éléments nécessaires aux reprises. Une commande de sauvegarde réussie ne remplace pas une vérification périodique de restauration.