Debugging remote-dev without opening a port

[Stuart Douglas]

Hi Everyone,

I have a proof of concept that allows you to debug remote-dev without needing to open a debug port on the remote container. To activate it all that is needed is to set the QUARKUS_LAUNCH_DEVMODE_DEBUG=true environment var, and then connect your debugger to 'localhost:5005' once your remote dev session is activated.

Here is a video of it in action: https://drive.google.com/file/d/1Nah4FisA6LgoxY6unz7qZIjnFKh1eMwd/view?usp=sharing

The way it works is somewhat complex, basically:

When you run with QUARKUS_LAUNCH_DEVMODE_DEBUG Quarkus starts in what I am calling 'debug agent mode', instead of launching a normal quarkus app this mode will launch a new standard quarkus process in debug mode, with a different HTTP port. It will then listen on the normal http port and act as a proxy between the new process it launched and normal HTTP traffic.

If a request comes in with an Upgrade: quarkus-remote-debug header then instead of forwarding the request to the application it will connect to the applications debug port and immediately begin forwarding the JDWP protocol over the upgraded connection.

Meanwhile when the quarkus:remote-dev process connects to the remote container it will start listening on port 5005. If you connect your debugger to this port then it will immediately send an upgrade request to the agent above, and start forwarding the protocol to the remote agent.

Basically the traffic flow looks like:

IDE <--> mvn quarkus:remote-dev  <--> 'debug agent mode process'  <-->  Quarkus application

This code is a huge hack at the moment, it is basically just my attempt at getting a working prototype out the door. It will be quite a bit of work to get this to production quality, so I want to see if there is interest in this feature before spending more time on it to get it to the point where it can be merged.

The (massively hacky) code can be found at https://github.com/stuartwdouglas/quarkus/tree/upgrade-based-debug

Stuart

[Georgios Andrianakis]

Very cool!

Just yesterday I got a question about how to make debugging work with remote-dev - it's definitely not obvious to users, so I think this will be very helpful

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cxmavBZDaDdyh%3DVf5YZ%3DtjK8dy4rnQaSddeT8FrqS7WPw%40mail.gmail.com.

[Alexey Loubyansky]

+1

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3DgUT5-Yf6y%3D%3D1cCwj9pPuur9Bv%2BKXWjkgZA2hfvwEESQ%40mail.gmail.com.

[William Burke]

So what is the net benefit?  That the user doesn't have to do anything except set an environment variable and expose the port?  While before they would either have to wrap their app in a shell script or modify their container run command?

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cxmavBZDaDdyh%3DVf5YZ%3DtjK8dy4rnQaSddeT8FrqS7WPw%40mail.gmail.com.

--

Bill Burke

Red Hat

[Max Rydahl Andersen]

this is cool for sure and I can see interesting thing to do by controlling the JVM debug channel...BUT it exposes debug facility to the public internet; thus from a security perspective even worse afaics. Would a port forward not be sufficient?

Would it not be more appropriate when we connect to a kubernetes cluster we in the kubernetes/openshift extension send the proper kubectl/oc commands (using kubernetes client if possible) to do a port forward instead ?

That would of course not make it work for non-kubernetes scenario but at least would not be opening debugging port to public internet ?

/max

[William Burke]

Another thought is, would this only work with REST services?  How would this work with something like Kafka where you don't have an HTTP stack compiled with the application?

[Max Rydahl Andersen]

On 12 Nov 2021, at 15:44, William Burke wrote:

> So what is the net benefit? That the user doesn't have to do anything
> except set an environment variable and expose the port? While before they
> would either have to wrap their app in a shell script or modify their
> container run command?

they would need to setup a port forward do the specific pod and connect IDE to that.

Which reminds me - either suggested option only works when 1 pod running; if N pods running you don't know which one
gets the request. Which is expected but another aspect to consider as a user working within kubernetes.


/max

>> <https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cxmavBZDaDdyh%3DVf5YZ%3DtjK8dy4rnQaSddeT8FrqS7WPw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .

>>
>
>
> --
> Bill Burke
> Red Hat
>

> --
> You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAL%3DE%3DjSNOZD7mGwcfRESn5n3XtyDhHCtR3L9BycCEq%3Dm0gT7ag%40mail.gmail.com.

/max
https://xam.dk/about

[Stuart Douglas]

The user does not even have to open a port, they just connect the same way they do to debug locally.

Stuart

[Stuart Douglas]

On Sat, 13 Nov 2021, 1:47 am Max Rydahl Andersen, <mand...@redhat.com> wrote:

this is cool for sure and I can see interesting thing to do by controlling the JVM debug channel...BUT it exposes debug facility to the public internet; thus from a security perspective even worse afaics. Would a port forward not be sufficient?

It will use password based auth same as remote dev already does.

Stuart

[William Burke]

What about my other comment?

Will this only work for REST services?  Doesn't this require an HTTP stack bundled with the quarkus app?

[Stuart Douglas]

Yes, it does, but that is true of any app that is using the remote dev HTTP support.

Same with the N pods problem max raised, if you are developing and there are multiple pods you are only going to update one.

Stuart