Configuration of the MTA is done with the standard approach using MTA extension descriptors. Extension descriptors are complementary files to the main deployment descriptor that provide additional data. They have file extension .mtaext and are external for MTA archive .mtar. Extension descriptors can be used to provide deployment specific information, for example credentials to external services.
For the test purpose of the example, we will use an MTA containing a simple application, simple service and binding between them. The MTA will be deployed in DEV and PROD environments using different extension descriptors resulting in different set-ups.
-
Quota for application
-
Quota for different service plans. The example uses service offering "application-logs", free service plan "lite" and paid service plan "standard". You can try it out with a different service offering and plan at your convenience.
The first step of the example shows an unsuccessful attempt to deploy the MTA without an extension descriptor.
This approach uses deployment descriptor mtad.yaml and ready application binaries appBits.zip:
$ cf deploy -f
...
Error building cloud model: Service "my-service" has missing required parameter: service-plan
...Note that deployment fails expectedly because the MTA defines as required the parameter service-plan for resource my-service, which represents a service instance. This is done with the MTA parameter metadata called optional. By default, the optional parameter is set to false. Setting it to true makes the parameter it refers to optional. Thus the field service-plan can be left empty in the descriptor.
- name: my-service
type: org.cloudfoundry.managed-service
parameters:
service-plan: # set the service plan to use
service: application-logs #set the service offering (label)
parameters-metadata:
service-plan:
optional: false # this is the default value and is implicitly set but can be changedThe goal is to make the operator deploying the MTA match the service plan to the specific region, organization and space. For example, in a development working environment (DEV), it’s usually the free and small service plan that is used. In production environment (PROD), on the other hand, the service plans used are paid and supported.
This step of the example shows how the MTA is deployed in DEV environment where the goal is to use minimal resources for the application and use a free service plan.
That approach uses deployment descritpr mtad.yaml, ready application binaries appBits.zip and extension descriptor for DEV env dev.mtaext:
$ cf deploy -f -e dev.mtaext
...
Uploading 1 files...
.../my-mta.mtar
OK
Uploading 2 files...
.../dev.mtaext
OK
...
No deployed MTA detected - this is initial deployment
Detected new MTA version: "1.0.0"
Processing service "my-service"...
Creating service "my-service" from MTA resource "my-service"...
Creating application "my-app" from MTA module "my-app"...
Uploading application "my-app"...
Scaling application "my-app" to "1" instances...
Staging application "my-app"...
Application "my-app" staged
Starting application "my-app"...
...Check that the app and service instance are created, and service plan is lite, defined in the extension descriptor:
$ cf s
...
name offering plan bound apps last operation ...
my-service application-logs lite my-app create succeeded ...
$ cf a
...
name requested state processes routes
my-app started web:1/1 ...|
Note
|
The application has 1 instance, that is defined in the mtad.yaml. It uses 1G memory and 1G disk that is default for the platform.
|
This step of the example shows how the MTA is deployed in PROD enviroment using prod.mtaext. The goal is that app and service can handle more load without performance issues. The application is scaled horizontally on 2 instances and the service uses the stable paid service plan standard:
_schema-version: 3.3.0
ID: my-mta-prod
extends: my-mta
version: 1.0.0
modules:
- name: my-app
parameters:
instances: 2
resources:
- name: my-service
parameters:
service-plan: "standard"|
Note
|
The extension descriptor extends the deployment descriptor id extends: my-mta
|
This approach uses deployment descriptor mtad.yaml, ready application binaries appBits.zip and extension descriptor for PROD environment prod.mtaext:
$ cf deploy -f -e prod.mtaext
...
Uploading 1 files...
.../my-mta.mtar
OK
Uploading 2 files...
.../prod.mtaext
OK
...
No deployed MTA detected - this is initial deployment
Detected new MTA version: "1.0.0"
Processing service "my-service"...
Creating service "my-service" from MTA resource "my-service"...
Creating application "my-app" from MTA module "my-app"...
Uploading application "my-app"...
Scaling application "my-app" to "2" instances...
Staging application "my-app"...
Application "my-app" staged
Starting application "my-app"...
...Check that app and service instance are created and service has the plan lite defined in the extension descriptor:
$ cf s
...
name offering plan bound apps last operation ...
my-service application-logs lite my-app create succeeded ...
$ cf a
...
name requested state processes routes
my-app started web:2/2 ...To handle an increased workload without compromising performance, the application and service will be deployed to the PROD environment using two extension descriptors: prod.mtaext and prod-scale-vertically.mtaext. The application is scaled horizontally on 2 instances and vertically using 2G of memory:
_schema-version: 3.3.0
ID: my-mta-prod-scale-vertically
extends: my-mta-prod
version: 1.0.0
modules:
- name: my-app
parameters:
memory: 2G|
Note
|
prod-scale-vertically.mtaext extends prod.mtaext that extends deployment descriptor mtad.yaml. It makes an extension descriptor chain.
|
|
Note
|
memory parameter is not defined in the deployment descriptor, however it is considered during deployment.
|
This approach uses deployment descriptor mtad.yaml, ready application binaries appBits.zip and 2 extension descriptors for PROD environment: prod.mtaext and prod-scale-vertically.mtaext:
$ cf deploy -f -e prod.mtaext,prod-scale-vertically.mtaext
...
Uploading 1 files...
.../my-mta.mtar
OK
Uploading 2 files...
.../prod.mtaext
.../prod-scale-vertically.mtaext
OK
...
No deployed MTA detected - this is initial deployment
Detected new MTA version: "1.0.0"
Processing service "my-service"...
Creating service "my-service" from MTA resource "my-service"...
Creating application "my-app" from MTA module "my-app"...
Uploading application "my-app"...
Scaling application "my-app" to "2" instances...
Staging application "my-app"...
Application "my-app" staged
Starting application "my-app"...
...Check that app and service instance are created, and app has values defined in both extension descriptors:
$ cf s
...
name offering plan bound apps last operation ...
my-service application-logs lite my-app create succeeded ...
$ cf a
...
name requested state processes routes
my-app started web:2/2 ...