Espaces de travail, instances et hébergement
Archestack est généralement déployé par un partenaire intégrateur : une entreprise qui construit une application sur Archestack et la livre à ses clients. Cette page suit un seul exemple du début à la fin : un éditeur de logiciels qui a construit une application pour les laboratoires d'analyses, ces entreprises qui analysent des denrées alimentaires, de l'eau et des matériaux pour le compte d'autres entreprises. L'application suit chaque échantillon, de sa réception jusqu'au certificat, et l'éditeur la déploie laboratoire après laboratoire. Chaque laboratoire est un client, et chacun a ses propres clients professionnels : les producteurs alimentaires, les compagnies des eaux et les industriels qui lui envoient des échantillons.
Le reste de cette page repose sur trois termes :
- Client : une entreprise à laquelle le partenaire livre l'application. Dans cet exemple, chaque laboratoire.
- Espace de travail : l'environnement isolé dans lequel travaille un client, avec sa propre application, ses propres données et ses propres membres. Son nom technique est tenant.
- Instance : une copie d'Archestack en fonctionnement. Elle fait tourner un espace de travail ou plusieurs.
En bref : un client travaille dans un espace de travail, et un espace de travail tourne sur une instance. Les sections suivantes abordent ce qu'est un espace de travail et ce qui l'isole des autres, les deux façons d'héberger les espaces de travail de vos clients, comment un laboratoire ouvre l'application à ses propres clients, comment Archestack lui-même est hébergé et comment une nouvelle version de votre application parvient à chaque client.
Ce qu'est un espace de travail
Un espace de travail est l'environnement isolé dans lequel travaille un client. Il contient toute l'application, les données sur lesquelles elle travaille et les personnes autorisées à y entrer, et il est coupé de tous les autres espaces de travail. Chaque laboratoire en reçoit un.
Tenant est le nom technique de ce même environnement. Les écrans parlent d'espace de travail ; l'API et le code parlent de tenant, le mot à l'origine des expressions hébergement mono-tenant et multi-tenant. Espace de travail et tenant ne sont pas deux couches, et aucun des deux ne contient l'autre : un laboratoire a un espace de travail, et l'API appelle cet espace de travail un tenant. Cette page parle d'espace de travail d'un bout à l'autre.
Instance Archestack Ce que contient un espace de travail
Un espace de travail contient trois choses :
- Core, une base de données PostgreSQL qui contient l'application elle-même : Business Entities, pages, Business Events, Script Modules, Scheduled Events, PDF Templates, packages, releases, suites de tests, endpoints et clés de la Data API, jetons MCP, branding, layouts d'application, traductions, paramètres, comptes mail et boîte d'envoi, ainsi que les préférences et les notifications de ses utilisateurs. Les mots de passe et les autres secrets qui y sont stockés sont chiffrés, et les clés d'API et les jetons MCP n'y sont conservés que sous forme de hachage.
- Runtime, une base de données PostgreSQL qui contient les données métier : les tables et leurs lignes, dans cet exemple les échantillons, les analyses, les résultats, les certificats d'analyse et les factures. Le Schema Designer en montre la structure exactement telle qu'elle est dans la base de données.
- Membres : les personnes autorisées à y entrer, chacune avec un rôle dans cet espace de travail. Les invitations sont envoyées par espace de travail.
Comme l'application vit dans Core, deux laboratoires qui utilisent la même application en ont
chacun leur propre copie. Une modification faite dans un espace de travail y reste jusqu'à ce
que vous la livriez aux autres, et c'est à cela que servent les
packages. Un espace de travail peut aussi avoir sa propre adresse,
comme peeters.labapp.example.com. Chez Archestack, il peut aussi être servi sur un
domaine propre à l'entreprise, comme app.peeters.be : un administrateur l'ajoute
sur la page Domains du builder et le prouve par un enregistrement DNS, et le certificat
suit tout seul.
Ce qui isole les espaces de travail les uns des autres
L'API et les tâches de fond servent tous les espaces de travail de l'instance, mais chaque requête et chaque tâche planifiée ne travaille que pour un seul espace de travail :
- Des bases de données séparées. Les pages, les Business Entities et les requêtes d'un espace de travail ne peuvent pas atteindre les tables d'un autre.
- Un jeton, un espace de travail. Chaque requête authentifiée porte un jeton signé qui désigne un seul espace de travail, et seules les bases de données de cet espace de travail sont ouvertes.
- Pas de repli. Un jeton qui désigne un espace de travail inexistant ou suspendu est refusé, jamais redirigé vers un autre espace de travail.
- Des clés au nom de leur espace de travail. Les clés d'API et les jetons MCP portent le nom de l'espace de travail auquel ils appartiennent et ne fonctionnent que dans celui-ci.
- Des tâches qui restent dans leur espace de travail. Les tâches planifiées s'exécutent dans l'espace de travail auquel elles appartiennent.
- Des sauvegardes par espace de travail. Les sauvegardes, les restaurations et les exports portent sur les bases Core et Runtime d'un seul espace de travail, si bien que les données d'un client peuvent être restaurées ou exportées sans toucher à celles d'un autre.
Un compte, un rôle par espace de travail
Les comptes sont rattachés à l'instance, les appartenances à l'espace de travail. Une personne a un seul compte sur une instance, avec une seule adresse e-mail et un seul mot de passe, et peut être membre de plusieurs espaces de travail avec un rôle différent dans chacun. Les consultants du partenaire peuvent être admin dans l'espace de travail de chaque laboratoire dont ils s'occupent, tandis que le personnel d'un laboratoire n'est membre que de son propre espace de travail.
Une personne membre de plusieurs espaces de travail passe de l'un à l'autre depuis le menu de l'avatar. Ce changement émet un nouveau jeton, qui ouvre l'autre espace de travail et lui seul. Retirer quelqu'un d'un espace de travail ne touche pas à ses autres appartenances.
L'espace de travail principal et les nouveaux
Chaque instance crée un espace de travail principal à son premier démarrage. Une entreprise qui n'a besoin que d'un seul environnement y travaille, tout simplement. Un partenaire qui a de nombreux clients garde l'espace de travail principal pour sa propre équipe et crée un espace de travail par client. Un nouvel espace de travail est créé en une seconde environ et démarre vide.
Subdiviser un espace de travail
Deux fonctionnalités divisent un espace de travail plus finement. Aucune des deux ne crée de nouvel environnement : toutes deux agissent à l'intérieur de l'espace de travail, sur ses propres bases Core et Runtime.
- Les Business Units le découpent par équipe, pour que chaque équipe voie les pages et les Business Entities qui la concernent. Elles ne masquent pas les lignes de données et ne constituent donc pas une séparation.
- Les organisations clientes le découpent par client. Ce ne sont pas des espaces de travail à part entière. Elles vivent à l'intérieur de l'espace de travail du laboratoire, pas à côté, sans bases de données propres : les clients du laboratoire utilisent l'application du laboratoire, ce qu'ils saisissent atterrit dans la base Runtime du laboratoire, et chaque client ne voit que ses propres lignes. Nous y revenons plus bas.
Deux façons d'héberger vos clients
Chaque espace de travail tourne sur une instance : une copie d'Archestack en fonctionnement, avec son API, ses tâches de fond et un serveur PostgreSQL qui contient les bases de données de ses espaces de travail. Les espaces de travail d'une même instance partagent l'instance qui les entoure, mais pas leurs bases de données :
| Propre à chaque espace de travail | Partagé par les espaces de travail d'une même instance | |
|---|---|---|
| L'application | Core : pages, Business Entities, Script Modules, paramètres et tout le reste | La version de la plateforme. Une mise à jour atteint tous les espaces de travail à la fois. |
| Les données | Runtime : ses tables et ses lignes | Le serveur PostgreSQL qui contient les bases de données |
| Les personnes | Membres, rôles et invitations | Les comptes : une adresse e-mail et un mot de passe par personne |
| Les traitements en arrière-plan | Ses tâches planifiées, qui s'exécutent dans l'espace de travail | Les tâches de fond et le planificateur de tâches |
| Les modules | Les packages qu'il a installés | Le catalogue du Module Store |
Les espaces de travail d'une même instance partagent aussi sa capacité : processeur, mémoire et connexions à la base de données. Pour chaque client, le partenaire décide si son espace de travail reçoit sa propre instance ou en partage une avec les espaces de travail d'autres clients. Dans les deux modèles, chaque client a son propre espace de travail avec ses propres bases Core et Runtime. Ce qui change, c'est le nombre d'espaces de travail qui partagent une instance, et donc ce qu'ils partagent entre eux.
Un espace de travail par instance (mono-tenant)
Archestack Archestack Archestack Chaque laboratoire reçoit sa propre instance, avec sa propre API et ses propres tâches de fond, et un espace de travail avec ses propres bases Core et Runtime. Ce modèle convient aux gros clients, aux clients qui décident de l'endroit où résident leurs données et aux clients qui choisissent quand faire leurs mises à jour. Le partenaire peut exploiter ces instances, ou en installer une dans le compte cloud ou le centre de données du laboratoire.
Avantages
- La séparation la plus forte qui soit. Rien n'est partagé avec d'autres clients, pas même la plateforme.
- Une capacité qui lui est propre. Un laboratoire très actif n'en ralentit jamais un autre, et son instance est dimensionnée pour lui seul.
- Des mises à jour au rythme du client. Chaque instance passe à une nouvelle version de la plateforme quand cela convient à ce client.
- Les données résident là où le client le souhaite : une région, un compte cloud ou ses propres serveurs.
- Une sortie propre. Remettez l'instance au client, ou arrêtez-la.
Inconvénients
- Chaque instance doit être exploitée : serveurs, certificats, sauvegardes, supervision et mises à jour, une fois par client.
- Une nouvelle version de votre application doit être importée dans chaque instance, séparément.
- Votre propre équipe a besoin d'un compte sur chaque instance sur laquelle elle intervient.
- Le plus petit client a quand même besoin d'une instance complète.
Plusieurs espaces de travail par instance (multi-tenant)
Archestack
Une seule instance sert de nombreux laboratoires. Chaque laboratoire a toujours son propre
espace de travail, avec ses propres bases Core et Runtime et, si vous le souhaitez, sa propre
adresse comme peeters.labapp.example.com. Les administrateurs de l'instance créent
un nouvel espace de travail en une seconde environ.
Avantages
- Chaque client a toujours ses propres bases de données, ses propres sauvegardes et sa propre version de l'application, adaptée à sa façon de travailler.
- Ajouter un client prend environ une seconde, et un client peu actif ne coûte presque rien : un espace de travail inutilisé n'occupe aucune connexion à la base de données.
- Une seule instance à exploiter, à sécuriser et à mettre à jour.
- Vos consultants utilisent un seul compte et passent d'un client à l'autre depuis le menu de l'avatar.
Inconvénients
- Tous les clients passent à une nouvelle version de la plateforme au même moment.
- Les clients partagent la capacité de l'instance, dimensionnez-la donc pour tous les clients réunis. Une instance qui compte plus de quelques dizaines d'espaces de travail utilisés en même temps demande aussi de relever la limite de connexions de PostgreSQL au-delà de sa valeur par défaut de 100.
- Une nouvelle version de votre application s'installe quand même espace de travail par espace de travail, depuis le Module Store de l'instance ou à partir d'un ZIP.
Côte à côte
| Un espace de travail par instance | Plusieurs espaces de travail par instance | |
|---|---|---|
| Bases de données propres | Oui, sur son propre serveur | Oui, sur un serveur partagé |
| Capacité | Par client | Partagée |
| Version de la plateforme | Par client | Partagée |
| Où les données peuvent résider | N'importe où, y compris dans le cloud du client | Là où le partenaire exploite l'instance |
| Livrer une nouvelle version de l'application | Un ZIP importé dans l'espace de travail de chaque client | Installée dans l'espace de travail de chaque client, depuis le Module Store de l'instance ou à partir d'un ZIP |
| Ajouter un client | Une nouvelle instance | Environ une seconde |
| Coût par client | Plus élevé | Faible |
Combiner les deux est courant : les petits laboratoires partagent une instance, un grand groupe de laboratoires reçoit la sienne, et les mêmes packages sont livrés aux uns et aux autres. Le développement, le test, la recette et la production ont chacun leur propre espace de travail. Placez le développement, le test et la recette sur une instance et la production sur une instance à part, pour qu'une mise à jour de la plateforme atteigne la recette avant la production.
Les clients d'un client, au sein de son application
Un laboratoire a ses propres clients : des producteurs alimentaires, des compagnies des eaux et des industriels qui lui envoient des échantillons. Ils veulent enregistrer les échantillons qu'ils envoient et suivre chacun d'eux pendant que le laboratoire le traite. Un producteur alimentaire ne doit jamais voir les échantillons d'un autre producteur ; le laboratoire, lui, les voit tous. Le laboratoire peut faire entrer ces clients dans l'application que le partenaire a construite pour lui, en tant qu'organisations clientes.
Le partenaire construit l'application et choisit l'hébergement, selon l'un ou l'autre des deux modèles ci-dessus. Ni le laboratoire ni ses clients ne remarquent lequel a été retenu. Le laboratoire invite ensuite ses clients, ou les laisse s'inscrire eux-mêmes.
Une organisation cliente n'est pas un espace de travail et n'a pas de bases de données propres. Elle vit à l'intérieur de l'espace de travail du laboratoire : l'application appartient à cet espace de travail, chaque client a ses propres membres, et tout ce qu'ils saisissent atterrit dans la base Runtime du laboratoire, estampillé du nom de l'entreprise qui l'a enregistré. Chaque client ne voit que ses propres lignes, le laboratoire les voit toutes, et un client peut avoir ses propres sous-unités : un groupe agroalimentaire, par exemple, avec une sous-unité pour chacune de ses usines et une pour chaque chaîne de production d'une usine. Chaque unité voit ses propres lignes et celles des unités situées en dessous d'elle. Les clients utilisent l'application telle que le laboratoire la publie et ne la modifient pas, et l'administrateur propre à chaque client invite et retire ses collègues.
Infrastructure d'hébergement
Archestack est livré sous forme d'une seule image de conteneur qui exécute à la fois l'API et les tâches de fond : Scheduled Events, mails sortants, exécutions des suites de tests, synchronisations avec d'autres systèmes et sauvegardes nocturnes. Elle monte en charge horizontalement : lancez davantage de copies de la même image derrière un répartiteur de charge à mesure que le nombre d'utilisateurs augmente. Les copies se coordonnent via PostgreSQL, si bien que le travail planifié est réparti entre elles et que chaque tâche ne s'exécute qu'une fois.
Image Archestack Image Archestack Faire tourner plus d'une copie demande quelques choses à l'infrastructure qui l'entoure :
- Pas de sessions persistantes, mais les WebSockets doivent passer. N'importe quelle copie peut répondre à n'importe quelle requête. Les mises à jour en direct (grilles qui se rafraîchissent, qui d'autre est sur une page, notifications) passent uniquement par WebSockets ; un répartiteur ou un réseau qui les bloque laisse l'application fonctionner, sans mises à jour en direct.
- Des volumes partagés pour les sauvegardes et les fichiers. Le dossier des
sauvegardes et celui qui contient les fichiers de chaque espace de travail (envois, logos,
fichiers écrits par les scripts) doivent se trouver sur un stockage que chaque copie monte
(dans Kubernetes, un volume
ReadWriteMany), sinon chaque copie ne voit que les sauvegardes et les fichiers qu'elle a écrits elle-même. - Une sonde de démarrage. Les copies qui démarrent ensemble préparent les bases de données à tour de rôle, et avec beaucoup d'espaces de travail à migrer cela prend un moment. Donnez aux conteneurs une startup probe plutôt qu'une liveness probe courte.
- Les limites de débit sont par copie. Trois copies autorisent trois fois plus de requêtes par appelant qu'une seule.
- Derrière PgBouncer en mode transaction, faites pointer
ConnectionStrings__Clusterdirectement sur PostgreSQL : les copies communiquent entre elles par une connexion PostgreSQL qui doit rester ouverte.
Outre les conteneurs, une instance a besoin de PostgreSQL 16 et d'un proxy qui gère le TLS.
Elle tourne partout où tournent des conteneurs : sur un seul serveur, dans un compte cloud ou
sur un cluster Kubernetes. Le partenaire peut l'héberger, Archestack peut l'héberger, ou elle peut tourner
dans l'infrastructure propre du client. Pour Kubernetes, il existe un chart Helm, et une instance
peut aussi vivre sous un chemin d'un nom d'hôte qui appartient à une autre application, comme
apps.example.com/archestack/.
Une nouvelle instance n'a aucun utilisateur. La première personne qui l'ouvre crée le premier administrateur, configurez-la donc avant qu'elle soit joignable depuis internet.
Capacité et dimensionnement donne les chiffres mesurés : combien de personnes et d'espaces de travail une instance sert, et les serveurs dont elle a besoin pour cela. Héberger sur AKS installe une instance sur Azure Kubernetes Service et la maintient d'elle-même sur la release la plus récente ; Héberger avec Docker fait de même sur un seul serveur.
Livrer votre application à chaque client
Quand chaque client a son propre espace de travail, chaque nouvelle version de l'application doit voyager. Un package est le moyen de la faire voyager :
- Mettez les tables, Business Entities, pages, Business Events, Script Modules, PDF Templates, Scheduled Events, suites de tests et layouts d'application de votre application dans un package, et exportez-le en ZIP.
- Importez-le dans l'espace de travail du client. L'import affiche d'abord un plan, puis applique les changements de tables à la base Runtime de l'espace de travail.
- Exécutez-y les suites de tests du package. Les tests s'exécutent dans une base de données sandbox séparée et ne touchent jamais aux données du client.
- Publiez une release. C'est à ce moment que les nouvelles pages atteignent les utilisateurs du client. Un espace de travail qui n'a jamais publié de release affiche ses pages dès la fin de l'import.
Certains éléments se configurent dans chaque espace de travail au lieu d'être livrés : endpoints et clés de la Data API, traductions, utilisateurs, rôles, Business Units, branding, comptes mail et connexions à d'autres systèmes. Tout ce qui est marqué public arrive marqué privé, donc installer un package ne peut jamais, à lui seul, mettre les données d'un client sur internet.
Sur une même instance, un module publié publiquement dans le Module Store est visible et installable par tous les espaces de travail de cette instance, ce qui évite de passer par l'export et l'import. Un module publié en privé n'est visible que par l'espace de travail qui l'a publié. D'une instance à l'autre, les packages voyagent sous forme de fichiers ZIP.
Quand l'application vit dans un dépôt git, Stratégie de déploiement décrit comment un pipeline la teste et la déploie dans chaque environnement sans interruption de service.
Pièges
- Une mise à jour de la plateforme atteint tous les espaces de travail de l'instance à la fois. Un client qui doit rester sur une version a besoin de sa propre instance.
- Un nouvel espace de travail démarre vide. Installez-y vos packages et invitez-y ses membres ; les appartenances à d'autres espaces de travail ne sont pas reprises.
Pour aller plus loin
Packages explique comment construire et exporter le package que vous livrez à chaque espace de travail. Le guide de la Data API montre comment un service se connecte à un espace de travail avec une clé d'API, et Database Backups couvre les sauvegardes par espace de travail.