DEV Community: Jean-François Lamy

Compiling Java 17 using Maven in an Azure DevOps Pipeline

Jean-François Lamy — Wed, 29 Dec 2021 15:27:51 +0000

Using ubuntu-latest machines in an Azure DevOps pipeline, there is currently no support for versions beyond 11. So using a Maven@3 task to compile using a newer version fails. The workaround is to use a container version of Maven.

jobs:
  # build uberjar
  - job: ${{ parameters.jobName }}
    pool:
      vmImage: ubuntu-latest
    container: maven:3.8.1-openjdk-17-slim
    variables:
      - name: JAVA_HOME_11_X64
        value: /usr/local/openjdk-17
    steps:
      - template: steps-prepare-maven.yml
      - task: Maven@3
        displayName: build ${{ parameters.moduleName }} uberJar 
        inputs:
          mavenPomFile: pom.xml
          mavenOptions: -Xmx3072m $(MavenOpts)
          javaHomeSelection: 'path'
          jdkDirectory: '/usr/local/openjdk-17'
          publishJUnitResults: true
          testResultsFiles: "**/surefire-reports/TEST-*.xml"
          effectivePomSkip: true
          goals: -P production -pl ${{ parameters.moduleName }} -am $(MavenOpts) -Dmaven.test.skip=${{ parameters.skipTests }} $(BuildGoal)

We are using openjdk-17 and explicitly using javaHomeSelection and jdkDirectory to set our JAVA_HOME to match where the container puts the JDK.

So why are we also defining the environment variable JAVA_HOME_11_X64, you ask? Well, I have reusable templates that are used outside the container setting. For example, the steps-prepare-maven.yml file is a template that creates a settings.xml file using the project secrets and updates the revision based on my build parameters - I also use it on Windows jobs. Such steps use the default version, Java 11. When running inside the container, the JAVA_HOME_11_X64 takes precedence and the Maven steps in the reusable templates work correctly.

This is extracted from a template file, replace the parameters with what you need.

Credit: sfragata's answer to a github issue got me started. Then I stumbled around until I could fix my included templates using the environment variable.

Interactive Java JVM Monitoring on Kubernetes - Configuring VisualVM to use JMXMP

Jean-François Lamy — Thu, 21 May 2020 13:11:18 +0000

This is part 2 of a 2-part series.

Despite feature requests to do so and some work to create a plugin, VisualVM does not ship with JMXMP configured by default. The following recipe has been tested with VisualVM 2.0.1.

If we used Maven to enable our application, we have a copy of the required java archive (jar) in the .m2 directory. The simple way is to add that jar to the class path using the --cp:a option. This jar would normally have to be "endorsed" to be used, but starting from the directory where it is found allows things to work.

cd C:\Dev\.m2\repository\org\glassfish\external\opendmk_jmxremote_optional_jar\1.0-b01-ea
C:\Dev\Java\visualvm_201\bin\visualvm.exe --cp:a opendmk_jmxremote_optional_jar-1.0-b01-ea.jar

You can also create a shortcut on your desktop to run the command. Use the Start In option to select the directory where the jmxremote jar is found.

Adding a remote host

When accessing a remote host such as KubeSail, add it using the add remote host option

Configure a connection

Under the new host (or under Local if connecting locally), right-click and use Add JMX Connection. Use the accessible address.

If running locally, this will be localhost, and the syntax will be service:jmx:jmxmp://localhost:1098
if remote, the external address obtained by querying the pod. In our example, that yieldsservice:jmx:jmxmp://54.151.2.??:300?? (the port is the one listed in the NodePort configuration as explained in Part 1.)

Double-clicking on the new connection will open it, and the name of the monitored application will be shown. You can then use the various tabs to monitor, examine or sample the application.

Interactive Java JVM Monitoring on Kubernetes: Exposing JMXMP

Jean-François Lamy — Thu, 21 May 2020 13:00:25 +0000

In addition to log-based or agent-based monitoring, it is occasionally necessary to inspect interactively the behavior of a Java application, in particular its memory usage or CPU usage. In the Java ecosystem, the free VisualVM or jconsole tools are often used. These tools also allow seeing the thread usage and drill down/filter interactively.

This post explains the steps necessary to manually inspect a Java application using the JMXMP protocol in a Kubernetes cluster.
Part 1 is about making the application to be monitored visible using JMXMP
Part 2 discusses how to add VisualVM to the mix (similar techniques apply to other monitoring tools)

