Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

If the application is already deployed, you need to either increment the version field in the package.json file to publish a new version of the application or pass the --force flag to the publish command to republish the application. Before republishing the application, API Runtime Services sends the SIGTERM signal to the currently deployed application to let it shutdown gracefully. If the app does not shutdown shut down in time, API Runtime Services will kill the application.

...

The execution time reported by the loglist and accesslog commands report slightly different values. The accesslog command reports the time required by Appcelerator Cloud to handle the initial user request, pass it to your Node,.js application for processing, and deliver the response. In contrast, loglist only reports the execution time for your application itself, not including the time required to process the request and response. Consequently, the accesslog execution times are a slightly longer than those of the corresponding loglist log item. For instance, below is accesslog output:

...

Multiexcerpt
MultiExcerptNamemigration

Node.js version

Prior to API Runtime Services (formerly known as Arrow Cloud) 1.2.0, the only Node.js versions you could use were 0.8.26 and 0.10.22.

Starting with API Runtime Services 1.2.0, you may specify any version of Node.js. Node.js 0.8.26, 0.10.22 and 0.12.4 are built in, but other versions will be downloaded from https://nodejs.org/ when the application is built prior to running npm install.

To specify a Node.js version, in the package.json file, set the engines.node key to the version of Node.js you want to use. DO NOT SPECIFY A RANGE. If you do not specify a Node.js version, the application will use 4.4.7 by default (as of SDK 6.0.0).

Code Block
titlepackage.json
{
  "engines": {
    "node": "0.12.4"
  }
}

Port binding

Starting with API Runtime Services 1.2.0, you may explicitly set the port the application listens on. Set the cloud.environment.PORT key in the appc.json file. or use the appc cloud config --set "PORT=<PORT_NUMBER>" command to set the special environment variable PORT. If you do not set PORT explicitly before publishing your application, API Runtime Services sets it to 80 by default.

Code Block
titleappc.json
{
  cloud: {
    environment: {
      PORT: 8080
    }
  }
}

Verify that the application listens on PORT, otherwise your app cannot be connected. Use process.env.PORT in the application to verify the application is connected to a port.

Install custom binaries

API Runtime Services allows you to install additional binaries before your application is built.

Starting with API Runtime Services 1.3.0, to install additional third-party tools, create a script called install.sh in the project's root folder, which installs the required packages.

Info
titleImageMagick and PhantomJS

Both ImageMagick and PhantomJS are pre-installed on the containers. 

Below is a sample script located in the ./install.sh folder in the application's directory.

Code Block
titleinstall.sh
languagebash
#!/bin/bash

echo "---"
echo "Start installing some tools..."
echo "(This bash script is run at npm preinstall.)"
echo "---"

apt-get install -qq tar bzip2 libaio1

apt-get install -y wget

echo "---"
echo "done installing additional tools!"
echo "---"

Prior to Release 1.3.0, you needed to create a script in your project folder (no name restrictions) and add the script to the package.json file. In the  package.json  file, set the  scripts.preinstall  or scripts.postinstall field to the path to the script:

Code Block
titlepackage.json
  "scripts": {
    "preinstall": "myscript.sh"
  }

Note that from API Runtime Services 1.3.0 and later, you can still use the above method but do not name the script install.sh or it will run twice, and only install the binaries in the project directory. Prior to API Runtime Services 1.3.0, binaries could be installed outside the project directory.

...

Starting with API Runtime Services 1.3.1, if you have scaled your application to use more than one server container, you can make a request to a specific container that your application is running on. To make a request to a specific server container, pass the _serverid parameter with the request and set it to the ID of the server container. To retrieve the server container ID, run the appc cloud cloud accesslog --show_serverid command.

...

You can bind a custom domain to your application that points to either a CNAME record or A record as well as assign it a path. When setting the domain, do no not specify the protocol, that is, do not prefix the URL with http:// or https://.

...

To set a custom domain, set the cloud.domain field in the appc.json file. You can optionally set the cloud.domainPath field to assign a path to the application. The following example sets a domain and path on the application that can be accessed from www.foo.com/v2

...

  • Certificate file (customapp.com.crt, for example)
  • Intermediate An intermediate certificate authority (gd_bundle.crt, for example)
  • Key used to generate the certificate (customapp.com.key, for example)

...

  • To specify a bigger container for the application, set the cloud.container field in the appc.json file or use the appc cloud server command.
  • To use more than one container for your application, see Scale the Application.

You can specify one of the following container sizes depending on your AMPLIFY Appcelerator Services subscription:

Excerpt
NamePoint CostMemoryCPU SharesArchive Behavior
Dev1512MB1000After an hour of inactivity
Small2256MB1000After a week of inactivity
Medium4512MB2000After a week of inactivity
Large81024MB4000After a week of inactivity
XLarge162048MB8000After a week of inactivity
Note

It is important to choose Dev (512MB) and Small (256MB) containers wisely. We recommend the use of a Medium or larger container for MBS (formerly known as ArrowDB) apps.

If your application is archived, to reactivate the application, make a request to it. The first request will be slow, but subsequent requests will respond with normal speed.

...