Builders

This page discusses how to set up Skaffold to use the tool of your choice to build Docker images.

Skaffold supports the following tools to build your image:

The build section in the Skaffold configuration file, skaffold.yaml, controls how artifacts are built. To use a specific tool for building artifacts, add the value representing the tool and options for using that tool to the build section.

For a detailed discussion on Skaffold configuration, see Skaffold Concepts and skaffold.yaml References.

Dockerfile locally with Docker

If you have Docker Desktop installed, Skaffold can be configured to build artifacts with the local Docker daemon.

By default, Skaffold connects to the local Docker daemon using Docker Engine APIs. Skaffold can, however, be asked to use the command-line interface instead. Additionally, Skaffold offers the option to build artifacts with BuildKit.

After the artifacts are successfully built, Docker images will be pushed to the remote registry. You can choose to skip this step.

Configuration

To use the local Docker daemon, add build type local to the build section of skaffold.yaml. The following options can optionally be configured:

Option Description Default
push should images be pushed to a registry. If not specified, images are pushed only if the current Kubernetes context connects to a remote cluster.
useDockerCLI use docker command-line interface instead of Docker Engine APIs. false
useBuildkit use BuildKit to build Docker images. false

Example

The following build section instructs Skaffold to build a Docker image gcr.io/k8s-skaffold/example with the local Docker daemon:

build:
  artifacts:
  - image: gcr.io/k8s-skaffold/example
  local: {}

Which is equivalent to:

build:
  artifacts:
  - image: gcr.io/k8s-skaffold/example
  local:
    useDockerCLI: false
    useBuildkit: false

Dockerfile remotely with Google Cloud Build

Google Cloud Build is a Google Cloud Platform service that executes your builds using Google infrastructure. To get started with Google Build, see Cloud Build Quickstart.

Skaffold can automatically connect to Cloud Build, and run your builds with it. After Cloud Build finishes building your artifacts, they will be saved to the specified remote registry, such as Google Container Registry.

Configuration

To use Cloud Build, add build type googleCloudBuild to the build section of 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.
dockerImage image that runs a Docker build. See Cloud Builders. gcr.io/cloud-builders/docker
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

Example

The following build section, instructs Skaffold to build a Docker image gcr.io/k8s-skaffold/example with Google Cloud Build:

build:
  artifacts:
  - image: gcr.io/k8s-skaffold/example
  googleCloudBuild:
    projectId: YOUR-GCP-PROJECT

Dockerfile in-cluster with Kaniko

Kaniko is a Google-developed open-source tool for building images from a Dockerfile inside a container or Kubernetes cluster. Kaniko enables building container images in environments that cannot easily or securely run a Docker daemon.

Skaffold can help build artifacts in a Kubernetes cluster using the Kaniko image; after the artifacts are built, kaniko can push them to remote registries.

Configuration

To use Kaniko, add build type kaniko to the build section of skaffold.yaml. The following options can optionally be configured:

Option Description

The buildContext can be either:

Option Description
gcsBucket CGS bucket to which sources are uploaded. Kaniko will need access to that bucket to download the sources.
localDir configures how Kaniko mounts sources directly via an emptyDir volume.

Example

The following build section, instructs Skaffold to build a Docker image gcr.io/k8s-skaffold/example with Kaniko:

build:
  artifacts:
    - image: gcr.io/k8s-skaffold/example
      kaniko:
        buildContext:
          gcsBucket: YOUR-BUCKET
  cluster:
    pullSecretName: YOUR-PULL-SECRET-NAME

Jib Maven and Gradle locally

Jib is a set of plugins for Maven and Gradle for building optimized Docker and OCI 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.

Configuration

To use Jib, add a jibMaven or jibGradle 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.

The jibMaven type offers the following options:

Option Description Default
module selects which Maven module to build, for a multi module project.
profile selects which Maven profile to activate.
args additional build flags passed to Maven. []

The jibGradle type offers the following options:

Option Description Default
project selects which Gradle project to build.
args additional build flags passed to Gradle. []

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 multi-module project with Maven, specify each module as a separate Skaffold artifact. For each artifact, add a jibMaven field with a module field specifying either the module’s :artifactId, groupId:artifactId, or the relative path to the module within the project. Each artifact’s context field should point to the root project location.

Building multi-module projects with Skaffold-Jib has one additional requirement: a Jib goal must be explicitly bound to the package phase for each specific module that produces a container image.

Gradle

To build a multi-module project with Gradle, specify each sub-project as a separate Skaffold artifact. For each artifact, add a jibGradle field with a project field containing the sub-project’s name (the directory, by default). Each artifact’s context field should point to the root project location.

Jib Maven and Gradle remotely with Google Cloud Build

//TODO(#1299)

Bazel locally

Bazel is a fast, scalable, multi-language, and extensible build system.

Skaffold can help build artifacts using Bazel; after Bazel finishes building container images, they will be loaded into the local Docker daemon.

Configuration

To use Bazel, bazel field to each artifact you specify in the artifacts part of the build section, and use the build type local. context should be a path containing the bazel files (WORKSPACE and BUILD). The following options can optionally be configured:

Option Description Default
target Required bazel build target to run.
args additional args to pass to bazel build. []

Example

The following build section instructs Skaffold to build a Docker image gcr.io/k8s-skaffold/example with Bazel:

build:
  artifacts:
  - image: gcr.io/k8s-skaffold/example
    bazel:
      target: //:example.tar