--- title: Frequently Asked Questions owner: Build Service Team --- ## How do Cloud Native Buildpacks (CNBs), kpack, and Tanzu Build Service overlap and differ? **CNBs** are build tools that adhere to the <a href="https://github.com/buildpacks/spec">CNB v3 Specification</a> and transform source code into an OCI compliant runnable image. The v3 specification, lifecycle, and local CLI (`pack`) are governed by the open source <a href="https://buildpacks.io">Cloud Native Buildpacks project.</a> <a href="https://github.com/pivotal/kpack">kpack</a> 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` | https://github.com/paketo-buildpacks/nodejs | | Paketo .NET Core | `paketo-buildpacks/dotnet-core` | https://github.com/paketo-buildpacks/dotnet-core | | Paketo Golang | `paketo-buildpacks/go` | https://github.com/paketo-buildpacks/go | | Paketo PHP | `paketo-buildpacks/php` | https://github.com/paketo-buildpacks/php | | Paketo HTTPD | `paketo-buildpacks/httpd` | https://github.com/paketo-buildpacks/httpd | | Paketo NGINX | `paketo-buildpacks/nginx` | https://github.com/paketo-buildpacks/nginx | | Paketo Procfile | `paketo-buildpacks/procfile` | https://github.com/paketo-buildpacks/procfile | Updated Buildpacks and new buildpacks will be available on [Tanzu Build Service Dependencies](https://network.pivotal.io/products/tbs-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](https://help.github.com/en/github/authenticating-to-github/adding-a-new-ssh-key-to-your-github-account) ``` kp secret create my-git-ssh-cred --git git@github.com --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 https://github.com --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 `buildservice.pivotal.io/defaultRepository` annotation on the `build-service-stack` Stack resource. 1. Re-run [`kp stack update`](managing-stack.html) with the most recent build image and run image from the [build-service-dependencies](https://network.pivotal.io/products/tbs-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. --- ## 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](installing.html#other-install), use the following to set the gcr credentials: registry_name="_json_key" 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