MTA deployment, a starter

INTRODUCTION

This blog post is aimed for developers who are very new to SAP BTP which requires a deployment descriptor (MTA or Manifest)  to deploy applications.

It is always challenging to deploy an MTA or manifest based application be it NodeJS, GO or Java. Additionally we face a lot of challenges and jargons which slows our development.

Though creating MTA might feel overwhelming at first, it has a lot of advantages to offer. The deployment is one touch most of the time and creates an ecosystem where different components from a single application can collaborate together. Helps us create more resources without writing manual commands or collective shell scripts for every resource we consume.  So the entire file is reusable

INSTALLATION OF CLOUD MTA BUILD TOOL

We can install the cloud MTA build tool using any of the methods below in the link

You have to consider the following limits for the MTA artifacts, which can be handled by the Cloud Foundry deploy service:

• Maximum size of the MTA archive: 4 GB
• Maximum size of MTA module content: 1 GB
• Maximum size of MTA resource content: 1 GB
• Maximum size of MTA descriptors (mtad.yaml and MANIFEST.MF): 1 MB

MTA DEPLOYMENT TERMINOLOGIES

The different terminologies used in MTA deployments are

Multitarget application (MTA)

An application comprised of multiple software modules, which are created with different technologies and deployed to different runtimes.

Development descriptor –

A YAML file named mta.yaml that contains a list of all entities, such as modules, resources, and properties that belong to an application or are used by it at runtime, and the dependencies between them. It is automatically generated when an MTA project is created or modified, or when a module is added or removed. The developer needs to edit the descriptor manually to define resources, properties, and dependencies, as well as fill in missing information.

Deployment descriptor

A YAML file named mtad.yaml that contains a list of all entities which is created from the WEB IDE or from Multitarget Application Archive Builder tool or manually. This file is similar to Development Descriptor but is used from the MTA Deployer.

Module

A self-contained application of a certain type, which is developed, packaged, and deployed.

Module Type

A type that defines the structure and the development technology of a module. You can see a list of the module types at Modules.

Resource

Any resource, such as an external service that is required by a module at runtime but not provided by the module itself.

Property

A property (key-value pair) of an application, module, or resource, that is used during deployment or at runtime.

Parameter

A reserved variable belonging to a module or resource, whose value is used during deployment or at runtime.

Dependency

A relationship between a module and another module, resource, or property, such as provides and requires.

provides: indicates the properties or parameters that are provided by a module or resource to other modules.

requires: indicates other modules or resources that are required by a module in order to run.

MTA archive (MTAR)

Archive containing a deployment descriptor, the module and resource binaries, and configuration files. The archive follows the JAR file specification.

Example

Consider a nodeJS app having dependency to a hdi-container in a subaccount.  This can be modelled like this

_schema-version: "3.1.0"
ID: simple-mta
version: 1.0.0

modules:
- name: anatz
  type: javascript.nodejs
  requires:
    - name: hdi-service

resources:
- name: hdi-service
  type: org.cloudfoundry.managed-service
  parameters:
    service: hana
    service-plan: hdi-shared

The sample file contains a nodejs module named anatz which ready to be deployed. You can also specify the path of the module by specifying the path property. Also few modules such as the launchpad do not contain the path property, as it takes the already created modules and configures them to deploy.

A requires property is specified which allows the module to be deployed only if the required dependencies are satisfied. The required dependencies can come from other modules or from the resources that will be created as services in SAP BTP. like databases or event meshes

Additionally we can also provide parameters such as memory and route to the module. This enables us to control all the modules in one place before deployment

_schema-version: 3.1.0
ID: anatz-keep-existing
version: 4.0.0

modules:
- name: anatz
  type: staticfile
  path: hello-world.zip
  parameters:
    memory: 64M
    route: new-custom-route-${space}
    keep-existing:
      env: true
      service-bindings: true
      routes: true

Sometime we would like to generate our files before starting the build. This can be done by running a shell script or individual commands like mvn clean install or npm install. All these can be speified under Build parameters.

• It is advisable to look into the manifest.yaml file (If you have already) make note of modules and dependencies before starting to create one here.
• Once you have the module files in place start creating the modules, if needed add a provide property to the module if it requires to be addressed by the upcoming modules by that name

CONCLUSION

If deployment is successful you will receive no process failed message at the end of deployment.

For more information on MTA’s checkout the help portal