Dokumentacja hostowanych celów

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Limity zmiennych środowiskowych

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

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

Informacje na temat ustawiania zmiennych środowiskowych znajdziesz w artykule Plik manifestu.

Zmienne środowiskowe ustawione w środowisku wykonawczym aplikacji

Gdy wdrażasz aplikację hostowanych celów, ustawione są te zmienne środowiskowe i są dla niej dostępne w czasie działania:

  • APIGEE_ENVIRONMENT – środowisko, w którym wdrożony jest hostowany serwer proxy.
  • APIGEE_ORGANIZATION – organizacja, w której wdrożono serwer proxy hostowany.
  • PORT – port, na którym musi nasłuchiwać aplikacja hostowana w środowisku docelowym.

Przydzielanie zasobów systemowych

Każda instancja z obiektami docelowymi otrzymuje te zasoby:

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

Skalowanie

W tej sekcji opisano, jak skalują się aplikacje hostowanych celów w zależności od typu posiadanego konta Edge.
  • Wersja próbna Apigee Edge jest ograniczona do 1 instancji hostowanych celów na serwer proxy.
  • Płatne konta Apigee Edge otrzymują automatyczne skalowanie na podstawie częstotliwości żądań, opóźnień odpowiedzi i innych wskaźników aplikacji na serwer proxy.
  • Aplikacje hostowane w środowiskach docelowych wdrożone w płatnej i próbnej wersji Apigee Edge skalują się do zera w okresach braku aktywności. W takim przypadku odpowiedź może być krótsza niż zwykle. Zobacz też Znane problemy

Plik manifestu

Aby zebrać informacje o środowisku wykonawczym na potrzeby skompilowania i wdrożenia hostowanej aplikacji, Edge szuka pliku manifestu o nazwie app.yaml w katalogu resources/hosted. Ten plik zawiera informacje niezbędne do skompilowania i wdrożenia aplikacji hostowanych celów.

Składnia pliku 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

Elementy pliku manifestu

Plik manifestu app.yaml zawiera te elementy:

  • runtime – (wymagany) określa typ wdrażanej aplikacji. Musisz określić node.
  • runtimeVersion – (opcjonalnie) wersja środowiska wykonawczego używanego przez aplikację. Domyślnie: Node.js LTS (v10.x). Inne opcje znajdziesz w oficjalnym repozytorium Dockera dla węzła.
  • command – (opcjonalny) pozwala określić polecenie do uruchomienia innego niż domyślne. Domyślnie: Node.js=npm
  • args – (opcjonalny) tablica argumentów wiersza poleceń, które mają być przekazywane do aplikacji (określona w standardowej składni tablicy YAML). Są one zwykle dodawane do polecenia domyślnego. Wartość domyślna to start. Na przykład domyślnie aplikacja Node.js będzie przekazywała polecenie npm start.
  • env – (opcjonalnie) tablica zmiennych środowiskowych (pary nazw i wartości) do ustawienia w środowisku wykonawczym hostowanych elementów docelowych. Te zmienne są dostępne dla wdrożonej aplikacji hostowanych celów.
    • nazwa – nazwa zmiennej.
    • value | valueRef – masz dwie opcje. Możesz ustawić wartość literałową lub odniesienie do wartości przechowywanej w mapie par klucz-wartość. Mapa klucz-wartość musi już istnieć w środowisku Edge. Patrz Praca z mapami klucz-wartość
      • Jeśli używasz opcji value, musisz określić zmienną name i literał value. Na przykład:
        runtime: node
env:
 - name: NODE_ENV
   value: production
      • Jeśli używasz valueRef, musisz podać nazwę mapy klucz-wartość (KVM) utworzonej wcześniej w Edge i podać 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 aplikacji Node.js. Plik manifestu jest wymagany do wdrożenia aplikacji hostowanych celów. Musi on znajdować się w katalogu apiproxy/resources/hosted, a plik musi mieć nazwę app.yaml.

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

    Przykład, który określa literałową zmienną środowiskową: 

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

    Przykład z poleceniem rozpoczęcia, 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 określający odniesienie do mapy klucz-wartość (KVM):

    Więcej informacji o dostępie KVM znajdziesz w artykule Plik manifestu.

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

    Przykładowe aplikacje z hostowanymi obiektami na GitHubie

    Apigee udostępnia przykładowe serwery proxy na GitHubie z aplikacjami hostowanych celów napisanych 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, w systemie musisz zainstalować 2 narzędzia:

    • apigeetool – narzędzie wiersza poleceń służące do wdrażania serwerów proxy brzegowych.
    • get_token – narzędzie wiersza poleceń służące do uzyskiwania tokena autoryzacji wymaganego przez apigeetool.

    Jeśli chcesz przetestować przykłady lokalnie, musisz też zainstalować środowisko Node.js.

    Uzyskiwanie przykładowego repozytorium

    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 przy użyciu preferowanej metody.
    3. cd do <katalogu instalacji>/api-platform-samples/doc-samples/udostępnianych-targets
    4. Po pobraniu repozytorium możesz przejść do dowolnego z przykładowych katalogów i postępować zgodnie z instrukcjami README, aby wdrożyć przykładowy serwer proxy na serwerze Edge. Polecenie wdrożenia jest widoczne poniżej. Wystarczy, że zastąpisz wskazane parametry swoim kontem 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 przeprowadzić ten test lokalny, musisz mieć zainstalowany 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

    Wdrożenie może potrwać kilka minut. Jeśli pojawi się błąd wdrożenia, wykonaj 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 sieciowe – teraz, gdy aplikacja Node.js nie działa już w JVM maszyny wirtualnej, występuje przeskok sieciowy między MP a wdrożeniem. Oczywiście wiąże się to z pewnymi kosztami, ale wstępne analizy pokazują, że mieści się w rozsądnym zakresie
    • Powolne odpowiedzi interfejsu API – infrastruktura, w której działają aplikacje, automatycznie skaluje się w zależności od potrzeb. Oznacza to, że Twoja aplikacja może być skalowana w dół do 0 instancji, a jeśli tak się stanie, kolejne żądanie do interfejsu API potrwa trochę dłużej niż typowe żądania do interfejsu API, ponieważ infrastruktura obraca instancje w celu ich przetwarzania.
    • Błąd wdrażania – jeśli podczas wdrażania serwera proxy hostowanych obiektów docelowych pojawi się błąd wdrożenia, spróbuj ponownie wdrożyć serwer proxy. W niektórych przypadkach może nastąpić przekroczenie limitu czasu, a ponowne wdrożenie rozwiąże problem.