With bleib, your Rails application gains two new rake tasks:
wait_for_database- waits until the database is running and the configured user can access itwait_for_migrations- performswait_for_database, then waits until all migrations are up
Bleib knows about the Apartment gem - if your project includes it, it will also check migrations on tenants.
This was built to be used in kubernetes/OpenShift deployments without a zero downtime approach.
It allows you to kubectl apply your multi-Rails-pod configuration and delegate migrations to either
a Job or one of the Pods.
Using bleib initContainers, dependent Rails Pods (say job workers or multiple replicas) can wait
for migrations or DB redeployments to finish.
- Add the gem to your application:
gem 'bleib' - Build your application image.
- Add an
initContainerthat's based on your application image to your applicationPod. - Set the command of the
initContainertorake wait_for_migrations.
Bleib's behaviour is configured via the environment:
| Environment variable | Default value | Description |
|---|---|---|
| BLEIB_CHECK_DATABASE_INTERVAL | 5 | Seconds to wait between database readiness checks |
| BLEIB_CHECK_MIGRATIONS_INTERVAL | 5 | Seconds to wait between migration readiness checks |
| BLEIB_DATABASE_YML_PATH | config/database.yml | Path to database.yml. Bleib needs this to perform database readiness checks without booting the whole rails environment. |
| BLEIB_LOG_LEVEL | info | Set this to debug to investigate why bleib is hanging. |
| BLEIB_DEFAULT_TENANT | public | Name of well-known always existing Tenant. This depends on the strategy you use with Apartment and your RDBMS. |
- Handles the
postresql,postgisandmysql2database adapters. It's simple to add further adapters, seeBleib::Database#database_down_exception?andBleib::Configuration#check!
Done by hand so far.
If I had a magic wand, I'd do integration tests of Bleib::Database and Bleib::Migrations against
a database container in various states (up, down, preloaded with dumps of different migration states).