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

Vous consultez la documentation Apigee Edge.
Accéder à la documentation sur Apigee X en savoir plus

Limites des variables d'environnement

Hosted Targets limite la taille et le nombre de variables d'environnement que vous pouvez définir dans l'environnement d'exécution Hosted Targets.

  • 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 Hosted Targets, les variables d'environnement suivantes sont définies et sont 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 de cible hébergée 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 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 requêtes, 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 évoluent à zéro lors des périodes d'inactivité. Dans ce cas, vous remarquerez peut-être des délais de réponse plus longs pendant une courte période. Consultez également la page 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 à la compilation et au déploiement de l'application Hosted Targets.

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 de Docker pour les nœuds pour découvrir les autres options disponibles.
  • command : (facultatif) 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). 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.
    • name : nom de la variable.
    • value | valueRef : vous avez deux options. Vous pouvez définir une valeur littérale ou référencer une valeur stockée dans un mappage de clés-valeurs. Le mappage de valeurs clés doit déjà exister dans votre environnement périphérique. Consultez la page Utiliser des mappages de clés-valeurs.
      • Si vous utilisez valeur, vous devez spécifier une variable name et une valeur littérale value. Exemple : 
        runtime: node
env:
 - name: NODE_ENV
   value: production
      • Si vous utilisez valueRef, vous devez fournir le nom d'un mappage clé-valeur (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

    Exemples de fichiers manifestes

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

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

    Exemple spécifiant 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 spécifiant une référence de mappage clé-valeur (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 Hosted Targets 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 avoir installé Node.js.

    Obtenir l'exemple de dépôt

    1. Dans un navigateur, accédez à https://github.com/apigee/api-platform-samples.
    2. Cliquez sur Cloner ou télécharger, puis extrayez le dépôt sur votre système local à l'aide de la méthode de votre choix.
    3. cd vers <votre répertoire d'installation>/api-platform-samples/doc-samples/hosted-targets
    4. 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 dans Edge. La commande de déploiement est présentée ci-dessous. Il vous suffit de remplacer les paramètres indiqués par ceux de votre compte Apigee:
      5. 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

    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é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 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 : maintenant que l'application Node.js ne s'exécute plus dans la JVM du MP, il existe un saut réseau entre le MP et le déploiement. Bien sûr, cela a un coût, mais les benchmarks initiaux montrent qu'il est tout à fait raisonnable.
    • Réponses d'API lentes : l'infrastructure exécutant vos applications évolue automatiquement en fonction des besoins. Cela signifie que votre application peut être réduite à zéro instance. Si tel est le cas, la prochaine requête API prendra un peu plus de temps que les requêtes API standards, car l'infrastructure lance l'instance 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 Hosted Targets, réessayez de le déployer. Dans certains cas, le délai avant expiration du déploiement peut être dépassé. Si vous le redéployez, le problème se résout de lui-même.