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 modeled as MTA resources of type org.cloudfoundry.managed-service
.
The service instance can be configured on it’s creation or update via the config
parameter.
... - 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 modeled as in the MTA modules describing the bound apps.
A binding is created or updated when a resource, describing a service instance, is required by an app module.
The service instance can be configured on it’s creation or update via the config
parameter.
... 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 |
This approach uses deployment descriptor mtad.yaml
and ready application binaries appBits.zip
:
cf deploy ./ -f ;
OR
First assemble an MTA archive using the mtad.yaml
deployment descriptor and then deploy the archive:
mbt assemble -t ./ ;
cf deploy my-mta_0.0.0.mtar ;
Note
|
See mtad.yaml for the modelling |
This approach uses development descriptor mta.yaml
and application binaries appBits.zip
to build an MTAR archive.
The built MTAR is then deployed:
mbt build -p cf -t . ;
cf deploy my-mta_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