Instances

Une instance Chinaski est un site complet : son propre processus applicatif, sa propre base de données, ses propres fichiers, son propre jeu de sauvegardes, son propre secret. Exécuter plusieurs sites signifie exécuter plusieurs instances, côte à côte sur le même serveur si vous le souhaitez. Cette page explique le modèle et, surtout, ce qui est isolé et ce qui ne l'est pas.

Une instance, un site

Chaque instance est une copie complète et autonome :

• Son propre processus d'application d'administration (un service systemd comme chinaski@1, chinaski@prod, chinaski@staging : le même modèle d'unité en exécute autant qu'on veut)
• Son propre fichier de base de données SQLite : contenu, utilisateurs, formulaires, journaux, tout
• Son propre répertoire de sortie : les fichiers statiques que votre serveur web publie
• Son propre répertoire média
• Son propre secret maître (dans un fichier aux permissions verrouillées, créé à l'installation)
• Son propre port (3001, 3002, … ; chacun unique sur l'hôte)
• Son propre répertoire et planning de sauvegardes
• Ses propres domaines (via le proxy inverse, ou gérés par le Manager)

Rien n'est partagé entre les instances : ni contenu, ni utilisateurs, ni formulaires, ni journaux, ni sessions. Les sites ne peuvent pas se voir, et leurs administrateurs non plus.

Pourquoi cette conception

Le public annoncé par le logiciel rend le raisonnement limpide : « Agences gérant plusieurs sites clients : une instance par client, stack identique, déploiement reproductible, audit log propre, aucune dépendance à un fournisseur. » Dupliquer des stacks entières, c'est plus de disque, moins de risque : une intrusion, un déploiement raté ou un acteur malveillant isolé dans une instance ne touche que ce site et rien d'autre. Quand un client souhaite partir, vous lui remettez sa base de données, sa sortie et son répertoire média : tout est dans un seul dossier.

L'isolement en pratique

• Le processus : l'application de chaque instance est confinée par systemd pour ne lire/écrire que son propre répertoire ; même un bug dans le code du CMS d'un site ne peut pas toucher les fichiers d'un autre site.
• La base de données : chaque site a son propre fichier SQLite, stocké avec des permissions de lecture réservées à l'utilisateur. Il n'existe aucun serveur de base de données partagé à compromettre, et des identifiants d'une instance sont sans valeur sur une autre.
• Les secrets : chaque instance possède un secret maître unique ; des identifiants fuyés restent limités à un seul site.
• Les sessions : les connexions d'administration vivent entièrement dans la base de données d'une instance et sont signées avec le secret de cette instance ; un administrateur d'un site n'a tout simplement aucune session sur un autre.
• Ports et domaines : chaque instance écoute sur son propre port de loopback derrière le proxy ; si le Chinaski Manager optionnel est utilisé, l'unicité des ports entre instances est garantie par le Manager lui-même.
• Sauvegardes et déploiements : les sauvegardes et les tâches de build/déploiement sont propres à chaque instance ; un build raté sur un site n'affecte jamais un autre.

Exécuter plusieurs sites

Deux manières, et elles coopèrent :

1. À la main : le modèle d'unité systemd fourni plus l'installateur en une commande. Chaque installation est une instance ; mettez à jour les sites un par un avec le script de déploiement par instance.
2. Avec le Manager (produit séparé) : un panneau de contrôle qui provisionne les instances, pilote leur cycle de vie (build, déploiement, retour arrière, démarrage/arrêt), rattache des domaines (en régénérant automatiquement la configuration du serveur web), prend des sauvegardes par instance et surveille la santé des instances. Sa fonctionnalité Discovery découvre les instances déjà en cours d'exécution sur le serveur (installées avec systemd, comme celles décrites ci-dessus) et les importe pour gestion.

Une option d'efficacité existe pour les hôtes à nombreuses instances : les dépendances Perl peuvent optionnellement être installées dans une bibliothèque partagée, pour que le déploiement de chaque instance ne les retélécharge pas (sur activation, et l'unité de chaque instance doit inclure le chemin).

Ce que « multi-tenancy » ne signifie pas ici

• Il n'y a pas de base de données multi-tenant : chaque site garde son propre fichier de données, conformément à l'énoncé de conception du projet (« une instance par client »). Un niveau multi-tenant intégré à l'application avec Postgres figure sur la feuille de route et n'est pas livré.
• Les « tenants » du Manager sont un regroupement au niveau du manager pour organiser les instances et les permissions ; ils ne réunissent pas plusieurs sites dans une seule base de données.

Le résumé en une ligne

Dix sites = dix petites stacks identiques et isolées, plus un panneau de contrôle optionnel ; chaque site peut être sauvegardé, restauré, mis à niveau, déployé, transféré ou supprimé individuellement, et un problème sur l'un ne prend jamais les autres en otage.