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 resoure 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 provideing 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:

  • Tanzu Java io.pivotal.java
  • Tanzu NodeJS io.pivotal.nodejs
  • .NET Core org.cloudfoundry.dotnet-core
  • Python org.cloudfoundry.python
  • Golang org.cloudfoundry.go
  • PHP org.cloudfoundry.php
  • HTTPD org.cloudfoundry.httpd
  • NGINX org.cloudfoundry.nginx

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.


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

Dockerhub requires the secret registry to be exactly: “https://index.docker.io/v1/”.

  1. Create a YAML file with these values:

    project: PROJECT-NAME
    repository: https://index.docker.io/v1/
    username: DOCKERHUB-USERNAME
    password: DOCKERHUB-PASSWORD
    

    Where:

    • PROJECT-NAME is the name of your Build Service project/namespace.
    • DOCKERHUB-USERNAME is your dockerhub username.
    • DOCKERHUB-PASSWORD is your dockerhub password.
  2. Create the secret by running:

    pb secrets registry apply -f SECRET-YAML-FILE
    

    Where SECRET-YAML-FILE is the YAML file you created in the previous step.


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

To configure an image to pull from a private GitHub repository:

  1. Create a personal access token by following the procedure in Creating a personal access token for the command line in the GitHub documentation.

  2. Create a YAML file with these values:

    project: PROJECT-NAME
    repository: GITHUB-REPOSITORY-URL
    username: PERSONAL-ACCESS-TOKEN
    password: PASSWORD
    

    Where:

    • PROJECT-NAME is the name of your Build Service project/namespace.
    • GITHUB-REPOSITORY-URL is the URL of your GitHub repository.
    • PERSONAL-ACCESS-TOKEN is the personal access token you generated in the previous step.
    • PASSWORD is the password for your GitHub repository.
  3. Create the secret by running:

    pb secrets git apply -f SECRET-YAML-FILE
    

    Where SECRET-YAML-FILE is the YAML file you created in the previous step.


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: pb stack status.

To update the the location of the run image:

  1. Use kubectl to update the buildservice.pivotal.io/defaultRepository annotation on the build-service-stack Stack resource.
  2. Re-run pb 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 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.