Version v1.39 of the documentation is no longer actively maintained. The site that you are currently viewing is an archived snapshot. For up-to-date documentation, see the latest version.
Jib Build
Jib is a set of plugins for Maven and Gradle for building optimized OCI-compliant container images for Java applications without a Docker daemon.
Skaffold can help build artifacts using Jib; Jib builds the container images and then pushes them to the local Docker daemon or to remote registries as instructed by Skaffold.
Skaffold requires using Jib v1.4.0 or later.
Skaffold supports building with Jib
Jib Maven and Gradle locally
Configuration
To use Jib, add a jib
field to each artifact you specify in the
artifacts
part of the build
section. context
should be a path to
your Maven or Gradle project.
Note
Your project must be configured to use Jib already.The jib
type offers the following options:
Option | Description | Default |
---|---|---|
project |
selects which sub-project to build for multi-module builds. |
|
args |
additional build flags passed to the builder. | [] |
type |
the Jib builder type; normally determined automatically. Valid types are maven : for Maven. gradle : for Gradle. |
|
fromImage |
overrides the configured jib base image. |
|
Skaffold’s jib support chooses the underlying builder (Maven or Gradle)
based on the presence of standard build files in the artifact
's
context
directory:
- Maven:
pom.xml
, or.mvn
directory. - Gradle:
build.gradle
,gradle.properties
,settings.gradle
, or the Gradle wrapper script (gradlew
,gradlew.bat
, orgradlew.cmd
).
Artifact Dependency
You can define dependency on other artifacts using the requires
keyword. This can be useful to specify another artifact image as the fromImage
.
build:
artifacts:
- image: image1 # jib artifact
jib:
fromImage: image2
requires:
- image: image2
- image: image2 # base image artifact
Example
See the Skaffold-Jib demo project for an example.
Multi-Module Projects
Skaffold can be configured for multi-module projects too. A multi-module project has several modules (Maven terminology) or sub-projects (Gradle terminology) that each produce a separate container image.
Maven
To build a Maven multi-module project, first identify the sub-projects (also called modules in Maven) that should produce a container image. Then for each such sub-project:
- Create a Skaffold
artifact
in theskaffold.yaml
. - Set the
artifact
'scontext
field to the root project location. - Add a
jib
element and set itsproject
field to the sub-project’s:artifactId
,groupId:artifactId
, or the relative path to the sub-project within the project.
Updating from earlier versions
Skaffold had required Maven multi-module projects bind a Jibbuild
or dockerBuild
goal to the package phase. These bindings are
no longer required with Jib 1.4.0 and should be removed.
Gradle
To build a multi-module project with Gradle, first identify the sub-projects that should produce a container image. Then for each such sub-project:
- Create a Skaffold
artifact
in theskaffold.yaml
. - Set the
artifact
'scontext
field to the root project location. - Add a
jib
element and set itsproject
field to the sub-project’s name (the directory, by default).
Remotely with Google Cloud Build
Skaffold can build artifacts using Jib remotely on Google Cloud Build.
Configuration
To configure, add googleCloudBuild
to build
section to skaffold.yaml
.
The following options can optionally be configured:
Option | Description | Default |
---|---|---|
projectId |
ID of your Cloud Platform Project. If it is not provided, Skaffold will guess it from the image name. For example, given the artifact image name gcr.io/myproject/image , Skaffold will use the myproject GCP project. |
|
diskSizeGb |
disk size of the VM that runs the build. See Cloud Build Reference. |
|
machineType |
type of the VM that runs the build. See Cloud Build Reference. |
|
timeout |
amount of time (in seconds) that this build should be allowed to run. See Cloud Build Reference. |
|
logging |
specifies the logging mode. Valid modes are: LOGGING_UNSPECIFIED : The service determines the logging mode. LEGACY : Stackdriver logging and Cloud Storage logging are enabled (default). GCS_ONLY : Only Cloud Storage logging is enabled. See Cloud Build Reference. |
|
logStreamingOption |
specifies the behavior when writing build logs to Google Cloud Storage. Valid options are: STREAM_DEFAULT : Service may automatically determine build log streaming behavior. STREAM_ON : Build logs should be streamed to Google Cloud Storage. STREAM_OFF : Build logs should not be streamed to Google Cloud Storage; they will be written when the build is completed. See Cloud Build Reference. |
|
dockerImage |
image that runs a Docker build. See Cloud Builders. | gcr.io/cloud-builders/docker |
kanikoImage |
image that runs a Kaniko build. See Cloud Builders. | gcr.io/kaniko-project/executor |
mavenImage |
image that runs a Maven build. See Cloud Builders. | gcr.io/cloud-builders/mvn |
gradleImage |
image that runs a Gradle build. See Cloud Builders. | gcr.io/cloud-builders/gradle |
packImage |
image that runs a Cloud Native Buildpacks build. See Cloud Builders. | gcr.io/k8s-skaffold/pack |
concurrency |
how many artifacts can be built concurrently. 0 means “no-limit”. | 0 |
workerPool |
configures a pool of workers to run the build. |
|
region |
configures the region to run the build. If WorkerPool is configured, the region will be deduced from the WorkerPool configuration. If neither WorkerPool nor Region is configured, the build will be run in global(non-regional). See Cloud Build locations. |
|
Example
Following configuration instructs skaffold to build
gcr.io/k8s-skaffold/project1
with Google Cloud Build using Jib builder:
build:
artifacts:
- image: gcr.io/k8s-skaffold/project1
jib: {}
googleCloudBuild:
projectId: YOUR-GCP-PROJECT
Advanced usage
Additional arguments
The jib
build artifact supports an args
field to provide additional arguments to the Maven or Gradle command-line. For example, a Gradle user may choose to use:
artifacts:
- image: jib-gradle-image
jib:
args: [--no-daemon]
Using the custom
builder
Some users may have more complicated builds that may be better suited to using the custom
builder. For example, the jib
builder normally invokes the prepare-package
goal rather than package
as Jib packages the .class
files rather than package in the jar. But some plugins require the package
goal.
artifacts:
- image: jib-gradle-image
custom:
buildCommand: mvn -Dimage=$IMAGE package $(if [ $PUSH_IMAGE = true ]; then echo jib:build; else echo jib:dockerBuild; fi)
dependencies:
paths:
- src/**