Cómo ejecutar migraciones de bases de datos en un grupo autoescalado

Estamos a punto de pasar de una arquitectura monolítica a un grupo autoescalado y no estoy seguro de cómo debería ejecutar las migraciones de mi base de datos (Laravel).

Estoy pensando que se ejecutará una secuencia de comandos cuando se active un nuevo cuadro, esto hará que mi último código baje. ¿Debería este script también ejecutar la migración de mi base de datos? No estoy seguro de cómo puedo ejecutarlo en una sola caja.

amazon-web-services autoscaling

— Mick
fuente

Supongo que al pasar de monolítico a autoescalado, se está refiriendo específicamente a su base de datos. ¿Estás usando AWS RDS? Si no, ¿lo has investigado? aws.amazon.com/blogs/database/…

— PrestonM

Sí, estamos usando RDS. No, estoy escalando y equilibrando la carga de las instancias EC2 donde se ejecuta la aplicación.

— Mick

Una solución es usar algo como flyway o liquibase que puede ejecutar actualizaciones idempotentes en la base de datos, de esta manera cada nodo que se inicia puede intentar actualizar la base de datos y no hacer nada si la migración ya ocurrió.

— Tensibai

Advertencia justa, Flyway marca las migraciones como completas solo después de que se han ejecutado. Si enciende Flyway simultáneamente desde varios nodos, hay una buena probabilidad de que intenten hacer la misma migración de una vez, lo que puede causar problemas.

— maplebird

Respuestas:

¿Cómo estás haciendo tus despliegues? Nuke + reconstruye el ASG (ya sea un nodo a la vez, o reemplazando todo el grupo a la vez), o ¿tiene un script que redistribuya todos sus nodos activos?

Y también, ¿cómo está activando sus implementaciones?

Idealmente, desea ejecutar / activar implementaciones desde alguna forma de servidor CI como Bamboo o Jenkins. Si está haciendo esto, puede ejecutar sus migraciones de base de datos desde el servidor de compilación (o sus instancias de agente de compilación de componentes).

Esto le permitiría un mayor control sobre su entorno, ya que podría, por ejemplo, restaurar la base de datos desde la instantánea si falla la implementación.

— maplebird
fuente

Por el momento, solo ingresamos SSH en la caja de producción y extraemos el código. En realidad, creo que la mayoría de las veces solo tendremos un nodo. Estaba pensando que usaríamos Code Deploy. Todavía no tenemos mucha experiencia en AWS / Devops y solo estamos tratando de encontrar una manera simple de comenzar con un equilibrio de carga y ASG.

— Mick

AWS CodeDeploy es excelente y se escala a largo plazo una vez que se hace más grande y comienza a usar más servidores. Si por el momento, está desplegando SSH manualmente para implementar, siempre puede tener un script separado que ejecute migraciones de DB. Es decir, ejecutaría el script de implementación normal a través de CodeDeploy y la migración de la base de datos manualmente desde un nodo. Si no está creando un servidor CI que pueda ejecutar Liquibase en el corto plazo, también puede buscar otro software como Datical: aws.amazon.com/blogs/devops/…

— maplebird

El estado de migración de muchas tiendas de orm en la base de datos en sí, pero si lo hace 'manualmente' tampoco es difícil de construir. Simplemente tenga una tabla de "estado de migración" donde se almacenan todas las migraciones ejecutadas. De esa manera, cuando un nodo se conecta, simplemente puede verificar esa tabla con su carpeta local de "migraciones" y ejecutar lo que falta: esto debería causar que solo su primer nodo después de un golpe de versión ejecute las migraciones.

Como nota al margen: CloudFoundry resuelve esto permitiendo que cada instancia (nodo) en su conjunto de escalas acceda a su identificador. El primero obtiene 0, el siguiente 1, etc. De esa manera, un nodo sabe si es el primero y puede ejecutar migraciones. No creo que los ASG tengan lo mismo.

— Trondh
fuente