Infra : taskori-prod (10.10.20.10) · Mis à jour : 2026-05-29
L'infrastructure de bases de données Taskori repose sur MariaDB 11.4 déployé en conteneur Docker sur la VM taskori-prod. Chaque service applicatif dispose de son propre utilisateur SQL avec des droits limités à sa base de données. Un utilisateur transversal (taskori_cron) couvre les jobs planifiés multi-bases, et un utilisateur en lecture seule (taskori_share_ro) isole les accès inter-services.
Redis est présent dans l'infra LORVA principalement pour Chatwoot (sur lorva-public) et pourra être étendu à Taskori selon les besoins.
| Paramètre | Valeur |
|---|---|
| Hôte VM | taskori-prod — 10.10.20.10 |
| Version | MariaDB 11.4 |
| Nom du conteneur | mariadb |
IP réseau Docker (db) |
172.34.0.2 |
| Root password | voir Flatnotes (note reference_lorva_db) |
| Exposition externe | Non — accessible depuis taskori-prod uniquement |
# Depuis taskori-prod
docker exec -it mariadb mariadb -u root -p
# Le mot de passe root est dans Flatnotes (note reference_lorva_db)
Le port 3306 n'est pas exposé hors du réseau Docker interne. Toute connexion depuis l'extérieur passe nécessairement par
docker execsur la VM.
7 bases applicatives sont déployées :
| Base | Utilisateur propriétaire | Rôle applicatif |
|---|---|---|
taskori_auth |
taskori_auth |
Authentification, 2FA TOTP, sessions |
taskori_manage |
taskori_manage |
Workspaces, équipes, membres |
taskori_portal |
taskori_portal |
Portail client |
taskori_projet |
taskori_projet |
Projets, tâches, membres |
taskori_share |
taskori_share |
Partage AES-256-GCM |
taskori_admin |
taskori_admin |
Back-office, billing Stripe |
taskori_ts |
taskori_ts |
Refonte complète (taskori-ts) |
Les mots de passe de tous les utilisateurs sont stockés dans Flatnotes (note reference_lorva_db) et dans les variables CI/CD GitLab de chaque repo. Ils ne figurent pas en clair dans ce wiki.
| Utilisateur | Base propriétaire | Accès supplémentaires |
|---|---|---|
taskori_auth |
taskori_auth R/W |
— |
taskori_manage |
taskori_manage R/W |
— |
taskori_portal |
taskori_portal R/W |
— |
taskori_projet |
taskori_projet R/W |
— |
taskori_share |
taskori_share R/W |
— |
taskori_share_ro |
— | taskori_projet lecture seule |
taskori_ts |
taskori_ts R/W |
— |
taskori_admin |
taskori_admin R/W |
taskori_auth, taskori_manage, taskori_share, taskori_ts (lecture, supervision) |
taskori_cron |
— | taskori_auth, taskori_manage, taskori_projet, taskori_share, taskori_ts |
taskori_auth est utilisé en AUTH_DB_USER par la quasi-totalité des services (manage, share, portal, ts, cron) pour valider les sessions. C'est la base la plus sollicitée en lecture.
taskori_share_ro existe pour isoler l'accès de taskori-share aux projets/tâches. Le service share lit taskori_projet en lecture seule via cet utilisateur (PROJECT_DB_USER dans son .env).
taskori_cron a accès cross-base pour les jobs planifiés (expiry sessions, trial expiration, cleanup). Il utilise taskori_auth pour la base auth avec les credentials de taskori_auth (variable AUTH_DB_USER).
taskori-auth → DB: taskori_auth (user taskori_auth, R/W)
taskori-manage → DB: taskori_manage (user taskori_manage, R/W)
→ DB: taskori_auth (user taskori_auth, lecture sessions)
taskori-portal → DB: taskori_portal (user taskori_portal, R/W)
→ DB: taskori_auth (user taskori_auth, lecture sessions)
taskori-projet → DB: taskori_projet (user taskori_projet, R/W)
→ DB: taskori_auth (user taskori_auth, lecture sessions)
taskori-share → DB: taskori_share (user taskori_share, R/W)
→ DB: taskori_auth (user taskori_auth, lecture sessions)
→ DB: taskori_projet (user taskori_share_ro, READ ONLY)
taskori-ts → DB: taskori_ts (user taskori_ts, R/W)
→ DB: taskori_auth (user taskori_auth, lecture sessions)
taskori-admin → DB: taskori_admin (user taskori_admin, R/W)
→ DB: taskori_auth / manage / share / ts
(user taskori_admin, lecture supervision)
taskori-cron → DB: taskori_projet (user taskori_cron, DB_NAME principal)
→ DB: taskori_auth / manage / share / ts
(user taskori_cron, jobs planifiés)
Chaque service a son fichier .env sur la VM taskori-prod :
/docker/taskori-auth/.env
/docker/taskori-manage/.env
/docker/taskori-portal/.env
/docker/taskori-projet/.env
/docker/taskori-share/.env
/docker/taskori-ts/.env
/docker/taskori-admin/.env
/docker/taskori-cron/.env
Les variables typiques dans chaque .env :
# Base propre au service
DB_HOST=172.34.0.2
DB_PORT=3306
DB_NAME=taskori_<service>
DB_USER=taskori_<service>
DB_PASS=<voir Flatnotes / CI GitLab>
# Base auth (transversal)
AUTH_DB_HOST=172.34.0.2
AUTH_DB_NAME=taskori_auth
AUTH_DB_USER=taskori_auth
AUTH_DB_PASS=<voir Flatnotes / CI GitLab>
Plusieurs tokens applicatifs sont partagés entre services via X-Internal-Token ou variables d'environnement. Ils sont stockés dans Flatnotes (note reference_lorva_db) et dans les variables CI/CD GitLab. Ne jamais les stocker en clair hors de ces deux emplacements.
| Secret | Usage |
|---|---|
TASKORI_ADMIN_INTERNAL_TOKEN |
Authentification des appels internes → service admin |
TASKORI_MANAGE_INTERNAL_TOKEN |
Authentification des appels internes → service manage |
TASKORI_PROJECT_INTERNAL_TOKEN |
Authentification des appels internes → service projet |
INTERNAL_TOKEN (share) |
Token interne taskori-share |
MASTER_KEY (share) |
Clé maître AES-256-GCM de taskori-share — critique, ne jamais perdre |
La
MASTER_KEYde taskori-share est la clé racine du chiffrement de tous les liens de partage. Sa perte rendrait inaccessibles toutes les données partagées existantes. Elle est dans Flatnotes (notetaskori-share).
docker exec mariadb mariadb -u root -p -e "SHOW DATABASES;"
docker exec -it mariadb mariadb -u taskori_auth -p taskori_auth
# Mot de passe dans Flatnotes / CI GitLab
docker exec mariadb mariadb -u root -p -e "SHOW GRANTS FOR 'taskori_share_ro'@'%';"
# Dump d'une base
docker exec mariadb mariadb-dump -u root -p taskori_auth > taskori_auth_$(date +%Y%m%d).sql
# Dump complet de toutes les bases Taskori
for db in taskori_auth taskori_manage taskori_portal taskori_projet taskori_share taskori_admin taskori_ts; do
docker exec mariadb mariadb-dump -u root -p "$db" > "${db}_$(date +%Y%m%d).sql"
done
docker exec -i mariadb mariadb -u root -p taskori_auth < taskori_auth_20260529.sql
Les migrations de schéma sont toujours gérées par les applications elles-mêmes au démarrage (via les runners GitLab). Il est interdit de lancer un DROP DATABASE ou un DROP TABLE manuellement, même pour corriger une migration bloquée.
En cas de migration bloquée :
docker logs taskori-<service> --tail=100ALTER TABLE ou DELETE FROM migrations WHERE ..., jamais DROPAucun système de backup automatisé n'est encore en place sur taskori-prod. La procédure recommandée est la suivante :
# Sur taskori-prod, créer un répertoire de backup daté
mkdir -p /backup/mariadb/$(date +%Y%m%d)
# Dump de toutes les bases applicatives
for db in taskori_auth taskori_manage taskori_portal taskori_projet taskori_share taskori_admin taskori_ts; do
docker exec mariadb mariadb-dump \
-u root -p"$(cat /run/secrets/mariadb_root_pass)" \
--single-transaction \
"$db" > /backup/mariadb/$(date +%Y%m%d)/${db}.sql
done
taskori-prod via taskori-cron ou cron système.sql compressés (gzip) pour réduire l'espace disqueRedis est déployé en tant que dépendance de Chatwoot sur la VM lorva-public. Il est utilisé pour les jobs Sidekiq, le cache ActionCable et les files de messages.
# Connexion Redis Chatwoot (depuis lorva-public)
docker exec -it chatwoot-redis redis-cli
Le conteneur Redis de Chatwoot n'est pas exposé hors du réseau Docker de lorva-public.
Redis n'est pas encore déployé sur taskori-prod mais pourrait être utilisé pour :
taskori-cron (BullMQ / etc.)Si Redis est ajouté à Taskori, il devra rejoindre le réseau Docker db sur taskori-prod et ne pas être exposé hors de ce réseau.
| Règle | Détail |
|---|---|
| Accès réseau | MariaDB accessible uniquement depuis taskori-prod (réseau Docker db, IP 172.34.0.2) |
| Credentials | Stockés dans Flatnotes et variables CI/CD GitLab uniquement — jamais en clair dans le code ou ce wiki |
| Principe du moindre privilège | Chaque service a son propre utilisateur SQL limité à sa base, sans droits GRANT ni accès à d'autres bases |
| Pas de DROP DATABASE | Interdit en toutes circonstances — migrations uniquement via les apps |
| MASTER_KEY share | Critique — sauvegardée dans Flatnotes, à ne jamais perdre ni faire tourner sans procédure |
| Root password | Uniquement pour maintenance admin — ne jamais utiliser dans les .env applicatifs |
reference_lorva_db — root password, mots de passe utilisateurs SQL, tokens internestaskori-share — MASTER_KEY AES-256-GCMtaskori-infra — architecture générale des 9 repos Taskori