Como isolar sites de clientes WordPress sem o Multisite

Isolamento é uma daquelas palavras que parecem resolvidas até um cliente fazer a pergunta difícil: se outro site nesta instalação for hackeado ou corromper seus dados, o meu também cai? Se a sua resposta depende de um database compartilhado, a resposta honesta é “talvez”. Este guia mostra um fluxo de trabalho de configuração para dar a cada site de cliente um isolamento real (dados separados, código separado, domínio de falha separado), enquanto você ainda gerencia uma única instalação do WordPress.

O que “isolamento” realmente significa

O isolamento não é uma única propriedade. São três, e o Multisite entrega aproximadamente uma delas.

• Isolamento de dados: as linhas, os usuários e as opções de um tenant não podem ser lidos ou corrompidos pelo contexto de outro tenant.
• Isolamento de código: cada tenant pode rodar seus próprios themes e plugins em suas próprias versões, para que uma atualização ou um plugin ruim no Cliente A nunca afete o Cliente B.
• Isolamento de domínio de falha: quando um tenant quebra (um erro fatal, uma tabela corrompida, um restore malsucedido), o raio de impacto para naquele tenant.

O Multisite compartilha um database e um diretório wp-content entre todos os subsites. Os subsites são separados apenas por um ID de blog e um prefixo de tabela dentro desse database único. Isso te dá uma forma fraca de separação de dados e nada mais: todo subsite roda os mesmos plugins e themes do mesmo diretório, e uma única tabela corrompida ou um erro fatal de plugin fica dentro do mesmo domínio de falha de todos os outros. Prefixos separam linhas. Eles não separam riscos.

Isolamento de database: prefixo, MySQL dedicado ou SQLite

O isolamento de database é o eixo com mais opções, então escolha com cuidado.

• MySQL compartilhado, prefixo único por tenant (plugin gratuito): o GrabWP Tenancy dá a todo tenant um prefixo de tabela único no database compartilhado, além de um diretório uploads separado. Isso é uma separação real em nível de linha e é a maneira mais rápida de colocar muitos sites de clientes no ar, mas os tenants ainda vivem em um único database, então é um isolamento parcial.
• Database MySQL dedicado por tenant (Pro): o GrabWP Tenancy Pro dá a cada tenant seu próprio database MySQL. Isso é o isolamento completo de dados com risco zero entre tenants na camada do database: um travamento, uma tabela inchada ou um índice corrompido fica dentro do database daquele cliente.
• SQLite por tenant (Pro): para tenants leves ou portáteis, o Pro pode respaldar um tenant com seu próprio arquivo de database SQLite, o que torna o tenant autossuficiente e muito fácil de mover.

Como o Pro suporta migração entre databases, essas não são escolhas definitivas. Você pode começar um cliente no modelo de prefixo compartilhado e mover esse tenant para um database MySQL ou SQLite dedicado mais tarde, sem precisar reconstruí-lo.

Isolamento de código via wp-content por tenant

O isolamento de dados é só metade da história. Se dois clientes compartilham um diretório wp-content, eles compartilham um conjunto de arquivos de plugin e theme, o que significa que a atualização de um plugin ou um theme incompatível de um cliente vira problema de todo mundo.

O plugin gratuito isola os uploads por tenant. O Pro vai além com a separação completa do wp-content: themes, plugins e uploads isolados por tenant, cada um sob seu próprio diretório de conteúdo. É isso que permite que o Cliente A rode uma versão antiga e fixada de um page builder, enquanto o Cliente B roda a mais recente, sem arquivos compartilhados e sem colisão de versão. O Pro também pode colocar o local de dados de um tenant inteiramente fora do wp-content/uploads, o que é útil quando você quer o armazenamento do tenant em um volume separado.

Roteando cada tenant sem DNS

O isolamento não vale de nada se os clientes não conseguem acessar seus sites, e você não deveria ter que mexer no DNS para cada novo tenant. O GrabWP Tenancy roteia os tenants de duas formas:

