Resolva tenants pelo hostname em uma função

Você serve todos os tenants de um produto a partir de uma função que resolve o tenant pelo hostname de cada requisição, lê a configuração do tenant no KV Store e lê apenas as linhas desse tenant no SQL Database. Fazer o onboarding de um tenant passa a ser uma mudança de dados e uma mudança de domínio, sem deployment.

Pré-requisitos

Uma aplicação com Application Accelerator ativado, servida por um workload na infraestrutura de produção. Para criá-los, consulte Primeiros passos com Applications, e para ativar Application Accelerator, consulte Ative Application Accelerator.
Um certificado no workload que cubra os hostnames dos tenants, como um certificado wildcard. Para solicitar um, consulte Solicite um certificado wildcard.
Um namespace do KV Store para a configuração dos tenants. Para criar um, consulte Namespaces.
Um banco de dados do SQL Database para os dados dos tenants. Para criar um, consulte Bancos de dados e consultas.
Um personal token, para as chamadas de API. Para criar um, consulte Personal tokens.
A Azion CLI instalada e autorizada, para armazenar a variável de ambiente.

Os exemplos usam example.com para a zona, *.app.example.com para os hostnames dos tenants, acme.app.example.com e globex.app.example.com para dois tenants com os IDs 1 e 2, saas-tenants para o namespace, saas-data para o banco de dados e uma tabela projects como os dados dos tenants. Substitua cada valor pelo seu.

Armazene o token de administração

A função escreve a configuração de um tenant em um caminho de administração que verifica um token guardado em uma variável de ambiente, então o token nunca entra no código.

Para criar o token antes, execute este comando com um valor seu. Uma função só lê o novo valor de uma variável depois de um novo deploy, então a variável existe antes da função:

azion create variables --key TENANT_ADMIN_TOKEN --value <admin-token> --secret true

O comando exibe o UUID da variável:

Created variable with UUID <variable-uuid>

O caso de uso Executar aplicações SaaS multi-tenant usa os valores deste exemplo.

Crie a função dos tenants

A função, tenant-app, é executada em todos os caminhos e faz dois trabalhos. Em um hostname de tenant, ela resolve o tenant e responde com os projetos desse tenant. Em PUT /_admin/tenants/<hostname>, ela escreve a configuração de um tenant, que é como o onboarding chega ao KV Store: uma key só é escrita a partir de uma função.

Crie uma função chamada tenant-app com este código e instancie-a na aplicação. Para as etapas em cada interface, consulte Primeiros passos com Functions, que cria uma função e a instancia em uma aplicação.

JavaScript

01export default {

02 async fetch(request, env, ctx) {

03 const url = new URL(request.url);

04 const kv = await Azion.KV.open('saas-tenants');

06 // Onboarding: write one tenant's configuration, keyed by its hostname.

07 if (url.pathname.startsWith('/_admin/tenants/') && request.method === 'PUT') {

08 if (request.headers.get('authorization') !== `Bearer ${Azion.env.get('TENANT_ADMIN_TOKEN')}`) {

09 return new Response('Unauthorized', { status: 401 });

10 }

11 const hostname = url.pathname.slice('/_admin/tenants/'.length);

12 const tenant = await request.json();

13 if (!Number.isInteger(tenant.id)) {

14 return new Response('The tenant id must be an integer', { status: 400 });

15 }

16 await kv.put(`tenant:${hostname}`, tenant);

17 return new Response('Tenant stored', { status: 201 });

18 }

20 // Every other request: resolve the tenant from the hostname.

21 const tenant = await kv.get(`tenant:${url.hostname}`, 'json');

22 if (tenant === null) {

23 return new Response('Unknown tenant', { status: 404 });

24 }

26 // Bind the integer tenant ID, so the query returns this tenant's rows only.

27 const { Database } = Azion.Sql;

28 const connection = await Database.open('saas-data');

29 const rows = await connection.query('select id, name from projects where tenant_id = ? order by id', [tenant.id]);

30 const projects = [];

31 let row = await rows.next();

32 while (row) {

33 projects.push({ id: row.getValue(0), name: row.getValue(1) });

34 row = await rows.next();

35 }

36 return new Response(JSON.stringify({ tenant: tenant.name, projects }), {

37 headers: { 'Content-Type': 'application/json' },

38 });

39 },

40};

O ID do tenant precisa ser um inteiro, porque uma consulta recusa uma string JavaScript como parâmetro. A key de busca é o hostname, que a requisição sempre carrega, porque KV Store não tem nenhuma operação que liste keys.

A instância tenant-app está na aplicação e responde 404 para um hostname sem key.

O caso de uso Executar aplicações SaaS multi-tenant usa os valores deste exemplo.

Execute a função em todos os caminhos

Adicione a regra que executa a instância em todos os caminhos, como Execute uma função em uma aplicação descreve, com estes valores:

Name: tenants - run tenant-app.
Phase: Request Phase.
Criterion: ${uri} starts with /, para que todos os caminhos de todos os hostnames de tenant executem a função.
Behavior: Run Function com a instância tenant-app.

Na API, o corpo de POST /v4/workspace/applications/<application-id>/request_rules leva o ID da instância tenant-app em attributes.value:

