Open calebmeyer opened 6 years ago
Hi @calebmeyer. I think this would also be a useful example to include. I've done this a few different ways in the past.
docker-compose.yml
, call it db
and just run the community mysql
imagedepends_on
to services you want to spin up the database for first. app
with database commands.I imagine it would look something like:
services:
db-migrate:
command: sh -c "bundle exec rake db:migrate"
depends_on:
- db
environment:
- DB_HOST: db
image: 'mikeantonelli/docker-rails-compose:${VERSION-latest}'
db:
image: 'mysql:5.6'
Rather than build a new image varient, I would think that our production image should have all schema, migrations, and db connection configuration. It might also be a good time to introduce env_files
instead of environment
in service definitions so that we can take advantage of the same database configuration for db
, db-migrate
and app
.
The result would be the capability to:
docker-compose run db-migrate
You could also override this to run custom commands:
docker-compose run db-migrate sh -c 'bundle exec rake db:setup`
So, maybe a different name than db-migrate
makes more sense?
I also think we could update the app front end to show the current migration version so there was an example of database utilization in the project.
@calebmeyer I opened #4 if you want to take a look.
The current application has nothing in schema.rb, no migrations, and no host defined in the database.yml
I assume there's some work to be done to ensure that docker can talk to a database run
The "in another container" solution seems the best from the perspective of running everything needed locally using docker. However, this presents challenges:
Can we get that included?