Skip to content

Configuring multiple Applications with a single Manifest

MindSphere Cloud Foundry requires multiple applications to be described with a single Manifest file. This file contains properties for all applications, e.g. application name, memory limit, service bindings and routes, and allows to deploy them with a single cf push command.

The Operator Cockpit uses the single manifest to automatically register your applications in the production system. This section describes the necessary attributes in the manifest and provides a short checklist for transferring your application to the production system.

Application Components and Cloud Foundry applications

MindSphere enables you to design and create Software as a Service. Most applications consist of multiple services that in combination are accessible through a single entry point, e.g. by clicking on an icon on the Launchpad. While accessing the application multiple resources are loaded and many requests are made. Those requests and resources might be delivered by different internal services in the background which are not visible for a customer or client.

To achieve this behavior MindSphere has an integrated application gateway that sits between clients and services. It acts as a reverse proxy and is routing requests from client to the different services. When mapping this to Cloud Foundry, the services are the individual Cloud Foundry applications running within the same Cloud Foundry Space.

During deployment each application gets a route assigned, except if you want to have a service that is completely internal and only communicates with Backing Services. To avoid accidental exposure of unprotected services on the internet, you must register each route in the Developer Cockpit in order to access it. In the Developer Cockpit we use the term "components" to name a single service that maps to one Cloud Foundry application. The name of the component must match the name of the Cloud Foundry application which is defined in the Cloud Foundry manifest configuration file.

Configuring the manifest file

Defining random routes and explicit routes

Cloud Foundry provides multiple ways for defining a route for applications. You can either use the CLI or the routes attribute in the Manifest to define the route for your application. The preferred way for defining routes is using random routes that are generated automatically from the application name.

Attention

The host, domain or route attributes in the manifest file are deprecated. Only routes or random-route is supported.

For example, if you have the application with the name monitorservice the configuration could look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
applications:
- name: monitorservice
  instances: 1
  random-route: true
  path: /monitorservice/target/monitorservice-0.0.1.BUILD-SNAPSHOT.jar
  memory: 1GB
  services:
    - mymongodb
- name: monitorui
  instances: 1
  random-route: true
  buildpack: staticfile_buildpack
  path: /monitorui/www
  memory: 1GB

Once we have deployed the application with the above configuration Cloud Foundry is going to create a route similar to this: monitorservice-grateful-jaguar.apps.eu1.mindsphere.io. As long as the application or the route is not deleted the generated random route will be reused.

In the next example we are using explicit route definitions like monitorservice-mytenant.apps.eu1.mindsphere.io for one of our application. This is beneficial if you need to make calls between Cloud Foundry applications, however requires you to add the tenant name in the route to avoid route conflicts. When applying this to our previous example we end up with the following configuration:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
applications:
- name: monitorservice
  instances: 1
  routes:
  - route: monitorservice-mytenant.apps.eu1.mindsphere.io
  path: /monitorservice/target/monitorservice-0.0.1.BUILD-SNAPSHOT.jar
  memory: 1GB
  services:
    - mymongodb
- name: monitorui
  instances: 1
  routes:
  - route: monitorui-mytenant.apps.eu1.mindsphere.io
  buildpack: staticfile_buildpack
  path: /monitorui/www
  memory: 1GB

In a final step the defined or generated routes are used to configure the components in the Developer Cockpit. Each component requires

  • a name which must match the Cloud Foundry application name and
  • a Cloud Foundry URL which is the route.

Duplicate Routes

Please be aware that you cannot reuse the same route in the development and production system. Therefore, we advise to either use random routes or to suffix the route with a tenant name. You can use the cf check-route ROUTE command to check whether is available.

Adding bindings for Backing Services

Next to the route configuration the manifest might also include the bindings for one or more Backing Services. Ensure that you add all bindings in the manifest file and to configure the required Backing Service plans with the correct instance name in the Developer Cockpit.

Directory Structure

We recommend to use a directory structure in which each application resides in a sub directory. You can use the path attribute to point to the correct directory for each application. The example route configurations from the previous section already reflect this structure and use the correct path values.

1
2
3
4
5
6
7
├───monitorservice
│   ├───src
│   └───target
├───monitorui
│   └───www
├───.cfignore
└───manifest.yml

Binary Upload

Use the same structure for creating the ZIP file to avoid any problems with the deployment on the production system.

Preparing applications for operator deployment

After successfully testing your application you can transfer it to the application repository for productive usage. The following checklist and directory structure guide will help you preparing a productive version.

Preparation Checklist

For transferring an application to the application repository and eventually assigning it to an operator, you should check the following points to avoid any problems:

  • Each component name has a matching Cloud Foundry application (name) as defined in the manifest file
  • All bindings are present in the manifest file.
  • Cloud Foundry manifest does not contain host, domain or route attributes. Only routes or random-route is supported.
  • Routes are still available and/or inform an operator about the required route changes (e.g. replacing the tenant name).
  • Configure the correct amount of memory for each application.
  • All required environment parameters are set.
  • All path values match your directory structure.
  • Explicitly define the buildpack, especially when using staticfile buildpack.
  • Set your fixed dependencies to specific versions or use wildcards for patch versions.
  • Use a .cfignore to avoid uploading of unnecessary files.
  • Test the deployment at least once with the single manifest file.
  • Use the directory structure mentioned above.

Except where otherwise noted, content on this site is licensed under the MindSphere Development License Agreement.

Any questions left?

Ask the community


Except where otherwise noted, content on this site is licensed under the MindSphere Development License Agreement.