Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How Tomcat images are used in Dockerfile

2025-01-18 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

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

This article will explain in detail how to use Tomcat images in Dockerfile. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have some understanding of the relevant knowledge after reading this article.

Official Tomcat image

1.Supported tags and respective Dockerfile links

Supported tags and corresponding Dockerfile links. A Dockerfile can correspond to multiple tags, and we will analyze it with the 8.5.16-jre8 version of Dockerfile.

2.How to use this image

How to use this image includes commands to run the container in different ways, as well as some major environment variables. It is not detailed enough here, we will explain it in detail.

Preparation knowledge: APR pattern of APR, Tomcat Native, Tomcat

APR is the abbreviation of Apache Portable Runtime. In fact, it is a group of dynamic link libraries written in C language, which provides a unified API interface for accessing the underlying operating system. See http://apr.apache.org/ for details.

The main role of Tomcat Native is to provide tomcat with the ability to access local resources. That is, using the APR library to access the network, generate random numbers and so on. Tomcat Native depends on APR, OpenSSL, JDK. See http://tomcat.apache.org/native-doc/ for details.

After configuring Tomcat Native, you can turn on APR mode in the tomcat configuration file. When enabled, Tomcat will directly call the APR library to access the network without having to transfer through jvm.

Because APR and Tomcat Native are closely related to the specific operating system, they are not compiled and can be used across platforms like java applications. So tomcat does not install these features by default, but manually compiles the source code to install it as needed, as well as the specific operating system. From some sources, when tomcat's APR mode is turned on, the performance of tomcat will not necessarily be greatly improved (or even degraded in some cases). Whether to turn on APR mode depends on the specific situation. Personally, in general, when it comes to mining Tomcat performance, using tomcat cluster will be a better solution, which will improve the performance, stability and reliability of the system.

Analyze Dockerfile (tomcat:8.5.16-jre8)

Address: https://github.com/docker-library/tomcat/blob/master/8.5/jre8/Dockerfile

Note that taking the Dockerfile link of the master branch as an example, it may be inconsistent with the Dockerfile link on DockerHub, but it does not affect our next analysis. The following is the content of this Dockerfile, which I have added comments to explain:

