Spring/spring-boot
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add documentation for Maven plugin's build-image support

Browse Source 
Closes gh-19830
This commit is contained in:
Stephane Nicoll
2020-01-23 16:35:45 +01:00
parent 6df5e7af4f
commit 63019ab3f1
3 changed files with 113 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/asciidoc/index.adoc
View File

@@ -17,6 +17,7 @@ It allows you to package executable jar or war archives, run Spring Boot applica
include::getting-started.adoc[]
include::packaging.adoc[]
include::packaging-oci-image.adoc[]
include::running.adoc[]
include::integration-tests.adoc[]
include::build-info.adoc[]

111
spring-boot-project/spring-boot-tools/spring-boot-maven-plugin/src/docs/asciidoc/packaging-oci-image.adoc Normal file
View File

@@ -0,0 +1,111 @@
[[build-image]]
== Packaging OCI Images
The plugin can create https://github.com/opencontainers/image-spec[OCI images] using a https://buildpacks.io/[buildpack].
Images can be built using the `build-image` goal and a local Docker installation.
It is possible to automate the creation of an image whenever the `package` phase is invoked, as shown in the following example:
[source,xml,indent=0,subs="verbatim,attributes"]
----
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>{version}</version>
<executions>
<execution>
<goals>
<goal>build-image</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
----
TIP: While the buildpack runs from an <<repackage,executable archive>>, it is not necessary to execute the `repackage` goal first as the executable archive is created automatically if necessary.
When the `build-image` repackages the application, it applies the same settings as the `repackage` goal would, i.e. dependencies can be excluded using one of the exclude options, and Devtools is automatically excluded by default (you can control that using the `excludeDevtools` property).
By default, the image is built using the `cloudfoundry/cnb:0.0.43-bionic` builder and its name is deduced from the `artifactId` of the project.
Both these settings can be tuned via configuration, see <<build-image-example-custom-image-builder,custom image builder>> and <<build-image-example-custom-image-name,custom image name>>.
include::goals/build-image.adoc[leveloffset=+1]
[[build-image-examples]]
=== Examples
[[build-image-example-custom-image-builder]]
==== Custom Image Builder
If you need to customize the builder used to create the image, configure yours as shown in the following example:
[source,xml,indent=0,subs="verbatim,attributes"]
----
<project>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>{version}</version>
<executions>
<execution>
<id>build-image</id>
<goals>
<goal>build-image</goal>
</goals>
<configuration>
<image>
<builder>mine/java-cnb-builder</builder>
</image>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
----
This configuration will use the `latest` version of the `mine/java-cnb-builder` builder.
[[build-image-example-custom-image-name]]
==== Custom Image Name
By default, the image name is inferred from the `artifactId` and the `version` of the project, something like `docker.io/library/${project.artifactId}:{project.version}`.
You can take control over the name, as shown in the following example:
[source,xml,indent=0,subs="verbatim,attributes"]
----
<project>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>{version}</version>
<executions>
<execution>
<id>build-image</id>
<goals>
<goal>build-image</goal>
</goals>
<configuration>
<image>
<name>example.com/library/${project.artifactId}</builder>
</image>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
----
Note that this configuration does not provide an explicit version so `latest` is used.
It is possible to specify a version as well, either using `${project.version}`, any property available in the build or an hardcoded version.