20 lines
1.7 KiB
Plaintext
20 lines
1.7 KiB
Plaintext
[[container-images.buildpacks]]
|
||
== Cloud Native Buildpacks
|
||
Dockerfiles are just one way to build docker images.
|
||
Another way to build docker images is directly from your Maven or Gradle plugin, using buildpacks.
|
||
If you’ve ever used an application platform such as Cloud Foundry or Heroku then you’ve probably used a buildpack.
|
||
Buildpacks are the part of the platform that takes your application and converts it into something that the platform can actually run.
|
||
For example, Cloud Foundry’s Java buildpack will notice that you’re pushing a `.jar` file and automatically add a relevant JRE.
|
||
|
||
With Cloud Native Buildpacks, you can create Docker compatible images that you can run anywhere.
|
||
Spring Boot includes buildpack support directly for both Maven and Gradle.
|
||
This means you can just type a single command and quickly get a sensible image into your locally running Docker daemon.
|
||
|
||
See the individual plugin documentation on how to use buildpacks with {spring-boot-maven-plugin-docs}#build-image[Maven] and {spring-boot-gradle-plugin-docs}#build-image[Gradle].
|
||
|
||
NOTE: The https://github.com/paketo-buildpacks/spring-boot[Paketo Spring Boot buildpack] has also been updated to support the `layers.idx` file so any customization that is applied to it will be reflected in the image created by the buildpack.
|
||
|
||
NOTE: In order to achieve reproducible builds and container image caching, Buildpacks can manipulate the application resources metadata (such as the file "last modified" information).
|
||
You should ensure that your application does not rely on that metadata at runtime.
|
||
Spring Boot can use that information when serving static resources, but this can be disabled with configprop:spring.web.resources.cache.use-last-modified[].
|