Multi-tenancy simples com Django em execução no OpenShift

Chris Hambridge Blocked Unblock Seguir Seguindo 12 de janeiro Foto por Samuel Zeller em Unsplash

A necessidade de aplicativos com vários inquilinos não é nova, mas com a crescente popularidade das ofertas de software como serviço (SaaS) , você está criando algo errado se não considerar esse requisito essencial. A multilocação na arquitetura de software é onde uma única instância de um aplicativo atende a vários clientes (cada cliente é chamado de inquilino) . Um cliente pode ser uma empresa inteira ou uma divisão de uma empresa, ou Todd, o desenvolvedor.

Foto por rawpixel no Unsplash

Existem muitas abordagens para resolver este problema. A área de foco mais comum é em torno dos dados armazenados para um inquilino. As abordagens variam de um banco de dados por cliente até tabelas compartilhadas com uma coluna especificando o cliente. A utilização de uma convenção de nomenclatura de banco de dados ou tabela (por exemplo, prefixo de cliente, etc.) permite que os desenvolvedores continuem pensando em um único foco no cliente e também separem os dados de alguns outros dados do cliente. A abordagem baseada em colunas do cliente diz basicamente que você adiciona uma cláusula WHERE a tudo. Cada um pode ter suas próprias desvantagens; a criação de banco de dados pode levar muito tempo, as convenções de nomenclatura podem adicionar complexidade de código e a abordagem baseada em coluna pode atingir rapidamente os problemas de desempenho à medida que todos os dados do cliente são forçados juntos.

Multi-tenancy e PostgresSQL

Foto de Matthew Spiteri no Unsplash

O PostgresSQL é o banco de dados mais comumente utilizado para aplicativos Django . O Postgres tem um recurso, esquemas , que aproveitam as vantagens da abordagem baseada em banco de dados / tabela, ao mesmo tempo em que aborda alguns dos problemas de complexidade e desempenho. Os esquemas fornecem o comportamento de um banco de dados, mas são mais rápidos de criar. Com esquemas, as tabelas para cada inquilino podem ser idênticas, o que reduz a complexidade, mas também pode residir no mesmo banco de dados, juntamente com dados compartilhados independentes de inquilino. Essa segregação de dados também permite que você evite a desvantagem da abordagem baseada em coluna, que pode se deparar com problemas de desempenho e tem o acréscimo adicional de que a velocidade de consulta em um inquilino com apenas uma pequena quantidade de dados é afetada por todos os outros dados de inquilino. Embora os esquemas sejam um bom recurso, ainda não torna a multilocação simples.

Felizmente, a comunidade opensource ajudou a contribuir com bibliotecas que, de fato, tornam simples o desenvolvimento com esquemas do PostgresSQL . Há uma variedade de bibliotecas agora disponíveis; nossa equipe empregou django-tenant-schemas para ajudar a resolver esse problema. O django-tenant-schemas se encaixa muito bem no ciclo de vida do Django . A criação do esquema aciona as migrações para serem executadas e permite manter o processo normal de desenvolvimento do Django . O módulo também fornece um gerenciador de contexto que simplifica a seleção do esquema com o qual você deseja interagir.

Gerenciador de Contexto para Acessar Dados do Locatário

Além disso, você pode diferenciar entre dados compartilhados e dados de inquilino simplesmente especificando a configuração.

Esquemas de Tenant do Django em Ação

Enquanto a documentação para django-tenant-schemas é muito boa, nós não utilizamos sua implementação padrão pronta para uso. A implementação padrão usa a noção de criar os esquemas de inquilino com base na URL do domínio; por exemplo, pense em cada locatário tendo seu próprio subdomínio para acessar dados (ie {tenant} .myapp.io) e derivando o nome do esquema daquele padrão. Embora os subdomínios sejam um bom padrão, podem não atender às suas necessidades; não correspondeu aos nossos requisitos.

Em nosso caso, a locação pode ser determinada por dados em um cabeçalho que forneceu informações sobre a conta. Felizmente, este foi um padrão bastante comum que também encontramos documentação de exemplo para lidar com esse fluxo. Embora os exemplos sejam ótimos, pode ser útil ver um aplicativo em funcionamento com um pouco mais de complexidade, em que temos vários aplicativos compartilhados e aplicativos de inquilino .

Configuração de esquema específico para inquilino e compartilhada

Você também pode mergulhar em nosso middleware de locatário para ver nosso fluxo, não apenas criando inquilinos com base nas informações de cabeçalho, mas também criando objetos de clientes e usuários associados à solicitação.

Implantando no OpenShift com Source-to-Image (S2I)

Agora que exploramos os blocos de construção de um aplicativo Django com vários locatários, devemos considerar as implicações na implantação contínua e nas migrações de dados à medida que novas facetas / recursos são implementados em um projeto. Se você é um experiente desenvolvedor do Django, você está familiarizado com o fluxo de migração . Como mencionado anteriormente, o django-tenant-schemas se encaixa no ciclo de vida do Django , por exemplo, fornecendo seu próprio comando, migrate-schemas , para aplicar migrações através de esquemas. Com essas peças disponíveis, qual a melhor maneira de encaixá-las em sua estratégia de implantação contínua?

Como criar uma imagem do S2I Builder – Red Hat OpenShift Blog
O Source-To-Image (S2I) é uma ferramenta autônoma que é muito útil ao criar imagens do construtor. Acontece também que S2I… blog.openshift.com

O OpenShift oferece um mecanismo de construção / implantação chamado Source-to-Image (s2i) para casar imagens de base com código do controle de origem (como o GitHub ). O Source-to-image suporta um fluxo padrão de execução de montagem e execução de scripts que são acionados pela imagem base após o download da origem do código. Se você mergulhar nesses scripts, poderá ver como ele prepara o contêiner com base na origem fornecida.

Migração de Esquema com s2i

O script acima mostra o estágio no script de execução que foi alterado para suportar migrações de inquilino com o comando migrate_schemas . Com isso, você pode migrar sua estrutura de banco de dados e adicionar novas tabelas em seus esquemas compartilhados e inquilinos em uma configuração de implantação contínua.

Exemplo de esquemas de inquilinos em ação

Sinopse

Nesta história, destacamos a necessidade de considerar a multilocação em seu design de software, juntamente com alguns padrões comuns de implementação. No mundo do desenvolvimento do Django , descobrimos que o PostgresSQL fornece esquemas, o que permite uma abordagem equilibrada no contexto dos padrões comuns e suas desvantagens. Ainda mais importante, a comunidade opensource tornou simples o uso de esquemas com o Django . Por fim, consideramos os impactos na migração e na implantação contínua com o s2i no Openshift e exploramos as atualizações necessárias.

Texto original em inglês.