Selecting and Migrating Apps

This section provides considerations for selecting and migrating apps to the Apcera platform, and walks you through some common migration scenarios.

App selection considerations

You can deploy virtually any type of POSIX-compatible app to the Apcera platform. Nonetheless, certain types of apps are ideally suited for Apcera. Such an app may include the following characteristics:

  • Application state is held externally in a database or cache
  • Requires minimal filesystem based configuration
  • Designed for horizontal scale
  • Has no specific kernel requirements (can run on top of the Ubuntu kernel)

See also the twelve-factor app methodology for building cloud-based apps designed to scale.

App migration considerations

Migrating applications to the Apcera platform is generally straightforward due to Apcera's parameterized and extensible environment.

For example, if you were migrating apps to Apcera from another platform, often the main change required is to get your application PORT and SERVICE settings/URIs from Apcera-provided environmental variables instead of the variables that the other platform may provide, such as VCAP and VCAP_SERVICES.

The following examples provide migration considerations for specific types of apps, and provides examples for each type.

Migrating stand alone apps (no services)

If the app you want to migrate is a stand alone app and does not require any external services or service bindings, the migration is straightforward.

For example, another platform may provide the ENV vars "VCAP_APP_PORT" and "VCAP_APP_HOST" which is the port/host your application should bind to. In Apcera this is "PORT" and the host is localhost. Below is how you would migrate NodeJS configuration code to run in the Apcera platform.

App to migrate:

config.env = config.env || { port: process.env.VCAP_APP_PORT || 3000, host: process.env.VCAP_APP_HOST || '' };

Apcera app:

config.env = config.env || { port: process.env.PORT || 3000, host: '' };

Migrating apps with custom environment variables

If your app has custom environment variables, you can specify those custom variables when you create or deploy the app in Apcera.

For example, Apcera supports adding any environment variables you want. In Apcera this is done at application creation or update time. If the application you want to migrate has the following custom environment variables:


You can add these to your Apcera job when deploying using APC commands:

apc app create [appname] --start --env-set 'MYSQL_DOCKER_URI=mysql://host:port/db' --env-set 'EXTERNAL_SERVICE_URI=http://host:port/path'

Migrating apps with services

Apps with services usually require more work because in general each system handles credentialing differently.

For example, credentials and URIs for services within the Apcera platform may not be exposed the same way as in other platforms that may use environment variables (such as VCAP_SERVICES) and/or JSON objects for storing connection credentials.

In Apcera when you bind a job to a service the system creates environment variables with the URI. Instead of parsing the JSON you just parse the URI that we expose.

For example, here is a configuration block reading VCAP_SERVICES:

 var vcapServices = process.env.VCAP_SERVICES;
  if (vcapServices) {
    vcapServices = JSON.parse(vcapServices);

    if (vcapServices.redis) {
      var vcapRedis = vcapServices.redis[0];

      nconf.set('middleware:session:config:port', vcapRedis.credentials.port);
      nconf.set('middleware:session:config:db', vcapRedis.credentials.db);

On the Apcera platform a Redis service connection string is exposed as the REDIS_URI environment variable.

Example parsing code may look like the following:

var url = require("url");
var redisService = process.env.REDIS_URI
serviceInfo = url.parse(redisService)

nconf.set('middleware:session:config:port', serviceInfo.port);
nconf.set('middleware:session:config:db', serviceInfo.pathname);

Migrating apps using manifest files

Apcera supports the use of creating apps using a manifest file.

Currently the Apcera platform does not read or consume manifests from other providers, but offers similar functionality. This allows you to create services at deploy time, and allows for reproducible deploys in the Apcera platform.