Estou desenvolvendo um site do django com um banco de dados Postgres. Eu desenvolvo localmente e tenho 3 servidores VPS para teste, preparo e produção. Cada VPS executa sua própria pilha Linux / Apache / Python / Postgres, com seus próprios bancos de dados.
O que eu comecei a descobrir é que, com a implantação contínua usando o git, o preparo praticamente se tornou redundante (passar do escalonamento para a produção requer a troca de endereços IP que requerem uma reinicialização do VPS).
A única vez que eu posso esperar que o teste seja útil é quando uma migração complexa do banco de dados precisa acontecer, e mesmo assim, como os bancos de dados do Postgres sobre armazenamento temporário e produção não são espelhados, pode haver problemas na perda de dados entre migrações.
Minha (s) pergunta (s) é que devo estar espelhando o Postgres entre o teste e a produção? (se sim, como?) E estou fazendo certo? Não consigo encontrar muita documentação em qualquer lugar sobre as práticas recomendadas de implantação de aplicativos da Web.
Eu diria que você deve estar espelhando o Postgres entre o teste e a produção, se você acha que terá que fazer uma migração complexa do banco de dados mais de uma vez. Fazer migrações manualmente pode ser tão propenso a erros que você quase certamente recuperará o investimento de tempo na configuração da migração.
Não sou especialista em Postgres, mas aqui está uma visão geral das opções de replicação.
Você pode evitar a perda de dados durante a migração, tornando o site ao vivo somente leitura durante a atualização.
Presumivelmente, você tem algum sistema de backup para o seu banco de dados postgresql? Nesse caso, você pode usar esses backups para preencher seus dados em seu ambiente de preparação / desenvolvimento. Eu tenho alguns clientes que usam replicação (principalmente no espaço do MySQL).
Para backups / armazenamento temporário: Produção - replicação - > Staging --mysqldump - > backup
Para desenvolvimento: Cópia de segurança --mysqlimport - > desenvolvimento
Quando eles precisam testar na implantação, eles simplesmente interrompem a replicação. Este sistema é usado com pouca frequência (2-4 vezes por ano). A desvantagem disso é que em algum momento você precisa redefinir a replicação, o que pode exigir algum tempo de inatividade no sistema de produção.
Existem provavelmente implementações mais limpas, mas eles descobriram que isso funciona bem. O bom é que eles simplesmente promovem o código para o sistema de teste, quebram a replicação e, basicamente, possuem uma caixa atual ativa para regressão e teste de aplicativos.
Tags postgresql django linux deployment