Se usó la API de Cloud Translation para traducir esta página.

Referencia de Destinos alojados

Estás viendo la documentación de Apigee Edge.
Ve a la documentación de Apigee X. Más información

Límites de variables de entorno

Los destinos alojados limitan el tamaño y la cantidad de variables de entorno que puedes configurar en el entorno de ejecución de los destinos alojados.

1000: Es la longitud máxima de una sola variable de entorno.
100: Es la cantidad máxima de variables de entorno que puedes configurar.

Para obtener información sobre la configuración de variables de entorno, consulta El archivo de manifiesto.

Variables de entorno configuradas en el entorno de ejecución de la aplicación

Cuando implementas una aplicación de destinos alojados, se configuran las siguientes variables de entorno y están disponibles para tu aplicación en el entorno de ejecución:

APIGEE_ENVIRONMENT: Es el entorno en el que se implementa el proxy de destino alojado.
APIGEE_ORGANIZATION: Es la organización en la que se implementa el proxy de destino alojado.
PORT: Es el puerto en el que la aplicación de destino alojada debe escuchar.

Asignación de recursos del sistema

Cada instancia de destinos alojados recibe los siguientes recursos:

256 MB de memoria
CPU de 1.2 GHz

Escalamiento

En esta sección, se describe cómo escalan las aplicaciones de destinos alojados, según el tipo de cuenta de Edge que tengas.

La versión de prueba de Apigee Edge se limita a una instancia de Destinos alojados por proxy.
Las cuentas pagadas de Apigee Edge reciben el ajuste de escala automático según el porcentaje de solicitudes, las latencias de respuesta y otras métricas de la aplicación por proxy.
Las apps de destinos alojados implementadas en las versiones pagadas y de prueba de Apigee Edge reducen la escala a cero durante los períodos de inactividad. En este caso, es posible que notes tiempos de respuesta más lentos durante un período breve. Consulta también Problemas conocidos

El archivo de manifiesto

Para recopilar información del entorno de ejecución para compilar y, luego, implementar la aplicación alojada, Edge busca un archivo de manifiesto llamado app.yaml en el directorio resources/hosted. Este archivo contiene la información necesaria para compilar y, luego, implementar la aplicación de destinos alojados.

Sintaxis del archivo de manifiesto

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

Elementos del archivo de manifiesto

Un archivo de manifiesto app.yaml incluye estos elementos:

runtime: (Obligatorio) Especifica el tipo de aplicación que implementas. Debes especificar node.
runtimeVersion (opcional): Es la versión del entorno de ejecución que usa tu aplicación. Predeterminada: Node.js LTS (v10.x). Si deseas conocer otras opciones, consulta el repositorio oficial de Docker para Node.
command (opcional): Te permite especificar un comando para ejecutar que no sea el comando predeterminado que se usa con el fin de iniciar la aplicación. Predeterminada: Node.js=npm
args: Es un array (opcional) de argumentos de línea de comandos que se pasarán a la aplicación (especificado en la sintaxis estándar del array de YAML). Por lo general, se agregan al comando predeterminado. El valor predeterminado es start. Por ejemplo, de forma predeterminada, a la app de Node.js se le pasará el comando npm start.
env: Opcional: Un array de variables de entorno (pares nombre/valor) que se configurará en el entorno de ejecución de objetivos alojados. Estas variables están disponibles para la app de Hosted Target implementada.
Los destinos alojados limitan el tamaño y la cantidad de variables de entorno que puedes configurar. Consulta Límites.

name: Es el nombre de la variable.
value | valueRef: Tienes dos opciones. Puedes establecer un valor literal o hacer referencia a un valor almacenado en un mapa de par clave-valor. El mapa de par clave-valor ya debe existir en tu entorno de Edge. Consulta Cómo trabajar con mapas de par clave-valor.
- Si usas value, debes especificar una variable name y un value literal. Por ejemplo:
```
runtime: node
env:
 - name: NODE_ENV
   value: production
```
- Si usas valueRef, debes proporcionar el nombre de un mapa de pares clave-valor (KVM) que creaste anteriormente en Edge y una clave. Por ejemplo:
```
runtime: node
env:
  - name: DB_ENV
    value: production
  - name: DB_PASSWORD
    valueRef:
      name: hosted-kvm
      key: db-password
```
  La búsqueda de KVM se limita al entorno. No se admiten la organización de KVM ni el alcance de la aplicación o el proxy. Los valores de KVM se insertan en el KVM una vez cuando se inicia la app de Node.js. Si modificas el KVM más adelante, esto no tendrá ningún efecto. La opción de KVM te permite almacenar información sensible en el KVM encriptado de Edge, en lugar de colocarla en el paquete de proxy. Consulta Trabaja con mapas de par clave-valor.

