Jib - How to use environmental variables from base image
Asked Answered
C

3

17

I have a base java image with some pre defined java_opts as a environmental variable. How can I use them in plugin?

                    <plugin>
                        <groupId>com.google.cloud.tools</groupId>
                        <artifactId>jib-maven-plugin</artifactId>
                        <version>1.8.0</version>
                        <configuration>
                            <from>
                                <image>${docker.registry}java:11</image>
                            </from>
                            <to>
                                <image>${docker.registry}portal-backend:${dockerfile.tag}</image>
                            </to>
                            <container>
                                <jvmFlags>
                                    # This will fail
                                    <jvmFlag>$JAVA_OPTS</jvmFlag>
                                </jvmFlags>
                            </container>
                        </configuration>
                    </plugin>
Chelyabinsk answered 16/12, 2019 at 13:15 Comment(0)
M
14

(Before I start: even if $JAVA_OPTS were expanded when running a Maven build at compile time (it isn't expanded, obviously), <jvmFlag>$JAVA_OPTS<jvmFlag> would still fail, because the entire string value of $JAVA_OPTS containing multiple JVM flags would be passed as a single argument to the java binary. For example, -Xms1024m -Xmx2048m should be passed as two separate flags. The entire string including the whitespace as a single argument is not a valid JVM flag.)


First of all, it'd helpful to understand and figure out who can/should expand variables at which point in time. Variable expansion is not magic, and after all, it's just plain string replacement. Some program, be it Gradle, Maven, a shell program (like bash), JVM, Kubernetes, etc., should be directed to replace strings of the form $FOO. It could be at container build time (i.e., replaced strings are baked into a built image) or at runtime (i.e., bash replaces strings when it runs).


So, you want to read and specify JVM arguments defined in the base image? If possible, have the base image define JAVA_TOOL_OPTIONS instead (note not JAVA_TOOL_OPTS nor JAVA_OPTS). Most JVMs will honor JAVA_TOOL_OPTIONS at runtime. See https://mcmap.net/q/745586/-jib-maven-spring-boot-profile for details. (Also note that, container runtimes (docker, Kubernetes, etc.) can always provide environment variables (and/or override whatever variables defined at build time as container configuration) at runtime. That is, you can dynamically set arguments at runtime.)


Another option, which is a general solution to expand any variables at runtime (i.e., not limited to variables from a base image): define your own <entrypoint> to use a shell. (Therefore, you need a base image that includes a shell binary (such as /bin/bash). Note that the default base image prior to Jib 3.0 was Distroless and did not include a shell program. OTOH, Jib 3.0+ doesn't use Distroless.)

In this method, you'll need to know the right Java runtime classpath and the main class to use in your JVM launch command. To help this, starting with Jib >= 3.1, Jib creates two JVM argument files inside a built image; they will hold, respectively, the classpath and the main class inside a built image.

Knowing the entrypoint, you can write a shell script (my-entrypoint.sh):

#!/bin/sh

# Assumes `java` is on PATH in the base image.
exec java $JAVA_OPTS \
  -cp $( cat /app/jib-classpath-file ) \
  $( cat /app/jib-main-class-file )

Alternatively, if you are on Java 9+, you can leverage the @-argument file:

exec java $JAVA_OPTS -cp @/app/jib-classpath-file @/app/jib-main-class-file

Place my-entrypoint.sh under <project root>/src/main/jib. This is the default directory for Jib's <extraDirectories> feature, and Jib will place src/main/jib/my-entrypoint.sh at the root directory in the container image. Then set the default <entrypoint> to this script:

<container>
  <!-- Assumes you have /bin/sh as specified at the top of /my-entrypoint.sh. -->
  <entrypoint>/my-entrypoint.sh</entrypoint>
</container>
<!-- You also need to make the script executable. -->
<extraDirectories>
  <permissions>
    <permission>
      <file>/my-entrypoint.sh</file>
      <mode>755</mode>
    </permission>
  </permissions>
</extraDirectories>

Alternatively, if you invoke /bin/sh as below, you don't have to configure <extraDirectories> to make the file executable. This may not look customary; you would normally make the script executable and run it directly. But this is perfectly valid, and there is no difference in terms of actual execution (as long as the shebang of /entrypoint.sh is the same #!/bin/sh).

<container>
  <entrypoint>
    <arg>/bin/sh</arg>
    <arg>/my-entrypoint.sh</arg>
  </entrypoint>
</container>

It's also possible to do this without creating a script (basically embedding the entire script in pom.xml and passing it to a shell program). In this case, you don't need to configure <extraDirectories>.

          <container>
            <entrypoint>
              <arg>/bin/sh</arg>
              <arg>-c</arg>
              <arg>exec java $JAVA_OPTS -cp $( cat /app/jib-classpath-file ) $( cat /app/jib-main-class-file )</arg>
            </entrypoint>
          </container>
Marris answered 16/12, 2019 at 17:34 Comment(2)
Thanks! I went with approach to define custom entrypoint very similar to your example.Chelyabinsk
+1 for mentioning JAVA_TOOL_OPTIONS environment variable. You can use it without defining in the base Docker image.Shawnna
S
3

My solution is to remove JVM memory parameters from jib-maven-plugin configuration at all. Instead I define JAVA_TOOL_OPTIONS environment variable (example: JAVA_TOOL_OPTIONS='-Xss=512k') for the container (for example: in docker-compose configuration file).

Please note that this environment variable DOESN'T NEED to be defined in a base image at all.

Shawnna answered 25/2, 2021 at 9:29 Comment(1)
#71145714Stockpile
V
2

Variables defined as below

Option 1: Java System Properties (VM Arguments)

It's important that the -D parameters are before your application.jar otherwise they are not recognized.

java -jar -Dspring.profiles.active=prod application.jar

Option 2: Program arguments

java -jar application.jar --spring.profiles.active=prod --spring.config.location=c:\config

POM changes : When using jib as maven plugin - to change the loading of spring config file location : then entryPoint to be passed inside container, but seems jib plugin didn't pick that up . so below changes needs to be done in pom for the argument access for the location :

<plugin>
    <groupId>com.google.cloud.tools</groupId>
    <artifactId>jib-maven-plugin</artifactId>
    <version>2.2.0</version>
    <configuration>
        <to>
            <image>image-url</image>
        </to>
        <container>
            <creationTime>${​​​​​​maven.build.timestamp}​​​​​​</creationTime>
            <mainClass>com.package.SpringBootMainClass</mainClass>
            <args>
                <arg>--spring.config.location=/demo/location/application.yml</arg>
            </args>
        </container>
    </configuration>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>build</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Jib-maven plugin in pom how to pass the arguments , just shown a way through pom , jib don't pick up arguments from entrypoint for spring app, that's why thought of providing another way for the same. as above answer doesn't have it.

Villainous answered 14/1, 2021 at 7:46 Comment(2)
This answer has nothing to do with environment variables being used in Jib config...Housley
Jib-maven plugin in pom how to pass the arguments , just shown a way through pom , jib don't pick up arguments from entrypoint for spring app, that's why thought of providing another way for the same. as above answer doesn't have it.Villainous

© 2022 - 2024 — McMap. All rights reserved.