Configuring multiple Applications with a single Manifest¶

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. For more information on using cf push, see Cloud Foundry documentation.

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¶

You can design and create Software as a Service. Most of the applications consists 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, we have an integrated application Gateway that resides 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 Developer Cockpit in order to access it. In 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.

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

applications:
- name: monitorservice
  stack: cflinuxfs3
  instances: 1
  random-route: true
  buildpacks:
    - java_buildpack
  path: /monitorservice/target/monitorservice-0.0.1.BUILD-SNAPSHOT.jar
  memory: 1GB
  services:
    - mypostgresql
- name: monitorui
  stack: cflinuxfs3
  instances: 1
  random-route: true
  buildpacks:
    - 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.myRegion.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.myRegion.mindsphere.io for one of our applications. This is beneficial if you need to make calls between Cloud Foundry applications. However, it requires you to add the tenant name in the route to avoid route conflicts. When applying this to our previous example, we would have the following configuration:

applications:
- name: monitorservice
  stack: cflinuxfs3
  instances: 1
  buildpacks:
    - java_buildpack
  routes:
  - route: monitorservice-myTenant.apps.myRegion.mindsphere.io
  path: /monitorservice/target/monitorservice-0.0.1.BUILD-SNAPSHOT.jar
  memory: 1GB
  services:
    - mypostgresql
- name: monitorui
  instances: 1
  routes:
  - route: monitorui-myTenant.apps.myRegion.mindsphere.io
  buildpacks:
    - staticfile_buildpack
  path: /monitorui/www
  memory: 1GB

In a final step, the generated routes are used to configure the components in Developer Cockpit. Each component requires the following:

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

Adding bindings for Backing Services¶

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

Directory Structure¶

It is recommended 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.

├───monitorservice
│   ├───src
│   └───target
├───monitorui
│   └───www
├───.cfignore
└───manifest.yml

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.
• Define the stack to use for your application.
• Explicitly define the buildpack, especially when using staticfile buildpack.
• Set your fixed dependencies to specific versions or use wildcards for patch versions.
• Test the deployment at least once with the single manifest file.
• Use the directory structure mentioned above.

If you want to use auto-deployment option to deploy your applications in Operator Cockpit, then make sure that:

• either buildpack or buildpacks is available. However, since buildpack is deprecated, it is recommended to use buildpacks. If there are multiple buildpacks in the manifest, ensure you have enough disk quota. If not, specify the disk quota in manifest file.
• binary_buildpack is available. Out of all the buildpack, only binary_buildpack is supported.

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