Espaços de trabalho, instâncias e alojamento
O Archestack é normalmente disponibilizado por um parceiro de implementação: uma empresa que constrói uma aplicação sobre o Archestack e a entrega aos seus clientes. Esta página segue sempre o mesmo exemplo: uma empresa de software que construiu uma aplicação para laboratórios de ensaio, as empresas que analisam alimentos, água e materiais para outras empresas. A aplicação acompanha cada amostra desde a receção até ao certificado, e a empresa de software leva-a a um laboratório atrás do outro. Cada laboratório é um cliente, e cada um tem os seus próprios clientes empresariais: os produtores alimentares, as empresas de águas e os fabricantes que enviam amostras.
O resto desta página assenta em três palavras:
- Cliente: uma empresa a quem o parceiro entrega a aplicação. Neste exemplo, cada laboratório.
- Espaço de trabalho: o ambiente isolado em que um cliente trabalha, com a sua própria aplicação, os seus próprios dados e os seus próprios membros. O seu nome técnico é tenant.
- Instância: uma cópia do Archestack em execução. Corre um espaço de trabalho ou muitos.
Em resumo: um cliente trabalha num espaço de trabalho, e um espaço de trabalho corre numa instância. As secções abaixo explicam o que é um espaço de trabalho e o que o mantém separado, as duas formas de alojar os espaços de trabalho dos seus clientes, como um laboratório deixa entrar os seus próprios clientes, como o próprio Archestack é alojado e como uma nova versão da sua aplicação chega a cada cliente.
O que é um espaço de trabalho
Um espaço de trabalho é o ambiente isolado em que um cliente trabalha. Contém a aplicação inteira, os dados com que essa aplicação trabalha e as pessoas que podem entrar, e está fechado a todos os outros espaços de trabalho. Cada laboratório recebe um.
Tenant é o nome técnico da mesma coisa. Nos ecrãs aparece espaço de trabalho; na API e no código aparece tenant, a palavra por trás do alojamento single-tenant e multi-tenant. Espaço de trabalho e tenant não são duas camadas, e nenhum deles contém o outro: um laboratório tem um espaço de trabalho, e a API chama tenant a esse espaço de trabalho. Esta página usa sempre espaço de trabalho.
Instância do Archestack O que há dentro de um espaço de trabalho
Um espaço de trabalho contém três coisas:
- Core, uma base de dados PostgreSQL que contém a própria aplicação: Business Entities, páginas, Business Events, Script Modules, Scheduled Events, PDF Templates, packages, releases, test suites, endpoints da Data API e chaves de API, tokens MCP, branding, app layouts, traduções, definições, contas de email e a caixa de saída, e as preferências e notificações dos seus utilizadores. As palavras-passe e outros segredos aqui guardados são encriptados, e as chaves de API e os tokens MCP só são guardados como hash.
- Runtime, uma base de dados PostgreSQL que contém os dados de negócio: as tabelas e as linhas que contêm, neste exemplo as amostras, as análises, os resultados, os certificados de análise e as faturas. O Schema Designer mostra a estrutura dela exatamente como está na base de dados.
- Membros: as pessoas que podem entrar, cada uma com uma role neste espaço de trabalho. Os convites são enviados por espaço de trabalho.
Como a aplicação vive no Core, dois laboratórios que correm a mesma aplicação têm cada um a sua
própria cópia. Uma alteração feita num espaço de trabalho fica lá até a distribuir pelos outros,
e é para isso que servem os packages. Um espaço de trabalho também pode
ter um endereço próprio, como peeters.labapp.example.com. No alojamento do
Archestack, também pode ser servido num domínio próprio da empresa, como
app.peeters.be: um administrador adiciona-o na página Domains do builder e
prova-o com um registo DNS, e o certificado chega sozinho.
O que mantém os espaços de trabalho separados
A API e os jobs em segundo plano servem todos os espaços de trabalho da instância, mas cada pedido e cada job agendado trabalha para um só espaço de trabalho:
- Bases de dados separadas. As páginas, as Business Entities e as queries de um espaço de trabalho não conseguem chegar às tabelas de outro espaço de trabalho.
- Um token, um espaço de trabalho. Cada pedido com sessão iniciada leva um token assinado que indica exatamente um espaço de trabalho, e só as bases de dados desse espaço de trabalho são abertas.
- Sem redirecionamento. Um token que indica um espaço de trabalho que não existe ou que foi suspenso é recusado, nunca redirecionado para outro espaço de trabalho.
- Chaves que indicam o seu espaço de trabalho. As chaves de API e os tokens MCP levam o nome do espaço de trabalho a que pertencem e só funcionam aí.
- Jobs que ficam no seu espaço de trabalho. Os jobs agendados correm dentro do espaço de trabalho a que pertencem.
- Backups por espaço de trabalho. Os backups, os restauros e as exportações abrangem o Core e o Runtime de um só espaço de trabalho, por isso os dados de um cliente podem ser restaurados ou exportados sem tocar nos de outro.
Uma conta, uma role por espaço de trabalho
As contas são da instância, as pertenças são do espaço de trabalho. Uma pessoa tem uma conta numa instância, com um endereço de email e uma palavra-passe, e pode ser membro de vários espaços de trabalho, com uma role diferente em cada um. Os consultores do parceiro podem ser admin no espaço de trabalho de cada laboratório que acompanham, enquanto o pessoal de um laboratório só é membro do seu próprio espaço de trabalho.
Quem pertence a vários espaços de trabalho alterna entre eles a partir do menu do avatar. A mudança emite um novo token, que abre o outro espaço de trabalho e só esse. Remover alguém de um espaço de trabalho não mexe nas suas outras pertenças.
O espaço de trabalho principal e os novos
Cada instância cria um espaço de trabalho principal da primeira vez que arranca. Uma empresa que precisa de um único ambiente trabalha simplesmente nele. Um parceiro com muitos clientes reserva o espaço de trabalho principal para a sua própria equipa e cria um espaço de trabalho por cliente. Um novo espaço de trabalho é criado em cerca de um segundo e começa vazio.
Dividir um espaço de trabalho
Há duas funcionalidades que dividem ainda mais um espaço de trabalho. Nenhuma delas cria um novo ambiente: ambas funcionam dentro do espaço de trabalho, sobre o seu próprio Core e Runtime.
- As Business Units dividem-no por equipa, para que cada equipa veja as páginas e as Business Entities que lhe dizem respeito. Não escondem linhas de dados, por isso não são uma separação.
- As organizações cliente dividem-no por cliente. Não são espaços de trabalho próprios. Vivem dentro do espaço de trabalho do laboratório, não ao lado dele, sem bases de dados próprias: os clientes do laboratório usam a aplicação do laboratório, o que introduzem vai parar ao Runtime do laboratório, e cada cliente vê apenas as suas próprias linhas. Mais detalhes abaixo.
Duas formas de alojar os seus clientes
Cada espaço de trabalho corre numa instância: uma cópia do Archestack em execução, com a sua API, os seus jobs em segundo plano e um servidor PostgreSQL que contém as bases de dados dos seus espaços de trabalho. Os espaços de trabalho de uma instância partilham a instância à volta deles, não as bases de dados uns dos outros:
| Próprio de cada espaço de trabalho | Partilhado pelos espaços de trabalho de uma instância | |
|---|---|---|
| A aplicação | Core: páginas, Business Entities, Script Modules, definições e o resto | A versão da plataforma. Uma atualização chega a todos os espaços de trabalho ao mesmo tempo. |
| Os dados | Runtime: as suas tabelas e linhas | O servidor PostgreSQL que contém as bases de dados |
| Pessoas | Membros, roles e convites | As contas: um endereço de email e uma palavra-passe por pessoa |
| Trabalho em segundo plano | Os seus jobs agendados, que correm dentro do espaço de trabalho | Os jobs em segundo plano e o agendador de jobs |
| Módulos | Os packages instalados nele | O catálogo da Module Store |
Os espaços de trabalho de uma instância também partilham a sua capacidade: processador, memória e ligações à base de dados. Para cada cliente, o parceiro decide se o espaço de trabalho desse cliente recebe uma instância só sua ou se partilha uma com os espaços de trabalho de outros clientes. Nos dois modelos, cada cliente tem um espaço de trabalho próprio, com o seu próprio Core e Runtime. O que muda é quantos espaços de trabalho partilham uma instância e, portanto, o que partilham entre si.
Um espaço de trabalho por instância (single-tenant)
Archestack Archestack Archestack Cada laboratório recebe uma instância só sua, com a sua própria API e os seus próprios jobs em segundo plano, e um espaço de trabalho com as suas próprias bases de dados Core e Runtime. É indicado para clientes grandes, para clientes que decidem onde ficam os seus dados e para clientes que escolhem quando atualizar. O parceiro pode gerir estas instâncias, ou instalar uma na conta de cloud ou no centro de dados do próprio laboratório.
Vantagens
- A separação mais forte que existe. Nada é partilhado com outros clientes, nem sequer a plataforma.
- Capacidade própria. Um laboratório muito ocupado nunca torna outro mais lento, e a sua instância é dimensionada só para ele.
- Atualizações ao ritmo do cliente. Cada instância passa para uma nova versão da plataforma quando convém a esse cliente.
- Os dados ficam onde o cliente quer: numa região, numa conta de cloud ou nos seus próprios servidores.
- Uma saída limpa. Entregue a instância, ou desligue-a.
Desvantagens
- Cada instância tem de ser gerida: servidores, certificados, backups, monitorização e atualizações, uma vez por cliente.
- Uma nova versão da sua aplicação tem de ser importada para cada instância separadamente.
- A sua própria equipa precisa de uma conta em cada instância em que trabalha.
- O cliente mais pequeno continua a precisar de uma instância completa.
Vários espaços de trabalho por instância (multi-tenant)
Archestack
Uma instância serve muitos laboratórios. Cada laboratório continua a ser um espaço de trabalho
próprio, com as suas próprias bases de dados Core e Runtime e, se quiser, o seu próprio endereço,
como peeters.labapp.example.com. Os administradores da instância criam um novo espaço
de trabalho em cerca de um segundo.
Vantagens
- Cada cliente continua a ter as suas próprias bases de dados, os seus próprios backups e a sua própria versão da aplicação, adaptada à forma como trabalha.
- Adicionar um cliente demora cerca de um segundo, e um cliente pouco ativo quase não custa nada: um espaço de trabalho que ninguém usa não mantém nenhuma ligação à base de dados.
- Uma só instância para gerir, proteger e atualizar.
- Os seus consultores usam uma só conta e alternam entre clientes a partir do menu do avatar.
Desvantagens
- Todos os clientes passam para uma nova versão da plataforma no mesmo momento.
- Os clientes partilham a capacidade da instância, por isso dimensione-a para todos eles em conjunto. Uma instância com mais do que algumas dezenas de espaços de trabalho em uso ao mesmo tempo precisa também de um limite de ligações do PostgreSQL acima do valor predefinido de 100.
- Uma nova versão da sua aplicação continua a ser instalada espaço de trabalho a espaço de trabalho, a partir da Module Store da instância ou de um ZIP.
Lado a lado
| Um espaço de trabalho por instância | Vários espaços de trabalho por instância | |
|---|---|---|
| Bases de dados próprias | Sim, no seu próprio servidor | Sim, num servidor partilhado |
| Capacidade | Por cliente | Partilhada |
| Versão da plataforma | Por cliente | Partilhada |
| Onde os dados podem ficar | Em qualquer lado, incluindo a cloud do próprio cliente | Onde o parceiro gere a instância |
| Distribuir uma nova versão da aplicação | Um ZIP importado para o espaço de trabalho de cada cliente | Instalada no espaço de trabalho de cada cliente, a partir da Module Store da instância ou de um ZIP |
| Adicionar um cliente | Uma nova instância | Cerca de um segundo |
| Custo por cliente | Mais alto | Baixo |
Combinar os dois é normal: os laboratórios pequenos partilham uma instância, um grande grupo de laboratórios recebe uma só sua, e os mesmos packages chegam a ambos. Desenvolvimento, teste, aceitação e produção são, cada um, um espaço de trabalho próprio. Coloque desenvolvimento, teste e aceitação numa instância e produção numa instância própria, para que uma atualização da plataforma chegue à aceitação antes de chegar à produção.
Os clientes de um cliente, dentro da sua aplicação
Um laboratório tem os seus próprios clientes: produtores alimentares, empresas de águas e fabricantes que enviam amostras. Querem registar as amostras que enviam e acompanhar cada uma enquanto o laboratório trabalha nela. Um produtor alimentar nunca pode ver as amostras de outro produtor; o laboratório vê-as todas. O laboratório pode deixar estes clientes entrar na aplicação que o parceiro construiu para ele, como organizações cliente.
O parceiro constrói a aplicação e escolhe o alojamento, com qualquer um dos dois modelos acima. O laboratório não se apercebe de qual deles é usado, e os seus clientes também não. Depois, o laboratório convida os seus clientes, ou deixa que se registem sozinhos.
Uma organização cliente não é um espaço de trabalho e não tem bases de dados próprias. Vive dentro do espaço de trabalho do laboratório: a aplicação pertence a esse espaço de trabalho, cada cliente tem os seus próprios membros, e tudo o que introduzem vai parar à base de dados Runtime do laboratório, marcado com a empresa que o registou. Cada cliente vê apenas as suas próprias linhas, o laboratório vê todas, e um cliente pode ter as suas próprias subunidades: um grupo alimentar, por exemplo, com uma subunidade para cada uma das suas fábricas e uma para cada linha de produção de uma fábrica. Cada unidade vê as suas próprias linhas e as das unidades abaixo dela. Os clientes usam a aplicação tal como o laboratório a publica e não a alteram, e o próprio administrador de cada cliente convida e remove colegas.
Infraestrutura de alojamento
O Archestack é distribuído como uma única imagem de container que corre tanto a API como os jobs em segundo plano: Scheduled Events, email de saída, execuções de test suites, sincronizações com outros sistemas e os backups noturnos. Escala horizontalmente: corra mais cópias da mesma imagem atrás de um balanceador de carga à medida que o número de utilizadores cresce. As cópias coordenam-se através do PostgreSQL, por isso o trabalho agendado é repartido entre elas e cada job corre uma única vez.
Imagem do Archestack Imagem do Archestack Correr mais do que uma cópia pede algumas coisas à infraestrutura à sua volta:
- Sem sessões fixas, mas os WebSockets têm de passar. Qualquer cópia pode responder a qualquer pedido. As atualizações em direto (grelhas que se atualizam, quem mais está numa página, notificações) viajam só por WebSockets, por isso um balanceador ou uma rede que os bloqueie deixa a app a funcionar, mas sem atualizações em direto.
- Volumes partilhados para backups e ficheiros. A pasta dos backups e a pasta
com os ficheiros de cada espaço de trabalho (uploads, logótipos, ficheiros que os scripts
escrevem) têm de estar num armazenamento que todas as cópias montam (em Kubernetes, um volume
ReadWriteMany), senão cada cópia só vê os backups e os ficheiros que ela própria escreveu. - Uma startup probe. As cópias que arrancam ao mesmo tempo preparam as bases de dados à vez, e com muitos espaços de trabalho para migrar isso demora. Dê aos containers uma startup probe em vez de uma liveness probe curta.
- Os limites de pedidos são por cópia. Três cópias permitem a cada cliente três vezes mais pedidos do que uma.
- Atrás do PgBouncer em modo transaction, aponte
ConnectionStrings__Clusterdiretamente para o PostgreSQL: as cópias falam entre si por uma ligação PostgreSQL que tem de ficar aberta.
Além dos containers, uma instância precisa de PostgreSQL 16 e de um proxy que trate do TLS. Corre
em qualquer lado onde corram containers: um único servidor, uma conta de cloud ou um cluster
Kubernetes. Pode ser alojada pelo parceiro ou pelo Archestack, ou correr na infraestrutura do
próprio cliente. Para Kubernetes existe um chart Helm, e uma instância também pode viver sob um
caminho de um nome de host que pertence a outra aplicação, como
apps.example.com/archestack/.
Uma instância nova não tem utilizadores. A primeira pessoa que a abre cria o primeiro administrador, por isso configure-a antes de ficar acessível a partir da internet.
Capacidade e dimensionamento tem os valores medidos: quantas pessoas e quantos espaços de trabalho uma instância serve, e os servidores de que precisa para isso. Alojamento no AKS instala uma instância no Azure Kubernetes Service e mantém-na na release mais recente por si só; Alojamento com Docker faz o mesmo num só servidor.
Levar a sua aplicação a cada cliente
Quando cada cliente tem o seu próprio espaço de trabalho, cada nova versão da aplicação tem de viajar. É num package que ela viaja:
- Coloque num package as tabelas, as Business Entities, as páginas, os Business Events, os Script Modules, os PDF Templates, os Scheduled Events, as test suites e os app layouts da sua aplicação, e exporte-o como ZIP.
- Importe-o para o espaço de trabalho do cliente. A importação mostra primeiro um plano e depois aplica as alterações de tabelas à base de dados Runtime do espaço de trabalho.
- Corra aí as test suites do package. Os testes correm numa base de dados sandbox separada e nunca tocam nos dados do cliente.
- Publique uma release. É nesse momento que as novas páginas chegam aos utilizadores do cliente. Um espaço de trabalho que nunca publicou uma release mostra as suas páginas assim que a importação termina.
Há coisas que se configuram em cada espaço de trabalho em vez de serem distribuídas: endpoints e chaves da Data API, traduções, utilizadores, roles, Business Units, branding, contas de email e ligações a outros sistemas. Tudo o que está marcado como público chega como privado, por isso instalar um package nunca pode, por si só, pôr os dados de um cliente na internet.
Numa instância, um módulo publicado na Module Store como público fica visível para todos os espaços de trabalho dessa instância, e todos o podem instalar, o que poupa a exportação e a importação. Uma listagem privada só é visível para o espaço de trabalho que a publicou. Entre instâncias, os packages viajam como ficheiros ZIP.
Quando a aplicação vive num repositório git, Estratégia de deployment descreve como um pipeline a testa e faz deploy dela para cada ambiente sem tempo de inatividade.
Armadilhas
- Uma atualização da plataforma chega a todos os espaços de trabalho da instância ao mesmo tempo. Um cliente que tenha de ficar numa versão precisa de uma instância própria.
- Um novo espaço de trabalho começa vazio. Instale nele os seus packages e convide quem vai trabalhar nele; as pertenças não transitam de outros espaços de trabalho.
Para onde seguir a partir daqui
Packages explica como construir e exportar o package que distribui para cada espaço de trabalho. O guia da Data API mostra como um serviço se liga a um espaço de trabalho com uma chave de API, e Database Backups trata dos backups por espaço de trabalho.