Docker Console and Debugger

[SammySteiner]

Ticket

• Resolves Improve debugging during local development #14

Changes

• Updated web_console config to allow most local IPs to access the console for local development with docker
• Updated docs to give more specific instructions on how to access the debugger

Questions for reviewers

1. In the technical-foundation doc, it says to run the app with make rails-console though I think elsewhere it says to use make init-native/container and make start-native/container for local native and local docker development. Should we change it here to be consistent?
2. We're pulling the ruby:3.3.1-slim image from dockerhub which comes with the debug gem version 1.19.1. However, in our local gemfile.lock we have debug version 1.19.2 installed. Using debug in docker breaks when there is a version mismatch between the server and the client. This will be fixed whenever dockerhub updates their ruby:3.3.1-slim image, but I was only able to get it running locally by locking my debug version in the gemfile to 1.9.1. Is there a best practice to address this?
3. When setting the IP addresses for permissions, there are some programmatic ways of getting locaL IP addresses, but it seems like those require additional libraries (socket, ipaddr). Is that preferred to the current method or should we go even further by allowing 0.0.0.0?

Testing

• Add a console statement to a view in the application and confirm that the console shows up in your browser when hitting that page. Test in both native and container modes.
• Add a debugger statement to a controller and follow the instructions in the technical-foundation.md doc to attach the debugger. Confirm in both native and container modes.

[rocketnova]

Thank you for working on this! Left some thoughts below.

[rocketnova]

1. In the technical-foundation doc, it says to run the app with make rails-console though I think elsewhere it says to use make init-native/container and make start-native/container for local native and local docker development. Should we change it here to be consistent?

I addressed this in my inline comments. make init-container and make start-container initialize and start the container. They do not create an interactive rails console. make rails-console does.

2. We're pulling the ruby:3.3.1-slim image from dockerhub which comes with the debug gem version 1.19.1. However, in our local gemfile.lock we have debug version 1.19.2 installed. Using debug in docker breaks when there is a version mismatch between the server and the client. This will be fixed whenever dockerhub updates their ruby:3.3.1-slim image, but I was only able to get it running locally by locking my debug version in the gemfile to 1.9.1. Is there a best practice to address this?

Can you link me to where the upstream ruby docker hub image includes the debug gem? I'm not seeing that. You said "I was only able to get it running locally". What were you trying to run that was failing with this?

3. When setting the IP addresses for permissions, there are some programmatic ways of getting locaL IP addresses, but it seems like those require additional libraries (socket, ipaddr). Is that preferred to the current method or should we go even further by allowing 0.0.0.0?

Can you explain what wasn't working before you added this? I'm not sure I'm following.

[SammySteiner]

1. In the technical-foundation doc, it says to run the app with make rails-console though I think elsewhere it says to use make init-native/container and make start-native/container for local native and local docker development. Should we change it here to be consistent?

I addressed this in my inline comments. make init-container and make start-container initialize and start the container. They do not create an interactive rails console. make rails-console does.

Sounds good. Thanks for clarifying.

2. We're pulling the ruby:3.3.1-slim image from dockerhub which comes with the debug gem version 1.19.1. However, in our local gemfile.lock we have debug version 1.19.2 installed. Using debug in docker breaks when there is a version mismatch between the server and the client. This will be fixed whenever dockerhub updates their ruby:3.3.1-slim image, but I was only able to get it running locally by locking my debug version in the gemfile to 1.9.1. Is there a best practice to address this?

Can you link me to where the upstream ruby docker hub image includes the debug gem? I'm not seeing that. You said "I was only able to get it running locally". What were you trying to run that was failing with this?

The debug gem in the docker ruby 3.3.1-slim image is listed as version 1.9.1, which I was able to confirm on the dockerhub website:

The debug version getting installed in our project is listed as 1.9.2 in our gemfile.lock.
When I try to attach a debugger to the docker container with docker exec -i <Container ID> rdbg -An I get the error in my terminal:

app-rails-1  | 14:42:38 web.1  | DEBUGGER: wait for debugger connection...
app-rails-1  | 14:43:25 web.1  | DEBUGGER: Connected.
app-rails-1  | 14:43:25 web.1  | DEBUGGER: GreetingError: out DEBUGGER: Incompatible version (server:1.9.2 and client:1.9.1)
app-rails-1  | 14:43:25 web.1  | DEBUGGER: Disconnected.

However, if I lock my debug gem to version 1.9.1, and re-bundle and create a new containerized app, it works as expected.

I described how I'm running my docker container in the inline comment here, are you doing it differently?

3. When setting the IP addresses for permissions, there are some programmatic ways of getting locaL IP addresses, but it seems like those require additional libraries (socket, ipaddr). Is that preferred to the current method or should we go even further by allowing 0.0.0.0?

Can you explain what wasn't working before you added this? I'm not sure I'm following.

Responded to your inline comment.

[rocketnova]

However, if I lock my debug gem to version 1.9.1, and re-bundle and create a new containerized app, it works as expected.

I described how I'm running my docker container in the inline comment here, are you doing it differently?

Got it! Thanks. I think what we should do is explicitly install a global version of the debug gem inside the docker image that is used for development, by adding this to line 57 of the Dockerfile:

# Install system-wide gems for development
# This version must match Gemfile.lock. Otherwise, `rdbg` will fail.
RUN gem install debug -v 1.9.2

3. When setting the IP addresses for permissions, there are some programmatic ways of getting locaL IP addresses, but it seems like those require additional libraries (socket, ipaddr). Is that preferred to the current method or should we go even further by allowing 0.0.0.0?

Can you explain what wasn't working before you added this? I'm not sure I'm following.

Responded to your inline comment.

I think your change is good and that we don't need to expand out to 0.0.0.0.

[rocketnova]

Running rdbg -An gave me this:

DEBUGGER (client): Connected. PID:10, $0:bin/rails
DEBUGGER (client): Type `Ctrl-C` to enter the debug console.

And I needed to hit Ctrl-C to enter the debug console. Whereas rdbg -A allowed me to skip hitting Ctrl-C. Any reason we need -n? I didn't see anything in particular in the docs.

[rocketnova]

Also, running rdbg (both natively and in the container), I got this:

DEBUGGER (client): Connected. PID:10, $0:bin/rails

# No sourcefile available for /usr/local/bundle/ruby/3.3.0/gems/puma-6.4.2/lib/puma/single.rb
=>#0	[C] Thread#join at /usr/local/bundle/ruby/3.3.0/gems/puma-6.4.2/lib/puma/single.rb:63
  #1	Puma::Single#run at /usr/local/bundle/ruby/3.3.0/gems/puma-6.4.2/lib/puma/single.rb:63
  # and 20 frames (use `bt' command for all frames)

Stop by SIGURG
(rdbg:remote) 

This issue is the only reference I found about this. I was able to hit c to continue past it, but it was persistent. Did you run into this?

[SammySteiner]

Thanks! i removed the n from the guidance, however that enables the --nonstop flag which is used to tell rdbg to not stop at the beginning of the script. I saw a bunch of troubleshooting tips that advised adding it, but it's not necessary in all cases.

I was only able to reproduce what you were seeing by connecting the debugger before the application hit the debug statement. But once the debug statement was hit by the user action, then the debugger terminal updated properly.

[rocketnova]

Oh I see! Thanks.

[rocketnova]

LGTM. Thank you!