# the basic image of this image. If you are interested, you can search openjdk on DockerHub and analyze the Dockerfile file of the official openjdk image. Why not use the jdk (jre) provided by oracle here? To put it simply, the issue of copyright. FROM openjdk:8-jre# declares the CATALINA_HOME environment variable, which everyone knows. ENV CATALINA_HOME / usr/local/tomcat# adds the bin path under Tomcat to the PATH environment variable. ENV PATH $CATALINA_HOME/bin:$PATH# creates the tomcat path. RUN mkdir-p "$CATALINA_HOME" # specifies the current working path of the RUN, CMD, ENTRYPOINT commands. WORKDIR $CATALINA_HOME#Tomcat Native path configuration. ENV TOMCAT_NATIVE_LIBDIR $CATALINA_HOME/native-jni-lib# adds TOMCAT_NATIVE_LIBDIR to the LD_LIBRARY_PATH environment variable so that when Tomcat looks for Tomcat Native-related dynamic link libraries, it looks for the path specified by the TOMCAT_NATIVE_LIBDIR environment variable. ENV LD_LIBRARY_PATH ${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:} $TOMCAT_NATIVE_LIBDIR# checks and updates OpenSSL. I haven't delved into the details of this piece. ENV OPENSSL_VERSION 1.1.0f-3RUN {\ echo 'deb http://deb.debian.org/debian stretch main';\} > / etc/apt/sources.list.d/stretch.list\ & & {\ echo' Package: *';\ echo 'Pin: release nasty stretchbacks;\ echo' Pin-Priority:-10 percent;\ echo;\ echo 'Package: openssl libssl*';\ echo "Pin: version $OPENSSL_VERSION" \ echo 'Pin-Priority: 990 files;\} > / etc/apt/preferences.d/stretch-opensslRUN apt-get update & & apt-get install- y-- no-install-recommends\ libapr1\ openssl= "$OPENSSL_VERSION"\ & & rm-rf / var/lib/apt/lists/*# is imported into key from the key server to verify the signature of the tomcat compressed file. ENV GPG_KEYS 05AB33110949707C93A279E3D3EFE6B686867BA6 07E48665A34DCAFAE522E5E6266191C37C037D42 47309207D818FFD8DCD3F83F1931D684307A10A5 541FBE7D8F78B25E055DDEE13C370389288584E7 61B832AC2F1C5A90F0F9B00A1C506407564C17A3 713DA88BE50911535FE716F5208B0AB1D63011C7 79F7026C690BAA50B92CD8B66A3AD3F4F22C4FED 9BA44C2621385CB966EBA586F72C284D731FABEE A27677289986DB50844682F8ACB77FC2E86E29AC A9C5DF4D22E99998D9875A5110C01C5A2F6059E7 DCFD35E0BF8CA7344752DE8B6FB21E8933C60243 F3A04C595DB5B6A5F1ECA43E3B7BBB100D811BBE F7DA48BB64BCB84ECBA7EE6935CD23C10D498E23RUN set-ex;\ for key in $GPG_KEYS; do\ gpg-- keyserver ha.pool.sks-keyservers.net-- recv-keys "$key";\ done#Tomcat version of the related files. Download address of ENV TOMCAT_MAJOR 8ENV TOMCAT_VERSION 8.5.16#Tomcat related files. ENV TOMCAT_TGZ_URL https://www.apache.org/dyn/closer.cgi?action=download&filename=tomcat/tomcat-$TOMCAT_MAJOR/v$TOMCAT_VERSION/bin/apache-tomcat-$TOMCAT_VERSION.tar.gzENV TOMCAT_ASC_URL https://www.apache.org/dist/tomcat/tomcat-$TOMCAT_MAJOR/v$TOMCAT_VERSION/bin/apache-tomcat-$TOMCAT_VERSION.tar.gz.asc# executes the command RUN set-x\\ # download the Tomcat zip file & & wget-O Tomcat.tar.gz "$TOMCAT_TGZ_URL"\ & & wget-O tomcat.tar.gz.asc "$TOMCAT_ASC_URL"\ # for signature verification & & gpg-batch-verify tomcat.tar.gz.asc tomcat.tar.gz\ # decompress Tomcat & & tar-xvf tomcat.tar.gz-strip-components=1\ # Delete .bat files for Windows system & & rm bin/*.bat\ # Delete pressure Shrink file & & rm tomcat.tar.gz*\\ # install Tomcat Native & & nativeBuildDir= "$(mktemp-d)"\ & & tar-xvf bin/tomcat-native.tar.gz-C "$nativeBuildDir"-strip-components=1\ & & nativeBuildDeps= "\ dpkg-dev\ gcc\ libapr1-dev\ libssl-dev\ make\ openjdk-$ {JAVA_ version% [- ~ bu] *}-jdk=$JAVA_DEBIAN_VERSION\"\ & & apt-get update & & apt-get install- y-- no-install-recommends $nativeBuildDeps & & rm-rf / var/lib/apt/lists/*\ & & (\ export CATALINA_HOME= "$PWD"\ & & cd "$nativeBuildDir/native"\ & & gnuArch= "$(dpkg-architecture-- query DEB_BUILD_GNU_TYPE)"\ & &. / configure\-- build= "$gnuArch"\-- libdir= "$TOMCAT_NATIVE_LIBDIR" \-- prefix= "$CATALINA_HOME"\-- with-apr= "$(which apr-1-config)"\-- with-java-home= "$(docker-java-home)"\-- with-ssl=yes\ & make-j "$(nproc)"\ & & make install\)\ & & apt-get purge-y-- auto-remove $nativeBuildDeps\ & & rm-rf "$nativeBuildDir"\ & & rm bin/ Tomcat-native.tar.gz# verifies that Tomcat Native has successfully installed RUN set-e\ & & nativeLines= "$(catalina.sh configtest 2 > & 1)"\ & & nativeLines= "$(echo" $nativeLines "| grep 'Apache Tomcat Native')"\ & & nativeLines= "$(echo" $nativeLines "| sort-u)"\ & & if! Echo "$nativeLines" | grep 'INFO: Loaded APR based Apache Tomcat Native library' > & 2; then\ echo > & 2 "$nativeLines";\ exit 1;\ fi# exposes commands executed when the port 8080 EXPOSE 808 container starts. CMD ["catalina.sh", "run"]

