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

This article focuses on "how to use Docker to optimize Spring Boot applications", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let the editor take you to learn how to use Docker to optimize Spring Boot applications.

Docker is powerful and easy to use. Docker allows developers to create portable images of software. These images can be deployed repeatedly. You can easily get a lot of value from Docker, but to get the most value from Docker, you need to understand some concepts. How to build Docker images plays an important role in continuous integration and continuous delivery. In this article, I will focus on:

How to build Docker images for Spring Boot applications in a more efficient way during iterative development and deployment.

The standard approach to building Docker images for Spring Boot applications has some drawbacks, so here we'll show you how to do it better.

Key concepts of Docker

Docker has four key concepts: images, layers, Dockerfile and Docker cache. In short, Dockerfile describes how to build a Docker image. The mirror image consists of many layers. Dockerfile starts with the base image and adds other layers. When new content is added to the mirror, a new layer is generated. Each layer built is cached, so it can be reused in subsequent builds. When the Docker build runs, it can reuse any existing layer from the cache. This reduces the time and space required for each build. Anything that has been changed or has not been built before will be built as needed.

Docker update frequency

The mirror layer content is very important.

The importance of mirroring each layer. Existing layers in the Docker cache can be used only if the contents of the mirror layer have not changed. The more layers change during Docker build, the more work Docker needs to do to rebuild the image. The order of the mirror layers is also important. If all the parent layers of a layer have not changed, the layer can be reused. Therefore, it is best to put layers that change more frequently on top, so that changes to them will affect fewer sublayers. The order and content of the mirror layers are important. When you package an application as a Docker image, the easiest way is to place the entire application in a separate mirror layer. However, if the application contains a large number of static library dependencies, you need to rebuild the entire mirror layer even if you change little code. This requires a lot of time and space to build in the Docker cache.

Mirror layer affects deployment

The mirror layer is also important when deploying Docker images. Before deploying Docker images, they are pushed to the Docker remote repository. The repository is the source of all deployed images and often contains many versions of the same image. Docker is so efficient that it is stored only once per tier. However, this is not the case for frequently deployed images with large layers that are constantly rebuilt. Mirrors of large layers, even if there are only a few internal changes, must be stored separately in the warehouse and pushed over the network. Because you need to move and store the same content, this increases deployment time

Application of Spring Boot in Docker

A Spring Boot application that uses the uber-jar method is itself a separate deployment unit. This model is ideal for deployment on a virtual machine or build package because the application brings everything you need. However, this is a disadvantage for Docker deployment: Docker already provides a way to package dependencies. It is common to put an entire Spring Boot JAR into a Docker image, but this results in too much immutable content in the application layer of the Docker image.

Java SpringBoot single layer

Discussions are under way in the Spring community about reducing deployment size and time when running Spring Boot applications, especially in Docker. In my opinion, this is ultimately a tradeoff between simplicity and efficiency. The most common way to build Docker images for Spring Boot applications is what I call a "single-tier" approach. Technically, this is not true, because Dockerfile actually creates multiple layers, but it is sufficient for discussion.

Single layer method

Let's take a look at the single-layer approach. The single-layer method is fast, simple and easy to understand and use. Docker's Spring Boot guide lists a single layer of Dockerfile to build your Docker image:

FROM openjdk:8-jdk-alpine VOLUME / tmp ARG JAR_FILE COPY ${JAR_FILE} app.jar ENTRYPOINT ["java", "- Djava.security.egd=file:/dev/./urandom", "- jar", "/ app.jar"]

The end result is a functioning Docker image that runs exactly the same way you expect Spring Boot applications to run. However, because it is based on the entire application JAR, there is a layering efficiency problem. As the application source changes, the entire Spring Boot JAR is rebuilt. The next time you build the Docker image, the entire application layer will be rebuilt, including all the immutable dependent libraries. Let's look at a concrete example, Spring Pet Clinic.

A more in-depth study of single-layer methods

The single-layer method uses Spring Boot JAR on top of the Open Boot JDK basic image as the Docker layer to build the Docker image:

