Como executar migrações de banco de dados em um grupo dimensionado automaticamente

Estamos prestes a mudar de uma arquitetura monolítica para um grupo de escala automática e não tenho certeza de como devo executar minhas migrações de banco de dados (Laravel).

Eu estou pensando que um script será executado quando uma nova caixa ficar online, isso irá puxar meu código mais recente. Esse script também deve executar minha migração de banco de dados? Não tenho certeza de como posso executá-lo em apenas uma caixa?

amazon-web-services autoscaling

— Mick
fonte

Estou assumindo que, passando de monolítico para auto-redimensionado, você está se referindo especificamente ao seu banco de dados. Você está usando o AWS RDS? Se não, você já olhou para ele? aws.amazon.com/blogs/database/…

— PrestonM 26/09/17

Sim, estamos usando o RDS. Não, estou dimensionando e balanceando a carga das instâncias do EC2 em que o aplicativo é executado.

— Mick

Uma solução é usar algo como flyway ou liquibase que possa executar atualizações idempotentes no banco de dados; dessa forma, cada nó que inicia pode tentar atualizar o banco de dados e não fazer nada se a migração já ocorreu.

— Tensibai

Aviso justo, a Flyway marca as migrações como concluídas somente depois de executadas. se você ativar o Flyway simultaneamente de vários nós, há uma boa chance de que eles tentem fazer a mesma migração de uma só vez, o que pode causar problemas.

— Maplebird

Respostas:

Como você está fazendo suas implantações? O Nuke + reconstrói o ASG (seja um nó de cada vez ou substituindo todo o grupo de uma vez) ou você possui um script que reimplanta todos os seus nós ativos?

E também, como você está acionando suas implantações?

Idealmente, você deseja executar / acionar implantações de algum tipo de servidor de CI, como Bamboo ou Jenkins. Se você estiver fazendo isso, poderá executar suas migrações de banco de dados a partir do servidor de compilação (ou de suas instâncias do agente de compilação de componentes).

Isso permitiria maior controle sobre seu ambiente, pois você poderia, por exemplo, restaurar o banco de dados a partir do instantâneo se a implantação falhar.

— maplebird
fonte

No momento, colocamos o SSH na caixa de produção e inserimos o código. Na realidade, acho que na maioria das vezes teremos apenas um nó. Eu estava pensando em usar o Code Deploy. Ainda não temos muita experiência com a AWS / Devops e estamos apenas tentando encontrar uma maneira simples de começar com um equilíbrio de carga e ASG.

— Mick

O AWS CodeDeploy é excelente e escala a longo prazo quando você cresce e começa a usar mais servidores. Se, por enquanto, você está manualmente com o SSHing para implantar, sempre pode ter um script separado que executa migrações de banco de dados. Ou seja, você executaria o script de implantação normal via CodeDeploy e a migração do banco de dados manualmente de um nó. Se você não está construindo um servidor de CI que pode ser executado Liquibase qualquer momento em breve, você também pode olhar para outro software como Datical: aws.amazon.com/blogs/devops/...

— Maplebird

A migração de muitas lojas da orm está no próprio banco de dados, mas se você fizer isso manualmente, também não será difícil criar você mesmo. Basta ter uma tabela "migrationstate" onde todas as migrações executadas são armazenadas. Dessa forma, quando um nó fica on-line, ele pode simplesmente verificar essa tabela na pasta "migrações" local e executar o que está faltando - isso deve causar apenas o primeiro nó após um bump de versão para executar as migrações.

Como observação lateral: o CloudFoundry resolve isso permitindo que cada instância (nó) no seu conjunto de escalas acesse seu identificador. O primeiro obtém 0, o próximo 1 etc. Dessa forma, um nó sabe se é o primeiro e pode executar migrações. Eu não acho que os ASGs tenham o mesmo.

— Trondh
fonte