Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Documentation de référence sur les cibles hébergées

Vous consultez la documentation Apigee Edge.
Accédez à la documentation**Apigee X**. info

Limites des variables d'environnement

Les cibles hébergées limitent la taille et le nombre de variables d'environnement que vous pouvez définir dans l'environnement d'exécution des cibles hébergées.

1 000 : longueur maximale d'une seule variable d'environnement.
100 : nombre maximal de variables d'environnement que vous pouvez définir.

Pour en savoir plus sur la définition des variables d'environnement, consultez le fichier manifeste.

Variables d'environnement définies dans l'environnement d'exécution de l'application

Lorsque vous déployez une application de cibles hébergées, les variables d'environnement suivantes sont définies et sont disponibles pour votre application au moment de l'exécution :

APIGEE_ENVIRONMENT : environnement dans lequel le proxy de cibles hébergées est déployé.
APIGEE_ORGANIZATION : organisation dans laquelle le proxy de cibles hébergées est déployé.
PORT : port sur lequel l'application de cibles hébergées doit écouter.

Allocation des ressources système

Chaque instance de cibles hébergées reçoit les ressources suivantes :

256 Mo de mémoire
1,2 GHz de processeur

Scaling

Cette section décrit comment les applications de cibles hébergées sont mises à l'échelle, en fonction du type de compte Edge dont vous disposez.

Une version d'essai d'Apigee Edge est limitée à une instance de cibles hébergées par proxy.
Les comptes Apigee Edge payants bénéficient d'un scaling automatique basé sur le taux de demandes, les latences de réponse, et d'autres métriques d'application par proxy.
Les applications de cibles hébergées déployées dans les versions payantes et d'essai d'Apigee Edge sont mises à l'échelle à zéro pendant les périodes d'inactivité. Dans ce cas, vous remarquerez peut-être des temps de réponse plus lents pendant une courte période. Consultez également l'article Problèmes connus.

Le fichier manifeste

Pour collecter des informations d'exécution afin de créer et de déployer l'application hébergée, Edge recherche un fichier manifeste nommé app.yaml dans le répertoire resources/hosted. Ce fichier contient les informations nécessaires pour créer et déployer l'application de cibles hébergées.

Syntaxe du fichier manifeste

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

Éléments du fichier manifeste

Un fichier manifeste app.yaml inclut les éléments suivants :

runtime : (obligatoire) spécifie le type d'application que vous déployez. Vous devez spécifier node.
runtimeVersion : (facultatif) version de l'environnement d'exécution utilisée par votre application. Valeur par défaut : Node.js LTS (v10.x). Pour connaître les autres options, consultez le dépôt Docker officiel pour Node.
command : (facultatif) vous permet de spécifier une commande à exécuter autre que la commande par défaut utilisée pour démarrer votre application. Valeur par défaut : Node.js=npm
args : (facultatif) tableau d'arguments de ligne de commande à transmettre à l' application (spécifié dans la syntaxe de tableau YAML standard). En règle générale, ils sont ajoutés à la commande par défaut. La valeur par défaut est start. Par exemple, par défaut, la commande npm start est transmise à l'application Node.js.
env : (facultatif) tableau de variables d'environnement (paires nom/valeur) à définir dans l'environnement d'exécution des cibles hébergées. Ces variables sont disponibles pour votre application de cibles hébergées déployée.
Les cibles hébergées limitent la taille et le nombre de variables d'environnement que vous pouvez définir. Consultez les limites.

name : nom de la variable.
value | valueRef : deux options s'offrent à vous. Vous pouvez définir une valeur littérale ou référencer une valeur stockée dans un mappage clé-valeur. Le mappage clé-valeur doit déjà exister dans votre environnement Edge. Consultez Utiliser des mappages clé-valeur
- Si vous utilisez value, vous devez spécifier un name de variable et une value littérale. Exemple :
```
runtime: node
env:
 - name: NODE_ENV
   value: production
```
- Si vous utilisez valueRef, vous devez fournir le name d'un mappage clé-valeur (KVM) que vous avez créé précédemment dans Edge et une key. Exemple :
```
runtime: node
env:
  - name: DB_ENV
    value: production
  - name: DB_PASSWORD
    valueRef:
      name: hosted-kvm
      key: db-password
```
  La recherche de KVM est limitée à l'environnement. L'organisation KVM et le champ d'application de l'application/du proxy ne sont pas compatibles. Les valeurs KVM sont injectées dans le KVM une seule fois au démarrage de l'application Node.js. La modification ultérieure du KVM n'aura aucun effet. L'option KVM vous permet de stocker des informations sensibles dans le KVM chiffré Edge, plutôt que de les placer dans le bundle de proxy lui-même. Consultez Utiliser des mappages clé-valeur.

