User provided services in CloudFoundry

This post builds on the discussion of Managed Services in CloudFoundry and covers the first of the two methods for using unmanaged services in CloudFoundry. It makes use of the Python echo service and Python service broker API implementation used previously.

Manually provision the service

This method assumes that an existing service has been provisioned outside of CloudFoundry. An instance of the echo service can be manually provisioned using cURL using the following commands. In this example, a new instance is provisioned with the id user-service-instance and bound to an app with id someapp. The new instance and binding is then confirmed to work by echoing a message.

vagrant@vagrant-ubuntu-trusty-64:~$ curl -X PUT http://echo-service.10.244.0.34.xip.io/echo/user-service-instance -w "\n"
{"instance_id": "user-service-instance", "state": "provision_success", "dashboard_url": "http://localhost:8090/dashboard/user-service-instance"}
vagrant@vagrant-ubuntu-trusty-64:~$ curl -X PUT http://echo-service.10.244.0.34.xip.io/echo/user-service-instance/someapp -w "\n"
{"state": "bind_success", "id": "user-service-instance", "app": "someapp"}
vagrant@vagrant-ubuntu-trusty-64:~$ curl -X POST http://echo-service.10.244.0.34.xip.io/echo/user-service-instance/someapp -H "Content-Type: application/json" -d '{"message": "Hello Test"}' -w "\n"
{"response": "Hello Test"}

The URI that should be provided to an application is

http://echo-service.10.244.0.34.xip.io/echo/user-service-instance/someapp

Add the service to CloudFoundry

The service can now be manually added to CloudFoundry as a user provided service. The CloudFoundry documentation suggests a predefined structure for the service parameters, but freeform JSON can be provided.

vagrant@vagrant-ubuntu-trusty-64:~$ cf cups user-echo-service -p '{"uri": "http://echo-service.10.244.0.34.xip.io/echo/user-service-instance/someapp"}'
Creating user provided service user-echo-service in org myorg / space mydept as admin...
OK
vagrant@vagrant-ubuntu-trusty-64:~$ cf services
Getting services in org myorg / space mydept as admin...
OK
 
name                service         plan    bound apps
test-echo-service   Echo Service    large   echo-php
user-echo-service   user-provided

The service is now available and can be bound to any existing app. Binding the user-provided service to an app will cause CloudFoundry to inject service details into each app instance. The next command assumes the existence of an app echo-php. The app must be restaged to enable environment injection.

vagrant@vagrant-ubuntu-trusty-64:~$ cf bind-service echo-php user-echo-service
Binding service user-echo-service to app echo-php in org myorg / space mydept as admin...
OK
TIP: Use 'cf restage' to ensure your env variable changes take effect
vagrant@vagrant-ubuntu-trusty-64:~$ cf restage echo-php
Restaging app echo-php in org myorg / space mydept as admin...
-----> Downloaded app package (4.0K)
-----> Downloaded app buildpack cache (4.0K)
-------> Buildpack version 1.0.2
Use locally cached dependencies where possible
 !     WARNING:        No composer.json found.
       Using index.php to declare PHP applications is considered legacy
       functionality and may lead to unexpected behavior.
       See https://devcenter.heroku.com/categories/php
-----> Setting up runtime environment...
       - PHP 5.5.12
       - Apache 2.4.9
       - Nginx 1.4.6
-----> Installing PHP extensions:
       - opcache (automatic; bundled, using 'ext-opcache.ini')
-----> Installing dependencies...
       Composer version ac497feabaa0d247c441178b7b4aaa4c61b07399 2014-06-10 14:13:12
       Warning: This development build of composer is over 30 days old. It is recommended to update it by running "/app/.heroku/php/bin/composer self-update" to get the latest version.
       Loading composer repositories with package information
       Installing dependencies
       Nothing to install or update
       Generating optimized autoload files
-----> Building runtime environment...
       NOTICE: No Procfile, defaulting to 'web: vendor/bin/heroku-php-apache2'
 
-----> Uploading droplet (64M)
 
0 of 1 instances running, 1 starting
1 of 1 instances running
 
App started
 
 
OK
Showing health and status for app echo-php in org myorg / space mydept as admin...
OK
 
requested state: started
instances: 1/1
usage: 256M x 1 instances
urls: echo-php.10.244.0.34.xip.io
last uploaded: Mon Nov 24 21:44:40 UTC 2014
 
     state     since                    cpu    memory          disk
#0   running   2014-11-25 05:31:22 PM   0.0%   87.3M of 256M   0 of 1G

The env command can then be used to confirm that the user-provided service is available in the environment for the app.

vagrant@vagrant-ubuntu-trusty-64:~$ cf env echo-php
Getting env variables for app echo-php in org myorg / space mydept as admin...
OK
 
System-Provided:
{
 "VCAP_SERVICES": {
  "Echo Service": [
   {
    "credentials": {
     "uri": "http://echo-service.10.244.0.34.xip.io/echo/8dea3b8e-4230-4509-8879-5f94b4812985/d2944b66-2d9e-46fe-8e3d-d9b102cb5bca"
    },
    "label": "Echo Service",
    "name": "test-echo-service",
    "plan": "large",
    "tags": []
   }
  ],
  "user-provided": [
   {
    "credentials": {
     "uri": "http://echo-service.10.244.0.34.xip.io/echo/user-service-instance/someapp"
    },
    "label": "user-provided",
    "name": "user-echo-service",
    "syslog_drain_url": "",
    "tags": []
   }
  ]
 }
}
 
{
 "VCAP_APPLICATION": {
  "application_name": "echo-php",
  "application_uris": [
   "echo-php.10.244.0.34.xip.io"
  ],
  "application_version": "921b2927-cedd-4623-9db5-b0f48985de39",
  "limits": {
   "disk": 1024,
   "fds": 16384,
   "mem": 256
  },
  "name": "echo-php",
  "space_id": "275cf0c6-b10e-4ef1-afbc-966880feb09f",
  "space_name": "mydept",
  "uris": [
   "echo-php.10.244.0.34.xip.io"
  ],
  "users": null,
  "version": "921b2927-cedd-4623-9db5-b0f48985de39"
 }
}
 
No user-defined env variables have been set
 
No running env variables have been set
 
No staging env variables have been set

From the output of the environment it is seen that this app has two service bindings. The first binding corresponds to a managed instance of the echo service. The second is the service instance that was manually provisioned in this post. It’s up to the app to extract and use the appropriate service. This means that the app must specifically look for the service connection values that are injected.

Twitter Digg Delicious Stumbleupon Technorati Facebook Email

About Daniel Watrous

I'm a Software & Electrical Engineer and online entrepreneur.

No comments yet... Be the first to leave a reply!

Leave a Reply