I use rails 7 these days with ruby 3.0 in a containerized app using docker-compose. The problem buzzing me a lot was debugging the app in localhost. Yes, you can debug RSpec when you run the RSpec in the
docker run command, but what about direct debugging on the local server?
Rails 7 has a built-in debug gem, and my target was to use this gem, not the old ones like debase, pry, etc.
The problem with docker-compose is that we can log or do console or even do RSpec give input option and system stops while doing RSpec, but rails server starts when we call
up on compose, and then we can see logs not control it.
In docker-compose, in rails service, write:
stdin_open: true in a
docker-compose.yml file means that the container will have an open
STDIN stream when it is run. This allows you to send input to the container over its
STDIN stream, which can be useful in certain situations.
For example, you might use
stdin_open: true when running an interactive command-line application in a container to type commands into the container and see the output.
tty: true in a
docker-compose.yml file means that the container will have a "pseudo-tty" when it is run. This allows you to interact with the container in a way that is similar to a terminal session.
When a container is run with a pseudo-tty, you can send input to the container using your keyboard, and the container’s output will be displayed in your terminal. This can be useful when running interactive command-line applications in a container.
Now, after running
docker-compose up, you write in the new terminal session
docker container ls to find the name of the rails container and then write
docker attach container_name and now add
debugger to your process and when that process run in docker then
rdbg will stop at that point and now you can debug the application. Use
c to continue to the next breakpoint.
docker container ls
docker attach container_name
To get out of the attached container session, press
Ctrl+P and then