This example shows how to create a service instance and a service binding for an application to that service instance within an MTA deployment.
Orchestration of the following CF features is covered:
-
creation of service instances: https://docs.cloudfoundry.org/devguide/services/managing-services.html
-
creation of app bindings to service instances https://docs.cloudfoundry.org/devguide/services/application-binding.html#bind
Service instances are modelled as MTA resources of type org.cloudfoundry.managed-service
.
Parameters in the config parameter can be specified to configure the service instance on it’s creation or update
... - name: my-cf-service-instance-resource type: org.cloudfoundry.managed-service parameters: service: logging service-plan: free service-name: my-logging-service config: map: of creation: parameters
parameter | configuration | optional |
---|---|---|
service |
service offering (label) |
mandatory |
service-plan |
the plan to be applied to the service instance |
mandatory |
service-name |
the name of the service instance |
optional (defaults to resource name) |
config |
creation/update parameters of the service instance |
optional (defaults to no parameters specified) |
Service instances are modelled as in the MTA moduels describing the bound apps. A binding is created/updated when a resource, describing a service instance is depicted as required by an app module. Parameters in the config parameter can be specified to configure the service binding on it’s creation or update
... modules: - name: my-mta-managed-app-module type: application requires: - name: my-cf-service-instance-resource parameters: config: binding-config: "binding-config-value"
parameter | configuration | optional |
---|---|---|
config |
creation/update parameters of the service binding |
optional (defaults to no parameters specified) |
-
service instance and binding parameters(configurations) management with MTAs
-
update of service instances and bindings [updating parameters, changing plans and labels; recreation ]
The example demostrates 2 different approaches that lead to the same result.
Note
|
you can adjust the service label and plan values to match the available in your environment |
That approach uses deployment descritpr mtad.yaml
and ready application binaries appBits.zip
:
cf deploy ./ -f ;
OR
First assemble an MTA archive using the mtad.yaml
and then deploy the archive:
mbt assemble -t ./ ;
cf deploy my-mta_0.0.0.mtar ;
Note
|
See mtad.yaml for the modelling |
The approach is using development descriptor mta.yaml
and application binaries appBits.zip
to build MTAR.
Then the MTAR is deployed.
mbt build -p cf -t . ;
cf deploy a.cf.app_0.0.0.mtar -f ;
Note
|
See mta.yaml for the concrete modelling |
$ cf services
Getting services in org deploy-service / space ****** as ******...
name service plan bound apps ...
my-logging-service-instance-name application-logs lite my-mta-managed-app-module
$ cf service my-logging-service-instance-name ;
Showing info of service my-logging-service-instance-name in org deploy-service / space ****** as ******...
name: my-logging-service-instance-name
service: application-logs
tags:
plan: lite
...
bound apps:
name binding name status message
my-mta-managed-app-module create succeeded