Referência de destinos hospedados

Você está lendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

Limites de variáveis de ambiente

Os destinos hospedados limitam o tamanho e o número de variáveis de ambiente que podem ser definidas no ambiente de execução dos destinos hospedados.

  • 1.000: comprimento máximo de uma única variável de ambiente.
  • 100: número máximo de variáveis de ambiente que podem ser definidas.

Para mais informações sobre como definir variáveis de ambiente, consulte O arquivo de manifesto.

Variáveis de ambiente definidas no ambiente de execução do aplicativo

Ao implantar um aplicativo de destinos hospedados, as seguintes variáveis de ambiente são definidas e ficam disponíveis para o aplicativo no momento da execução:

  • APIGEE_ENVIRONMENT - o ambiente em que o proxy de destino hospedado é implantado.
  • APIGEE_ORGANIZATION - a organização em que o proxy de destino hospedado é implantado.
  • PORT - a porta em que o aplicativo de destino hospedado precisa detectar.

Alocação de recursos do sistema

Cada instância de destinos hospedados recebe os seguintes recursos:

  • 256 MB de memória
  • CPU de 1,2 GHz

Escalonamento

Esta seção descreve como os aplicativos de destinos hospedados são escalonados, dependendo do tipo de conta do Edge.
  • Uma versão de teste do Apigee Edge é limitada a uma instância de destinos hospedados por proxy.
  • As contas pagas do Apigee Edge recebem escalonamento automático com base na taxa de solicitação, nas latências de resposta, e em outras métricas de aplicativos por proxy.
  • Os apps de destinos hospedados implantados nas versões pagas e de teste do Apigee Edge são escalonados para zero em períodos de inatividade. Nesse caso, você pode notar tempos de resposta mais lentos por um breve período. Consulte também Problemas conhecidos

O arquivo de manifesto

Para coletar informações de execução para criar e implantar o aplicativo hospedado, o Edge procura por um arquivo de manifesto chamado app.yaml no diretório resources/hosted. Esse arquivo contém as informações necessárias para criar e implantar o aplicativo de destinos hospedados.

Sintaxe do arquivo de manifesto

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 do arquivo de manifesto

Um arquivo de manifesto app.yaml inclui estes elementos:

  • runtime : (obrigatório) especifica o tipo de aplicativo que você está implantando. É necessário especificar node.
  • runtimeVersion : (opcional) a versão do ambiente de execução que o aplicativo usa. Padrão: Node.js LTS (v10.x). Consulte o repositório oficial do Docker para Node para outras opções.
  • command : (opcional) permite especificar um comando a ser executado diferente do comando padrão usado para iniciar o aplicativo. Padrão: Node.js=npm
  • args : (opcional) matriz de argumentos de linha de comando a serem transmitidos ao aplicativo (especificados na sintaxe padrão da matriz YAML). Normalmente, eles são adicionados ao comando padrão. O padrão é start. Por exemplo, por padrão, o comando npm start será transmitido ao app Node.js.
  • env : (opcional) uma matriz de variáveis de ambiente (pares de nome/valor) a serem definidas no ambiente de execução de destinos hospedados. Essas variáveis estão disponíveis para o seu app de destinos hospedados implantado.
    • name : o nome da variável.
    • value | valueRef : há duas opções. É possível definir um valor literal ou referenciar um valor armazenado em um mapa de chave-valor. O mapa de chave-valor já precisa existir no ambiente do Edge. Consulte Como trabalhar com mapas de chave-valor
      • Se você usar value, especifique um namename de variável e um value literal. Por exemplo: 
        runtime: node
env:
 - name: NODE_ENV
   value: production
      • Se você usar valueRef, forneça o name de um mapa de chave-valor (KVM) criado anteriormente no Edge e uma key. Por exemplo: 
        runtime: node
env:
  - name: DB_ENV
    value: production
  - name: DB_PASSWORD
    valueRef:
      name: hosted-kvm
      key: db-password

    Exemplos de arquivos de manifesto

    Esta seção contém exemplos de arquivos de manifesto para aplicativos Node.js. Um arquivo de manifesto é necessário para implantar um app de destinos hospedados e precisa estar localizado no diretório apiproxy/resources/hosted e o nome do arquivo precisa ser app.yaml.

    A seguir, há exemplos de arquivos app.yaml (manifesto) para apps Node.js.

    Exemplo que especifica uma variável de ambiente literal: 

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

    Exemplo com um comando de início, argumentos de linha de comando e uma variável de ambiente.

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


    Exemplo que especifica uma referência de mapa de chave-valor (KVM):

    Para mais informações sobre o acesso ao KVM, consulte O arquivo de manifesto.

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

    Exemplos de aplicativos de destinos hospedados no GitHub

    A Apigee oferece exemplos de proxies no GitHub com aplicativos de destinos hospedados escritos em Node.js. É possível clonar esse repositório e seguir as instruções do README para implantar qualquer um dos proxies.

    Pré-requisitos

    Para implantar os exemplos, é necessário ter duas ferramentas instaladas no sistema:

    • apigeetool: uma ferramenta de linha de comando para implantar proxies do Edge.
    • get_token: uma ferramenta de linha de comando para receber um token de autorização exigido pelo apigeetool.

    Se você quiser testar exemplos localmente, também é necessário ter o Node.js instalado.

    Como receber o repositório de exemplo

    1. Em um navegador, acesse https://github.com/apigee/api-platform-samples.
    2. Clique em Clone or download e extraia o repositório para o sistema local usando o método de sua preferência.
    3. cd para <your install dir>/api-platform-samples/doc-samples/hosted-targets
    4. Depois que o repositório for transferido por download, você poderá acessar qualquer um dos diretórios de exemplo e seguir as instruções do README para implantar um proxy de exemplo no Edge. O comando de implantação é mostrado abaixo. Basta substituir os parâmetros indicados por aqueles da sua conta do 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 .

    Exemplo: execução de um app de exemplo

    Clone o repositório de exemplos

    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

    Testar o aplicativo localmente

    É necessário ter o Node.js instalado para fazer esse teste local.

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

    Exemplo de saída:

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

    Implante o proxy

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

    Teste a implantação

    A implantação pode levar alguns minutos para ser concluída. Se você receber um erro de implantação, execute o comando de implantação novamente.

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

    Exemplo de saída:

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

    Problemas conhecidos

    • Latências de rede : agora que o aplicativo Node.js não é mais executado na JVM do MP, há um salto de rede entre o MP e a implantação. É claro que isso tem um custo, mas os benchmarks iniciais mostram que ele está dentro de um valor razoável.
    • Respostas lentas da API - a infraestrutura que executa seus aplicativos é escalonada automaticamente com base na necessidade. Isso significa que o aplicativo pode reduzir escala verticalmente a zero instâncias e, nesse caso, a próxima solicitação de API levará um pouco mais de tempo do que as solicitações de API típicas, já que a infraestrutura está ativando as instâncias para processar as solicitações.
    • Erro de implantação : se você receber um erro de implantação ao implantar um proxy de destinos hospedados, tente reimplantar o proxy. Em alguns casos, a implantação pode atingir o tempo limite e, se você reimplantar, o problema será resolvido.