GCP Cloud Run with PostgreSQL - how to do migrations?

user_14233806 0
Viewed 997

we are starting with our first cloud run project. in the past we used postgres in combination with spring boot. and we had our migrations running via flyway (similar to liquibase) when the app started.

now with cloud run, this approach will maybe hit it's limit because of the following (corner) cases:

  • multiple incoming requests (http, messages) routed to parallel instances that could do the same migration in parallel when bootstrapping the container. that would result in exceptions and retries of failed messages or http errors
  • flyway check on bootstrap would slow down the cold start times additionally every time a container gets started, which could be a lot if we do not have constant traffic with "warm" instances

what would be a good approach having springboot/flyway and postgres as backing database shared accross the instances? a similar problem arises when you replace postgres with a nosql datastore i guess if you want/need to migrate new structures....

right now i can think of:

  • do a migration of the postgres schema as part of the deployment pipeline before the cloud revision gets replaced which would introduce new challenges (rollbacks etc.)

please share your ideas? looking forward to your answers? marcel

google-cloud-run flyway google-cloud-platform postgresql
1 Answers

For migrations that introduce breaking changes either on commit or on rollback, it's mandatory to have a full stop, and of course, rollback planned accordingly.

Also pay attention, that a commit/push should not trigger immediately the new migrations. Often these are not part of the regular CI/CD pipeline that goes to production.

After you deploy a service, you can create a new revision and assign a tag that allows you to access the revision at a specific URL without serving traffic.

A common use case for this, is to run and control the first visit to this container. You can then use that tag to gradually migrate traffic to the tagged revision, and to rollback a tagged revision.

To deploy a new revision of an existing service to production:

gcloud beta run deploy myservice --image IMAGE_URL  --no-traffic --tag TAG_NAME

The tag allows you to directly test(or run via this the migration - the very first request) the new revision at a specific URL, without serving traffic. The URL starts with the tag name you provided: for example if you used the tag name green on the service myservice, you would test the tagged revision at the URL https://green---myservice-abcdef.a.run.app

user_2437820
Related