Gameur/Kuby
1
0
Fork 0
Code Issues 3 Pull requests Projects Releases Packages Wiki Activity Actions

Décentralisation Kuby #226

New issue
Open
opened 2026-07-07 18:33:27 +00:00 by Gameur.py · 8 comments
Gameur.py commented 2026-07-07 18:33:27 +00:00 (Migrated from gitlab.com)
Copy link

Décentralisation complète de Kuby

Contexte

Kuby tourne actuellement sur un seul serveur dédié. En cas de panne de ce serveur, le service est totalement interrompu pour les utilisateurs.

Objectif : éliminer ce point de défaillance unique en décentralisant l'intégralité du projet, afin que Kuby puisse redémarrer / continuer de fonctionner automatiquement en cas de panne d'un serveur, sans aucun impact perceptible pour les utilisateurs.

:puzzle_piece: Objectif technique

Faire évoluer l'architecture d'un modèle mono-serveur vers un modèle distribué / redondant, couvrant :

  • Le(s) processus applicatif(s) Python
  • La ou les base(s) de données
  • Le stockage (fichiers, cache, sessions, etc. si applicable)
  • La gestion du réseau / routage vers l'instance disponible

Critères d'acceptation

  • Kuby peut fonctionner sur plusieurs serveurs simultanément (ou au minimum : bascule automatique sur un serveur de secours)
  • En cas de panne d'un serveur, le service redémarre / bascule automatiquement, sans intervention manuelle
  • Aucune coupure perceptible côté utilisateur (zéro-downtime ou downtime minimal, à définir précisément avec l'équipe)
  • Pas de perte de données lors d'un basculement
  • La solution est documentée (schéma d'archi + procédure de déploiement/rollback)
  • Un plan de test de panne (chaos test / simulation de crash) est fourni et validé

Points techniques à investiguer et proposer

Merci de traiter chacun des points ci-dessous dans votre proposition technique :

1. Architecture générale

  • Modèle cible : actif/passif (failover) vs actif/actif (répartition de charge) ?
  • Nombre de serveurs/nœuds envisagés
  • Orchestration : conteneurisation (Docker/Kubernetes/Docker Swarm), ou autre approche pour les futurs MEP ?

2. Application Python

  • Le code est-il "stateless" ou faut-il le refactorer pour le rendre stateless (sessions, variables en mémoire, etc.) ?
  • Gestion des tâches de fond / cron / workers

3. Base de données

  • Réplication (master-slave / master-master) ?
  • Stratégie de failover automatique de la BDD
  • Cohérence des données entre nœuds

4. Réseau / routage

  • Load balancer ou reverse proxy (ex: Tailscale, Nginx etc...) avec health checks
  • DNS failover car plusieurs hébergeurs
  • Gestion du TLS/certificats sur plusieurs nœuds si applicable

5. Stockage & synchronisation

  • Fichiers partagés (NFS, object storage type S3/MinIO, sync applicative) ?
  • Cache distribué

6. Supervision & bascule automatique

  • Monitoring de santé des nœuds (Prometheus, healthchecks custom, etc.)
  • Mécanisme de détection de panne + bascule automatique (pas d'intervention manuelle)
  • Alerting en cas d'incident

7. Déploiement & CI/CD

  • Impact sur le pipeline de déploiement actuel
  • Procédure de rollback en cas de souci post-déploiement

📌 Process à suivre

  1. @takezo_sd et @truekiwwy_ échangent ensemble pour concevoir une solution technique complète couvrant les points ci-dessus.
  2. Une fois la solution définie, prise de rendez-vous obligatoire avant tout développement, pour présentation et validation : https://cal.com/gameur-omegakube
  3. Après validation (éventuels ajustements à discuter ensemble), le développement peut démarrer.
  4. En cas de blocage ou de point irréalisable, en discuter en amont plutôt que d'attendre la deadline.

⏱️ Deadline

Elle n'est pas vraiment importante c'est une date idéale rien de plus !

Peut être repoussée en cas de justification valable, ou l'issue peut être annulée si jugée irréalisable après étude technique

# Décentralisation complète de Kuby ## Contexte Kuby tourne actuellement sur un **seul serveur dédié**. En cas de panne de ce serveur, le service est totalement interrompu pour les utilisateurs. **Objectif** : éliminer ce point de défaillance unique en décentralisant l'intégralité du projet, afin que Kuby puisse redémarrer / continuer de fonctionner automatiquement en cas de panne d'un serveur, **sans aucun impact perceptible pour les utilisateurs**. --- ## :puzzle_piece: Objectif technique Faire évoluer l'architecture d'un modèle **mono-serveur** vers un modèle **distribué / redondant**, couvrant : - Le(s) processus applicatif(s) Python - La ou les base(s) de données - Le stockage (fichiers, cache, sessions, etc. si applicable) - La gestion du réseau / routage vers l'instance disponible --- ## Critères d'acceptation - [ ] Kuby peut fonctionner sur **plusieurs serveurs simultanément** (ou au minimum : bascule automatique sur un serveur de secours) - [ ] En cas de panne d'un serveur, le service **redémarre / bascule automatiquement**, sans intervention manuelle - [ ] **Aucune coupure perceptible** côté utilisateur (zéro-downtime ou downtime minimal, à définir précisément avec l'équipe) - [ ] Pas de perte de données lors d'un basculement - [ ] La solution est **documentée** (schéma d'archi + procédure de déploiement/rollback) - [ ] Un plan de test de panne (chaos test / simulation de crash) est fourni et validé --- ## Points techniques à investiguer et proposer Merci de traiter chacun des points ci-dessous dans votre proposition technique : ### 1. Architecture générale - Modèle cible : actif/passif (failover) vs actif/actif (répartition de charge) ? - Nombre de serveurs/nœuds envisagés - Orchestration : conteneurisation (Docker/Kubernetes/Docker Swarm), ou autre approche pour les futurs MEP ? ### 2. Application Python - Le code est-il "stateless" ou faut-il le refactorer pour le rendre stateless (sessions, variables en mémoire, etc.) ? - Gestion des tâches de fond / cron / workers ### 3. Base de données - Réplication (master-slave / master-master) ? - Stratégie de failover automatique de la BDD - Cohérence des données entre nœuds ### 4. Réseau / routage - Load balancer ou reverse proxy (ex: Tailscale, Nginx etc...) avec health checks - DNS failover car plusieurs hébergeurs - Gestion du TLS/certificats sur plusieurs nœuds si applicable ### 5. Stockage & synchronisation - Fichiers partagés (NFS, object storage type S3/MinIO, sync applicative) ? - Cache distribué ### 6. Supervision & bascule automatique - Monitoring de santé des nœuds (Prometheus, healthchecks custom, etc.) - Mécanisme de détection de panne + bascule automatique (pas d'intervention manuelle) - Alerting en cas d'incident ### 7. Déploiement & CI/CD - Impact sur le pipeline de déploiement actuel - Procédure de rollback en cas de souci post-déploiement --- ## :pushpin: Process à suivre 1. **@takezo_sd** et **@truekiwwy\_** échangent ensemble pour concevoir une solution technique complète couvrant les points ci-dessus. 2. Une fois la solution définie, **prise de rendez-vous obligatoire** avant tout développement, pour présentation et validation : https://cal.com/gameur-omegakube 3. Après validation (éventuels ajustements à discuter ensemble), le développement peut démarrer. 4. En cas de blocage ou de point irréalisable, en discuter en amont plutôt que d'attendre la deadline. --- ## :stopwatch: Deadline > Elle n'est pas vraiment importante c'est une date idéale rien de plus ! > > Peut être repoussée en cas de justification valable, ou l'issue peut être annulée si jugée irréalisable après étude technique
Gameur.py commented 2026-07-07 18:39:45 +00:00 (Migrated from gitlab.com)
Copy link

assigned to @tomeyrd

assigned to @tomeyrd
Gameur.py commented 2026-07-07 18:39:57 +00:00 (Migrated from gitlab.com)
Copy link

assigned to @truekiwwy and unassigned @tomeyrd

assigned to @truekiwwy and unassigned @tomeyrd
Gameur.py commented 2026-07-07 18:40:16 +00:00 (Migrated from gitlab.com)
Copy link

added time estimate of 20h

added time estimate of 20h
Gameur.py commented 2026-07-07 18:42:20 +00:00 (Migrated from gitlab.com)
Copy link

changed start date to July 07, 2026 and changed due date to July 20, 2026

changed start date to July 07, 2026 and changed due date to July 20, 2026
Gameur.py commented 2026-07-07 18:43:20 +00:00 (Migrated from gitlab.com)
Copy link

changed the description

changed the description
Gameur.py commented 2026-07-07 18:44:51 +00:00 (Migrated from gitlab.com)
Copy link

Je vous pries de bien vouloir mettre l'issue dans la catégorie qui correspond à l'état de la tâche.

Je vous pries de bien vouloir mettre l'issue dans la catégorie qui correspond à l'état de la tâche.
Gameur.py commented 2026-07-08 09:44:02 +00:00 (Migrated from gitlab.com)
Copy link

marked the checklist item Kuby peut fonctionner sur plusieurs serveurs simultanément (ou au minimum : bascule automatique sur un serveur de secours) as completed

marked the checklist item **Kuby peut fonctionner sur plusieurs serveurs simultanément \(ou au minimum : bascule automatique sur un serveur de secours\)** as completed
Gameur.py commented 2026-07-08 09:44:03 +00:00 (Migrated from gitlab.com)
Copy link

marked the checklist item Kuby peut fonctionner sur plusieurs serveurs simultanément (ou au minimum : bascule automatique sur un serveur de secours) as incomplete

marked the checklist item **Kuby peut fonctionner sur plusieurs serveurs simultanément \(ou au minimum : bascule automatique sur un serveur de secours\)** as incomplete
Gameur started working 2026-07-11 14:45:31 +00:00
Gameur stopped working 2026-07-11 14:45:44 +00:00
13 seconds
Gameur deleted spent time 2026-07-11 14:46:29 +00:00
- 13 seconds
truekiwwy was assigned by Gameur 2026-07-11 15:18:18 +00:00
Gameur added this to the Mise à jour d'été milestone 2026-07-11 16:51:59 +00:00
Gameur added the
In progress
 label 2026-07-11 16:52:33 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
dev
Dev-Eliott
dev-kma
No results found.
Labels
Clear labels   
In progress

   
Pending
  
Priority
High

  
Priority
Low

  
Priority
Normal

  
Priority
Urgent

  
Won't do

   
auto-report

   
bot-api

   
bug

   
enhancement

   
filesystem

   
git

   
infrastructure

   
manual-report

   
manual-suggestion

   
sécurité

   
windows
No labels
In progress
Pending
Priority
High
Priority
Low
Priority
Normal
Priority
Urgent
Won't do
auto-report
bot-api
bug
enhancement
filesystem
git
infrastructure
manual-report
manual-suggestion
sécurité
windows
Milestone
Clear milestone
No items
No milestone
Mise à jour d'été
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
truekiwwy
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: Gameur/Kuby#226
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?