How Tiles Work
Page last updated:
This topic describes how product tiles work in Pivotal Platform.
Product tiles make it easy for cloud operators to offer new and upgraded software services to developers in a Pivotal Platform deployment. Pivotal Network distributes these tiles as zipped code directories, with filename extension
.pivotal, that contain or point to all of the software elements that perform the tile’s functions.
This topic explains what each functional element of a tile does and how you create or specify it as input to the Tile Generator tool that creates
.pivotal files. For more information about the Tile Generator, see Tile Generator.
This topic also describes the typical structure of a tile directory. This is useful information for modifying generated tiles or legacy tiles that were created without the Tile Generator.
Pivotal Platform service tiles perform multiple functions that streamline the use of software services on Pivotal Platform, including:
Deploy a service broker that interfaces between the Cloud Controller, Pivotal Platform’s main executive component, and the service. For more information, see Service Broker.
Publish a catalog of available service plans to the Services Marketplace. For more information, see Catalog.
Define an interface for configuring service properties in Ops Manager. For more information, see Configuration.
Generate a BOSH manifest for deploying instances of the service, populating it with both user-configured and fixed properties. For more information, see Fixed Properties.
Run BOSH errands: deploy errands that set Pivotal Platform up to run the service when an operator first deploys the service, and delete errands that clean up when an operator deletes the service. For more information, see Errands.
Define dependencies for the tile, to prevent Ops Manager from installing the service when its dependencies are missing. For more information, see Dependencies.
Support one-click installation and upgrading from previous versions. For more information, see Update Rules.
These functions are described in more detail below.
Service brokers integrate services with Pivotal Platform by providing an API for the Cloud Controller to create service instances, bind them to apps, and perform other operations. For more information about requirements for this API, see Service Broker API v2.10.
Each service tile acts as a wrapper for a service broker. Installing the tile creates its service broker, registers it with the Cloud Controller, and publishes the service plans that the broker offers. For more information, see Catalog.
You can write a service broker in any language, and it can run anywhere, inside your Pivotal Platform installation or external. For sample code in Ruby, Java, and Go, see Example Service Brokers.
Specify the service broker for a tile in the tile directory’s
tile.yml file, as a package with
type: set to
external-broker type requires a
uri value, for the service broker location. For more information, see Packages.
Service brokers include catalog metadata that list their service plans. This information publishes to the Marketplace that app developers use to browse and select services.
Developers on either Pivotal Platform or open-source Cloud Foundry see a plain-text version of the Marketplace by running
cf marketplace. But Pivotal Platform also features a graphical Marketplace, and Pivotal Platform service brokers support this Marketplace with additional catalog metadata fields for display names, logo images, and links to more information and documentation.
Define this catalog metadata for your service by writing your service broker to return the API calls listed in the Service Metadata section of Open Service Broker API Profile (v2.15) in the Open Service Broker API repository on GitHub.
In the Ops Manager Installation Dashboard, service tiles present a form-based interface that cloud operators use to configure the service. These configured properties become part of the BOSH manifest that Pivotal Platform uses to deploy instances of the service.
You define this configuration interface in the
forms: section of the
tile.yml configuration file that you pass to the Tile Generator. Each named form element defines a configuration pane accessible under the tile’s Settings tab.
A left-side menu lists all configuration panes and indicates with check marks which ones have been configured. The menu lists service-specific panes, defined by the tile developer, between system-level panes like Assign AZs and Networks and Resource Config that all Pivotal Platform products and services use.
Each form, or configuration pane, has
label for the menu text, a
description to appear up top, and
property_inputs that define the configuration fields themselves. To construct your
forms, see Property and Template References.
For each property, you can combine specifications for
constraints. For more information, see the Form Properties and Property Blueprints sections of the Property and Template References topic.
Note: In the tile installer
.yml that Tile Generator creates, form properties appear in two locations: a
form_types section that defines the contents and layout of the configuration interface, and a
property_blueprints section that defines the corresponding field value types and constraints.
In the Ops Manager Installation Dashboard, your service tile bears an identifying label, description, and logo icon. Specify these at the top of your
tile.yml configuration file as
icon_file. The value of
icon_file should be the name of a 128×128 pixel PNG image.
A tile also writes fixed, unconfigurable properties into the BOSH manifest that it creates. You specify these properties in your
tile.yml configuration file using double parentheses expressions format. For more information, see the Double Parenthesis Expressions section of the Property and Template References topic.
Include credentials to pass into a BOSH manifest as
salted_credentials in your
tile.yml file. But you do not need to include credentials that already exist in other tiles, such as Pivotal Platform. BOSH automatically generates these for any packages that require them.
Tile Generator automatically generates
delete lifecycle errands for packages that deploy to Pivotal Platform. These errand scripts deploy the service to Pivotal Platform and publish its plans in the Marketplace, and remove the service from Pivotal Platform and the Marketplace.
You can also define additional
pre_delete errand scripts in
tile.yml that prepare Pivotal Platform to host the service or clean up before deleting it. You can configure these errands to run on their own dedicated VMs or co-locate them on existing errand VMs.
docker-bosh packages, which run jobs directly on BOSH rather than on the Pivotal Platform layer, you need to include
pre_delete errands with their package definitions in
tile.yml. Label them as lifecycle errands using
lifecycle: errand and either
post_deploy: true or
Tile Generator writes the
bosh-release errands into the main BOSH release that it creates for the service, and adds
docker-bosh errands into a separate Docker BOSH release that the main release depends on.
Include product dependencies under
requires_product_versions at the top of your
A mature tile may contain several of these
.js files, from previous versions and the current one, to enable tile updates to automatically chain together in sequence.
You can add custom update code in the
Tile directories contain the following components, which include each other as shown:
- Service source code
- Service broker
- Language-specific buildpack(s)
- Errands (service start and stop scripts)
- BOSH manifest (deployment properties for service)
Tile manifest template (adds properties into BOSH manifest)
- Configuration forms and properties
- Catalog metadata (for the Marketplace)
The three required top-level subdirectories in a
.pivotal tile directory are:
metadata: High-level information for configuring and publishing your service.
migrations: Rules that govern tile upgrades.
releases: The BOSH releases that deploy your service.
The tile manifest template defines these subdirectory locations, so they can reside anywhere in the directory, but the typical structure looks like this:
. ├── example-product │ ├── metadata │ │ └── example-product.yml │ ├── migrations │ │ └── v1 │ │ ├── 201512301616_convert_14_transmogrifier_rules.js │ │ ├── 201512301631_convert_15_16_transmogrifier_rules.js │ │ └── 201611060205_example_migration.js │ └── releases │ └── example-release-18.tgz
The entire tile directory is a ZIP file, with the
.zip extension renamed to
$ file TILE-NAME-TILE-VERSION.pivotal p-example-product-1.0.0.pivotal: Zip archive data, at least v1.0 to extract
TILE-NAMEis the name of the tile.
TILE-VERSIONis the version of the tile.
You can use any ZIP utility to create a
.pivotal file. Ensure that the top-level subfolders as seen above in the
example-product folder remain.
Within the tile’s
releases subfolder, the BOSH release exists as a gzipped tarfile.
$ cd example-product $ zip -r example-product.pivotal metadata/ migrations/ releases/ $ unzip -l example-product.pivotal Archive: example-product.pivotal Length Date Time Name -------- ---- ---- ---- 0 08-09-16 16:10 metadata/ 89458 08-09-16 16:10 metadata/example-product.yml 0 07-08-16 09:32 migrations/ 0 07-08-16 09:32 migrations/v1/ 423 07-08-16 09:32 migrations/v1/201512301616_convert_14_transmogrifier_rules.js 1228 07-08-16 09:32 migrations/v1/201512301631_convert_15_16_transmogrifier_rules.js 582 07-08-16 09:32 migrations/v1/201611060205_example_migration.js 0 08-09-16 16:11 releases/ 0 07-12-16 17:19 releases/example-release-18.tgz
Tile developers typically develop and archive their code on GitHub, and their Concourse build pipeline pulls from GitHub to perform continuous integration.
Tile Generator does not dictate any directory structure for a GitHub repository, but by convention your tile repository might look like this:
/tile.yml /src # source code for all components deployed by the tile /resources # other resources, such as icon images and imported Docker images or bosh releases /release # generated bosh release(s) /product # generated tile
Pivotal Platform services typically require multiple component job processes to run concurrently, such as a main app, a helper app, and a service broker. They also require buildpacks that run as one-time compilation tasks. Services also require components such as external brokers or storage, which do not run as jobs, but nevertheless need to remain available.
tile yml file that you pass to Tile Generator defines these service components it its
packages: section. Each package has a name and a package type. The list of possible package types to pass to Tile Generator is in the Tile Generator code on GitHub. It includes:
app: Pushed to Pivotal Platform
docker-app: Pushed to Pivotal Platform (image will not be embedded so requires Docker registry access).
app-broker: Pushed to Pivotal Platform and registered as a broker.
docker-app-broker: Pushed to Pivotal Platform and registered as a broker. Image is not embedded, so this package type requires Docker registry access.
external-broker: Registered as a broker.
buildpack: Installed with
cf create-buildpack. Runs as a one-time task rather than a long-running process.
docker-bosh: Describes a collection of Docker images that embed in the tile and run on BOSH-managed VMs, not Pivotal Platform.
bosh-release: A pre-existing BOSH release wrapped in a tile, to run on BOSH-managed VMs, not Pivotal Platform. Requires you to describe all jobs (long-running processes and errands).
Packages typically contain a single process, but can include more than one, packaged to run in the same location.
Where packaged processes run depends on their package type, as follows:
cf pushto run processes in containers on a Diego Cell.
bosh-releasepackages run their processes on VMs in the underlying BOSH layer.
buildpackpackages run one-time tasks, not long-running processes, on Diego Cells.
The service tile’s Resource Config pane allows the operator to configure resources individually for each package. This pane also allows operators to provision resources for VMs that handle one-time tasks, with the