This demo is a Docker container that starts a simple Java application with pre-configured JMX options. Manipulating the options and running a container and JMX console in different modes demonstrates different cases of JMX monitoring. In all variants, JMX is bound to the port 9010, so JConsole will always be connecting a remote host hostname:9010, even when running locally.

Run the docker build command in the project's directory.

docker build -t banging-daemon .

Bridge mode is the default for a Docker container. In this mode only the published container's ports are accessible

However, when running JConsole on the same machine, RMI options do not need to be advertised. The following lines of the Dockerfile may stay disabled.

#"-Dcom.sun.management.jmxremote.rmi.port=9010", \
#"-Djava.rmi.server.hostname=192.168.0.101", \

Run the container publishing the JMX remote port 9010.

docker run -it --rm --name hammer -p 9010:9010 banging-daemon

When JConsole is running on a different machine, RMI options have to be set, as a randomly RMI port is not accessible by the remote machine. It is convenient to set the port com.sun.management.jmxremote.rmi.port to the same value as com.sun.management.jmxremote.port, which is 9010 in this configuration. Using same port number makes one port mapping configuration less in a Docker container and eventually in a firewall. Parameter java.rmi.server.hostname should point at a host where Docker is running.

"-Dcom.sun.management.jmxremote.rmi.port=9010", \
"-Djava.rmi.server.hostname=192.168.0.101", \

In the host mode, the container's network is not encapsulated at all. It is accessible alongside the host's network. In this case the RMI options do not need to be configured.

#"-Dcom.sun.management.jmxremote.rmi.port=9010", \
#"-Djava.rmi.server.hostname=192.168.0.101", \

Running JConsole locally or remotely does not make any difference.

The JMX remote port does not need to be published:

docker run -it --rm --net=host --name hammer banging-daemon