Page last updated:
This documentation is intended for end users of Cloud Foundry and covers provisioning of service instances and integrating them with applications that have been pushed to Cloud Foundry. If you are interested in building services for Cloud Foundry and making them available to end users, see the Custom Services documentation.
Cloud Foundry offers a marketplace of services, from which users can provision reserved resources on-demand. Examples of resources services provide include databases on a shared or dedicated server, or accounts on a SaaS application. These resources are known as service instances and the systems that deliver and operate these resources are known as Services. Think of a service as a factory that delivers service instances.
For documentation on provisioning service instances and other lifecycle operations, see Managing Service Instances.
Note: For a service to be available in the marketplace, it must be integrated with Cloud Foundry by way of APIs. If you are interested in building services for Cloud Foundry and making them available to end users, see the Custom Services documentation.
Cloud Foundry enables users to leverage services that are not available in the marketplace using a feature called User-Provided Service Instances (UPSI).
Cloud Foundry enables users to provision credentials needed to interface with a service instance. You can use application binding to automatically deliver these credentials to your Cloud Foundry app. For external and local clients, you can use service keys to generate credentials to communicate directly with a service instance.
Service instance credentials can be delivered automatically to applications running on Cloud Foundry in an environment variable. For more information, see Delivering Service Credentials to an Application.
For details on binding to a specific application development framework, refer to the Service Binding section in the documentation for your framework’s buildpack.
Credentials managed manually are known as service keys. Use service keys when you want a set of credentials for use by clients other than the application in the same space. For instance, you can use service keys to connect to a service instance from a local client, or from an application in another space, or even from outside of Cloud Foundry.
For more information about creating a user-provided service instance with service keys, see the User-Provided Service Instances topic. For more information about service keys, see the Managing Service Keys topic.
Note: Not all services support service keys. Some services support credentials through application binding only.
To allow an app to communicate with a service external to PAS, you may need to configure the service to accept connections from your app based on its outbound IP address.
In your external service configuration, you must do one of the following:
- Whitelist the entire IP range for the Diego cell where the app is deployed.
- Derive the app IP address from its DNS name using a command-line tool such as
nslookup. In your external service configuration, whitelist the IP address or range of the app instance.
To learn how your application logs can be streamed to third-party log management services, see Streaming Application Logs to Log Management Services.
User-provided service instances can be used to drain applications logs to a service not available in the marketplace. This is also known as setting up a syslog drain. We’ve documented instructions for a few providers in the Service-Specific Instructions for Streaming Application Logs topic.
To learn how marketplace services (and user-provided service instances) can be used to perform preprocessing on application requests, see Manage Application Requests with Route Services.
If your app relies on a relational database, you must apply schema changes periodically. To perform database schema migrations on Cloud Foundry-managed services, run a database migration task with the Cloud Foundry Command Line Interface (cf CLI) tool.
For more information about running cf CLI tasks, see Running Tasks.
For information about migrating internal Pivotal Cloud Foundry system databases from MariaDB to Percona, see Migrating to Internal Percona MySQL.
Note: To run tasks with the cf CLI, you must install cf CLI v6.23.0 or later. See the Installing the cf CLI topic for information about downloading, installing, and uninstalling the cf CLI.
To perform a database schema migration with the cf CLI, do the following:
Run the following command to push the app:
$ cf push APP-NAME
APP-NAMEis the name of the app.
Note: To run a task without starting the app, push the app with
cf push -i 0and then run the task. You can run the app later by scaling up its instance count.
Run the following command to perform a database schema migration as a task on the app:
$ cf run-task APP-NAME "bin/rails db:migrate" --name TASK-NAME Creating task for app APP-NAME in org jdoe-org / space development as email@example.com... OK Task 1 has been submitted successfully for execution.
APP-NAMEis the name of the app.
TASK-NAMEis the name of the task.