Dokumentacja hostowanych celów

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X.
info

Ograniczenia dotyczące zmiennych środowiskowych

Hostowane cele ograniczają rozmiar i liczbę zmiennych środowiskowych, które można ustawić w środowisku wykonawczym hostowanych celów.

  • 1000: maksymalna długość pojedynczej zmiennej środowiskowej.
  • 100: maksymalna liczba zmiennych środowiskowych, które możesz ustawić.

Informacje o ustawianiu zmiennych środowiskowych znajdziesz w artykule o pliku manifestu.

Zmienne środowiskowe ustawione w środowisku wykonawczym aplikacji

Gdy wdrażasz aplikację z celami hostowanymi, ustawiane są te zmienne środowiskowe, które są dostępne dla aplikacji w czasie działania:

  • APIGEE_ENVIRONMENT – środowisko, w którym wdrażany jest hostowany docelowy serwer proxy.
  • APIGEE_ORGANIZATION – organizacja, w której wdrażany jest hostowany docelowy serwer proxy.
  • PORT – port, na którym musi nasłuchiwać hostowana aplikacja docelowa.

Przydział zasobów systemowych

Każda instancja hostowanych celów otrzymuje te zasoby:

  • 256 MB pamięci
  • Procesor 1,2 GHz

Skalowanie

Z tej sekcji dowiesz się, jak skalować aplikacje hostowanych celów w zależności od typu konta Edge.
  • Wersja próbna Apigee Edge jest ograniczona do 1 instancji hostowanych celów na serwer proxy.
  • Płatne konta Apigee Edge korzystają z automatycznego skalowania na podstawie częstotliwości żądań, opóźnień odpowiedzi i innych danych aplikacji na podstawie serwera proxy.
  • Aplikacje hostowanych aplikacji docelowych wdrożone zarówno w płatnych, jak i próbnych wersjach Apigee Edge są skalowane do zera w okresach braku aktywności. W takim przypadku przez krótki czas możesz zauważyć dłuższy czas odpowiedzi. Zobacz też znane problemy

Plik manifestu

Aby zebrać informacje o środowisku wykonawczym na potrzeby kompilowania i wdrażania hostowanej aplikacji, Edge szuka pliku manifestu o nazwie app.yaml w katalogu resources/hosted. Ten plik zawiera informacje potrzebne do skompilowania i wdrażania aplikacji Hostowane cele.

Składnia pliku manifestu

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

Elementy pliku manifestu

