Cloud Foundry – How to Set up an App Deployment Manifest

Table of Contents

• Define your application deployments with deployment manifest files
  • Environment Configuration
  • Service Bindings
  • Multi Application Configuration

Define your application deployments with deployment manifest files

The anynines PaaS allows you to define your application deployments using deployment manifest files. A deployment manifest is a yaml file describing all needed configuration options for your application’s runtime. The cf push command will automatically look for a file named manifest.yml in your current directory and use it for your deployment request. In case you need to manage different deployment configurations you can use the ‘-f’ parameter to specify the manifest for your current deployment like this:

$> cf push -f /path/to/your/manifest.yml

The following snippet shows an example of a basic deployment manifest:

Let’s have a closer look at the configuration

As you can see the deployment file defines a key called ‘applications’. You can add multiple applications underneath the applications key. Each application has its own configuration.

name: a name for the application in the Cloud Foundry context (required)
memory: the RAM associated to your app’s container (M for Megabytes, G for Gigabytes) (optional, defaults to 256M)
instances: the number of application instances that should be run (optional, defaults to 1)
buildpack: the git url of the buildpack to use for staging the application (optional, but recommended)
host: the subdomain under which the application should be made available (optional, defaults to the app name)
domain: the domain under which the application should be made available (optional, defaults to de.a9sapp.eu)
path: the path where your application bits reside (optional, defaults to ‘.’ )
command: the start command for your application (optional, the buildpack will try to detect the start command for your app, required for non framework applications)

Environment Configuration

As we aim to follow the 12 Factor paradigm when developing our applications we recommend to follow the third principle: application configuration should be stored in the environment.
The anynines platform will add basic environment configuration variables to our application containers. Please have a look at the example in our gist.

Let’s assume we rely on the following environment variables to configure an application:
SERVICE_START_DATE DEFAULT_ROLE CURRENCY

We can add those environment variables to our manifest as follows:

A full example file can be found here. One of the main benefits of this approach is the ability to configure a complete application runtime environment within one file. This simplifies the deployment process to updating the manifest with new configuration values and executing a simple cf push in the manifest’s directory.

Service Bindings

Most applications rely on services. Those services can be bound to your application as described here. You can configure a list of services to bind to your application within the deployment manifest under the ‘services’ key:

The listed service instances will be bound to your application on startup automatically.

Multi Application Configuration

You can define multiple deployment configurations within a single file to be able to deploy a cluster of applications using one simple push command. An example demonstrating this approach using a main application and a worker connected via Redis is described in this example gist.

Manifests support even more possibilities to refine your deployment configuration like manifest inheritance and global variables. The official Cloud Foundry documentation specifies all available configuration options in more detail.