MTA deployment a starter

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 shell scripts for every resource we consume.  So the entire file is reusable

Here I would describe the different terminologies used in MTA deployments

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.

build-parameters:
before-all:
- builder: custom
commands:
- npm install --production

Commands can also be run specific to modules.

Resources can also contain parameters which takes care of special hardcoded values such as url’s or references such to files.

So before we plan an MTA deployment

  • 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

Finally do an MTA build using the command mbt build on the module. resolve any errors shown. The final MTAR file will be generated in mta_archive as an .mtar file

You can deploy the mtar file to cloud foundry by  using the command  cf deploy filename.mtar

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