Instâncias

Uma instância do Chinaski é um site completo: seu próprio processo de aplicação, seu próprio banco de dados, seus próprios arquivos, seu próprio conjunto de backups, seu próprio segredo. Rodar vários sites significa rodar várias instâncias, lado a lado no mesmo servidor, se você quiser. Esta página explica o modelo e, importante, o que é isolado e o que não é.

Uma instância, um site

Cada instância é uma cópia completa e autônoma:

• Seu próprio processo de aplicação de administração (um serviço systemd como chinaski@1, chinaski@prod, chinaski@staging: o mesmo padrão de unit roda qualquer número)
• Seu próprio arquivo de banco de dados SQLite: conteúdo, usuários, formulários, logs, tudo
• Seu próprio diretório de saída: os arquivos estáticos que seu servidor web publica
• Seu próprio diretório de mídia
• Seu próprio segredo mestre (em um arquivo com permissões travadas, criado na instalação)
• Sua própria porta (3001, 3002, …; cada uma única no host)
• Seu próprio diretório e agendamento de backups
• Seus próprios domínios (via reverse proxy, ou gerenciados pelo Manager)

Nada é compartilhado entre instâncias: sem conteúdo, sem usuários, sem formulários, sem logs, sem sessões. Os sites não podem ver uns aos outros, e seus admins também não.

Por que esse design

O público declarado do software torna o raciocínio claro: "Agencies managing multiple client sites: one instance per client, identical stack, reproducible deployment, clean audit log, no vendor lock-in." Duplicar stacks inteiras é mais disco, menos risco: uma invasão, um deploy ruim, ou um único mau ator em uma instância afeta aquele site e nada mais. Quando um cliente quer sair, você lhe entrega o banco de dados, a saída e o diretório de mídia dele: estão todos em uma pasta.

Isolamento na prática

• O processo: a aplicação de cada instância é isolada pelo systemd para ler/escrever apenas seu próprio diretório; mesmo um bug no código do CMS de um site não pode tocar nos arquivos de outro site.
• O banco de dados: cada site tem seu próprio arquivo SQLite, armazenado com legibilidade apenas para o usuário. Não há servidor de banco de dados compartilhado para invadir, e credenciais de uma instância não significam nada em outra.
• Segredos: cada instância tem um segredo mestre único; credenciais vazadas ficam no escopo de um site.
• Sessões: autenticações de admin vivem inteiramente no banco de dados de uma instância e são assinadas com o segredo dessa instância; um admin de um site simplesmente não tem sessão em outro.
• Portas e domínios: cada instância escuta em sua própria porta de loopback atrás do proxy; se o opcional Chinaski Manager é usado, a unicidade de portas entre instâncias é imposta pelo próprio Manager.
• Backups e deploys: backups e jobs de build/deploy são por instância; um build que falha em um site nunca afeta outro.

Rodando muitos sites

Duas formas, e elas cooperam:

1. À mão: o padrão de unit systemd distribuído mais o instalador de um comando só. Cada instalação é uma instância; atualize os sites um de cada vez com o script de deploy por instância.
2. Com o Manager (produto separado): um painel de controle que provisiona instâncias, executa seu ciclo de vida (build, deploy, rollback, start/stop), anexa domínios (regenerando a configuração do servidor web automaticamente), faz backups por instância e monitora a saúde das instâncias. Seu recurso Discovery encontra instâncias já rodando no servidor (configuradas com systemd, como as acima) e as importa para gerenciamento.

Uma opção de eficiência existe para hosts de muitas instâncias: dependências Perl podem opcionalmente ser instaladas em uma biblioteca compartilhada, para que o deploy de cada instância não as baixe de novo (opt-in, e a unit de cada instância precisa incluir o caminho).

O que "multi-tenancy" não significa aqui

• Não há banco de dados multi-tenant: cada site mantém seu próprio arquivo de dados, conforme a declaração de design do próprio projeto ("one instance per client"). Um nível multi-tenant dentro da aplicação com Postgres está no roadmap e não foi entregue.
• Os "tenants" do Manager são um agrupamento no nível do manager para organizar instâncias e permissões; ele não coloca vários sites em um único banco de dados.

O resumo de uma linha

Dez sites = dez stacks pequenas, idênticas e isoladas mais um painel de controle opcional; cada site pode ter backup, restauração, atualização, deploy, transferência ou exclusão individuais, e um problema em um nunca toma os outros como reféns.