JSON

01{

02 "name": "tenants - run tenant-app",

03 "active": true,

04 "criteria": [[{ "variable": "${uri}", "conditional": "if", "operator": "starts_with", "argument": "/" }]],

05 "behaviors": [{ "type": "run_function", "attributes": { "value": <function-instance-id> } }]

06}

Toda requisição ao workload executa tenant-app. Uma regra nova leva alguns minutos para chegar a todos os data centers.

Faça o onboarding de um tenant

Fazer o onboarding de um tenant são quatro mudanças, e nenhuma delas é um deployment: as linhas do tenant, a key de configuração dele, o hostname dele no workload e o registro DNS dele. Esta seção faz o onboarding de acme.app.example.com com o ID de tenant 1.

Para fazer o onboarding do tenant:

Escreva as linhas do tenant

Substitua <database-id> pelo ID de saas-data. O primeiro statement cria a tabela no primeiro onboarding e não faz nada depois. Para como o endpoint de query executa os statements, consulte Crie tabelas e consulte dados:

Shell

01curl --request POST \

02 --url https://api.azion.com/v4/workspace/sql/databases/<database-id>/query \

03 --header 'Accept: application/json' \

04 --header 'Authorization: Token [TOKEN VALUE]' \

05 --header 'Content-Type: application/json' \

06 --data {

07 "statements": [

08 "CREATE TABLE IF NOT EXISTS projects (tenant_id INTEGER, id INTEGER, name TEXT);",

09 "INSERT INTO projects (tenant_id, id, name) VALUES (1, 1, '\''Website relaunch'\'');"

10 ]

11}

A API responde 200 com uma entrada por statement. Leia data[].error em cada entrada, porque um statement com falha também retorna 200.

Escreva a configuração do tenant

Envie a configuração ao caminho de administração da aplicação dos tenants, no domínio do workload, com o seu token:

Shell

01curl --request PUT \

02 --url https://<workload-domain>/_admin/tenants/acme.app.example.com \

03 --header 'Authorization: Bearer <admin-token>' \

04 --header 'Content-Type: application/json' \

05 --data '{"id": 1, "name": "Acme"}'

A função responde 201 com Tenant stored. Uma requisição sem o token responde 401.

Liste o hostname no workload

Envie todos os hostnames que o workload responde, incluindo o novo, porque domains substitui a lista. Para a mesma mudança pelo Azion Console ou pela Azion CLI, consulte Liste o domínio no workload:

Shell

01curl --request PATCH \

02 --url https://api.azion.com/v4/workspace/workloads/<workload-id> \

03 --header 'Accept: application/json' \

04 --header 'Authorization: Token [TOKEN VALUE]' \

05 --header 'Content-Type: application/json' \

06 --data {

07 "domains": ["acme.app.example.com", "globex.app.example.com"]

08}

A API aceita a atualização, e o workload lista o hostname em domains.

Aponte o hostname para o workload

Na zona example.com do Edge DNS, adicione um registro CNAME chamado acme.app cujo valor é o domínio do workload. Para as etapas, consulte Adicione, edite ou exclua um registro.

O tenant responde em acme.app.example.com quando a mudança no workload se propaga, o que leva vários minutos. KV Store torna uma key nova visível em todos os lugares em até 60 segundos, então um tenant pode responder 404 em algumas localidades durante o primeiro minuto.

O caso de uso Executar aplicações SaaS multi-tenant usa os valores deste exemplo.

Confirme que cada tenant vê os próprios dados

Cada verificação requisita um hostname de tenant ou o domínio do workload:

Um tenant vê os próprios dados. Requisite cada hostname de tenant:

curl -s https://acme.app.example.com/

O corpo nomeia o tenant e traz apenas as linhas dele:

{"tenant":"Acme","projects":[{"id":1,"name":"Website relaunch"}]}

A mesma requisição para globex.app.example.com nomeia Globex e não traz nenhum dos projetos da Acme.
Um hostname desconhecido não recebe nada. Requisite o domínio do workload, que não tem key de tenant:

curl -s -o /dev/null -w '%{http_code}\n' https://<workload-domain>/

O comando exibe 404.
O caminho de administração recusa uma requisição sem o token. Envie o PUT de Faça o onboarding de um tenant sem o header Authorization. A função responde 401.
O certificado cobre o tenant. Envie GET https://api.azion.com/v4/workspace/tls/certificates/<certificate-id>. O certificado fica active, porque o workload o usa, e uma requisição HTTPS a cada hostname de tenant conclui o handshake.

Um tenant que responde a página 404 padrão da Azion em vez de Unknown tenant ainda está esperando a mudança no workload se propagar. Quando a função não responder de forma alguma, ative Debug Rules para ver quais regras foram executadas.

Estas verificações confirmam o caso de uso Executar aplicações SaaS multi-tenant.

Próximos passos

Executar aplicações SaaS multi-tenantO design de que esta função faz parte: um certificado wildcard, a configuração dos tenants no KV Store e os dados dos tenants no SQL Database.KV Store APITodos os métodos que a função usa para abrir um namespace e para ler e escrever uma key.