Tanzu Build Service uses standard Kubernetes secrets to store credentials for registries and git based repositories. These credentials include the following: Git credentials added to namespaces Registry credentials added to namespaces Registry credentials provided during installation Encrypting Secrets at Rest Because Tanzu Build Service uses standard Kubernetes secrets, administrators may configure the cluster to encrypt secrets at rest. For more information, see the following link: https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ Using Synced Secrets to access Cluster Builders

Shipyard is a managed Build Service environment that VMware teams can use to build their applications. It also available for testing, demos and experimentation with Build Service. Note: Please don’t share this environment or your access creds externally because hosted build service is not covered by a EULA or export control. To access, follow these steps: Accessing shipyard gcloud auth login gcloud container clusters get-credentials shipyard --region us-central1-c --project cf-build-service-prod Getting started

This topic describes how to install and configure Tanzu Build Service. Overview Build Service can be installed on any Kubernetes cluster (v1.16 or later) including TKGI (formerly PKS), GKE and AKS clusters. The installation instructions are divided between the TKGI installation, which uses OpenID Connect (OIDC) for authentication, and the install on other hosted Kubernetes clusters. Prerequisites Before you install Build Service, you must: Have access to the Kubernetes cluster satisfying the minimum required permissions.

A ClusterStack is a cluster scoped resource that provides the build and run images for the Cloud Native Buildpack stack that will be used in a Builder. The Tanzu Network Build Service Dependencies page provides the following stacks and their updates. Name ID tiny io.paketo.stacks.tiny

[Projects Operator for Kubernetes] (Need a link) is a separate open source project from VMWare that works with Tanzu Build Service. A project is a resource that simplifies kubernetes namespaces and RBAC to provide multi-tenancy for images, secrets, and builders. The following procedures describe how to manage projects and project members with Build Service. Installing Projects Operator for Kubernetes Tanzu Build Service installs a ClusterRole on the cluster named build-service-user-role. To allow Projects Operator to integrate with Build Service, provide the ClusterRole build-service-user-role as the CLUSTER_ROLE_REF to use during Projects Operator installation. Creating a Project

Visit the Build Service dependencies tile on PivNet. Build Service can be updated with those artifacts both directly against the PivNet registry or via the downloaded versions of those images. Accessing the Tanzu Net Registry The Tanzu Net registry (registry.pivotal.io) contains the stack and buildpack images needed to keep Tanzu Build Service up to date to keep applications secure. Once you log in to the Tanzu Net registry, you can use the kp CLI to update dependencies. You will need the docker CLI to authenticate with the Tanzu Net registry. To log in to the Tanzu Net registry, run: docker login registry.pivotal.io

Managing Secrets kubernetes secrets are utilized to manage credentials within Tanzu Build Service. Registry secret is needed to publish images to a registry Git secret is needed to utilize source code stored in a private git repository Secrets are namespaced and therefore only available to image configurations within the same namespace. Secret management is made easier with the kp cli. $ kp secret Secret Commands

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.

Images Images provide a configuration for build service to build and maintain a docker image utilizing Tanzu, Paketo, and custom Cloud Native Buildpacks. Build Service will monitor the inputs to the image configuration to rebuild the image when the underlying source or buildpacks have changed. The following procedures describe how to create and manage images in Build Service with the kp cli. Creating Images Prerequisites:

Install kubectl apply -f release-0.0.9.yaml What's New? CustomBuilders utilize lifecycle v0.8.0 which fixes an issue with Harbor 2. Image and Builds support Service Bindings. Improved "Prepare" logging with docker credential setup. Images will default with a 2Gi cacheSize if a default storage class is defined. All Images in this release were built with kpack itself.

A Custom Builder is a Tanzu Build Service resource used to manage Cloud Native Buildpack builders. There are two types of Custom Builders: Custom Cluster Builders: Cluster-scoped Builders Custom Builders: Namespace-scoped Builders Note: Only Build Service Admins can manage Custom Cluster Builders. Creating a Custom Builder To create a Custom Builder:

A Store provides a collection of buildpacks that can be utilized by Builders. Buildpacks are distributed and added to a store in buildpackages which are docker images containing one or more buildpacks. Build Service ships with curated collection of Tanzu buildpacks for Java, and Paketo buildpacks for Nodejs, go, PHP, nginx, httpd, and .NET Core. It is important to keep these buildpacks up-to-date. Updates to these buildpacks are provided on the Tanzu Network Build Service Dependency page. In addition to supported Tanzu and Paketo buildpacks, custom buildpackages can be uploaded to Build Service stores. Creating Buildpacks and Buildpackages Documentation for creating buildpacks is available here. Documentation for creating buildpackages is available here.

After you configure and install Build Service, you can use the kp CLI to interact with your Build Service installation. For more information, see Installing Tanzu Build Service. The kp cli uses the local KUBECONFIG utilized by kubectl. All operations will be performed on the current context's namepace. To use your Build Service installation, gain kubeconfig access to the Kubernetes Cluster that has the Build Service installed. For example, if you are using PKS:

Use a kpack image in a concourse pipeline naturally. Installing The recommended method to use this resource is with resource_types in the pipeline config as follows: --- resource_types: - name: kpack-image type: registry-image source:

title: Landing Page owner: Build Service Team This topic provides an overview of Tanzu Build Service (Beta). Note: To request early access to this Tanzu Build Service beta release, contact Pivotal. Warning: This release of Tanzu Build Service is not intended for use in a production environment. Features are subject to change without notice in future releases. Overview Tanzu Build Service uses the open-source Cloud Native Buildpacks project to turn app source code into container images. Build Service executes reproducible builds that align with modern container standards, and additionally keep the images up-to date. It does so by leveraging kubernetes infrastructure with kpack, a Cloud Native Bulidpacks Platform, to orchestrate the image lifecycle.

Using Tanzu Build Service Without Projects Tanzu Build Service projects are a resource that simplifies kubernetes namespaces and RBAC to provide multitenancy for images, secrets, and builders. Projects are optional if users don't need to multitentancy or if they prefer to manage multitenacy via alternative mechanisms. Using the pb cli The pb cli can work with existing namespaces by targeting them as projects. Get kubeconfig access to the Kubernetes cluster that has the Build Service installated.

Using Build Service This topic describes how to manage images, builds, secrets, builders, the stack, the store, and projects with Build Service. See the following topics: Accessing Build Service Managing the Stack