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
- Jeśli używasz właściwości value, musisz podać zmienną
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
- W przeglądarce otwórz stronę https://github.com/apigee/api-platform-samples.
- Kliknij Sklonuj lub pobierz i pobierz repozytorium do systemu lokalnego za pomocą wybranej metody.
- cd to <your install dir>/api-platform-samples/doc-samples/hosted-targets
- 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:
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ąć.