Hosted Targets reference

You're viewing Apigee Edge documentation.
Go to the Apigee X documentation. info

Environment variable limits

Hosted Targets limits the size and number of environment variables that you can set in the Hosted Targets runtime environment.

  • 1000: Maximum length of a single environment variable.
  • 100: Maximum number of environment variables that you can set.

For information about setting environment variables, see The manifest file.

Environment variables set in the application runtime

When you deploy a Hosted Targets application, the following environment variables are set and are available to your application at runtime:

  • APIGEE_ENVIRONMENT - The environment where the Hosted Target proxy is deployed.
  • APIGEE_ORGANIZATION - The organization where the Hosted Target proxy is deployed.
  • PORT - The port where the Hosted Target application must listen.

System resource allocation

Each Hosted Targets instance receives the following resources:

  • 256 MB memory
  • 1.2 GHz CPU

Scaling

This section describes how Hosted Targets applications scale, depending on the type of Edge account you have.
  • A Trial version of Apigee Edge is limited to one Hosted Targets instance per proxy.
  • Paid Apigee Edge accounts receive automatic scaling based on request rate, response latencies, and other application metrics per proxy.
  • Hosted Targets apps deployed to both paid and trial versions of Apigee Edge scale to zero on periods of inactivity. In this case, you may notice slower response times for a brief period. See also Known issues

The manifest file

To gather runtime information for building and deploying the hosted application, Edge looks for a manifest file named app.yaml in the resources/hosted directory. This file contains information necessary to build and deploy the Hosted Targets application.

Manfiest file syntax

runtime: node
runtimeVersion: version_number
command: command_name
args: argument_array
env:
  - name: variable_name
    value: literal_value
  - name: variable_name
    valueRef:
      name: kvm_name
      key: kvm_value

Manifest file elements

A app.yaml manifest file includes these elements:

  • runtime - (Required) Specifies the type of application you are deploying. You must specify node.
  • runtimeVersion - (Optional) The version of the runtime that your application uses. Default: Node.js LTS (v10.x). Refer to the Docker official repository for Node for other options.
  • command - (Optional) Lets you specify a command to run other than the default command used to start your application. Default: Node.js=npm
  • args - (Optional) Array of command line arguments to pass to the application (specified in standard YAML array syntax). Typically, these are added to the default command. The default is start. For example, by default the Node.js app will be passed the command npm start.
  • env - (Optional) An array of environment variables (name/value pairs) to set in the Hosted Targets runtime environment. These variables are available to your deployed Hosted Targets app.
    • name - The variable name.
    • value | valueRef - You have two options. You can set a literal value or reference a value stored in a Key Value Map. The Key Value Map must already exist in your Edge environment. See Working with Key Value Maps
      • If you use value, then you must specify a variable name and a literal value. For example: 
        runtime: node
env:
 - name: NODE_ENV
   value: production
      • If you use valueRef, then you must supply the name of a Key Value Map (KVM) that you previously created in Edge and a key. For example: 
        runtime: node
env:
  - name: DB_ENV
    value: production
  - name: DB_PASSWORD
    valueRef:
      name: hosted-kvm
      key: db-password

    Example manifest files

    This section contains example manifest files for Node.js applications. A manifest file is required to deploy a Hosted Targets app, and must be located in the apiproxy/resources/hosted directory, and the filename must be app.yaml.

    Following are example app.yaml (manifest) files for Node.js apps.

    Example that specifies an literal environment variable: 

     runtime: node
 env:
   - name: NODE_ENV
     value: production

    Example with a start command, command-line arguments, and an environment variable.

     runtime: node
 command: ./node_modules/pm2/bin/pm2
 env:
   - name: NODE_ENV
     value: production
 args:
   - app.js


    Example that specifies a Key Value Map (KVM) reference:

    For more information about KVM access, see The Manifest file.

    runtime: node
env:
  - name: DB_ENV
    value: production
  - name: DB_PASSWORD
    valueRef:
      name: hosted-kvm
      key: db-password

    Sample Hosted Targets applications on GitHub

    Apigee provides sample proxies on GitHub with Hosted Targets applications written in Node.js. You can clone this repo and follow the README instructions to deploy any of the proxies.

    Prerequisites

    To deploy the samples, you must have two tools installed on your system:

    • apigeetool -- A command line tool for deploying Edge proxies.
    • get_token - A command line tool for obtaining an authorization token required by apigeetool.

    If you want to test samples locally, you must also have you must have Node.js installed.

    Obtaining the sample repo

    1. In a browser, go to https://github.com/apigee/api-platform-samples.
    2. Click Clone or download and pull the repo to your local system, using your preferred method.
    3. cd to <your install dir>/api-platform-samples/doc-samples/hosted-targets
    4. Once the repo is downloaded, you can cd to any of the sample directories and follow the README instructions to deploy a sample proxy to Edge. The deploy command is shown below. Simply replace the indicated parameters with ones for your Apigee account:
      5. get_token && apigeetool deployproxy \
  -o YOUR_ORGANIZATION \
  -e YOUR_ENVIRONMENT \
  --json \
  --token "$(< ~/.sso-cli/valid_token.dat)"\
  --api NAME_OF_THE_PROXY \
  --directory .

    Example: Executing a sample app

    Clone the samples repository

    cd ~/myhome
git clone https://github.com/apigee/api-platform-samples.git
cd ~/myhome/api-platform-samples/doc-samples/hosted-targets
cd node-hosted-hello

    Test the application locally

    You must have Node.js installed to do this local test.

     PORT=8081 node apiproxy/resources/hosted/index.js
 curl http://localhost:8081

    Example output:

    {"date":"2018-03-12T21:45:22.161Z","msg":"Hello, World!"}

    Deploy the proxy

     get_token && apigeetool deployproxy \
   -o myorg \
   -e test \
   --json \
   --token "$(< ~/.sso-cli/valid_token.dat)"\
   --api node-hosted-hello \
   --directory .

    Test the deployment

    The deployment may take a few minutes to complete. If you get a deployment error, execute the deploy command again.

    curl http://myorg-test.apigee.net/node-hosted-hello

    Example output:

    {"date":"2018-03-23T18:59:18.668Z","msg":"Hello, World!"

    Known Issues

    • Network Latencies - Now that the Node.js application no longer runs in the MP’s JVM, there is now a network hop between the MP and the deployment. Of course this comes at a cost but initial benchmarks show it to be well within a reasonable amount
    • Slow API Responses - The infrastructure running your applications automatically scales based on need. This means your application can actually scale down to zero instances and if that is the case, the next API request will take a little longer than typical API requests since the infrastructure is spinning up the instance(s) to process the request(s).
    • Deployment error - If you receive a deployment error when deploying a Hosted Targets proxy, try redeploying the proxy. In some cases, the deployment can time out and if you redeploy, the problem will resolve itself.