Como separar as migrações da base de dados do arranque da aplicação durante implementações de contentores

É mais fácil evitar migrações duplicadas da base de dados quando as alterações ao esquema são executadas como um único passo de implementação explícito, em vez de serem executadas no arranque de cada contentor da aplicação.

A abordagem preventiva consiste em atribuir as migrações a um único responsável, usar um único conjunto de credenciais e definir um único sinal de conclusão antes de as novas réplicas começarem a servir tráfego. Mantenha os contentores Web e de trabalho livres para reiniciar sem obter privilégios de alteração do esquema, faça a implementação aguardar por uma tarefa de migração bem-sucedida e conceba as alterações ao esquema de modo a permitir que as versões antiga e nova da aplicação coexistam brevemente. Assim, elimina a condição de corrida, em vez de simplesmente esperar que todas as réplicas detetem primeiro o mesmo histórico de migrações.

Remova os comandos de migração do arranque normal da aplicação

Inspecione o ponto de entrada da imagem, o comando do Compose, o comando do trabalhador, o wrapper de estado de funcionamento e o script de implementação à procura de chamadas automáticas de migração. A aplicação deve poder reiniciar sem modificar o esquema, a menos que esse reinício seja o passo de migração deliberadamente escolhido.

Um artigo da Octopus sobre implementações defende que as migrações precisam de um ciclo de vida separado, em vez de estarem associadas ao arranque de cada processo de microsserviço.

Mantenha o binário de migração disponível onde for necessário, mas não o invoque tanto no ponto de entrada Web como numa segunda tarefa. Um único responsável explícito é mais fácil de auditar do que vários caminhos de arranque que dependem todos do bloqueio da framework.

Execute uma tarefa de migração antes da implementação

Crie uma tarefa executada uma única vez, que utilize os mesmos ficheiros de migração da versão e termine com sucesso apenas depois de a base de dados de destino atingir o estado de esquema esperado. Faça a implementação da aplicação depender desse resultado.

Um guia atual de implementação mostra como uma tarefa é executada antes da implementação, em vez de permitir que todas as réplicas entrem em corrida no arranque.

Não dimensione a tarefa de migração como o serviço da aplicação. A tarefa deve ter um único responsável pela execução para cada base de dados de destino, um tempo limite definido, registos e um estado de falha claro que bloqueie a nova versão da aplicação.

Condicione o arranque da aplicação ao sucesso da migração

Mantenha os novos contentores Web e de trabalho à espera até a fase de migração indicar sucesso, mas não faça cada contentor em espera executar novamente a migração. A dependência é do resultado, não da execução repetida da alteração ao esquema.

O padrão de implementação de Andrew Lock utiliza pods da aplicação à espera da migração, mantendo a lógica de migração centralizada.

Numa pequena stack de servidor doméstico, o mesmo princípio pode ser implementado com um serviço dedicado do Compose e um script de implementação controlado. Mantenha o mecanismo suficientemente simples para que uma migração falhada interrompa visivelmente a implementação.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Utilize alterações ao esquema compatíveis com versões anteriores durante a sobreposição

As implementações progressivas podem executar temporariamente versões antiga e nova da aplicação na mesma base de dados. Evite uma migração que remova ou mude o nome de um campo antes de a versão antiga deixar de o utilizar.

Um guia recente sobre migrações sem tempo de inatividade recomenda expandir antes de contrair, para que as alterações aditivas ao esquema sejam aplicadas antes da limpeza destrutiva.

Divida as alterações de grande dimensão em fases de expansão, preenchimento retroativo, mudança e contração, quando necessário. A tarefa de migração não deve criar um esquema que apenas o novo contentor compreenda enquanto as réplicas antigas continuam a processar pedidos.

Mantenha as credenciais de migração fora das réplicas da aplicação

Quando for prático, utilize uma conta da base de dados com privilégios de alteração do esquema apenas na fase de migração executada uma única vez. Os contentores normais da aplicação devem manter as permissões mais restritas de leitura e escrita necessárias para os dados da aplicação.

Um artigo da Liquibase sobre implementações descreve que as alterações da base de dados pertencem à automatização, com aplicação controlada e repetível das alterações.

Esta separação reduz a probabilidade de uma execução acidental da migração, mesmo que um processo da aplicação seja reiniciado ou duplicado. Armazene a credencial elevada no caminho de segredos da implementação, em vez de a colocar no ambiente normal do serviço de longa duração.

Verifique que a implementação não consegue aplicar o lote duas vezes

Teste a implementação numa base de dados descartável ou num instantâneo restaurado, iniciando várias réplicas da aplicação, reiniciando-as e executando novamente o comando de implementação. A fase de migração deve comunicar o estado existente do esquema sem o alterar uma segunda vez.

A JetBrains resume a regra operacional como executar as migrações como passo da implementação antes do arranque normal da aplicação.

A política de prevenção está completa quando os reinícios da aplicação não conseguem alterar o esquema, uma migração falhada bloqueia a versão e a execução repetida da implementação não altera a base de dados. O artigo relacionado da ZimaSpace sobre o diagnóstico de migrações duplicadas é o ramo de recuperação caso a execução duplicada já tenha ocorrido.