Rails can't drop tables because of other containers using the database-CodePudding

I have a problem. I have build an application in rails using docker. This application consists of 4 containers:

Rails app
Postgres DB
Redis
Sidekiq (Clone of rails app)

Now I want to reset my db in my rails app, but when I run:

docker-compose exec app rails db:migrate:reset

I get:

ActiveRecord::StatementInvalid: PG::ObjectInUse: ERROR:  database "my_app_development" is being accessed by other users
DETAIL:  There are 4 other sessions using the database.

I saw this fix from someone, but this code results in:

kill: you need to specify whom to kill

I think because this is task will be executed in one container and it only looks for process within that container and not the other docker containers. My question is how I can reset my db without the other docker images to crash or anything, but temporary stop the database connections for them. I really need to be able to reset my database when I have to!

Please let me know!

CodePudding user response：

If you just want to stop and reset everything, the easiest way is to ask Compose to stop all of the containers and delete all of the state

docker-compose down -v

then recreate the database

docker-compose run app rake db:create

and finally restart the application

docker-compose up -d

You might also be able to do this by stopping the application containers, running the reset command, and then restarting things

docker-compose stop app sidekiq
docker-compose run app rails db:migrate:reset
docker-compose up -d

One notable thing here is that I'm using docker-compose run and not exec. This launches a new temporary container based on the app service, but overrides its command: with whatever you provide on the command line and doesn't publish ports:. In particular your error suggests that you can't run this command while the main rails server is running; but if you stop it then there's not a running container you can docker exec into. Starting a new container with docker-compose run gets around this problem; since it has the same network setup, image, and entrypoint wrapper as the main service, it should be able to run the same rails and rake commands.