Operators can now attach a JMX client — JConsole, VisualVM, Mission Control — to a running platform microservice container without modifying the container image or service definition. JMX support is built into the container management layer and configured through an interactive CLI tool that generates the required JVM flags and writes them to the service environment file.
Setup and configuration
- Interactive CLI setup. The tool prompts for JMX port, RMI port, hostname, SSL preference, and authentication method, then writes the resulting configuration to
service.env. Inline comments that would break environment file parsing are moved above their variables. - Environment variable overrides. JMX port, RMI port, and RMI hostname read from environment variables at container start, so orchestration layers supply values without baking them into the image.
- SSL transport. When SSL is selected at setup, the tool generates a self-signed keystore and configures the JVM to require TLS on the JMX transport.
Podman credential persistence
- Persistent Docker Hub credentials on Podman. The container management script persists Docker Hub credentials to Podman's credential store on login, so subsequent image pulls in the same session do not require re-authentication.
JMX access is intentionally restricted to operators with direct access to the service environment file; the configuration is not exposed through the platform's management API. This keeps the JMX attack surface out of the authenticated web tier while making the capability available to the infrastructure team.