User-provided service instances enable you to use services that are not available in the marketplace with their apps running on Cloud Foundry.
User-provided service instances can be used to deliver service credentials to an app, and/or to trigger streaming of app logs to a syslog compatible consumer. These two functions can be used alone or at the same time.
Note: The procedures in this topic use the Cloud Foundry Command Line Interface (cf CLI). You can also create user-provided service instances in Apps Manager from the Marketplace. To update existing user-provided service instances, navigate to the service instance page and select the Configuration tab.
Once created, user-provided service instances behave like service instances created through the marketplace; see Managing Service Instances and App Binding for details on listing, renaming, deleting, binding, and unbinding.
Create a user-provided service instance
The alias for cf create-user-provided-service is cf cups.
Deliver service credentials to an app
Suppose a developer obtains a URL, port, username, and password for communicating with an Oracle database managed outside of Cloud Foundry. The developer could manually create custom environment variables to configure their app with these credentials (of course you would never hard code these credentials in your app!).
User-provided service instances enable developers to configure their apps with these using the familiar App Binding operation and the same app runtime environment variable used by Cloud Foundry to automatically deliver credentials for marketplace services (VCAP_SERVICES).
cf cups SERVICE_INSTANCE -p '{"username":"admin","password":"pa55woRD"}'
To create a service instance in interactive mode, use the -p option with a comma-separated list of parameter names. The Cloud Foundry Command Line Interface (cf CLI) prompts you for each parameter value.
$ cf cups my-user-provided-route-service -p "host, port" host> rdb.local port> 5432 Creating user provided service my-user-provided-route-service in org my-org / space my-space as [email protected]... OK
Once the user-provided service instance is created, to deliver the credentials to one or more apps see App Binding.
Stream app logs to a service
User-provided service instances enable developers to stream app logs to a syslog compatible aggregation or analytics service that isn’t available in the marketplace. For more information about the syslog protocol see RFC 5424 and RFC 6587.
Important RFC-5424 is used to establish connections over HTTP/HTTPS. RFC-6587 is used for TCP based communication over syslog/syslog-tls drains.
Create the user-provided service instance, specifying the URL of the service with the -l option.
cf cups SERVICE_INSTANCE -l syslog://example.log-aggregator.com
To stream app logs to the service, bind the user-provided service instance to your app.
Proxy app requests to a route service
User-provided service instances enable developers to proxy app requests to route services for preprocessing. To create a user-provided service instance for a route service, specify the url for the route service using the -r option.
$ cf create-user-provided-service my-user-provided-route-service -r https://my-route-service.example.com Creating user provided service my-user-provided-route-service in org my-org / space my-space as [email protected]... OK
Important When creating the user-provided service, the route service url specified must be https.
To proxy requests to the user-provided route service, you must bind the service instance to the route. For more information, see Managing App Requests with Route Services.
Update a user-provided service instance
You can use cf update-user-provided-service to update the attributes of an instance of a user-provided service. New credentials overwrite old credentials, and parameters that are not provided are deleted.
The alias for update-user-provided-service is uups. Bound apps can access the new configuration after restart. You can use rolling restarts to avoid any app downtime. For more information, see Restart an App in Rolling App Deployments.
Important If you are rotating credentials, the old credentials must be active until the restart is finished.