Exemples de fichiers manifestes

Cette section contient des exemples de fichiers manifestes pour les applications Node.js applications. Un fichier manifeste est requis pour déployer une application de cibles hébergées. Il doit se trouver dans le apiproxy/resources/hosted répertoire et son nom de fichier doit être app.yaml.

N'oubliez pas que vous n'avez pas besoin d'inclure un répertoire node_modules avec une application Node.js de cibles hébergées. Lors du déploiement, les cibles hébergées exécutent npm install pour extraire toutes les dépendances spécifiées dans le fichier package.json

Vous trouverez ci-dessous des exemples de fichiers app.yaml (manifestes) pour les applications Node.js.

Exemple qui spécifie une variable d'environnement littérale :

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

Exemple avec une commande de démarrage, des arguments de ligne de commande et une variable d'environnement.

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

Exemple qui spécifie une référence de mappage clé-valeur (KVM) :

Pour en savoir plus sur l'accès KVM, consultez le fichier manifeste.

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

Exemples d'applications de cibles hébergées sur GitHub

Apigee fournit des exemples de proxys sur GitHub avec des applications de cibles hébergées écrites en Node.js. Vous pouvez cloner ce dépôt et suivre les instructions du fichier README pour déployer l'un des proxys.

Prérequis

Pour déployer les exemples, vous devez installer deux outils sur votre système :

apigeetool : outil de ligne de commande permettant de déployer des proxys Edge.
get_token : outil de ligne de commande permettant d'obtenir un jeton d'autorisation requis par apigeetool.

Si vous souhaitez tester des exemples en local, vous devez également installer Node.js.

Obtenir l'exemple de dépôt

Dans un navigateur, accédez à https://github.com/apigee/api-platform-samples.
Cliquez sur Clone or download et extrayez le dépôt vers votre système local à l'aide de de la méthode de votre choix.
Accédez à <your install dir>/api-platform-samples/doc-samples/hosted-targets.
Une fois le dépôt téléchargé, vous pouvez accéder à l'un des répertoires d'exemples et suivre les instructions du fichier README pour déployer un exemple de proxy sur Edge. La commande de déploiement est indiquée ci-dessous. Il vous suffit de remplacer les paramètres indiqués par ceux de votre compte Apigee :

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

Exemple : Exécuter un exemple d'application

Cloner l'exemple de dépôt

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

Tester l'application en local

Vous devez avoir installé Node.js pour effectuer ce test local.

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

Exemple de résultat :

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

Déployer le proxy

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

Tester le déploiement

Le déploiement peut prendre quelques minutes. Si vous recevez une erreur de déploiement, exécutez à nouveau la commande de déploiement.

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

Exemple de résultat :

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

Problèmes connus

Latences réseau : l'application Node.js ne s'exécutant plus dans la JVM du processeur de messages, il existe désormais un saut réseau entre le processeur de messages et le déploiement. Bien sûr, cela a un coût, mais les benchmarks initiaux montrent qu'il reste dans une limite raisonnable.
Réponses d'API lentes : l'infrastructure exécutant vos applications est automatiquement mise à l'échelle en fonction des besoins. Cela signifie que votre application peut être mise à l'échelle à zéro instance. Dans ce cas, la requête d'API suivante prendra un peu plus de temps que les requêtes d'API classiques, car l'infrastructure lancera la ou les instances pour traiter la ou les requêtes.
Erreur de déploiement : si vous recevez une erreur de déploiement lors du déploiement d'un proxy de cibles hébergées, essayez de redéployer le proxy. Dans certains cas, le déploiement peut expirer. Si vous le redéployez, le problème se résoudra de lui-même.