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.
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
CONCLUSION
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.
For more information on MTA's checkout the help
portal
