solo-io / kubesquash

A debugger for Kubernetes applications.
228 stars 15 forks source link

Ruby Support #4

Open kingdonb opened 6 years ago

kingdonb commented 6 years ago

I heard that as a Ruby user I'll find support in kubesquash compared to other languages is lacking, or perhaps just undocumented.

I also saw #1 asking for Python support

I'm still learning how KubeSquash works but if I'm using it, I'm definitely going to want to use it to debug Ruby. I think both ruby gems byebug and pry have remote debugging modes, so maybe that helps with adding support? Has anyone tried this yet

yuval-k commented 6 years ago

I'm not familiar with ruby - currently kubesquash works for go which is the primary programming language I use :)

It essentially works by deploying a privileged go debugger container (dlv), to the same node as the pod you want to debug, uses the container runtime interface to find the pid of the process you wish to debug, and then attaches the debugger to it, and drops you to an interactive prompt.

Can you shed some light on how debugging in ruby works? can one attach a debugger using a pid like in go\c ?

kingdonb commented 6 years ago

So I'm not sure how much alike Ruby and Go are, I'm more familiar with Ruby, but there are a lot of tools for Ruby debugging that I've honestly never tried, like rdebug.

It looks like there is a tool called rbspy that can be used to attach to and profile a running ruby pid. You can also use gdb and strace, but rbspy is more ruby-native. I'm not sure you can use it for anything other than sampling profiling, but I haven't used KubeSquash yet so I'm not sure how much more you can usually do with the tool in its native habitat!

I have some go projects I'm working on too, and others in python, I'm happy to talk this through and see if it makes sense for what we're doing.

What I think developers, in my own circles at least, are taking most advantage of while debugging their Ruby apps are two features:

  1. hot code reloading in development mode

Ruby is not compiled, and Rails apps use a somewhat dynamic loader that can be configured to reload code changes as files change on disk. So if you want to try a code change while you're debugging a running app, you can simply modify your code in place (eg. inside the pod) without restarting, and this is really handy for...

  1. Inserting breakpoints with "pry" or "byebug"

Both of these tools have Ruby methods you can call to intercept the running path of code as in breakpoint, and pop up a REPL console in terminal where you can inspect objects in the current context, and interact with them, or create from any Rails globals or ruby classes that you've defined.

They can also be configured to start whenever an unhandled exception is raised. Both of these tools also have a remote mode that lets you expose the debugger over the network (as opposed to hijacking the process terminal's stdin and stdout.)

I have to confess we are doing some with microservices but honestly not much with Kubernetes yet. Hopefully more soon. Maybe KubeSquash or Solo can help us make it worthwhile to change?

(edit: I should probably watch the KubeCon video, I suspect I've got the idea of what KubeSquash can do from having seen a few debuggers, and reading a bit about the VS Code integration.)

kingdon commented 6 years ago

https://kubernetes.io/blog/2018/05/01/developing-on-kubernetes/

This blog post has been really helpful explaining how I can get those kinds of behavior in Kubernetes

I'm still not there yet, but ksync is something else I never heard of that seems really handy. (Ilya and his weekly office hour is also how I found out about kubesquash)