Plik manifestu app.yaml zawiera te elementy:

  • runtime – (wymagany) typ wdrażanej aplikacji. Musisz podać wartość node.
  • runtimeVersion – (opcjonalnie) wersja środowiska wykonawczego używane przez aplikację. Domyślnie: Node.js LTS (v10.x). Inne opcje znajdziesz w oficjalnym repozytorium Dockera dla Node.
  • command – (opcjonalnie) umożliwia określenie polecenia do uruchomienia zamiast domyślnego polecenia służącego do uruchamiania aplikacji. Wartość domyślna: Node.js=npm
  • args – (opcjonalny) tablica argumentów wiersza poleceń przekazywanych do aplikacji (określona w standardowej składni tablicy YAML). Zwykle są one dodawane do polecenia domyślnego. Wartość domyślna to start. Na przykład domyślnie aplikacja Node.js otrzyma polecenie npm start.
  • env – (opcjonalny) tablica zmiennych środowiskowych (pary nazw i wartości) do ustawienia w środowisku wykonawczym hostowanych celów. Te zmienne są dostępne dla wdrożonej aplikacji hostowanej wartości docelowej.
    • name – nazwa zmiennej.
    • value | valueRef – masz 2 opcje. Możesz ustawić literał lub odwoływać się do wartości zapisanej w mapie wartości kluczy. Mapa klucz-wartość musi już istnieć w Twoim środowisku Edge. Zobacz Praca z mapami klucz-wartość.
      • Jeśli używasz właściwości value, musisz podać zmienną name i literał value. Na przykład:
        runtime: node
        env:
         - name: NODE_ENV
           value: production
      • Jeśli używasz właściwości valueRef, musisz podać nazwę mapy klucz-wartość (KVM) utworzonej wcześniej w Edge oraz klucz. Na przykład:
        runtime: node
        env:
          - name: DB_ENV
            value: production
          - name: DB_PASSWORD
            valueRef:
              name: hosted-kvm
              key: db-password

    Przykładowe pliki manifestu

    Ta sekcja zawiera przykładowe pliki manifestu dla aplikacji Node.js. Plik manifestu jest wymagany do wdrożenia aplikacji hostowanej usługi docelowej. Musi znajdować się w katalogu apiproxy/resources/hosted, a nazwa pliku musi mieć nazwę app.yaml.

    Poniżej znajdziesz przykładowe pliki app.yaml (manifestu) aplikacji Node.js.

    Przykład, w którym podano dosłowną zmienną środowiskową:

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

    Przykład z poleceniem start, argumentami wiersza poleceń i zmienną środowiskową.

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


    Przykład, w którym podano odwołanie do mapy klucz-wartość:

    Więcej informacji o dostępie do KVM zawiera plik manifestu.

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

    Przykładowe aplikacje hostowanych celów w GitHub

    Apigee udostępnia na GitHubie przykładowe serwery proxy z aplikacjami Hosted Targets napisanymi w Node.js. Możesz skopiować to repozytorium i wykonać instrukcje README, aby wdrożyć dowolny z serwerów proxy.

    Wymagania wstępne

    Aby wdrożyć przykłady, musisz mieć zainstalowane w systemie 2 narzędzia:

    • apigeetool – narzędzie wiersza poleceń do wdrażania serwerów proxy Edge.
    • get_token – narzędzie wiersza poleceń do uzyskiwania tokena autoryzacji wymaganego przez apigeetool.

    Jeśli chcesz testować próbki lokalnie, musisz też mieć zainstalowaną platformę Node.js.

    Pobieranie repozytorium przykładowego

    1. W przeglądarce otwórz stronę https://github.com/apigee/api-platform-samples.
    2. Kliknij Sklonuj lub pobierz i pobierz repozytorium do systemu lokalnego za pomocą wybranej metody.
    3. cd to <your install dir>/api-platform-samples/doc-samples/hosted-targets
    4. Po pobraniu repozytorium możesz przejść do dowolnego katalogu przykładowego i postępować zgodnie z instrukcjami w pliku README, aby wdrożyć przykładowy serwer proxy na urządzeniu Edge. Poniżej znajduje się polecenie wdrożenia. Wystarczy, że: zastąpisz wskazane parametry parametrami z Twojego konta 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 .

    Przykład: uruchamianie przykładowej aplikacji

    Klonowanie repozytorium przykładów

    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

    Testowanie aplikacji lokalnie

    Aby wykonać ten test lokalny, musisz mieć zainstalowany pakiet Node.js.

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

    Przykładowe dane wyjściowe:

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

    Wdrażanie serwera proxy

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

    Testowanie wdrożenia

    Wdrażanie może potrwać kilka minut. Jeśli wystąpi błąd wdrożenia, uruchom polecenie wdrażania ponownie.

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

    Przykładowe dane wyjściowe:

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

    Znane problemy

    • Opóźnienia w sieci – ponieważ aplikacja Node.js nie działa już w JVM maszyny wirtualnej MP, między MP a wdrożeniem występuje przeskok sieciowy. Oczywiście wiąże się to z kosztami, ale wstępne testy wskazują, że są one w przyzwoitych granicach.
    • Powolne odpowiedzi interfejsu API – infrastruktura, w której działają Twoje aplikacje, automatycznie skaluje się odpowiednio do potrzeb. Oznacza to, że aplikacja może być skalowana w dół do zera. W takim przypadku następne żądanie do interfejsu API będzie trwać nieco dłużej niż typowe żądania do interfejsu API, ponieważ infrastruktura rotuje instancje, aby przetworzyć żądania.
    • Błąd wdrożenia – jeśli podczas wdrażania serwera proxy Hosted Targets wystąpi błąd wdrożenia, spróbuj ponownie wdrożyć serwer proxy. W niektórych przypadkach może wystąpić przekroczenie limitu czasu wdrażania. Jeśli ponownie wdrożysz aplikację, problem powinien zniknąć.