Shulou(Shulou.com)06/02 Report--

This article mainly introduces "the method of dynamically assigning Java startup parameters to the container". In daily operation, I believe that many people have doubts about the method of dynamically assigning Java startup parameters to the container. Xiaobian consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts of "dynamically assigning Java startup parameters to the container". Next, please follow the editor to study!

You will encounter a problem when you do Java program containerization, ENTRYPOINT ["java", "$JAVA_OPTS", "- jar",.] In this way, $JAVA_OPTS is a string that cannot be expanded at run time. In order not to hard-code the parameters into the container, each time you adjust the parameters to reconstruct the image, you can have a variety of solutions. First introduce several solutions that are not good enough.

ENTRYPOINT java $JAVA_OPTS-jar. The problem with this approach is that java is not the container main process (as to why java is the main process, another topic, is one of the basic best practices of containerization)

ENTRYPOINT ["sh", "- c", "java $JAVA_OPTS-jar..."], which is actually equivalent to the above method, which is run with / bin/sh-c "java $JAVA_OPTS-jar." So the defects are the same.

ENTRYPOINT ["entrypoint.sh"] then starts java in a script, which is useful for containers that need to do complex operations at startup, but it makes a mountain out of a molehill to start java, and there is also the problem that java is not the main process of the container.

From the point of view of shell, the solution to the problem of non-main process is to use the exec command. When starting the instructions in the following parameters, exec will not create a child process but replace itself with the instruction process, so that the instruction process occupies its own PID (after the first instruction after the exec replaces itself, other subsequent instructions will not be executed naturally). So the above three schemes can be changed to

ENTRYPOINT exce java $JAVA_OPTS-jar...

ENTRYPOINT ["sh", "- c", "exce java $JAVA_OPTS-jar..."]

Write exec java $JAVA_OPTS-jar in the script.

Using exec can solve the previous problem, but the ensuing problem is... Ugly, any extra commands will break cleanliness, and Dockerfile must be neat for programmers who pursue clean code. Fortunately, java is a mature ecology, which in fact provides the corresponding environment variables JDK_JAVA_OPTIONS and JAVA_TOOL_OPTIONS:

JDK_JAVA_OPTIONS was introduced in Java 9, java program startup does not need to specify on the command line will automatically read the environment variables, it is slightly limited, mainly to prevent abuse does not allow the use of parameters that may change the main class or let the main class not execute, usually need to specify memory, GC and other parameters can be used. Java will report an error and exit directly when it encounters parameters that are not allowed, so as long as the program starts smoothly, you don't have to worry about using parameters that are not allowed. The parameters specified here cannot override the same parameters on the command line, and the configuration that needs to be locked can be specified directly in the ENTRYPOINT.

JAVA_TOOL_OPTIONS is a long-standing environment variable, and this environment variable also does not need to be explicitly specified on the command line. The TOOL in its name indicates that in addition to the java command, other java tool commands such as javac will also read the value of this variable. The parameters specified here can override neither the same parameters on the command line nor the same parameters in JDK_JAVA_OPTIONS, with the lowest priority.

In addition, there are some special environment variables, such as _ JAVA_OPTIONS of Oracle home and IBM_JAVA_OPTIONS of IBM home, which usually provide the ability to override the same parameters on the command line, but the environment variable name is not portable, so it is not a good choice in the era of Xxx as Code.

To sum up, the decision path can be obtained as follows:

Java 9 and above (er, there are still Java 9 and below? The java command of) uses JDK_JAVA_OPTIONS

Use JAVA_TOOL_OPTIONS for non-java commands such as CI/CD or packaging tools

Java commands below Java 9 use JAVA_TOOL_OPTIONS

In very special cases, when you need to override the parameters on the command line, reflect on yourself first, then reflect on yourself, and finally find your own defined environment variables.

Finally, there may be questions here. Will setting environment variables affect other java processes? If containerization best practices are followed, the answer is obviously no, and even on the host, it's easy for multiple inter-process environment variables not to affect each other, isn't it?

At this point, the study of "the method of dynamically assigning Java startup parameters to the container" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.