Referência de destinos hospedados

Você está visualizando 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: tamanho 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 variáveis de ambiente a seguir são definidas e disponibilizadas para o aplicativo no ambiente de execução:

  • APIGEE_ENVIRONMENT: o ambiente onde 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 do Hosted Targets são dimensionados, dependendo do tipo de conta do Edge.
  • Uma versão de avaliação 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 reduzidos a zero em períodos de inatividade. Nesse caso, os tempos de resposta podem ficar mais lentos por um breve período. Consulte também Problemas conhecidos.

O arquivo de manifesto

Para coletar informações sobre o ambiente de execução para criar e implantar o aplicativo hospedado, o Edge procura um arquivo de manifesto chamado app.yaml no diretório resources/hosting. 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 conferir 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 para o aplicativo (especificado na sintaxe de matriz YAML padrão). Normalmente, elas são adicionadas ao comando padrão. O padrão é start. Por exemplo, o app Node.js receberá o comando npm start por padrão.
  • env: (opcional) uma matriz de variáveis de ambiente (pares de nome/valor) a serem definidas no ambiente de execução dos destinos hospedados. Essas variáveis estão disponíveis para o app de destinos hospedados implantado.
    • name: o nome da variável.
    • value | valueRef: você tem 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 precisa já existir no seu ambiente do Edge. Consulte Como trabalhar com mapas de chave-valor.
      • Se você usar value, será necessário especificar uma variável name e um literal value. Por exemplo: 
        runtime: node
env:
 - name: NODE_ENV
   value: production
      • Se você usar valueRef, será necessário fornecer o nome de um mapa de chave-valor (KVM) criado anteriormente no Edge e uma chave. 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 destino hospedado e precisa estar localizado no diretório apiproxy/resources/hosted, e o nome do arquivo precisa ser app.yaml.

    Confira a seguir 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 "start", 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 do mapa de chave-valor (KVM):

    Para saber mais sobre o acesso à 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 do Targets hospedado no GitHub

    O Apigee oferece proxies de exemplo no GitHub com aplicativos de destino hospedado escritos em Node.js. Você pode clonar este repositório e seguir as instruções do README para implantar qualquer um dos proxies.

    Pré-requisitos

    Para implantar as amostras, você precisa ter duas ferramentas instaladas no seu sistema:

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

    Se quiser testar amostras localmente, você também precisa ter o Node.js instalado.

    Como acessar o repositório de exemplo

    1. Em um navegador, acesse https://github.com/apigee/api-platform-samples.
    2. Clique em Clonar ou fazer o download e extraia o repositório para o sistema local usando seu método preferido.
    3. cd para <diretório de instalação>/api-platform-samples/doc-samples/hosting-targets
    4. Depois de fazer o download do repositório, é possível usar o comando cd para acessar qualquer um dos diretórios de amostra e seguir as instruções do README para implantar um proxy de amostra no Edge. O comando "deploy" é mostrado abaixo. Basta substituir os parâmetros indicados pelos parâmetros da sua conta da 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 amostras

    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: como 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 comparativos de mercado iniciais mostram que ela está dentro de uma quantidade razoável
    • Respostas de API lentas: a infraestrutura que executa seus aplicativos é escalonada automaticamente com base na necessidade. Isso significa que o aplicativo pode reduzir a escala a zero instâncias e, se esse for o caso, a próxima solicitação de API vai demorar um pouco mais do que as solicitações de API normais, já que a infraestrutura está ativando as instâncias para processar as solicitações.
    • Erro de implantação: se você receber um erro ao implantar um proxy do Hosted Targets, tente fazer a implantação novamente. Em alguns casos, a implantação pode expirar e, se você reimplantar, o problema será resolvido automaticamente.