How Pivotal Platform and Pivotal Platform Services Work
Page last updated:
There are many ways to integrate services with Pivotal Platform. The right one for each service depends on what the service does, and how customer applications consume it. To determine the best way to integrate your service, you’ll need a good understanding of Pivotal Platform concepts like applications, containers, services, brokers, and buildpacks.
This page provides a collection of links to documentation for the most relevant concepts. If you prefer to learn through guided training, ask us about available training options.
For general overview of Pivotal Platform, and the various ways to interact with it, use the following links:
- Cloud Foundry Subsystems provides high-level descriptions of internal functions performed by different Pivotal Platform components.
- Cloud Foundry Command Line Interface (cf CLI) links to topics that explain how to direct Pivotal Platform deployment from your local command line.
- Pivotal Ops Manager describes the Ops Manager and Installation Dashboard interfaces, where cloud operators see, install, configure, and deploy service tiles.
- Pivotal Apps Manager describes the Apps Manager interface, where app developers create and configure service instances and bind them to their apps.
Cloud Foundry is primarily a cloud native application platform. To understand how to integrate your services with Cloud Foundry, you should understand how your customers are using the platform to develop, deploy, and operate their applications.
- Developer Guide explains how to push an app to run on Pivotal Platform and enable it to use services.
- Logging and Monitoring describes how Pivotal Platform aggregates and streams logs and metrics from the apps it hosts and from internal system components.
Most value-add integrations are done by exposing your software to customer applications as services. To understand the service concepts, and what a service integration looks like, read the following documentation:
- Services Overview explains how developers provision and use existing services in their apps.
- Cloud Foundry Service Brokers and Pivotal Platform Tiles briefly describes the two main elements of Pivotal Platform service integration: the service broker API, which connects the service to Pivotal Platform internally by taking commands from the Cloud Controller; and the tile, a packaged interface that cloud operators use to install and configure a service within Pivotal Platform.
- Custom Services explains how service authors package their service as a Managed Service that is available for use by Pivotal Platform operators and developers, and which runs locally on Pivotal Platform rather than running remotely.
When application code is deployed to Cloud Foundry, it is processed by a language-specific buildpack. Language buildpacks provide a convenient integration hook for any service that needs to inspect or embellish application code. Supplying buildpacks also provides a language-agnostic way to inject your code into the application container image.
- Application Staging Process explains how Pivotal Platform packages and deploys apps in containers with buildpacks so that they can run on multiple VMs interchangeably.
- Language Buildpacks describes the language-specific buildpacks support Pivotal Platform apps.
- Custom Buildpacks describes how to use supply buildpacks to add dependencies or code without having to change (multiple) language-sepcific buildpacks.
Some integrations depend on the ability to inject code into the application container.
We refer to these injected components as “container-embedded agents”.
Buildpacks provide a mechanism to inject components into the application container image, and the
.profile.d directory provides a way to start agents before or alongside the customer application.
Cloud Foundry’s logging system, Loggregator, has a feature named firehose. The firehose includes the combined stream of logs from all apps, plus metrics data from Cloud Foundry components, and is intended to be used by operators and administrators.
A nozzle takes this data and forwards it to an external logging and/or metrics solution.