run migrations on docker app start #298
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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!