Frequently Asked Questions

Page last updated:

How do Cloud Native Buildpacks (CNBs), kpack, and Tanzu Build Service overlap and differ?

CNBs are build tools that adhere to the CNB v3 Specification and transform source code into an OCI compliant runnable image. The v3 specification, lifecycle, and local CLI (pack) are governed by the open source Cloud Native Buildpacks project.

kpack is a collection of open source resource controllers that together function as a Kubernetes native build service. The product provides a declarative image type that builds an image and schedules image rebuilds when dependencies of the image change. kpack is a platform implementation of CNBs in that it utilizes CNBs and the v3 lifecycle to execute image builds.

Tanzu Build Service is a commercial product owned and operated by VMware that utilizes kpack and CNBs. Build Service provides additional abstractions intended to ease the use of the above technologies in Enterprise settings. These abstractions are covered in detail throughout the documentation on this site. Additionally, customers of Build Service are entitled to support and VMware Tanzu buildpacks.

Why do I see two images in the image registry after a successful build?

By default Build Service will tag each built image twice. The first tag will be the configured image tag. The second tag will be a unique tag with the build number and build timestamp. The second tag is added to ensure that previous images are not deleted on registries that garbage collect untagged images.

How does TBS work in air gapped environments?

Build Service is shipped using a duffle bundle, which is composed of the kubernetes manifests and images required to successfully install Build Service. The relocate command ensure all the images can be relocated to airgapped registries, and by providing the credentials to the air-gapped registry when executing the install command, Build Service can then use that secret to pull images from said registry, hence working in air-gapped environments.

Which buildpacks does TBS support?

Tanzu Build Service ships with the following buildpacks:

Name ID Link
Tanzu Java tanzu-buildpacks/java N/A
Paketo NodeJS paketo-buildpacks/nodejs
Paketo .NET Core paketo-buildpacks/dotnet-core
Paketo Golang paketo-buildpacks/go
Paketo PHP paketo-buildpacks/php
Paketo HTTPD paketo-buildpacks/httpd
Paketo NGINX paketo-buildpacks/nginx
Paketo Procfile paketo-buildpacks/procfile

Updated Buildpacks and new buildpacks will be available on Tanzu Build Service Dependencies release page.

Why do I get an X509 error from Build Service when trying to create an image in my registry?

When interacting with a registry or a git repo that has been deployed using a self signed certificate, Build Service needs to be provided the certificate during install-time in the credentials.yaml file. Unfortunately, you will either need to target a registry that does not have self signed certificates and re-install Build Service to work with this registry.

How do I configure a secret to publish images to Dockerhub?

  1. Create a dockerhub secret with the kp cli:

    kp secret create my-dockerhub-creds --dockerhub DOCKERHUB-USERNAME

    Where DOCKERHUB-USERNAME is your dockerhub username You will be prompted for your dockerhub password

How can I configure an image to pull from a private GitHub repository?

  1. Create a github secret with the kp cli:

    Using a git ssh key

    kp secret create my-git-ssh-cred --git --git-ssh-key PATH-TO-GITHUB-PRIVATE-KEY

    Where PATH-TO-GITHUB-PRIVATE-KEY is the absolute local path to the github ssh private key

    Or with a basic auth github username and password

    kp secret create my-git-cred --git --git-user GITHUB-USERNAME

    Where GITHUB-USERNAME is your github username You will be prompted for your github password

Why do some builds fail with Error: could not read run image: *?

The run image must be publicly readable or readable with the registry credentials configured in a project/namespace.

To see where the build service run image is located run: kp stack status STACK-NAME.

To update the the location of the run image:

  1. Use kubectl to update the annotation on the build-service-stack Stack resource.
  2. Re-run kp stack update with the most recent build image and run image from the build-service-dependencies page.

Why don’t my image builds appear in my Harbor v1.X.X registry?

There is a known bug in Harbor that, at times, prevents the UI from showing images. If you are unable to see a recently built image in the Harbor UI, try pulling it using the docker CLI to verify that it exists.

How do I fix “unsupported status code 500” when creating a builder on my Harbor v2.X.X registry?

Some builders are very large and can overwhelm Harbor’s default database connection. You can remediate this issue by increasing the database.maxOpenConns setting in the helm values.yaml file. Increase this value from 100 to 300. The exact setting can be found here.

How do I configure credentials for using gcr as my installation registry?

You can use Google Container Registry for your Tanzu Build Service installation registry.

If you have trouble configuring the registry credentials for gcr when following the install docs, use the following to set the gcr credentials:

registry_password="$(cat /path/to/gcp/service/account/key.json)"
duffle install BUILD-SERVICE-INSTALLATION-NAME -c /tmp/credentials.yml  \
    --set kubernetes_env=CLUSTER-NAME \
    --set docker_registry=DOCKER-REGISTRY \
    --set docker_repository=DOCKER-REPOSITORY \
    --set registry_username="$registry_name" \
    --set registry_password="$registry_password" \
    --set custom_builder_image="BUILDER-IMAGE-TAG" \
    -f /tmp/build-service-${version}.tgz \
    -m /tmp/relocated.json