Améliorer le process de mise à jour #73

Open
opened 2026-05-21 17:56:35 +02:00 by unurled · 3 comments
Owner

Synced from GitHub: https://github.com/flambeaux-org/Sacadoc/issues/113
Author: @logut | Created: 2026-03-12


Le système de mise à jour est assez fragile, il faudrait l'améliorer, notament :

  • que les fichiers obsolètes soient supprimés
  • si une lib python supplémentaire est ajouté, il faut qu'elle soit installée
  • rollback automatiquement si la page d'accueil ne répond pas en 200 (ou un peu plus de tests)

Une piste pour ça :

  1. Build un container avec des actions github en prévoyant que la db, media et static soient montés sur l'host
    voir si on peut utiliser whitenoise pour les static, il faut voir comment on gère le fichier de settings de prod, soit on passe tout en var d'env, soit mount un dossier avec le fichier dedans (pas un fichier, ça change d'inode lors des modifs)
    qui lance les migrations en start du container
  2. un script qui tourne sur l'host installé par le playbook ansible, lancé en root par systemd
  3. écoute sur un "named pipe" des commandes simples "install x.y.z"
  4. pull, down le container, backup, up avec la nouvelle version
    (voir comment je fait ça, modifier l'unit sacadoc.container + daemon-reload + start ?) commande podman ? faut que ce soit pas écrasé par ansible si je relance le playbook
  5. attends que le service systemd soit up + x seconds et curl/ fait les vérifs que c'est up
  6. si pas ok, stop, restore le backup et start l'ancien tag

Il faut que malgré les modifs à sacadoc, le dev reste simple.

> **Synced from GitHub:** https://github.com/flambeaux-org/Sacadoc/issues/113 > **Author:** @logut | **Created:** 2026-03-12 --- Le système de mise à jour est assez fragile, il faudrait l'améliorer, notament : * que les fichiers obsolètes soient supprimés * si une lib python supplémentaire est ajouté, il faut qu'elle soit installée * rollback automatiquement si la page d'accueil ne répond pas en 200 (ou un peu plus de tests) Une piste pour ça : 1. Build un container avec des actions github en prévoyant que la db, media et static soient montés sur l'host *voir si on peut utiliser whitenoise pour les static*, il faut voir comment on gère le fichier de settings de prod, soit on passe tout en var d'env, soit mount un dossier avec le fichier dedans (pas un fichier, ça change d'inode lors des modifs) qui lance les migrations en start du container 2. un script qui tourne sur l'host installé par le playbook ansible, lancé en root par systemd 3. écoute sur un "named pipe" des commandes simples "install x.y.z" 4. pull, down le container, backup, up avec la nouvelle version (voir comment je fait ça, modifier l'unit sacadoc.container + daemon-reload + start ?) commande podman ? faut que ce soit pas écrasé par ansible si je relance le playbook 5. attends que le service systemd soit up + x seconds et curl/ fait les vérifs que c'est up 6. si pas ok, stop, restore le backup et start l'ancien tag Il faut que malgré les modifs à sacadoc, le dev reste simple.
Author
Owner

@mpeterschmitt commented on GitHub:

  1. pour moi les settings de prod on passe par les variables d'environnements
  2. Pour toi on passerait la version du conteneur a pull ? (genre latest, 1.3.5.6.29, d'ailleurs j'aurais aimé changer de fonctionnement des version mais c'est une autre histoire ça (Semantic Versioning par exemple))
  3. Tout ça me semble pas hyper stable mais bon 🤷 pour avoir un historique de la version lors du reboot il faut forcement modifier le sacadoc.container.
    Je suis pas sur mais j'imagine qu'il est possible d'utiliser des variables avec ansible donc on pourrait définir une valeur par défaut (genre ${varible:-default_valeur} sur les compose.yaml) et sinon ça utilise la variable défini avec le script ?

Pour moi il faut impérativement qu'on marque quelque part la version actuelle de sacadoc pour pouvoir le relancer en cas d'arret.

<!-- gh-comment-id:4050374841 --> **@mpeterschmitt** commented on GitHub: 1. pour moi les settings de prod on passe par les variables d'environnements 3. Pour toi on passerait la version du conteneur a pull ? (genre latest, 1.3.5.6.29, d'ailleurs j'aurais aimé changer de fonctionnement des version mais c'est une autre histoire ça (Semantic Versioning par exemple)) 4. Tout ça me semble pas hyper stable mais bon 🤷 pour avoir un historique de la version lors du reboot il faut forcement modifier le sacadoc.container. Je suis pas sur mais j'imagine qu'il est possible d'utiliser des variables avec ansible donc on pourrait définir une valeur par défaut (genre ${varible:-default_valeur} sur les compose.yaml) et sinon ça utilise la variable défini avec le script ? Pour moi il faut impérativement qu'on marque quelque part la version actuelle de sacadoc pour pouvoir le relancer en cas d'arret.
Author
Owner

@logut commented on GitHub:

Garder à minima temporairement l'ancien système et ajouter un settings pour gérer le nouveau.

@mpeterschmitt Je réfléchi à utiliser uniquement l'api github pour réupérer les versions, ça évitera de devoir modifier le fichier version.txt, et simplifie le process en passant tout en merge request et en protégeant la branche principale

<!-- gh-comment-id:4062711883 --> **@logut** commented on GitHub: Garder à minima temporairement l'ancien système et ajouter un settings pour gérer le nouveau. @mpeterschmitt Je réfléchi à utiliser uniquement l'api github pour réupérer les versions, ça évitera de devoir modifier le fichier version.txt, et simplifie le process en passant tout en merge request et en protégeant la branche principale
Author
Owner

@mpeterschmitt commented on GitHub:

Utiliser l'api GitHub pour utiliser les releases ? J'aime bien l'idée oui

<!-- gh-comment-id:4108980254 --> **@mpeterschmitt** commented on GitHub: Utiliser l'api GitHub pour utiliser les releases ? J'aime bien l'idée oui
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
mirror/sacadoc#73
No description provided.