Data migration during upgrade

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:

  1. rancher-compose run “migrate-command”
  2. 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:

  1. rancher-compose -f migration-compose.yml up
  2. rancher-compose -f migration-compose.yml rm
  3. 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:

  1. rancher-compose create
  2. rancher-compose up db_migrate
  3. rancher-compose up web --upgrade -d

you’ve got many options including :

  • 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 ):

hope it helps,


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.