Ejemplos de archivos de manifiesto

Esta sección contiene archivos de manifiesto de ejemplo para aplicaciones de Node.js. Se requiere un archivo de manifiesto para implementar una app de destinos alojados, que debe ubicarse en el directorio apiproxy/resources/hosted y cuyo nombre debe ser app.yaml.

Recuerda que no es necesario que incluyas un directorio node_modules con una app de Node.js de destinos alojados. Después de la implementación, los destinos alojados ejecutan npm install para extraer las dependencias especificadas en el archivo package.json.

A continuación, se muestran ejemplos de archivos app.yaml (manifiesto) para apps de Node.js.

Ejemplo en el que se especifica una variable de entorno literal:

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

Ejemplo con un comando de inicio, argumentos de línea de comandos y una variable de entorno.

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

Ejemplo en el que se especifica una referencia de un mapa de par clave-valor (KVM):

Para obtener más información sobre el acceso a KVM, consulta Archivo de manifiesto.

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

Aplicaciones de destinos alojados de ejemplo en GitHub

Apigee proporciona proxies de muestra en GitHub con aplicaciones de destinos alojados escritas en Node.js. Puedes clonar este repositorio y seguir las instrucciones README para implementar cualquiera de los proxies.

Requisitos previos

Para implementar los ejemplos, debes tener dos herramientas instaladas en tu sistema:

apigeetool: Es una herramienta de línea de comandos para implementar proxies de Edge.
get_token: Es una herramienta de línea de comandos para obtener un token de autorización que requiere apigeetool.

Si quieres probar muestras de forma local, también debes tener instalado Node.js.

Cómo obtener el repositorio de muestra

En un navegador, dirígete a https://github.com/apigee/api-platform-samples.
Haz clic en Clone or download y extrae el repositorio a tu sistema local con el método que prefieras.
cd a <your install dir>/api-platform-samples/doc-samples/usercontent-targets
Cuando se descargue el repositorio, puedes dirigirte a cualquiera de los directorios de muestra y seguir las instrucciones README para implementar un proxy de muestra en Edge. El comando de implementación se muestra a continuación. Solo debes reemplazar los parámetros indicados por los de tu cuenta de Apigee:

get_token && apigeetool deployproxy \
  -o YOUR_ORGANIZATION \
  -e YOUR_ENVIRONMENT \
  --json \
  --token "$(< ~/.sso-cli/valid_token.dat)"\
  --api NAME_OF_THE_PROXY \
  --directory .

Ejemplo: Cómo ejecutar una app de ejemplo

Clona el repositorio de muestras

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

Prueba la aplicación de forma local

Debes tener instalado Node.js para realizar esta prueba local.

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

Resultado de ejemplo:

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

Implementa el proxy

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

Prueba la implementación

La implementación puede tardar unos minutos en completarse. Si recibes un error de implementación, vuelve a ejecutar el comando de implementación.

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

Resultado de ejemplo:

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

Problemas conocidos

Latencias de red: Ahora que la aplicación de Node.js ya no se ejecuta en la JVM del MP, hay un salto de red entre el MP y la implementación. Esto tiene un costo, pero las comparativas iniciales muestran que se encuentra dentro de un importe razonable
Respuestas lentas a la API: La infraestructura que ejecuta tus aplicaciones se ajusta automáticamente según las necesidades. Esto significa que tu aplicación puede escalar hasta cero instancias y, si ese es el caso, la siguiente solicitud a la API tardará un poco más que las solicitudes típicas a la API, ya que la infraestructura está iniciando las instancias para procesar las solicitudes.
Error de implementación: Si recibes un error de implementación cuando implementas un proxy de objetivos alojados, intenta volver a implementarlo. En algunos casos, es posible que se agote el tiempo de espera de la implementación y, si la vuelves a implementar, el problema se resolverá solo.