Contents
In the previous post I wrote about what reusable services in Cloud Foundry are, why we should take advantage of them. I also discussed how reusable services can be discovered in service marketplace, what are service instances and how to create them and use them for your application hosted in the Cloud Foundry. In another post I have
went one level deep and explained how such a reusable service can be created and published in the service marketplace, what service brokers are and how the Cloud Foundry platform communicates with the service broker and the service instances. I have also briefed about how Service Brokers work with the Cloud Controller. Today In this post I will explain the life cycle management of the Service Brokers.
Below I have explained all Cloud Foundry CLI commands to manage Service Brokers.
List the service-brokers
To list all Service Broker the below command needs to be used
$ cf service-brokersIt will list all service brokers that has been registered with the platform with name and its base URL
name url
ServiceBroker1 https://the.cfapp.url.with.cf.domain/app-specific-sufixDeploy a service broker
Before a Service Broker can be registered with the Cloud Controller, it has to be deployed in a space just like we deploy any application (for example using cf push command). The Service Broker will have a route URL after deployment .This URL is needed for registration with the Cloud Controller. There are java libraries for Service Brokers that can be extended to create a new service. There are certain hooks or callbacks that need to be implemented to create a service broker. These callbacks respond to HTTP requests from the Cloud Controller. The HTTP requests in the Cloud Controller are predefined and get generated when users in the Cloud Foundry platform performs certain operations like create and delete service instance, create and delete service keys and bind with or unbind from the service instance. How those callbacks can be implemented is not the scope of this blog today.
Register service brokers
The next step is to register the Service Broker with the Cloud controller. How that is done is again platform specific. Different platforms that install Cloud Foundry as PaaS have different ways to do this task. Then we need the enable-service-access command.
$ cf enable-service-access search-serviceThis command makes the Service Broker public into the service marketplace and from this point the service is usable for all. To register a Service Broker a username and password needs to be provided as a basic authentication mechanism. The cloud controller encrypts the username and password and uses them in further communications to the service broker. The Service Broker has to save the username and password so that it can validate the API calls coming from the Cloud Controller. Otherwise, anyone can curl the service broker and delete service instances. The credentials are updateable using update-service-broker command.
Create service brokers
After a service broker is being registered the Cloud Controller fetches and validates the catalog from the Service Broker and saves the catalog to its database. When the Service Broker is registered with a URL having the scheme https (recommended), Cloud Controller will make all API calls to the Service Broker over HTTPS.
A Service Broker can be global, that is visible from any space in an org, or it can be visible in only one space.
$ cf create-service-broker <service-broker-name> <user> <password> <service-broker-app-url>/<suffix>
$ cf create-service-broker <service-broker-name> <user> <password> <service-broker-app-url>/<suffix> --space-scopedThe <service-broker-app-url>/<suffix> is the route of the service broker app. For example,if the suffix of the service broker is "my-service-broker" and <service-broker-name> is "service-abcd", the created service name will be "my-service-broker-service-abcd" .
Make Plans Public
New service plans can be created for a Service Broker. No one can use the plan after an admin creates a new service plan from a standard broker until the admin explicitly makes it available to users within a specific org or all orgs in the deployment.
At this point we will be able to create service instances(using cf create-service command) of our service like any other reusable service. These services are called managed services because the Cloud Foundry platform manages these services. When a binding of a service instance is done the Service Broker propagates some credentials and information to the service instance which is made available to VCAP_SERVICES by the Cloud Controller.
It has to be noted that all the above steps from registering, creating a service broker and making a service broker plan public also might have been automated using some Administrative tools so that these CF commands do not have to be run manually.
View Registered Services
All the registered service in the service marketplace can be seen by issuing this command.
$ cf marketplace or
$ cf marketplace -s SERVICENAME Marketplace is the catalog that shows the potential users of the reusable services what are the services available to be used. For each of such reusable services there is a service broker running behind to cater the requests generated from the Cloud Controller. As one service broker can provide implementation for several reusable services it might be the case that for each reusable service in the marketplace a dedicated service broker does not exist.
Delete Service Broker
The command to delete a Service Broker is
$ cf delete-service-broker <service-broker-name>A Service Broker can only be deleted when all the service instances created with the service broker are deleted.
Update Service Broker
$ cf update-service-broker my-broker-name user password https://mybroker.example.comThe above command is an example that can be used to update a Service Broker. Any change in the Service Broker application, change in credentials can be updated using the update command. The Cloud Controller performs the same actions in updates that are performed at the time of registration.
Rename service broker
Finally, to rename a Service Broker this command can be used
$ cf rename-service-broker my-broker-name my-new-broker-name The name is only used as a reference by the end users or the Cloud Foundry operators.
Purge Service
There could be a situation where a service broker itself was deleted or shutdown or moved to another URL before deleting all the service instances. When a service instance is created for a service broker the Cloud Controller maintains that information in its database. In fact, the unique IDs of the service instances comes from the Cloud Controller itself. This is why in this case, removing a service broker and its service plans will not be possible from the service marketplace. It leaves the Cloud Controller in an inconsistent state. When there are any operations done by the user for those service instances the Cloud Controller will not know to which service broker implementation to make the corresponding calls. As there is no restriction from the platform and each service broker runs as a plain backend service in the Cloud Foundry still service brokers can be deleted. This might frequently happen in development environments. In this scenario using the purge service command can be used to purge such service broker entries from the Cloud Controller database. This command deletes the service offering from the marketplace along with the existing service instances and their bindings. While deleting the service instances and binding the Cloud Controller will not make any call to the service broker (which normally it would to let the service broker know).
The command is simply
$ cf purge-service-offering my-service-namePurge Service Instance
Similarly, to purge a service instance of a reusable service we can use this command
cf purge-service-instance my-service-instance1This command deletes the service instances and their binding from the Cloud Controller database, without the Cloud Controller sending corresponding requests to the service broker.
Comments