Deploy Your First Multitarget Application

1. Create an index.html file with the following content:

   <h3>Hello World!</h3>
   

2. Archive the index.html file into a content.zip archive and place it to a directory that is called my_first_mta.

Copy the example below to an mtad.yaml file that is located in the my_first_mta directory.

_schema-version: "3.1"
ID: app
version: 1.0.0

modules:
  - name: my-first-app
    type: staticfile
    path: content.zip
    requires:
      - name: my-first-app-service
    parameters:
      memory: 64m
      disk-quota: 64m

resources:
  - name: my-first-app-service
    type: org.cloudfoundry.managed-service
    parameters:
      service: application-logs
      service-plan: lite

The MTA deployment descriptor comprises of an MTA module, which represents a simple static application, and an MTA resource, which represents an application-logs service instance with plan lite.

Execute the following:

cf add-plugin-repo CF-Community https://plugins.cloudfoundry.org
cf install-plugin multiapps

Execute the following:

cd  <path to my_first_mta>
cf deploy ./

The result should be as follows:

Deploying multi-target app archive app.mtar in org <ORG> / space <SPACE> as <USER>...
Uploading 1 files...
<PATH_TO_MTAR>
OK
Operation ID: <MTA_OPERATION_ID>
Deploying in org "deploy-service" and space "<SPACE>"
Detected MTA schema version: "3"
No deployed MTA detected - this is initial deployment
Detected new MTA version: "1.0.0"
Processing service "my-first-app-service"...
Creating service "my-first-app-service" from MTA resource "my-first-app-service"...
1 of 1 done
Creating application "my-first-app" from MTA module "my-first-app"...
Binding service instance "my-first-app-service" to application "my-first-app"...
Uploading application "my-first-app"...
Started async upload of application "my-first-app"
Scaling application "my-first-app" to "1" instances...
Staging application "my-first-app"...
Application "my-first-app" staged
Starting application "my-first-app"...
Application "my-first-app" started and available at "<ORG>-<SPACE>-my-first-app.<DEFAULT_DOMAIN>"
Skipping deletion of services, because the command line option "--delete-services" is not specified.
Process finished.
Use "cf dmol -i <MTA_OPERATION_ID>" to download the logs of the process.

In the output example above, the application my-first-app is deployed and started. A service called my-first-app-service is also created and is bound to the application. Credentials are provisioned for the service instance and delivered to the application runtime in the VCAP_SERVICES environment variable.

The example above shows the deployment from a directory where the MTA deployment descriptor is available.
If you want to deploy a ready MTA archive, with a file extension .mtar, execute the following command:

cf deploy <PATH_TO_MTAR>

When triggering a deployment from a directory, the MTAR is built under the hood and it can be verified by checking the new file app.mtar in the current folder.

To check the application, execute:

cf apps

The result should be as follows:

cf apps
Getting apps in org <ORG> / space <SPACE> as <USER>...
OK

name          requested state  processes   routes
my-first-app  started          web:1/1    <ORG>-<SPACE>-my-first-app.<DEFAULT_DOMAIN>

To check the service, execute:

cf services

The result should be as follows:

cf services
Getting services in org <ORG> / space <SPACE> as <USER>...

name                   service            plan     bound apps     last operation
my-first-app-service   application-logs   lite     my-first-app   create succeeded

Extension descriptors are files complementary to the main deployment descriptor that provide additional data. They have a file extension .mtaext and are external to the MTA archive .mtar. They are used to provide deployment specific information, for example, credentials to external services.

1. Copy the example below to an app-2-instances.mtaext file:

   _schema-version: "3.1"
   ID: app-instances-2
   extends: app
   
   modules:
   - name: my-first-app
     parameters:
       instances: 2
   

2. Place the file to the directory my_first_mta.

The extension descriptor is used to extend the MTA deployment descriptor (mtad.yaml), so that my-first-app will be scaled to two instances.

Execute the following command:

cf deploy ./ -e app-2-instances.mtaext

The result should be as follows:

OK
Uploading 1 files...
<PATH_TO_MTAR>
OK
Uploading 1 files...
<PATH_TO_EXTENSION_DESCRIPTOR>
OK
Operation ID: <MTA_OPERATION_ID_2>
Deploying in org "<ORG>" and space "<SPACE>"
Detected MTA schema version: "3"
Detected deployed MTA with namespace "null", ID "app" and version "1.0.0"
Detected new MTA version: "1.0.0"
Deployed MTA version: "1.0.0"
Processing service "my-first-app-service"...
Updating application "my-first-app"...
Application "my-first-app" attributes are not modified and will not be updated
Unbinding service instance "my-first-app-service" from application "my-first-app"...
Binding service instance "my-first-app-service" to application "my-first-app"...
Uploading application "my-first-app"...
Content of application "my-first-app" is not changed - upload will be skipped.
Scaling application "my-first-app" to "2" instances...
Stopping application "my-first-app"...
Starting application "my-first-app"...
Application "my-first-app" started and available at "<ORG>-<SPACE>-my-first-app.<DEFAULT_DOMAIN>"
Skipping deletion of services, because the command line option "--delete-services" is not specified.
Process finished.
Use "cf dmol -i <MTA_OPERATION_ID_2>" to download the logs of the process.

To verify that the application is scaled to two instances, execute:

cf apps

The result should be as follows :

cf apps
Getting apps in org <ORG> / space <SPACE> as <USER>...
OK

name          requested state  processes   routes
my-first-app  started          web:2/2    <ORG>-<SPACE>-my-first-app.<DEFAULT_DOMAIN>