What about RMI?

Exposing the default RMI protocol is extremely painful because of the way it handles ports and requires a back channel. The general consensus is don't bother. After wasting a couple days, I wholeheartedly agree.

Enabling JMXMP monitoring

The simplest way to enable monitoring is to create the monitoring port ourselves. For example, in a web frontend, add the following to open port 1098 for JMXMP monitoring:



try {
    // Get the MBean server for monitoring/controlling the JVM
    MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();

    // Create a JMXMP connector server
    JMXServiceURL url = new JMXServiceURL("jmxmp", "localhost", 1098);
    JMXConnectorServer cs = JMXConnectorServerFactory.newJMXConnectorServer(url,
            null, mbs);
    cs.start();
} catch (Exception e) {
    e.printStackTrace();
}

In order for this code to compile, you will need to include a JMXMP implementation. If using Maven, add the following to your pom.xml



<!-- https://mvnrepository.com/artifact/org.glassfish.external/opendmk_jmxremote_optional_jar -->
<dependency>
    <groupId>org.glassfish.external</groupId>
    <artifactId>opendmk_jmxremote_optional_jar</artifactId>
    <version>1.0-b01-ea</version>
</dependency>

In real life,

you will likely use an environment variable so you can configure the port number using a ConfigMap or Secret, and perhaps not start the connector if there is no such variable present.
You may wish to secure the connection. For my own purposes, I have used IP whitelisting of my development workstation in a k8s networking policy, so I have not explored this topic further. See https://interlok.adaptris.net/interlok-docs/advanced-jmx.html for examples on how to enable this.

Special considerations for building the container

KubeSail uses IPv6 by default. In the process of debugging this recipe, we have found it necessary to add the following Java flags to the Java entry point command of the Docker container.



-Djava.net.preferIPv4Stack=true
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

(Editor's note - We will be checking whether they are still necessary.)

Exposing a port in Kubernetes for Docker Desktop

The following instructions have been tested with the new WSL2 Docker backend which runs directly on Linux.

For Docker Desktop, the simplest way to expose a port is to use a LoadBalancer service. This avoids having to use kubectl on every session.



kind: Service
apiVersion: v1
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  ports:
  - protocol: TCP
    name: http
    port: 80
    targetPort: 8080
  - protocol: TCP
    name: jmx
    port: 1098
    targetPort: 1098
  type: LoadBalancer

This makes it possible to open the web application on http://localhost even though the container is communicating on port 8080, and also opens up the JMX monitoring channel on port 1098. You can change the port to suit your needs, but targetPort needs to match what is used by the application being monitored (see the Java above).

Exposing a port with KubeSail Kubernetes

KubeSail is an affordable managed PaaS for running Kubernetes applications. By default, only the traffic coming in through an Ingress (NGINX) is allowed to go further. It is therefore necessary to

create a Network Policy that allows traffic to flow to the monitored application container
expose the port for monitoring

Creating a network policy

The following opens the 1098 port on the application to be accessed from the outside, and limits outside access to a certain address (obviously you would use your own).



kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: myapp-allow-jmx
spec:
  podSelector:
    matchLabels:
      app: myapp
  policyTypes:
  - Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 208.77.188.166/32
    ports:
    - protocol: TCP
      port: 1098

More advanced topics are discussed on this page
https://www.magalix.com/blog/kubernetes-network-policies-101

Exposing the monitoring port

The simplest way is to use a NodePort, which makes the virtual machine open a port and expose it to the outside world. In the case of a shared service like KubeSail, there is therefore the possibility that the chosen port is in conflict with others, and that you will need to change it.
The last line (externalTrafficPolicy) is required to prevent Kubernetes from doing a NAT (Network Address Translation)



kind: Service
apiVersion: v1
metadata:
  name: jmx
spec:
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 1098
    targetPort: 1098
    nodePort: 30098
  type: NodePort
  externalTrafficPolicy: Local

Getting the address of the node

In order to the the address of the node, you may use



  kubectl get pod -o wide

You may also install the jq JSON query tool, and use the following one-liner



  kubectl get pod -o json -l 'app=myapp' | jq -r '.items[0].spec.nodeName'

which will output the ip address (54.151.3.??) in the example

In order to test that all is good, you can use the command.



  telnet 54.151.3.?? 300??

You will get garbage back, but with a recognizable javax.management.remote.message.HandshakeBeginMessage string at the beginning.