![在 pod 中启用/禁用 jvms 的 jmx 和 xdebug 参数的顾虑和策略](https://linux22.com/image/720359/%E5%9C%A8%20pod%20%E4%B8%AD%E5%90%AF%E7%94%A8%2F%E7%A6%81%E7%94%A8%20jvms%20%E7%9A%84%20jmx%20%E5%92%8C%20xdebug%20%E5%8F%82%E6%95%B0%E7%9A%84%E9%A1%BE%E8%99%91%E5%92%8C%E7%AD%96%E7%95%A5.png)
我正在编写一个大型项目中一项服务的代码。大多数应用都是 Java REST 服务,全部在 pod 中的容器中运行。
为了调试 JVM 中发生的情况,可以方便地添加典型的 JMX 和 Xdebug 参数之一或两者,以允许自省 JVM 的性能,或者在调试器中逐步执行代码。
该镜像有一个运行 Java 的 shell 脚本。我认为默认情况下不提供 JMX 和 Xdebug 参数可能会很方便,但如果设置了特定环境变量(每组一个),则添加它们。我可以在部署规范中设置或不设置这些环境变量。
我想知道如何优化开发人员的工作流程。例如,假设容器当前在没有 JMX 参数的情况下运行,我如何才能让开发人员更轻松地进入 JVM 现在使用这些 JMX 参数运行的状态?
我们的构建/部署过程目前使用我不熟悉的 Ansible 过程,这导致部署被推出(我可以随后使用“kubectl rollout status”来检查状态)。
假设我们仍然使用这种环境变量启用策略,那么“官方”流程将要求开发人员将 git 更改推送到部署规范,这将重建并重新部署所有内容。
我可以采取哪些步骤来优化这个过程,以尽量减少开发人员切换 JMX(或 Xdebug)参数所需的步骤和时间?
我想知道的另一件事是,我是否需要担心 JMX 参数始终存在。它没有使用 auth 或 ssl,但建立到端口的 JMX 连接很麻烦(并非不可能)(通常需要“端口转发”机制)。我们是否过于偏执而默认关闭这些?