You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
More efficient container images can also be created by copying the dependencies to the image as a separate layer from the application classes and resources (which normally change more frequently).
37
-
There is more than one way to achieve this layer separation.
38
-
For example, using a `Dockerfile` you could express it in this form:
36
+
NOTE: Using the `JarLauncher` over the application's main method has the added benefit of a predictable classpath order.
37
+
The jar contains a `classpath.idx` file which is used by the `JarLauncher` when constructing the classpath.
Assuming the above `Dockerfile` is in the current directory, your docker image can be built with `docker build .`, or optionally specifying the path to your application jar, as shown in the following example:
More efficient container images can also be created by <<spring-boot-features.adoc#building-docker-images,creating separate layers>> for your dependencies and application classes and resources (which normally change more frequently).
Copy file name to clipboardExpand all lines: spring-boot-project/spring-boot-docs/src/docs/asciidoc/spring-boot-features.adoc
+28-57Lines changed: 28 additions & 57 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7996,77 +7996,41 @@ The other issue is that putting your application's code and all its dependencies
7996
7996
Since you probably recompile your code more often than you upgrade the version of Spring Boot you use, it’s often better to separate things a bit more.
7997
7997
If you put jar files in the layer before your application classes, Docker often only needs to change the very bottom layer and can pick others up from its cache.
7998
7998
7999
-
=== Layered Jars
8000
-
To make it easier to create optimized Docker images that can be built with a dockerfile, Spring Boot supports "layered jars".
8001
-
A regular fat jar that can be run with `java -jar` has the following structure:
8002
-
8003
-
[source]
8004
-
----
8005
-
META-INF/
8006
-
MANIFEST.MF
8007
-
org/
8008
-
springframework/
8009
-
boot/
8010
-
loader/
8011
-
...
8012
-
BOOT-INF/
8013
-
classes/
8014
-
...
8015
-
lib/
8016
-
...
8017
-
----
8018
-
8019
-
The jar is organized into three main parts:
8020
-
8021
-
* Classes used to bootstrap jar loading
8022
-
* Your application classes in `BOOT-INF/classes`
8023
-
* Dependencies in `BOOT-INF/lib`
8024
-
8025
-
Instead of the above jar, you can create a layered jar that looks something like this:
8026
-
8027
-
[source]
8028
-
----
8029
-
META-INF/
8030
-
MANIFEST.MF
8031
-
org/
8032
-
springframework/
8033
-
boot/
8034
-
loader/
8035
-
...
8036
-
BOOT-INF/
8037
-
layers/
8038
-
<name>/
8039
-
classes/
8040
-
...
8041
-
lib/
8042
-
...
8043
-
<name>/
8044
-
classes/
8045
-
...
8046
-
lib/
8047
-
...
8048
-
layers.idx
8049
-
----
8050
-
8051
-
You still see the bootstrap loader classes (you can still run `java -jar`) but now the `lib` and `classes` folders have been split up and categorized into layers.
8052
-
There’s also a `layers.idx` file that provides the order in which layers should be added.
7999
+
=== Layering Docker Images
8000
+
To make it easier to create optimized Docker images that can be built with a dockerfile, Spring Boot supports adding a layer index file to the jar.
8001
+
The `layers.idx` file lists all the files in the jar along with the layer that the file should go in.
8002
+
The list of files in the index is ordered based on the order in which the layers should be added.
8053
8003
Out-of-the-box, the following layers are supported:
8054
8004
8055
8005
* `dependencies` (for regular released dependencies)
8006
+
* `spring-boot-loader` (for everything under `org/springframework/boot/loader`)
This layering is designed to separate code based on how likely it is to change between application builds.
8062
8025
Library code is less likely to change between builds, so it is placed in its own layers to allow tooling to re-use the layers from cache.
8063
8026
Application code is more likely to change between builds so it is isolated in a separate layer.
8064
8027
8065
-
For Maven, refer to the {spring-boot-maven-plugin-docs}/#repackage-layered-jars[packaging layered jars section] for more details on creating a layered jar.
8028
+
For Maven, refer to the {spring-boot-maven-plugin-docs}/#repackage-layered-jars[packaging layered jars section] for more details on adding a layer index to the jar.
8066
8029
For Gradle, refer to the {spring-boot-gradle-plugin-docs}/#packaging-layered-jars[packaging layered jars section] of the Gradle plugin documentation.
8067
8030
8068
-
=== Writing the Dockerfile
8069
8031
8032
+
8033
+
=== Writing the Dockerfile
8070
8034
When you create a layered jar, the `spring-boot-jarmode-layertools` jar will be added as a dependency to your jar.
8071
8035
With this jar on the classpath, you can launch your application in a special mode which allows the bootstrap code to run something entirely different from your application, for example, something that extracts the layers.
8072
8036
Here’s how you can launch your jar with a `layertools` jar mode:
Assuming the above `Dockerfile` is in the current directory, your docker image can be built with `docker build .`, or optionally specifying the path to your application jar, as shown in the following example:
0 commit comments