I was wondering if there exists a best practice on how to do data migration during “rancher-compose up”. By that I mean doing a rake db:migrate, liquibase:update or equivalent before actually starting the new container.
My initial thoughts were to do something along these lines:
rancher-compose run “migrate-command”
rancher-compose up --upgrade
As there is no run command I figured another solution could be to have a migration-compose.yml file containing a cmd with the migrate-command, and doing perhaps this:
rancher-compose -f migration-compose.yml up
rancher-compose -f migration-compose.yml rm
rancher-compose up --upgrade
What do you think? Or how are you doing db migrations at your projects?
Or maybe having a db_migrate container inside docker-compose.yml, with a command: “rake db:migrate”, as a sidekick of some sorts? So you’ll end up doing something like this:
either ship in your application a migration feature which compare the running application version and a flag in database which says which version has generated data : if the application is more recent, the code run your shipped migration procedures.
you provide a dedicated container which run your migration command/code once, by applying this label to your container (cf http://docs.rancher.com/rancher/labels/ ): io.rancher.container.start_once
Thanks for the reply @clescot! io.rancher.container.start_once was new to me. That might help.
Option 1 is by the easiest and most maintainable version I think, which I should evaluate again. The team has been reluctant to doing a check-for-migrations-always, as the deploy-process was scripted as to stop the deploy if migrations failed. Using rancher-compose and upgrade with healthchecks I guess this can be overcome as the “new” app would fail to start. A zero downtime was not implemented earlier as well.