$docker images REPOSITORY TAG IMAGE ID CREATED SIZE springio/spring-petclinic latest 94b0366d5ba2 16 seconds ago 140MB

The resulting Docker image is 140 MB. You can use the docker history command to check the layers. You can see that the Spring Boot application JAR has been copied to the mirror with a size of 38.3 MB.

$docker history springio/spring-petclinic IMAGE CREATED CREATED BY SIZE COMMENT 94b0366d5ba2 52 seconds ago / bin/sh-c # (nop) ENTRYPOINT ["java"-Djav... 0B 213dff56a4bd 53 seconds ago / bin/sh-c # (nop) COPY file:d3551559c2aa35af … 38.3MB bc453a32748e 6 minutes ago / bin/sh-c # (nop) ARG JAR_FILE 0B 7fe0bb0d8026 6 minutes ago / bin/sh-c # (nop) VOLUME [/ tmp] 0B cc2179b8f042 8 days ago / bin/sh-c set-x & & apk add-- no-cache o … 97.4MB 8 days ago / bin/sh-c # (nop) ENV JAVA_ALPINE_VERSION=8 … 0B 8 days ago / bin/sh-c # (nop) ENV JAVA_VERSION=8u151 0B 8 days ago / bin/sh-c # (nop) ENV PATH=/usr/local/sbin:... 0B 8 days ago / bin/sh-c # (nop) ENV JAVA_HOME=/usr/lib/jv … 0B 8 days ago / bin/sh-c {echo'#! / bin/sh'; echo 'set … 87B 8 days ago / bin/sh-c # (nop) ENV LANG=C.UTF-8 0B 5 months ago / bin/sh-c # (nop) CMD ["/ bin/sh"] 0B 5 months ago / bin/sh-c # (nop) ADD file:093f0723fa46f6cdb … 4.15MB

The next time you build the Docker image, the entire 38 MB layer will be recreated because the JAR file has been repackaged. In this example, the size of the application is relatively small (because it is based only on spring-boot-starter-web and other dependencies, such as spring-actuator). In actual development, these sizes are usually much larger because they include not only Spring Boot libraries, but also other third-party libraries. In my experience, the size of an actual Spring Boot application may range from 50 MB to 250 MB, if not larger. If you look closely at the application, only 372 KB in the application JAR is the application code. The remaining 38 MB is a dependent library. This means that only 0.1% of the layers are actually changing. The remaining 99.9% remains unchanged.

Mirror layer life cycle

This is based on the basic consideration of the mirror layer: the life cycle of the content. The content of the mirror layer should have the same life cycle. The content of Spring Boot applications has two different lifecycles: dependent libraries that change infrequently and application classes that change frequently. The unchanged binaries are also included each time the layer is rebuilt due to a change in the application code. In a rapid application development environment, the additional cost of constantly changing and redeploying application code can become very expensive. Imagine an application team iterating on Pet Clinic. The team changes and redeploys the application 10 times a day. The cost of these 10 new tiers is 383MB per day. If you use more actual sizes, you can reach a maximum of 2.5 GB or more per day. End up wasting a lot of build time, deployment time, and Docker warehouse space. The development and delivery of rapid iterations will determine whether we continue to use a simple single-tier approach or a more efficient alternative.

Hug Docker and enter the double layer.

When making a trade-off between simplicity and efficiency, I think the right choice is a "two-tier" approach. There can be more layers, but too many layers can be harmful and violate Docker best practices. In the two-tier approach, we build the Docker image so that the dependency libraries of the Spring Boot application exist in the layer below the application code. In this way, each layer will follow a different lifecycle of the content. Iterative rebuild and redeployment are faster by pushing dependent libraries that change infrequently into a separate tier and leaving only the application classes at the top level.

Java Spring Boot double layer

The two-tier approach speeds up iterative development and minimizes deployment time. Of course, the actual efficiency varies from application to application, but on average, this will reduce the application deployment size by 90% and shorten the deployment cycle accordingly.

At this point, I believe you have a deeper understanding of "how to use Docker to optimize Spring Boot applications". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.