The main functions of this Dockerfile can be summarized as follows:

1. Build the image based on openjdk image.

two。 Install Tomcat Native and its dependent libraries (such as APR, OpenSSL, etc.). Verify that it is installed correctly.

3. Download Tomcat, check signatures, extract, remove useless files, etc.

4. Expose port 8080 and configure the entry command.

Generally speaking, the function of this Dockerfile is relatively clear. If you want to build your own Tomcat image, you can refer to this Dockerfile. In addition, the Dockerfile of Tomcat should be generated automatically rather than written by hand, because first, there are many versions of Dockerfile in Tomcat, which requires a lot of manual maintenance; second, there are some areas that I don't think are very reasonable (such as getting a lot of key from key server). So when analyzing some official Dockerfile, don't struggle too much if you encounter something that doesn't feel very reasonable.

How to use official mirrors

$docker run-d-name tomcat-test-p 8888purl 8080 tomcat:8.5.16-jre8

The above instructions will launch a container using this image, and you can access the Tomcat in the container through the http:// native ip:8888. There is no application deployed in this way, so it doesn't make any practical sense.

$docker run-d-- name tomcat-test-p 8888 tomcat:8.5.16-jre8 8080\-v / home/myWebApp:/usr/local/tomcat/webapps/ROOT\-v / home/myWebAppLogs:/usr/local/tomcat/logs\ tomcat:8.5.16-jre8

The above directive adds two volume, mount / home/myWebApp to / usr/local/tomcat/webapps/ROOT in the container, and mount / home/myWebAppLogs to the / usr/local/tomcat/logs path in the container. After the container starts, the root application of tomcat will be myWebApp (accessed through http:// native ip:8888), and tomcat logs will be output to the / home/myWebAppLogs path.

After that, if the container is deleted, the application and the application log will not be deleted with the container. When updating the application, you only need to update the / home/myWebApp path and restart the container.

If you don't want to mount the application to the root directory, you can change the volume configuration, such as-v / home/myWebApp:/usr/local/tomcat/webapps/myWebApp, and access it via http:// native ip:8888/myWebApp.

Note: if you want to output the logs within myWebApp to the / home/myWebAppLogs path, configure the output path of myWebApp's log file to the Tomcat log path (relative path), for example: logs/myLog.log. In this way, the log file of myWebApp will be output to / usr/local/tomcat/logs (because volume is mounted, it is actually output to the / home/myWebAppLogs path).

From a normative point of view, in fact, this kind of application deployment is not recommended, because the deployment is still environment-dependent. In other words, the application directory and log directory must be specified before deployment. Moreover, if you want to deploy two identical applications on one machine for load balancing (you need to build two sets of application and log directories, and modify the container startup command), it is difficult to achieve automatic deployment. But then again, I believe this kind of deployment will be welcomed by most people. At present, our company also widely uses this model in the test environment, so that one test server can deploy multiple applications (Tomcat) without any connection or influence to each other.

If you want to achieve completely environment-independent deployment, you can consider building a new image based on the official Tomcat image. Download and deploy myWebApp directly in the Dockerfile of this new image, and use some tools or frameworks to upload and summarize the logs generated by Tomcat and myWebApp into a unified log service. So, if you want to deploy the same application again, just give me a machine with a Docker environment and I can execute an instruction (note port conflicts in the same Docker environment). This approach is conducive to automated deployment and is more appropriate in the case of a large number of servers. Of course, the trouble with this approach is that every time you release an application version, you have to rebuild a new image.

For automated deployment, you can also refer to Docker Compose and Kubernetes, which are not done in depth here (mainly because I don't know enough about this area and application).

The deficiency of the official mirror image

There are still some problems encountered in the actual use of this image:

1. In order to take care of image users around the world, neither the official openjdk image nor the Tomcat image has customized the time zone. The default is UTC time (eight hours earlier than Beijing time). If there is no time zone configuration within the application, the system time obtained by the application will also be UTC time.

two。 On some machines (or virtual machines), jdk's random number generator takes too long to initialize, causing Tomcat to take too long to start. This is the case with the Aliyun ECS that I have used.

So much for sharing about how Tomcat images are used in Dockerfile. I hope the above content can be helpful to you and learn more. If you think the article is good, you can share it for more people to see.

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report