Document how to provide runtime JVM arguments when building an image

[sergey-morenets]

Hi

I'm using Spring Boot 2.3.0 and JDK 14.0.1 and want to pack my application using new buildpack feature in Spring Boot Maven plugin.
Since I use preview features I have to add "--enable-preview" flag as JVM argument (JAVA_OPTS environment variable).

So here's my Spring Boot Maven plugin configuration:

			<plugin>
				<groupId>org.springframework.boot</groupId>
				<artifactId>spring-boot-maven-plugin</artifactId>
				<configuration>
					<jvmArguments>
						--enable-preview
					</jvmArguments>
					<image>
						<env>
							<JAVA_OPTS>--enable-preview</JAVA_OPTS>
						</env>
					</image>
				</configuration>
				<executions>
					<execution>
						<id>buildImage</id>
						<goals>
							<goal>build-image</goal>
						</goals>
					</execution>
				</executions>
			</plugin>

Docker image is built successfully but container fails to start with exception:
Exception in thread "main" java.lang.UnsupportedClassVersionError: Preview features are not enabled for demo/Application (class file version 58.65535). Try running with '--enable-preview'

And resulting JAVA_OPTS environment variable in the image is missing my argument:
-Djava.security.properties=/layers/paketo-buildpacks_bellsoft-liberica/java-security-properties/java-security.properties -agentpath:/layers/paketo-buildpacks_bellsoft-liberica/jvmkill/jvmkill-1.16.0-RELEASE.so=printHeapHistogram=1 -XX:ActiveProcessorCount=2 -XX:MaxDirectMemorySize=10M -XX:MaxMetaspaceSize=104953K -XX:ReservedCodeCacheSize=240M -Xss1M -Xmx431622K -Dio.paketo.openssl.ca-certificates=/etc/ssl/certs/ca-certificates.crt

[tha2015]

As I understand, <env> is not for passing environment variables to the application image. It is for configuring buildpack behaviors (e.g. BP_JVM_VERSION to choose which JVM version to be included in the image).

I also have the same question as yours. I want to pass some environment variables to my application image. I've checked Paketo buildpacks web site and it doesn't seem to have the information I need.

I'd suggest to improve the plugin document to give an example how to include environment variables into the OCI images.

[scottfrederick]

As I understand, <env> is not for passing environment variables to the application image. It is for configuring buildpack behaviors (e.g. BP_JVM_VERSION to choose which JVM version to be included in the image).

That's correct. We'll research how to get environment variables passed to the JVM in the built image.

[scottfrederick]

After discussions with the Cloud Native Buildpacks team, there currently isn't a way to pass environment variables to a builder and request that the builder set the variable in the resulting image. In order to support this, CNB builder clients like the pack CLI and the Spring Boot build plugins would need a way to specify whether an environment variable is meant for use by the builder, or intended to be used only during image build process, or intended to be set in the resulting image. The CNB team will need to think about a design for this requirement.

As an alternative to setting something like JAVA_OPTS permanently in the built image, you can provide environment variables to the container runtime when running the container image. For example, with Docker you can do this:

$ docker run --env JAVA_OPTS="--enable-preview" <image>

[francescopeloi]

@scottfrederick do you have a reference on CNB for this feature request? Thank you

[scottfrederick]

There's not an issue opened with CNB or Paketo for this feature yet, but you can join the discussion in the Paketo slack.

[bmd007]

what if we deploy the images in something like hashi corp Nomad? Any tricks for passing jvm options there?

[scottfrederick]

@bmd007 The Paketo documentation now has information on passing arguments run running an app in an image. See https://paketo.io/docs/buildpacks/language-family-buildpacks/java/.

As mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements. This is a question that would be better suited to Stack Overflow.

[wilkinsona]

I think it's now possible to burn runtime arguments into the JVM at build time. Via @ekcasey, the environment variables buildpack can be used like this:

To use the environment variables buildpack you would probably want to pass --env "BPE_APPEND_JAVA_TOOL_OPTIONS=-Dspring.devtools.restart.enabled=true" and --env "BPE_DELIM_JAVA_TOOL_OPTIONS= " to append your value with a whitespace delimiter and thus avoid overriding that buildpack’s memory configuration.