• Roteamento baseado em caminho (subdiretório): acesse um tenant em yoursite.com/site/client-a sem nenhuma mudança de DNS. O prefixo site é configurável através da constante GRABWP_TENANCY_PATH_PREFIX se você quiser um segmento diferente.
• Roteamento de domain personalizado: aponte o próprio domain do cliente para o tenant quando ele estiver pronto para uma URL com sua marca.

O roteamento baseado em caminho é o superpoder silencioso do fluxo de trabalho de isolamento: você pode provisionar, testar e entregar um site de cliente totalmente isolado antes que qualquer DNS exista. Também há um isolamento de cache embutido, para que os tenants não entrem em conflito em uma infraestrutura compartilhada. O plugin desativa os drop-ins de cache de página por requisição e prefixa as chaves de object-cache com o ID do tenant, o que previne colisões de cache entre tenants em um backend Redis ou Memcached compartilhado.

Isolamento de domínio de falha via backup e restore por tenant

O domínio de falha é o eixo que as pessoas esquecem até que aconteça um incidente. O isolamento verdadeiro significa que você pode fazer o backup e o restore de um cliente sem tocar em nenhum outro.

O Pro oferece um backup de 7 etapas e um restore de 8 etapas por tenant, com progresso via AJAX, para que a recuperação do Cliente A seja uma operação independente. Você pode agendar backups automáticos (de hora em hora, duas vezes ao dia, diário, semanal, quinzenal ou mensal) com substituições por tenant e enviá-los para o S3. Essa combinação é o que transforma “isolado”, de uma afirmação de arquitetura, em uma realidade operacional: um tenant pode ser revertido para o dia anterior, enquanto todos os outros continuam rodando sem interrupções.

Colocando um tenant isolado no ar, passo a passo

Aqui está o fluxo de trabalho concreto para um site de cliente genuinamente isolado:

1. Instale o GrabWP Tenancy na sua única instalação do WordPress e ative-o.
2. Crie o tenant para o cliente. No plugin gratuito, isso provisiona automaticamente um prefixo de tabela único e um diretório uploads separado.
3. Faça o upgrade do tenant para isolamento completo com o Pro: atribua a ele um database MySQL ou SQLite dedicado e seu próprio diretório wp-content, para que dados e código fiquem ambos separados.
4. Roteie o tenant usando o roteamento baseado em caminho (yoursite.com/site/client-a) para que você possa construir e testar sem DNS, e então anexe o domain personalizado do cliente na hora da entrega.
5. Configure o agendamento de backup para aquele tenant, adicione um destino de envio no S3, rode um backup manual e teste o restore para confirmar que o domínio de falha está realmente isolado.
6. Clone a partir de um tenant base quando você precisar de um ponto de partida repetível: a clonagem copia as tabelas do database e os uploads com substituição automática de URL (ele pula symlinks), então um novo cliente começa a partir da sua stack padrão.

O resultado é uma instalação para atualizar e monitorar, com cada cliente ficando em seu próprio limite de dados, código e recuperação.

Quando o isolamento importa mais

Nem todo projeto precisa de databases dedicados. Mas o isolamento deixa de ser opcional quando:

• Você hospeda trabalhos de clientes pelos quais você é contratualmente responsável, onde o incidente de um cliente não pode afetar outro.
• Os clientes rodam versões conflitantes de plugin ou theme que não podem coexistir em um wp-content compartilhado.
• Você precisa de um limite limpo de falha e recuperação por cliente, para que um restore ruim ou uma tabela corrompida seja um problema de um cliente, e não de toda a sua lista.
• Você quer uma arquitetura de isolamento de dados que você possa descrever honestamente para os clientes que perguntam onde os dados deles ficam.

Para um olhar mais profundo sobre onde o modelo compartilhado falha, veja quando não usar o WordPress Multisite e a comparação completa de Multisite vs multi-tenancy.

Comece agora

Comece com o plugin gratuito GrabWP Tenancy para prefixos de tabela únicos, uploads separados e roteamento de caminho sem DNS. Quando um cliente precisar de isolamento completo (MySQL ou SQLite dedicado, separação completa do wp-content e backup e restore por tenant), faça o upgrade para o GrabWP Tenancy Pro por $9.99/month.