You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I assume there's some work to be done to ensure that docker can talk to a database run
locally at 0.0.0.0
in another container
somewhere that DNS can resolve (like database.mywebsite.com)
The "in another container" solution seems the best from the perspective of running everything needed locally using docker. However, this presents challenges:
How do we get the schema loaded? Do we do this every time?
How do we seed the initial data? Do we do this every time?
Can we keep a local copy of our data, or is the database refreshed every time?
Can we get that included?
The text was updated successfully, but these errors were encountered:
Hi @calebmeyer. I think this would also be a useful example to include. I've done this a few different ways in the past.
Create a new service in our docker-compose.yml, call it db and just run the community mysql image
Add depends_on to services you want to spin up the database for first.
Create a utility service that overrides 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.
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?
The text was updated successfully, but these errors were encountered: