Cette page a été traduite par l'API Cloud Translation.

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

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

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 Hosted Cibles.

1 000: longueur maximale d'une variable d'environnement unique.
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 disponibles pour votre application au moment de l'exécution:

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

Allocation des ressources système

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

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

Scaling

Cette section décrit le scaling des applications des cibles hébergées, en fonction du type de compte Edge dont vous disposez.

Une version d'évaluation 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 à la fois dans les versions payantes et d'essai d'Apigee Edge effectuent un scaling à zéro instance lors des périodes d'inactivité. Dans ce cas, vous constaterez peut-être des temps de réponse plus longs pendant une courte période. Voir aussi Problèmes connus

Le fichier manifeste

Pour recueillir des informations sur l'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 à la création et au déploiement de l'application Hosted Cibles.

Syntaxe du fichier Manfiest

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 contient 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 qui de votre application. Valeur par défaut: Node.js LTS (v10.x). Reportez-vous au dépôt officiel de Docker pour les nœuds. pour découvrir d'autres options.
command (facultatif) : permet de spécifier une commande à exécuter autre que par défaut utilisée pour démarrer votre application. Par défaut : Node.js=npm
args : (facultatif) tableau d'arguments de ligne de commande à transmettre à la fonction (spécifiée dans la syntaxe de tableau YAML standard). En règle générale, celles-ci sont ajoutées à la commande par défaut. La valeur par défaut est start. Par exemple, l'application Node.js reçoit par défaut la commande npm start
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 déployée sur l'application Hosted Cibles. <ph type="x-smartling-placeholder">
</ph>
Les cibles hébergées limitent la taille et le nombre de variables d'environnement que vous pouvez définir. Voir Limites

name : le nom de la variable.
valeur | valueRef : vous avez deux options. Vous pouvez définir une valeur littérale ou référencer une valeur stockée dans un Key Value Map. Le mappage de clé-valeur existent déjà dans votre environnement périphérique. Consultez la page Utiliser des mappages de clés-valeurs. <ph type="x-smartling-placeholder">
- Si vous utilisez value, vous devez spécifiez une variable name et un littéral value. Exemple :
```
runtime: node
env:
 - name: NODE_ENV
   value: production
```
- Si vous utilisez valueRef, vous devez alors fournir le nom d'un Key Value Map (KVM) que vous avez créé précédemment dans Edge, ainsi qu'une clé. Exemple :
```
runtime: node
env:
  - name: DB_ENV
    value: production
  - name: DB_PASSWORD
    valueRef:
      name: hosted-kvm
      key: db-password
```
  La recherche KVM s'applique à l'environnement. Organisation et application/proxy des KVM le champ d'application ne sont pas acceptés. Les valeurs KVM sont injectées dans la KVM une fois au démarrage de l'application Node.js. Modifier la KVM ultérieurement n'aura aucun effet. L'option KVM vous permet de stocker des informations sensibles dans la KVM chiffrée Edge, plutôt que de le placer dans le groupe de proxy lui-même. Consultez la page Utiliser des mappages de clés-valeurs.

Exemples de fichiers manifestes

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

Rappelez-vous qu'il n'est pas nécessaire d'inclure un répertoire node_modules avec des cibles hébergées Application Node.js Lors du déploiement, Hosted Target exécute npm install pour extraire les dépendances spécifié dans le fichier package.json.

Vous trouverez ci-dessous des exemples de fichiers app.yaml (manifeste) 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 à un mappage de clés-valeurs (KVM, Key Value Map) :

Pour en savoir plus sur l'accès à KVM, consultez la section 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 README pour déployer l’un des proxies.

Prérequis

Pour déployer les exemples, deux outils doivent être installés sur votre système:

apigeetool : une ligne de commande pour 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 avoir installé 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 (Cloner ou télécharger) et extrayez le dépôt sur votre système local à l'aide de votre méthode préférée.
cd vers <votre répertoire d'installation>/api-platform-samples/doc-samples/Hosted-targets
Une fois le dépôt téléchargé, vous pouvez accéder à l'un des exemples de répertoire à l'aide de la commande cd, puis suivre les instructions Instructions README pour déployer un exemple de proxy sur Edge. La commande "deploy" est illustrée ci-dessous. Simply remplacez 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 une application exemple

Cloner le dépôt d'exemples

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

Node.js doit être installé pour effectuer ce test en 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éployez 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 obtenez une erreur de déploiement, exécutez à nouveau la commande "deploy".

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 de réseau : l'application Node.js ne s'exécute plus. dans la JVM du MP, il existe désormais un saut de réseau entre le MP et le déploiement. Bien entendu, Cela a un coût, mais les analyses comparatives initiales montrent qu'elle se situe bien dans les limites d'un montant raisonnable.
Réponses d'API lentes : l'infrastructure exécutant vos applications et effectue un scaling automatique en fonction des besoins. Cela signifie que votre application peut effectuer un scaling à la baisse aucune instance. Si c'est le cas, la requête API suivante prendra un peu plus de temps des requêtes API courantes, car l'infrastructure fait tourner la ou les instances pour traiter le demande(s) en attente.
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 et si vous effectuez un redéploiement, le problème se résoudra de lui-même.