Workspace, istanze e hosting
Di solito Archestack viene introdotto da un partner di implementazione: un'azienda che costruisce un'app su Archestack e la consegna ai propri clienti. Questa pagina segue un unico esempio dall'inizio alla fine: un'azienda di software che ha costruito un'app per i laboratori di prova, le aziende che analizzano alimenti, acqua e materiali per conto di altre imprese. L'app segue ogni campione dall'accettazione al certificato, e l'azienda di software la porta in un laboratorio dopo l'altro. Ogni laboratorio è un cliente, e ognuno ha a sua volta dei clienti aziendali: i produttori alimentari, le aziende idriche e le imprese manifatturiere che inviano i campioni.
Il resto della pagina ruota intorno a tre parole:
- Cliente: un'azienda a cui il partner consegna l'app. In questo esempio, ogni laboratorio.
- Workspace: l'ambiente isolato in cui lavora un cliente, con la propria app, i propri dati e i propri membri. Il suo nome tecnico è tenant.
- Istanza: una copia in esecuzione di Archestack. Esegue un solo workspace o molti.
In breve: un cliente lavora in un workspace, e un workspace gira su un'istanza. Le sezioni qui sotto spiegano cos'è un workspace e cosa lo tiene separato dagli altri, i due modi per ospitare i workspace dei tuoi clienti, come un laboratorio fa entrare i propri clienti, come viene ospitato Archestack stesso e come una nuova versione della tua app arriva a ogni cliente.
Cos'è un workspace
Un workspace è l'ambiente isolato in cui lavora un cliente. Contiene l'intera app, i dati su cui quell'app lavora e le persone che possono accedervi, ed è chiuso a ogni altro workspace. Ogni laboratorio ne riceve uno.
Tenant è il nome tecnico della stessa cosa. Le schermate dicono workspace; l'API e il codice dicono tenant, la parola da cui prendono il nome l'hosting single-tenant e quello multi-tenant. Workspace e tenant non sono due livelli, e nessuno dei due contiene l'altro: un laboratorio ha un workspace, e nell'API quel workspace si chiama tenant. In questa pagina si dice sempre workspace.
Istanza Archestack Cosa contiene un workspace
Un workspace contiene tre cose:
- Core, un database PostgreSQL che contiene l'app stessa: business entity, pagine, business event, script module, scheduled event, PDF template, package, release, test suite, endpoint e chiavi API della Data API, token MCP, branding, app layout, traduzioni, impostazioni, account di posta e posta in uscita, oltre alle preferenze e alle notifiche dei suoi utenti. Le password e gli altri segreti salvati qui sono cifrati, e le chiavi API e i token MCP sono conservati solo come hash.
- Runtime, un database PostgreSQL che contiene i dati di business: le tabelle e le loro righe, in questo esempio i campioni, le analisi, i risultati, i certificati di analisi e le fatture. Lo Schema Designer ne mostra la struttura esattamente com'è nel database.
- Membri: le persone che possono accedervi, ognuna con un ruolo in questo workspace. Gli inviti vengono mandati per singolo workspace.
Visto che l'app vive nel Core, due laboratori che usano la stessa app ne hanno ciascuno una
copia propria. Una modifica fatta in un workspace resta lì finché non la distribuisci agli
altri, ed è a questo che servono i package. Un workspace può anche
avere un proprio indirizzo, come peeters.labapp.example.com. Con l'hosting di
Archestack può anche essere servito su un dominio proprio dell'azienda, come
app.peeters.be: un amministratore lo aggiunge nella pagina Domains del
builder e lo dimostra con un record DNS, e il certificato arriva da solo.
Cosa tiene separati i workspace
L'API e i job in background servono tutti i workspace dell'istanza, ma ogni richiesta e ogni job pianificato lavora per un solo workspace:
- Database separati. Le pagine, le business entity e le query di un workspace non possono raggiungere le tabelle di un altro workspace.
- Un token, un workspace. Ogni richiesta autenticata porta con sé un token firmato che indica un solo workspace, e si aprono solo i database di quel workspace.
- Nessun fallback. Un token che indica un workspace inesistente o sospeso viene rifiutato, mai reindirizzato a un altro workspace.
- Chiavi che indicano il proprio workspace. Le chiavi API e i token MCP portano il nome del workspace a cui appartengono e funzionano solo lì.
- Job che restano nel proprio workspace. I job pianificati girano dentro il workspace a cui appartengono.
- Backup per workspace. Backup, ripristini ed export riguardano il Core e il Runtime di un solo workspace, così i dati di un cliente si possono ripristinare o esportare senza toccare quelli di un altro.
Un solo account, un ruolo per workspace
Gli account appartengono all'istanza, le appartenenze al workspace. Una persona ha un solo account su un'istanza, con un indirizzo email e una password, e può essere membro di più workspace con un ruolo diverso in ciascuno. I consulenti del partner possono essere admin nel workspace di ogni laboratorio che seguono, mentre il personale di un laboratorio è membro solo del proprio workspace.
Chi appartiene a più workspace passa dall'uno all'altro dal menu dell'avatar. Il passaggio emette un nuovo token, che apre l'altro workspace e solo quello. Rimuovere qualcuno da un workspace non tocca le sue altre appartenenze.
Il workspace principale e quelli nuovi
Ogni istanza crea un workspace principale al primo avvio. Un'azienda a cui basta un solo ambiente lavora semplicemente lì. Un partner con molti clienti tiene il workspace principale per il proprio team e crea un workspace per ogni cliente. Un nuovo workspace si crea in circa un secondo e parte vuoto.
Suddividere un workspace
Due funzionalità suddividono ulteriormente un workspace. Nessuna delle due crea un nuovo ambiente: entrambe lavorano dentro il workspace, sul suo Core e sul suo Runtime.
- Le business unit lo suddividono per team, così ogni team vede le pagine e le business entity che lo riguardano. Non nascondono righe di dati, quindi non sono una separazione.
- Le organizzazioni cliente lo suddividono per cliente. Non sono workspace a sé. Vivono dentro il workspace del laboratorio, non accanto a esso, senza database propri: i clienti del laboratorio usano l'app del laboratorio, ciò che inseriscono finisce nel Runtime del laboratorio, e ogni cliente vede solo le proprie righe. Maggiori dettagli più sotto.
Due modi per ospitare i tuoi clienti
Ogni workspace gira su un'istanza: una copia in esecuzione di Archestack, con la sua API, i suoi job in background e un server PostgreSQL che contiene i database dei suoi workspace. I workspace di un'istanza condividono l'istanza che li circonda, non i database l'uno dell'altro:
| Proprio di ciascun workspace | Condiviso dai workspace di un'istanza | |
|---|---|---|
| L'app | Core: pagine, business entity, script module, impostazioni e il resto | La versione della piattaforma. Un aggiornamento raggiunge tutti i workspace in una volta. |
| I dati | Runtime: le sue tabelle e le loro righe | Il server PostgreSQL che contiene i database |
| Persone | Membri, ruoli e inviti | Gli account: un indirizzo email e una password per persona |
| Lavoro in background | I suoi job pianificati, che girano dentro il workspace | I job in background e lo scheduler dei job |
| Moduli | I package che ha installato | Il catalogo del Module Store |
I workspace di un'istanza ne condividono anche la capacità: processore, memoria e connessioni al database. Per ogni cliente il partner decide se il suo workspace riceve un'istanza tutta sua o ne condivide una con i workspace di altri clienti. In entrambi i modelli ogni cliente ha un workspace tutto suo, con il proprio Core e il proprio Runtime. Quello che cambia è quanti workspace condividono un'istanza, e quindi cosa condividono tra loro.
Un workspace per istanza (single-tenant)
Archestack Archestack Archestack Ogni laboratorio riceve un'istanza tutta sua, con la propria API e i propri job in background, e un workspace con i propri database Core e Runtime. È la soluzione adatta ai grandi clienti, a quelli che decidono dove stanno i loro dati e a quelli che scelgono quando aggiornare. Il partner può gestire queste istanze, oppure installarne una nell'account cloud o nel data center del laboratorio.
Vantaggi
- La separazione più forte che esista. Nulla è condiviso con altri clienti, nemmeno la piattaforma.
- Capacità dedicata. Un laboratorio molto attivo non rallenta mai gli altri, e la sua istanza è dimensionata solo per lui.
- Aggiornamenti con i tempi del cliente. Ogni istanza passa a una nuova versione della piattaforma quando fa comodo a quel cliente.
- I dati stanno dove li vuole il cliente: in una regione, in un account cloud o sui suoi server.
- Una chiusura pulita. Consegni l'istanza, oppure la spegni.
Svantaggi
- Ogni istanza va gestita: server, certificati, backup, monitoraggio e aggiornamenti, una volta per cliente.
- Una nuova versione della tua app va importata in ogni istanza, una per una.
- Il tuo personale ha bisogno di un account su ogni istanza su cui lavora.
- Anche il cliente più piccolo ha bisogno di un'istanza completa.
Più workspace per istanza (multi-tenant)
Archestack
Un'unica istanza serve molti laboratori. Ogni laboratorio resta comunque un workspace a sé, con
i propri database Core e Runtime e, se vuoi, un proprio indirizzo come
peeters.labapp.example.com. Gli amministratori dell'istanza creano un nuovo
workspace in circa un secondo.
Vantaggi
- Ogni cliente ha comunque i propri database, i propri backup e la propria versione dell'app, adattata al suo modo di lavorare.
- Aggiungere un cliente richiede circa un secondo, e un cliente poco attivo non costa quasi niente: un workspace che nessuno usa non tiene aperta nessuna connessione al database.
- Una sola istanza da gestire, proteggere e aggiornare.
- I tuoi consulenti usano un solo account e passano da un cliente all'altro dal menu dell'avatar.
Svantaggi
- Tutti i clienti passano a una nuova versione della piattaforma nello stesso momento.
- I clienti condividono la capacità dell'istanza, quindi dimensionala per tutti loro insieme. Un'istanza con più di qualche decina di workspace in uso contemporaneamente richiede anche di alzare il limite di connessioni di PostgreSQL oltre il valore predefinito di 100.
- Una nuova versione della tua app si installa comunque workspace per workspace, dal Module Store dell'istanza o da uno ZIP.
A confronto
| Un workspace per istanza | Più workspace per istanza | |
|---|---|---|
| Database propri | Sì, su un server proprio | Sì, su un server condiviso |
| Capacità | Per cliente | Condivisa |
| Versione della piattaforma | Per cliente | Condivisa |
| Dove possono stare i dati | Ovunque, anche nel cloud del cliente | Dove il partner gestisce l'istanza |
| Distribuire una nuova versione dell'app | Uno ZIP importato nel workspace di ogni cliente | Installata nel workspace di ogni cliente, dal Module Store dell'istanza o da uno ZIP |
| Aggiungere un cliente | Una nuova istanza | Circa un secondo |
| Costo per cliente | Più alto | Basso |
Combinare i due modelli è normale: i laboratori piccoli condividono un'istanza, un grande gruppo di laboratori ne riceve una tutta sua, e gli stessi package arrivano a entrambi. Sviluppo, test, collaudo e produzione sono ciascuno un workspace a sé. Metti sviluppo, test e collaudo su un'istanza e la produzione su un'istanza tutta sua, così un aggiornamento della piattaforma arriva in collaudo prima che in produzione.
I clienti di un cliente dentro la sua app
Un laboratorio ha a sua volta dei clienti: produttori alimentari, aziende idriche e imprese manifatturiere che inviano campioni. Vogliono registrare i campioni che inviano e seguirli uno per uno mentre il laboratorio ci lavora. Un produttore alimentare non deve mai vedere i campioni di un altro produttore; il laboratorio li vede tutti. Il laboratorio può far entrare questi clienti nell'app che il partner ha costruito per lui, come organizzazioni cliente.
Il partner costruisce l'app e sceglie l'hosting, con uno qualsiasi dei due modelli visti sopra. Il laboratorio non si accorge di quale sia, e nemmeno i suoi clienti. Il laboratorio poi invita i propri clienti, oppure li lascia registrare da soli.
Un'organizzazione cliente non è un workspace e non ha database propri. Vive dentro il workspace del laboratorio: l'app appartiene a quel workspace, ogni cliente ha i propri membri, e tutto ciò che inseriscono finisce nel database Runtime del laboratorio, contrassegnato con l'azienda che l'ha scritto. Ogni cliente vede solo le proprie righe, il laboratorio le vede tutte, e un cliente può avere a sua volta delle sottounità: un gruppo alimentare, per esempio, con una sottounità per ciascuno dei suoi stabilimenti e una per ogni linea di produzione di uno stabilimento. Ogni unità vede le proprie righe e quelle delle unità sottostanti. I clienti usano l'app così come il laboratorio la pubblica e non la modificano, e l'amministratore di ciascun cliente invita e rimuove i propri colleghi.
Infrastruttura di hosting
Archestack viene distribuito come un'unica immagine container che esegue sia l'API sia i job in background: scheduled event, posta in uscita, esecuzioni delle test suite, sincronizzazioni con altri sistemi e i backup notturni. Scala in orizzontale: esegui più copie della stessa immagine dietro un load balancer man mano che cresce il numero di utenti. Le copie si coordinano tramite PostgreSQL, quindi il lavoro pianificato viene ripartito tra loro e ogni job gira una sola volta.
Immagine Archestack Immagine Archestack Eseguire più di una copia chiede qualcosa all'infrastruttura che la circonda:
- Niente sessioni sticky, ma i WebSocket devono passare. Qualsiasi copia può rispondere a qualsiasi richiesta. Gli aggiornamenti in tempo reale (griglie che si aggiornano, chi altro è su una pagina, notifiche) viaggiano solo su WebSocket, quindi un load balancer o una rete che li blocca lascia l'app funzionante ma senza aggiornamenti in tempo reale.
- Volumi condivisi per backup e file. La cartella dei backup e quella con i
file di ogni workspace (upload, loghi, file scritti dagli script) devono stare su uno storage
montato da ogni copia (in Kubernetes, un volume
ReadWriteMany), altrimenti ogni copia vede solo i backup e i file che ha scritto lei. - Una startup probe. Le copie che partono insieme preparano i database a turno, e con molti workspace da migrare ci vuole un po'. Dai ai container una startup probe invece di una liveness probe breve.
- I limiti di frequenza valgono per copia. Tre copie consentono a ogni chiamante il triplo delle richieste di una sola.
- Dietro PgBouncer in modalità transaction, punta
ConnectionStrings__Clusterdirettamente su PostgreSQL: le copie si parlano tramite una connessione PostgreSQL che deve restare aperta.
Oltre ai container, un'istanza ha bisogno di PostgreSQL 16 e di un proxy che gestisca il TLS.
Gira ovunque girino i container: un singolo server, un account cloud o un cluster Kubernetes.
Può ospitarla il partner, può ospitarla Archestack, oppure può girare nell'infrastruttura del
cliente. Per Kubernetes c'è un chart Helm, e un'istanza può anche vivere sotto un percorso di un
hostname che appartiene a un'altra applicazione, come apps.example.com/archestack/.
Una nuova istanza non ha utenti. La prima persona che la apre crea il primo amministratore, quindi configurala prima che sia raggiungibile da internet.
Capacità e dimensionamento riporta le cifre misurate: quante persone e quanti workspace serve un'istanza, e i server di cui ha bisogno per farlo. Hosting su AKS installa un'istanza su Azure Kubernetes Service e la mantiene da sola sulla release più recente; Hosting con Docker fa lo stesso su un unico server.
Portare la tua app a ogni cliente
Quando ogni cliente ha il proprio workspace, ogni nuova versione dell'app deve viaggiare. Un package è il mezzo con cui viaggia:
- Metti in un package le tabelle, le business entity, le pagine, i business event, gli script module, i PDF template, gli scheduled event, le test suite e gli app layout della tua app, ed esportalo come ZIP.
- Importalo nel workspace del cliente. L'import mostra prima un piano, poi applica le modifiche alle tabelle sul database Runtime del workspace.
- Lì esegui le test suite del package. I test girano in un database sandbox separato e non toccano mai i dati del cliente.
- Pubblica una release. È in quel momento che le nuove pagine arrivano agli utenti del cliente. Un workspace che non ha mai pubblicato una release mostra le sue pagine non appena l'import finisce.
Alcune cose si configurano in ogni workspace invece di essere distribuite: endpoint e chiavi della Data API, traduzioni, utenti, ruoli, business unit, branding, account di posta e connessioni ad altri sistemi. Tutto ciò che è marcato come pubblico arriva privato, quindi installare un package non può mai, da solo, mettere su internet i dati di un cliente.
Su un'unica istanza, un modulo pubblicato come pubblico nel Module Store è visibile a tutti i workspace dell'istanza e ognuno di loro può installarlo, il che evita l'export e l'import. Una scheda privata è visibile solo al workspace che l'ha pubblicata. Tra istanze diverse, i package viaggiano come file ZIP.
Quando l'app vive in un repository git, Strategia di deployment descrive come una pipeline la testa e ne fa il deploy in ogni ambiente senza downtime.
Trappole
- Un aggiornamento della piattaforma raggiunge tutti i workspace dell'istanza in una volta. Un cliente che deve restare su una versione ha bisogno di un'istanza tutta sua.
- Un nuovo workspace parte vuoto. Installaci i tuoi package e invita le persone che ci lavorano; le appartenenze non vengono ereditate dagli altri workspace.
Dove andare dopo
La sezione Packages spiega come costruire ed esportare il package che distribuisci a ogni workspace. La guida alla Data API mostra come un servizio si connette a un workspace con una chiave API, e Database Backups tratta i backup per workspace.