Open Liberty 19.0.0.12 provides support for MicroProfile 3.2, allowing users to provide their own health check procedures and monitor microservice applications easily with metrics. Additionally, updates allow trust to be established using the JDK's default truststore or a certificate through an environment variable.
In Open Liberty 19.0.0.12:
- MicroProfile 3.2 support
- Provide your own health check procedures (MicroProfile Health Check 2.1)
- Monitor microservice applications easily wth metrics (MicroProfile Metrics 2.2)
- Jaeger support in MicroProfile Open Tracing
- Trusted certificate enhancements (Transport Security 1.0)
- Liberty reader role support
Run your apps using 19.0.0.12
If you're using Maven, here are the coordinates:
<dependency>
<groupId>io.openliberty</groupId>
<artifactId>openliberty-runtime</artifactId>
<version>19.0.0.12</version>
<type>zip</type>
</dependency>
Or for Gradle:
dependencies {
libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[19.0.0.12,)'
}
Or if you're using Docker:
FROM open-liberty
MicroProfile 3.2 support
Add the whole of MicroProfile 3.2 to your application with this convenience feature in your server.xml:
<featureManager>
<feature>microProfile-3.2</feature>
<featureManager>
The microProfile-3.2 feature automatically includes the following features in your app: JAX-RS 2.1, CDI 2.0, JSON-P 1.1, JSON-B 1.0, MicroProfile Config 1.3, MicroProfile Fault Tolerance 2.0, MicroProfile Health Check 2.1, MicroProfile JWT 1.1, MicroProfile Metrics 2.2, MicroProfile OpenAPI 1.1, MicroProfile OpenTracing 1.3, and MicroProfile Rest Client 1.3.
The MicroProfile Health Check and Metrics features contain updates.
Provide your own health check procedures (MicroProfile Health Check 2.1)
MicroProfile Health Check 2.1 enables you to provide your own health check procedures to be invoked by Liberty, to verify the health of your microservice:
HealthCheckResponse.up("myCheck");
In previous versions, to define a simple successful/failed named health check response, the application level code is always expected to use several static methods together from the HealthCheckResponse API to retrieve a HealthCheckResponseBuilder used to construct a HealthCheck response.
In the mpHealth-2.1 feature for OpenLiberty, you can now use convenient and simpler methods from standard Java APIs, to construct UP/DOWN named health check responses, in your applications, such as HealthCheckResponse.named(“myCheck”).up().build();
To make it work include the following line in the server.xml file:
<feature>mpHealth-2.1</feature>
Applications are expected to provide health check procedures by implementing the HealthCheck interface with the @Liveness or @Readiness annotations, which are used by Liberty to verify the Liveness or Readiness of the application, respectively. Add the logic of your health check in the call() method, and return the HealthCheckResponse object by constructing using the simple up() and down() methods from the API. To view the status of each health check, access either the +http://:/health/live+ or +http://:/health/ready+ endpoints.
**Liveness Check**
@Liveness
@ApplicationScoped
public class AppLiveCheck implements HealthCheck {
...
@Override
public HealthCheckResponse call() {
...
HealthCheckResponse.up("myCheck");
...
}
}
For more information:
Monitor microservice applications easily wth metrics (MicroProfile Metrics 2.2 )
MicroProfile Metrics 2.2 enables developers to instrument metrics in their (microservice) applications for easy monitoring by their operations team.
Previously, the MetadataBuilder API had reusable() and notReusable() method to set the reusable field to true or false. The MetadataBuilder API has been changed to include a new setter method for the reusable attribute. This change is implemented so the MetadataBuilder API follows the builder pattern.
To enable the feature in the server.xml file:
<feature>mpMetrics-2.2</feature>
The example shows how to set the reusable field with the MetadataBuilder API:
MetadataBuilder mdb = Metadata.builder();
mdb = mdb.withName("metricName").withType(MetricType.COUNTER)
.reusable(resolveIsReusable());
For more information:
- Changes to MicroProfile metrics
- Microserice observability metrics
Jaeger support added for tracing (MicroProfile OpenTracing 1.3)
Open Liberty has added support for Jaeger in MicroProfile OpenTracing. A sample tracer is available for using Zipkin as a tracing backend. With the addition of Jaeger support, developers can also use Jaeger as a tracing backend.
You can download the Jaeger client version 0.34.0 library and its dependencies from Maven repository.
In the server.xml:
<library id="jaegerLib" apiTypeVisibility="+third-party" >
<file name="<path>/jaegerLib_0.34/gson-2.8.2.jar" />
<file name="<path>/jaegerLib_0.34/jaeger-client-0.34.0.jar" />
<file name="<path>/jaegerLib_0.34/jaeger-core-0.34.0.jar" />
<file name="<path>/jaegerLib_0.34/jaeger-thrift-0.34.0.jar" />
<file name="<path>/jaegerLib_0.34/jaeger-tracerresolver-0.34.0.jar" />
<file name="<path>/jaegerLib_0.34/libthrift-0.12.0.jar" />
<file name="<path>/jaegerLib_0.34/slf4j-api-1.7.25.jar" />
<file name="<path>/jaegerLib_0.34/slf4j-jdk14-1.7.25.jar" />
<file name="<path>/jaegerLib_0.34/opentracing-util-0.31.0.jar" />
<file name="<path>/jaegerLib_0.34/opentracing-noop-0.31.0.jar" />
</library>
Define your application:
<webApplication location="yourapp.war" contextRoot="/yourapp">
<!-- enable visibility to third party apis -->
<classloader commonLibraryRef="jaegerLib" apiTypeVisibility="+third-party" />
</webApplication>
You can find out more about Jaeger settings set up using environment variables by looking at jaeger-client-java readme.
For the JAEGER_PASSWORD environment variable, the password can be encoded using the securityUtility command. Depending on Jaeger's sampling settings JAEGER_SAMPLER_TYPE and JAEGER_SAMPLER_PARAM, Jaeger may not report every spans created by the applications.
Trusted certificate enhancements (Transport Security 1.0)
Open Liberty now offers new options to help establish trust for TLS connections. An easy way to use the JDK's default truststore for trust and a way to pass the certificate needed to establish trust to a truststore through an environment variable is now provided.
Establishing trust using the JDK's default truststore
By default, the JDK default truststore is the cacerts file. The default truststore may be set by the javax.net.ssl.truststore system property or the jssecacerts file if users have one configured. For Open Liberty to use what is configured as the JDK default truststore the useDefaultCerts attribute needs to be set to true on the ssl element. It is set to false by default. For example:
<ssl id="defaultSSLConfig" keyStoreRef="defaultKeyStore" trustStoreRef="defaultTrustStore" trustDefaultCerts="true" />
<keyStore id="defaultKeyStore" location="key.p12" type="PKCS12" password=<your password> />
<keyStore id="defaultTrustStore" location="trust.p12" type="PKCS12" password=<your password> />
With trustDefaultCerts set to true, the server will try to establish trust with the configured truststore, in this case defaultTrustStore, first. If trust is not establish with the configured truststore then it will try to use the JDK's default truststore to establish trust.
Providing a certificate through an environment variable to establish trust
Open Liberty will read a certificate from an environment variable and add it to a keystore or truststore so it can be used for trust. The certificate will be added to the runtime copy of the keystore or truststore and will not be stored to the file system. If the keystore configuration includes the readOnly attribute set to true then the certificate will not be included.
The environment variable key must be in the format cert_ + keystore id. For example:
<keyStore id="myKeyStore" location="myKey.p12" type="PKCS12" password=<your password> />
The key of the environment variable should be cert_myKeyStore (it is case-sensitive).
The value of the environment variable can either be a certificate in the base 64-bit format or the path to a file containing a base 64-bit encode certificate or DER-encoded certificate. If using the base 64-bit encode certificate directly on the environment variable, it must contain the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- tags. For example:
cert_myKeyStore="-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----"
The environment variable for a file will look similar to:
cert_myKeyStore=/Users/me/servercert.crt
Any value not starting with the -----BEGIN CERTIFICATE----- tag will be treated like a file.
[#rrs]
Liberty reader role support (Application Security 2.0 and Application Security 3.0)
The reader role is a management role that allows read-only access to select administrative REST APIs as well as the Admin Center UI (adminCenter-1.0).
Prior to this release, the Administrator management role was the only management role within Open Liberty and it provided read and write access. The new Reader management role provides the ability to assign a read-only role to users and groups. This will allow those users and groups to monitor the server without granting those users the ability to modify the server in anyway.
Using the new Reader management role is nearly identical to using the Administrator management role. In the server.xml include the appSecurity-2.0 or appSecurity-3.0 feature and also add the new reader-role configuration element, that specifies the group(s), user(s), and/or the access ID of the group(s) or user(s) that should be granted the Reader management role.
<server>
<featureManager>
<feature>appSecurity-3.0</feature>
</featureManager>
<reader-role>
<group>group</group>
<group-access-id>group:realmName/groupUniqueId</group-access-id>
<user>user</user>
<user-access-id>user:realmName/userUniqueId</user-access-id>
</reader-role>
</server>
Try Open Liberty 19.0.0.12 in Red Hat Runtimes now
Open Liberty is part of the Red Hat Runtimes offering. If you're a Red Hat Runtimes subscriber, you can try Open Liberty now.
To learn more about deploying Open Liberty applications to OpenShift, take a look at our Open Liberty guide: Deploying microservices to OpenShift.
