mysql - tutorial - Ejecución de migraciones con Rails en un contenedor Docker con varias instancias de contenedor
tutorial docker windows (2)
He visto muchos ejemplos de cómo hacer contenedores Docker para aplicaciones de Rails. Por lo general, ejecutan un servidor de rieles y tienen una CMD que ejecuta migrations / setup y luego muestra el servidor de Rails.
Si estoy generando 5 de estos contenedores al mismo tiempo, ¿cómo maneja Rails los procesos múltiples que intentan iniciar las migraciones? Veo que Rails comprueba la versión del esquema actual en el registro general de consultas (es una base de datos MySQL):
SELECT `schema_migrations`.`version` FROM `schema_migrations`
Pero puedo ver una condición de carrera aquí si esto ocurre al mismo tiempo en diferentes instancias de Rails.
Teniendo en cuenta que DDL no es transaccional en MySQL y no veo ningún bloqueo en el registro general de consultas mientras se ejecutan migraciones (que no sean las transacciones por migración), parecería que iniciarlas en paralelo sería una mala idea. De hecho, si pateo esto tres veces localmente, puedo ver que dos de las instancias de los rieles se cuelgan al intentar crear una tabla porque ya existe mientras que la tercera instancia de rieles completa las migraciones felizmente. Si se tratara de una migración que inserta algo en la base de datos, sería bastante inseguro.
¿Es entonces una mejor idea ejecutar un solo contenedor que ejecute migrations / setup y luego genere (por ejemplo) una instancia de Unicorn que a su vez genera múltiples trabajadores de rieles?
¿Debo estar generando contenedores de rieles N y un ''contenedor de migración'' que ejecuta la migración y luego sale?
¿Hay alguna opción mejor?
Especialmente con Rails no tengo ninguna experiencia, pero veamos desde el punto de vista de docker e ingeniería de software.
El equipo de Docker defiende, a veces bastante agresivamente, que los contenedores se refieren a las aplicaciones de envío. En esta muy buena declaración , Jerome Petazzoni dice que se trata de la separación de las preocupaciones. Siento que este es exactamente el punto que ya descubriste.
Ejecutar un contenedor de rieles que inicie una migración o configuración puede ser bueno para la implementación inicial y probablemente también sea necesario durante el desarrollo. Sin embargo, cuando entre en producción, realmente debería considerar separar las preocupaciones.
Por lo tanto, diría que tengo una imagen, que usa para ejecutar el contenedor N rails y agregar herramientas / migration / setup en cualquier contenedor, que usa para realizar tareas administrativas. Eche un vistazo a lo que los desarrolladores de la imagen oficial de los rieles dicen sobre esto:
Está diseñado para ser utilizado como un contenedor desechable (monte su código fuente y comience el contenedor para iniciar su aplicación), así como también la base para construir otras imágenes.
Cuando miras esa imagen, no hay ningún comando de configuración o migración. Depende totalmente del usuario cómo usarlo. Entonces, cuando necesite ejecutar varios contenedores, simplemente continúe.
De mi experiencia con mysql esto funciona bien. Puede ejecutar un contenedor de solo datos para alojar los datos, ejecutar un contenedor con el servidor mysql y, finalmente, ejecutar un contenedor para tareas administrativas como la copia de seguridad y la restauración. Para los tres contenedores puedes usar la misma imagen. Ahora puede acceder a su base de datos, digamos varios contenedores de Wordpress . Esto significa una clara separación de preocupaciones. Cuando utiliza docker-compose no es tan difícil administrar todos esos contenedores. Ciertamente, ya hay muchos contenedores y herramientas de terceros para ayudarle a configurar una aplicación compleja que consta de varios contenedores.
Finalmente, debe decidir si Docker y la arquitectura de micro-servicios son adecuados para su problema. Como se describe en este artículo, hay algunas razones en contra. Uno de los problemas centrales es que agrega una nueva capa de complejidad. Sin embargo, ese es el caso con muchas soluciones y supongo que lo sabe y está dispuesto a excluirlo.
docker run <container name> rake db:migrate
Inicia el contenedor de aplicaciones estándar pero no ejecuta el CMD ( rails server ), sino rake db:migrate
ACTUALIZACIÓN: Sugerido por Roman, el comando ahora sería:
docker exec <container> rake db:migrate