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

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

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation 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 des cibles hébergées.

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 la section 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 cible hébergée est déployé.
APIGEE_ORGANIZATION : organisation dans laquelle le proxy Hosted Target est déployé.
PORT : port sur lequel l'application Hosted Target 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 1,2 GHz

Mise à l'échelle

Cette section décrit comment les applications de cibles hébergées s'adaptent en fonction de votre type de compte Edge.

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 en fonction du taux de demandes, des latences de réponse et d'autres métriques d'application par proxy.
La fonctionnalité Hosted Cibles les applications déployées sur les versions payantes et d'essai d'Apigee Edge effectue un scaling à zéro pendant les périodes d'inactivité. Dans ce cas, vous constaterez peut-être des temps de réponse plus longs pendant une courte période. Consultez également la page Problèmes connus.

Fichier manifeste

Pour recueillir des informations d'exécution pour la création et le déploiement de 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 compilation 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 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). Reportez-vous au dépôt officiel Docker pour Node pour connaître les autres options.
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. 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). Ils sont généralement ajoutés à 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 "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. Voir Limites

name : nom de la variable.
value | valueRef : vous avez deux options. Vous pouvez définir une valeur littérale ou faire référence à une valeur stockée dans un mappage de valeurs clés. Le mappage de clé-valeur doit déjà exister dans votre environnement périphérique. Consultez la section Utiliser des cartes clés-valeurs.
- Si vous utilisez value, vous devez spécifier 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 mappage de valeurs clés (KVM) que vous avez précédemment créé dans Edge et une clé. Par exemple :
```
runtime: node
env:
  - name: DB_ENV
    value: production
  - name: DB_PASSWORD
    valueRef:
      name: hosted-kvm
      key: db-password
```
  La recherche KVM est limitée à l'environnement. L'organisation KVM et le champ d'application application/proxy ne sont pas pris en charge. Les valeurs KVM sont injectées dans 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 le KVM chiffré en périphérie, plutôt que de les placer dans le groupe de proxys lui-même. Consultez la page Utiliser des cartes clés-valeurs.

Exemples de fichiers manifestes

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

Rappelez-vous qu'il n'est pas nécessaire 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écute npm install pour extraire toutes les dépendances spécifiées dans le fichier package.json.

Vous trouverez ci-dessous des exemples de fichiers manifestes app.yaml 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 de référence de mappage de clés-valeurs (KVM) :

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 du fichier README pour déployer les proxys.

Conditions préalables

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

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

Si vous souhaitez tester des exemples en local, Node.js doit également être installé.

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) pour extraire le dépôt sur votre système local en utilisant la méthode de votre choix.
cd pour <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'exemple et suivre les instructions README pour déployer un exemple de proxy sur Edge. La commande de déploiement est illustrée ci-dessous. Il vous suffit de remplacer les paramètres indiqués par ceux associés à 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 : maintenant que l'application Node.js ne s'exécute plus dans la JVM du protocole de mesure, il y a désormais un saut de réseau entre le point de vue et le déploiement. Bien sûr, cette approche a un coût, mais les benchmarks initiaux montrent que cette approche se situe dans une limite raisonnable.
Réponses d'API lentes : l'infrastructure qui exécute vos applications évolue automatiquement en fonction des besoins. Cela signifie que votre application peut effectivement être réduite à zéro instance et que, dans ce cas, la requête API suivante prendra un peu plus de temps que les requêtes API classiques, car l'infrastructure démarre 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 dépasser le délai. Si vous redéployez la fonctionnalité, le problème se résout de lui-même.