0

I'm working on the code for one service that is part of a larger project. Most of the apps are Java REST services, all running in containers in pods.

To debug what's happening in the JVM, it's convenient to add either or both of the typical JMX and Xdebug parameters, to allow introspecting the JVM's performance, or step through code in a debugger.

The image has a shell script that runs Java. It occurs to me that it might be convenient to have the JMX and Xdebug parameters not present by default, but to add them if a particular environment variable is set (one for each set). I could set or not set those environment variables in a deployment specification.

I'm wondering about how to optimize the developer workflow. Assuming the container is currently running without the JMX parameters, for instance, how can I make it easier for the developer to get to a state where the JVM is now running with those JMX parameters?

Our build/deploy process currently uses an Ansible process that I'm not familiar with, which results in the deployment being rolled out (I can see it using "kubectl rollout status" afterwards to check status).

Assuming we still use this strategy of env var enablement, the "official" process would require the developer pushing a git change to the deployment spec, which would rebuild and redeploy everything.

What are some steps I could take to optimize this process, to minimize the steps and time a developer has to take to toggle the JMX (or Xdebug) parameters?

Another thing I'm wondering about is whether I need to be at all concerned about having the JMX parameters present all the time. It's not using auth or ssl, but it's awkward (not impossible) to make the JMX connection to the port (normally requires a "port-forward" mechanism). Are we overly paranoid to have these off by default?

David M. Karr
  • 121
  • 1
  • 5
  • You could just check the environment variable in the shell script that starts the app. This is pretty trivial, and your devs already should know how to set environment variables in Kubernetes. – Michael Hampton Apr 11 '18 at 17:43
  • Yes, that part is obvious. That's not really the point of my question. – David M. Karr Apr 11 '18 at 20:53
  • OK, I did miss a paragraph somewhere, apparently. Anyway... This change shouldn't be happening that often in production, should it? If they need JMX all the time, you may as well leave it on. It's useful enough for monitoring that you may as well just have your existing monitoring system talk to the app via JMX. But I'd put some kind of firewall in front of it just to be safe. But again I wonder how often the devs really need to run Xdebug _in production_? – Michael Hampton Apr 11 '18 at 21:18
  • Yeah, I don't expect we would be turning Xdebug on in prod, but I do want that flexibility for our test environment. I want to make it as convenient as possible to dynamically change the config and restart the pod. – David M. Karr Apr 11 '18 at 21:30
  • I can't think of anything easier than changing the environment variable. If a dev is working locally, e.g. on a minikube or something, then they can just restart the pod whenever they want. – Michael Hampton Apr 11 '18 at 21:32
  • We're not using minikube, but devs will likely have the ability to use kubectl to the remote server to control the app that they're working on. – David M. Karr Apr 12 '18 at 00:00

0 Answers0