- Modeling
- Related examples
- Requirements
- Official documentation in SAP Help Portal
- Try it out
- Deploy with an inactive resource
- Deploy with an active optional & misconfigured service resource
- Deploy with an active properly configured service resource
- Print the MTA details to confirm the deployment
- Clean up resources
This example shows how to mark service resources as optional/mandatory or active/inactive in order to influence the deployment behaviour.
Orchestration of the following Cloud Foundry 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.
If a service instance is not mandatory for a deployment but you want it to be used if availalble, it can be marked as optional in the mta(d).yaml descriptor:
...
- name: my-cf-service-instance-resource
type: org.cloudfoundry.managed-service
optional: true #default is false
parameters:
...
|
Note
|
The value of the optional resource attribute can be changed for each deployment by using an extension descriptor.
|
Service instance resources can be marked as active or inactive to provide finer control over what is deployed. Depending on their status, the MTA deployer will either process or ignore these resources when deploying.
...
- name: my-cf-service-instance-resource
type: org.cloudfoundry.managed-service
active: false #default is true
parameters:
...
|
Note
|
The value of the active resource attribute can be changed for each deployment by using an extension descriptor.
|
|
Note
|
The active attribute can also be specified for resources of type org.cloudfoundry.existing-service. In that case it determines if app bindings to the service would be created or not. If an app module has a reference to an existing-service resource via requires: … and the resource has active: false, a service binding between them will not be created during deployment.
|
-
service instance and binding creation (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.
This approach uses deployment descriptor mtad.yaml and ready application binaries appBits.zip:
$ cf deploy ./ -f ;OR
You can assemble an MTA archive using the mtad.yaml by running the following command:
$ mbt assemble -t ./ ;Then deploy the assembled archive:
$ cf deploy my-mta_0.0.0.mtar ;|
Note
|
See mtad.yaml for the modelling |
|
Note
|
please adjust the service label and plan values to match the available in your environment |
This approach uses development descriptor mta.yaml and application binaries appBits.zip to build an MTAR archive.
$ mbt build -p cf -t . ;The built MTAR archive is then deployed:
$ cf deploy my-mta_0.0.0.mtar -f ;|
Note
|
See mta.yaml for the specific modeling |
$ cf deploy ./
...
Operation ID: 7c8d9c49-badf-11ea-9455-eeee0a9e129b
Deploying in org "deploy-service" and space "********"
Detected MTA schema version: "3"
Detected deployed MTA with ID "my-mta" and version "0.0.0"
Detected new MTA version: "0.0.0"
Deployed MTA version: "0.0.0"
Service "my-cf-service-instance-resource" is inactive and will not be processed
...The Cloud Foundry application gets created. Since the service’s resource is inactive, the service is not created and not bound to the app.
Let’s enable the resource and mark it optional, but make sure to make the service creation not-possible in order to see how the deploy behaves. See how this is done in active_optional.mtaext
$ cf deploy ./ -f -e active_optional.mtaext 6895
Deploying multi-target app archive /Users/********/dev/repos/ds/cf-mta-examples/active-optional-resources/my-mta.mtar in org deploy-service / space ******** as ********...
Uploading 1 files...
/Users/********/dev/repos/ds/cf-mta-examples/active-optional-resources/my-mta.mtar
OK
Uploading 1 files...
/Users/********/dev/repos/ds/cf-mta-examples/active-optional-resources/active_mandatory.mtaext
OK
Operation ID: 6cc12802-bae0-11ea-9455-eeee0a9e129b
Deploying in org "deploy-service" and space "********"
Detected MTA schema version: "3"
Detected deployed MTA with ID "my-mta" and version "0.0.0"
Detected new MTA version: "0.0.0"
Deployed MTA version: "0.0.0"
Processing service "my-cf-service-instance-resource"...
Updating application "my-mta-managed-app-module"...
...The Cloud Foundry application gets created. Since the service’s resource is inactive, the service is not created and not bound to the app.
Let’s enable the resource with an extension descriptor See how this is done in active_mandatory.mtaext
$ cf deploy ./ -f -e active_mandatory.mtaext
...
Operation ID: 6cc12802-bae0-11ea-9455-eeee0a9e129b
Deploying in org "deploy-service" and space "********"
Detected MTA schema version: "3"
Detected deployed MTA with ID "my-mta" and version "0.0.0"
Detected new MTA version: "0.0.0"
Deployed MTA version: "0.0.0"
Processing service "my-cf-service-instance-resource"...
Updating application "my-mta-managed-app-module"...
...The service instance & app get created and bound as expected.
At any step you can check the created deployment with the following:
$ cf mta my-mta
Showing health and status for multi-target app my-mta in org deploy-service / space ******** as ********...
OK
Version: 0.0.0
Apps:
name requested state instances memory disk urls
my-mta-managed-app-module started 1/1 1G 1G deploy-service-********-my-mta-managed-app-module.cfapps.sap.hana.ondemand.com
Services:
name service plan bound apps last operation
my-cf-service-instance-resource application-logs lite my-mta-managed-app-module create succeeded