Managing Stores

--- title: Managing Stores owner: Build Service Team --- 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](https://network.pivotal.io/products/tbs-dependencies/) page. In addition to supported Tanzu and Paketo buildpacks, custom buildpackages can be uploaded to Build Service stores. ## <a id='buildpacks-buildpackages'></a> Creating Buildpacks and Buildpackages Documentation for creating buildpacks is available [here](https://buildpacks.io/docs/buildpack-author-guide/create-a-buildpack/). Documentation for creating buildpackages is available [here](https://buildpacks.io/docs/buildpack-author-guide/package-a-buildpack/). Note: Only Build Service Admins can perform store commands. ## <a id='list-stores'></a> Listing Stores Users can view the existing stores with: kp store list ## <a id='create-store'></a> Creating a Store Tanzu Build Service ships with a `default` store containing all of the supported buildpacks. Users can create additional stores with: kp store create <store-name> <buildpackage-1> <buildpackage-2> --default-repository <image-repository> Where `<image-repository>` is the Docker repository where the buildpackage images will be stored. This can be set to the same value used during installation for the `docker_repository` during the `duffle` install described in the [install docs](installing.html#other-install). Note: The user must have read access to the source Docker registry and write access to the registry used for the <code>default-repository</code> on the local machine. ## <a id='add-buildpackages-to-store'></a> Adding Buildpackages to a Store Users can add multiple buildpackages at a time from a Docker registry or from a file on the local machine: * If using a Docker registry: ``` kp store add <store-name> <buildpackage-1> <buildpackage-2> ... ``` Note: The user must have read access to the source Docker registry and write access to build service registry on the local machine. * If using local stack images created with `docker save`: ``` kp store add <store-name> <path-to-buildpackage-1>.tar <path-to-buildpackage-2>.tar ... --local ``` Note: At this time <code>kp</code> does not support the <code>.cnb</code> buildpackage format ## <a id='remove-buildpackages-from-store'></a> Removing Buildpackages from a Store Users can remove a buildpackage from a store: kp store remove <store-name> <buildpackage> Note: Buildpackages must be removed from stores by full image reference. The <code><buildpackage></code> args should include their digests and will look like <code>registry.io/repository@sha256:<sha256></code>. ## <a id='show-buildpackages-in-store'></a> Store Status Users can use the `kp` cli to get details about a store including buildpackages and their buildpacks, as well as meta-buildpacks. [Meta-buildpacks](https://buildpacks.io/docs/concepts/components/buildpack/#meta-buildpack) are buildpacks that indicate the order that other buildpacks run: To view the buildpackages in a store: kp store status <store-name> To view buildpackages & their individual buildpacks as well as display the order of meta-buildpacks: kp store status <store-name> --verbose ## <a id='kpack-resources'></a> Corresponding kpack Resource All Build Service builders utilize cluster scoped [Store Resources](https://github.com/pivotal/kpack/blob/master/docs/custombuilders.md#store).