One approach to running docker on app start - we can't simply add the command to the dockerfile as this will run on all of the containers that use that image (eg app, mqtt-task, sidekiq, auth, etc, etc) causing a race, so instead we create another ephemeral container which runs the migrations then quits.
The only downside to this is that the output from db:migrate goes into the logs for that container, so we don't see whether migrations have been run or not in the terminal, and in the case of long-running migrations (Which ideally shouldn't happen often, if at all, apart from the big kits refactor), they can take a little while to appear.
reading this it appears that there's a school of thought that docker(-compose) shouldn't be responsible for migrations and that they should be run manually when needed. Maybe worth thinking through it and deciding if this is really what we want! (I'm not strongly for or against but probably worth understanding the issues better!
One approach to running docker on app start - we can't simply add the command to the dockerfile as this will run on all of the containers that use that image (eg app, mqtt-task, sidekiq, auth, etc, etc) causing a race, so instead we create another ephemeral container which runs the migrations then quits. The only downside to this is that the output from
db:migrategoes into the logs for that container, so we don't see whether migrations have been run or not in the terminal, and in the case of long-running migrations (Which ideally shouldn't happen often, if at all, apart from the big kits refactor), they can take a little while to appear.reading this it appears that there's a school of thought that docker(-compose) shouldn't be responsible for migrations and that they should be run manually when needed. Maybe worth thinking through it and deciding if this is really what we want! (I'm not strongly for or against but probably worth understanding the issues better!