We should try it out and perhaps make some documentation updates if it works as hoped.

[scottfrederick]

There is an open issue to document the environment variables buildpack on the Paketo documentation site. Once this is done, the Spring Boot documentation should link to this Paketo documentation and embellish it with examples of setting BPE_APPEND_JAVA_TOOL_OPTIONS and BPE_DELIM_JAVA_TOOL_OPTIONS in a Maven pom.xml and Gradle build.gradle.

[MosheElisha]

Thanks for the pointers.

I used the following options:

<plugin>
  <artifactId>spring-boot-maven-plugin</artifactId>
  <groupId>org.springframework.boot</groupId>
  <version>2.4.1</version>
  <configuration>
    <image>
      <env>
        <BPE_DELIM_JAVA_TOOL_OPTIONS xml:space="preserve"> </BPE_DELIM_JAVA_TOOL_OPTIONS>
        <BPE_PREPEND_JAVA_TOOL_OPTIONS>-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager</BPE_PREPEND_JAVA_TOOL_OPTIONS>
      </env>
    </image>
...

And it works well:

Spring Cloud Bindings Enabled
Picked up JAVA_TOOL_OPTIONS: -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager -Djava.security.properties=/layers/paketo-buildpacks_bellsoft-liberica/java-security-properties/java-security.properties -agentpath:/layers/paketo-buildpacks_bellsoft-liberica/jvmkill/jvmkill-1.16.0-RELEASE.so=printHeapHistogram=1 -XX:ActiveProcessorCount=12 -XX:MaxDirectMemorySize=10M -Xmx24854642K -XX:MaxMetaspaceSize=146261K -XX:ReservedCodeCacheSize=240M -Xss1M -Dorg.springframework.cloud.bindings.boot.enable=true

[kulack]

Near as I can tell, this doesn't actually work for other general image environment variables does it?
For example there appears to be no "TEST" variable when using something like this

	<BPE_DELIM_TEST xml:space="preserve"> </BPE_DELIM_TEST>
	<BPE_APPEND_TEST>TESTING</BPE_APPEND_TEST>`

[scottfrederick]

@kulack The Paketo environment variables buildpack will get that configuration, and it's up to the buildpack to decide what to do with it. BPE_APPEND_TEST might assume that an environment variable TEST already exists to be appended to, and I'm not sure what it does if the environment variable does not exist. If you're just trying to set an environment variable, then BPE_DEFAULT_TEST might be what you want. You can refer to the Paketo documentation or ask on the Paketo slack to get more information on buildpack behavior.

[kulack]

Yeah, I had tried both DEFAULT and OVERRIDE and wasn't having great luck. I'll dig into see what the build pack actually does.
Thanks!

[job4saurabh]

Passing the JVM parameters to your Spring boot-based application doesn't help directly and does not reflect with your applications deployment configuration if you are using docker/Opensift/Kubernetes based platform. You need to the he following changes bypassing the parameters through the environment variable if S2I or by setting these parameters in deployment.yaml file through jenkins pipeline.

1. **Jenkins Pipeline:For example, if you are using a jenkins pipeline to deploy your application or services then you can meke following changes in the json template to refelect these changes in deployment.yaml file to deploy your application with JKube, the following settings will override the default values for the MaxMetaspaceSize and MaxMetaspaceSize:

spec:  
template:    
spec:      containers:      

• env:        
  - name: JAVA_OPTIONS          
  - value: '-Xms256m -Xmx1024m'       
  -  - name: GC_MAX_METASPACE_SIZE          
  - value: 1024        
  - name: GC_METASPACE_SIZE        
  -   value: 256

Note: After deploying your service over OpenShift/Kernates validate the deployment configuration file(deployment.yml) for these parameters. In case not not reflecting then delete your pods completly and reploy the application.

You can follow this link to get more detail on it. [https://facingissuesonit.com/2021/10/23/openshift-metaspace-issue-with-springboot-based-micro-services/]