|
|
|
|
|
by xmodem
2237 days ago
|
|
I'm going to check out your product on the weekend. It looks pretty neat. But it would be cool to hear a bit more about how you achieve some of your stated claims. Particularly working with debuggers. The kubernetes/minikube setup at my current role seems downright hostile to debugging - * We need to maintain separate profiles for running apps in debug mode, to expose the java debug port to the host and supply the right JVM options * Latency - even to a VM running on the same computer when compared to running a local process - means a significantly worse debugging experience * Don't leave your debugger paused for too long, or your healthchecks will fail and your app will get rebooted from under you * And forget about trying to debug something that happens on application boot |
|
> We need to maintain separate profiles for running apps in debug mode, to expose the java debug port to the host and supply the right JVM options
Yes, you should. This is something you can do in the 'okteto.yml' file. You can specify different environment variables, different commands and even a different image (e.g. an image with your dev tools and debugger, which you don't need in prod).
> Latency
This can be a challenge, for sure, specially if you have a bad network connection. In our experience, debuggers and incremental file sync don't require too much bandwidth.
> Don't leave your debugger paused for too long
This has happened a lot to me. In the latest version we introduced a switch to disable healthchecks during dev time so avoid this.
> And forget about trying to debug something that happens on application boot
This is the trickiest definitely. I've had luck by pausing the debugger on attach (on go and node you can do this), but it's not the most optimal.