Dokumentacja operacji i konfiguracji Edge Microgateway

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

Edge Microgateway w wersji 3.0.x

W tym artykule dowiesz się, jak zarządzać Edge Microgateway i konfigurować to narzędzie.

Uaktualnianie Edge Microgateway, jeśli masz połączenie z internetem

W tej sekcji dowiesz się, jak uaktualnić istniejącą instalację Edge Microgateway. Jeśli nie masz połączenia z internetem, zapoznaj się z artykułem Czy mogę zainstalować Edge Microgateway bez połączenia z internetem?.

Apigee zaleca przetestowanie obecnej konfiguracji w nowej wersji przed uaktualnieniem środowiska produkcyjnego.

1. Aby przejść na najnowszą wersję Edge Microgateway, uruchom to polecenie npm:

   npm upgrade edgemicro -g

   Aby przejść na konkretną wersję Edge Microgateway, musisz podać numer wersji w poleceniu uaktualnienia. Jeśli nie podasz numeru wersji, zostanie zainstalowana najnowsza wersja. Aby na przykład przejść na wersję 3.0.2, użyj tego polecenia:

   npm upgrade edgemicro@3.0.2 -g

2. Sprawdź numer wersji. Jeśli na przykład zainstalujesz wersję 3.0.2:

   edgemicro --version
   current nodejs version is v12.5.0
   current edgemicro version is 3.0.2
       

3. Na koniec uaktualnij serwer proxy edgemicro-auth do najnowszej wersji:

   edgemicro upgradeauth -o org_name -e env_name -u username

Wprowadzanie zmian w konfiguracji

Pliki konfiguracji, które musisz znać, to:

• Domyślny plik konfiguracyjny systemu
• Domyślny plik konfiguracyjny nowo zainicjowanej instancji Edge Microgateway
• Dynamiczny plik konfiguracji dla uruchomionych instancji

W tej sekcji omawiamy te pliki i informacje, które musisz znać, aby je zmienić.

Domyślny plik konfiguracji systemu

Podczas instalowania Edge Microgateway domyślny plik konfiguracji systemu jest umieszczany w tym miejscu:

prefix/lib/node_modules/edgemicro/config/default.yaml

gdzie prefix to npm katalog prefiksu. Jeśli nie możesz znaleźć tego katalogu, zapoznaj się z artykułem Gdzie jest zainstalowana usługa Edge Microgateway.

Jeśli zmienisz plik konfiguracyjny systemu, musisz ponownie zainicjować, skonfigurować i uruchomić Edge Microgateway:

edgemicro init
edgemicro configure [params]
edgemicro start [params]

Domyślny plik konfiguracyjny nowo zainicjowanych instancji Edge Microgateway

Gdy uruchomisz polecenie edgemicro init, plik konfiguracji systemu (opisany powyżej) default.yaml zostanie umieszczony w katalogu ~/.edgemicro.

Jeśli zmienisz plik konfiguracyjny w ~/.edgemicro, musisz ponownie skonfigurować i uruchomić Edge Microgateway:

edgemicro stop
edgemicro configure [params]
edgemicro start [params]

Dynamiczny plik konfiguracji instancji działających

Gdy uruchomisz polecenie edgemicro configure [params], w katalogu ~/.edgemicro zostanie utworzony dynamiczny plik konfiguracji. Nazwa pliku jest zgodna z tym wzorcem: org-env-config.yaml, gdzie org i env to nazwy organizacji i środowiska Apigee Edge. Za pomocą tego pliku możesz wprowadzać zmiany w konfiguracji, a następnie ponownie je wczytywać bez przestoju. Jeśli na przykład dodasz i skonfigurujesz wtyczkę, możesz ponownie załadować konfigurację bez przestoju, jak opisano poniżej.

Jeśli Edge Microgateway jest uruchomiony (opcja bez przestoju):

1. Ponownie załaduj konfigurację Edge Microgateway:

   edgemicro reload -o org_name -e env_name -k key -s secret

   Gdzie:

   • org_name to nazwa Twojej organizacji Edge (musisz być administratorem organizacji).
   • env_name to środowisko w Twojej organizacji (np. „test” lub „prod”).
   • key to klucz zwrócony wcześniej przez polecenie configure.
   • secret to klucz zwrócony wcześniej przez polecenie configure.

   Przykład:

   edgemicro reload -o docs -e test -k 701e70ee718ce6dc188...78b6181d000723 \
     -s 05c14356e42ed1...4e34ab0cc824

Jeśli Edge Microgateway jest zatrzymany:

1. Uruchom ponownie Edge Microgateway:

   edgemicro start -o org_name -e env_name -k key -s secret

   Gdzie:

   • org_name to nazwa Twojej organizacji Edge (musisz być administratorem organizacji).
   • env_name to środowisko w Twojej organizacji (np. „test” lub „prod”).
   • key to klucz zwrócony wcześniej przez polecenie configure.
   • secret to klucz zwrócony wcześniej przez polecenie configure.

   Na przykład:

   edgemicro start -o docs -e test -k 701e70ee718ce...b6181d000723 \
     -s 05c1435...e34ab0cc824

Oto przykładowy plik konfiguracyjny. Szczegółowe informacje o ustawieniach pliku konfiguracyjnego znajdziesz w artykule Informacje o konfiguracji Edge Microgateway.

edge_config:
  bootstrap: >-
    https://edgemicroservices-us-east-1.apigee.net/edgemicro/bootstrap/organization/docs/environment/test
  jwt_public_key: 'https://docs-test.apigee.net/edgemicro-auth/publicKey'
  managementUri: 'https://api.enterprise.apigee.com'
  vaultName: microgateway
  authUri: 'https://%s-%s.apigee.net/edgemicro-auth'
  baseUri: >-
    https://edgemicroservices.apigee.net/edgemicro/%s/organization/%s/environment/%s
  bootstrapMessage: Please copy the following property to the edge micro agent config
  keySecretMessage: The following credentials are required to start edge micro
  products: 'https://docs-test.apigee.net/edgemicro-auth/products'
edgemicro:
  port: 8000
  max_connections: 1000
  max_connections_hard: 5000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - oauth
headers:
  x-forwarded-for: true
  x-forwarded-host: true
  x-request-id: true
  x-response-time: true
  via: true
oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  verify_api_key_url: 'https://docs-test.apigee.net/edgemicro-auth/verifyApiKey'
analytics:
  uri: >-
    https://edgemicroservices-us-east-1.apigee.net/edgemicro/axpublisher/organization/docs/environment/test

Ustawianie zmiennych środowiskowych

Polecenia interfejsu wiersza poleceń, które wymagają wartości dla organizacji i środowiska Edge oraz klucza i tajnego klucza potrzebnych do uruchomienia Edge Microgateway, można przechowywać w tych zmiennych środowiskowych:

• EDGEMICRO_ORG
• EDGEMICRO_ENV
• EDGEMICRO_KEY
• EDGEMICRO_SECRET

Ustawianie tych zmiennych jest opcjonalne. Jeśli je ustawisz, nie musisz podawać ich wartości, gdy używasz interfejsu wiersza poleceń (CLI) do konfigurowania i uruchamiania Edge Microgateway.

Konfigurowanie protokołu SSL na serwerze Edge Microgateway

Obejrzyj te filmy, aby dowiedzieć się, jak skonfigurować TLS w Apigee Edge Microgateway:

Możesz skonfigurować serwer Microgateway tak, aby używał protokołu SSL. Jeśli na przykład masz skonfigurowany protokół SSL, możesz wywoływać interfejsy API za pomocą Edge Microgateway z protokołem „https”, np. w ten sposób:

https://localhost:8000/myapi

Aby skonfigurować SSL na serwerze Microgateway, wykonaj te czynności:

1. Wygeneruj lub uzyskaj certyfikat SSL i klucz za pomocą narzędzia openssl lub dowolnej innej metody.
2. Dodaj atrybut edgemicro:ssl do pliku konfiguracji Edge Microgateway. Pełną listę opcji znajdziesz w tabeli poniżej. Na przykład:
   

   edgemicro:
     ssl:
      key: <absolute path to the SSL key file>
      cert: <absolute path to the SSL cert file>
      passphrase: admin123 #option added in v2.2.2
      rejectUnauthorized: true #option added in v2.2.2
      requestCert: true

3. Ponownie uruchom Edge Microgateway. Wykonaj czynności opisane w sekcji Wprowadzanie zmian w konfiguracji, w zależności od tego, który plik konfiguracji został zmodyfikowany: domyślny czy plik konfiguracji środowiska wykonawczego.

Oto przykład sekcji edgemicro pliku konfiguracyjnego z konfiguracją SSL:

edgemicro:
  port: 8000
  max_connections: 1000
  max_connections_hard: 5000
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - oauth
  ssl:
    key: /MyHome/SSL/em-ssl-keys/server.key
    cert: /MyHome/SSL/em-ssl-keys/server.crt
    passphrase: admin123 #option added in v2.2.2
    rejectUnauthorized: true #option added in v2.2.2

Oto lista wszystkich obsługiwanych opcji serwera:

Korzystanie z opcji SSL/TLS klienta

Podczas łączenia się z docelowymi punktami końcowymi możesz skonfigurować Edge Microgateway jako klienta TLS lub SSL. W pliku konfiguracji Microgateway użyj elementu targets, aby ustawić opcje SSL/TLS.

Ten przykład zawiera ustawienia, które zostaną zastosowane do wszystkich hostów:

edgemicro:
...
targets:
  ssl:
    client:
      key: /Users/jdoe/nodecellar/twowayssl/ssl/client.key
      cert: /Users/jdoe/nodecellar/twowayssl/ssl/ca.crt
      passphrase: admin123
      rejectUnauthorized: true

W tym przykładzie ustawienia są stosowane tylko do określonego hosta:

edgemicro:
...
targets:
  - host: 'myserver.example.com'
    ssl:
      client:
        key: /Users/myname/twowayssl/ssl/client.key
        cert: /Users/myname/twowayssl/ssl/ca.crt
        passphrase: admin123
        rejectUnauthorized: true

Oto przykład dla TLS:

edgemicro:
...
targets:
  - host: 'myserver.example.com'
    tls:
      client:
        pfx: /Users/myname/twowayssl/ssl/client.pfx
        passphrase: admin123
        rejectUnauthorized: true

Oto lista wszystkich obsługiwanych opcji klienta:

Dostosowywanie serwera proxy edgemicro-auth

Domyślnie Edge Microgateway używa serwera proxy wdrożonego w Apigee Edge do uwierzytelniania OAuth2. Ten serwer proxy jest wdrażany podczas pierwszego uruchomienia polecenia edgemicro configure. Możesz zmienić domyślną konfigurację tego serwera proxy, aby dodać obsługę niestandardowych roszczeń do tokena sieciowego JSON (JWT), skonfigurować wygaśnięcie tokena i generować tokeny odświeżania. Szczegółowe informacje znajdziesz na stronie edgemicro-auth w GitHubie.

Korzystanie z niestandardowej usługi uwierzytelniania

Domyślnie Edge Microgateway używa serwera proxy wdrożonego w Apigee Edge do uwierzytelniania OAuth2. Ten serwer proxy jest wdrażany podczas pierwszego uruchomienia polecenia edgemicro configure. Domyślnie adres URL tego serwera proxy jest określony w pliku konfiguracyjnym Edge Microgateway w ten sposób:

authUri: https://myorg-myenv.apigee.net/edgemicro-auth

Jeśli chcesz używać własnej usługi niestandardowej do obsługi uwierzytelniania, zmień wartość authUri w pliku konfiguracyjnym, aby wskazywała Twoją usługę. Możesz na przykład mieć usługę, która używa protokołu LDAP do weryfikacji tożsamości.

Zarządzanie plikami dziennika

Edge Microgateway rejestruje informacje o każdym żądaniu i odpowiedzi. Pliki dziennika zawierają przydatne informacje do debugowania i rozwiązywania problemów.

Miejsce przechowywania plików dziennika

Domyślnie pliki dziennika są przechowywane w /var/tmp.

Jak zmienić domyślny katalog plików dziennika

Katalog, w którym są przechowywane pliki dziennika, jest określony w pliku konfiguracji Edge Microgateway. Zobacz też Wprowadzanie zmian w konfiguracji.

edgemicro:
  home: ../gateway
  port: 8000
  max_connections: -1
  max_connections_hard: -1
  logging:
    level: info
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

Zmień wartość dir, aby określić inny katalog plików dziennika.

Wysyłanie logów do konsoli

Możesz skonfigurować rejestrowanie tak, aby informacje z logów były wysyłane na standardowe wyjście zamiast do pliku logu. Ustaw flagę to_console na wartość true (prawda) w ten sposób:

edgemicro:
  logging:
    to_console: true

W tym ustawieniu logi będą wysyłane do standardowego wyjścia. Obecnie nie możesz wysyłać logów zarówno do stdout, jak i do pliku logu.

Ustawianie poziomu rejestrowania

Możesz ustawić te poziomy rejestrowania: info, warn i error. Zalecany jest poziom INFO. Rejestruje wszystkie żądania i odpowiedzi interfejsu API. Jest to ustawienie domyślne.

Jak zmienić interwały historii zmian

Te interwały możesz skonfigurować w pliku konfiguracyjnym Edge Microgateway. Zobacz też Wprowadzanie zmian w konfiguracji.

Konfigurowalne atrybuty to:

• stats_log_interval: (domyślnie: 60) interwał w sekundach, po którym rekord statystyk jest zapisywany w pliku dziennika interfejsu API.
• rotate_interval: (domyślnie: 24) interwał w godzinach, po którym następuje rotacja plików dziennika. Na przykład:

edgemicro:
  home: ../gateway
  port: 8000
  max_connections: -1
  max_connections_hard: -1
  logging:
    level: info
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

Sprawdzone metody prowadzenia plików dziennika

W miarę gromadzenia się danych w plikach dziennika Apigee zaleca stosowanie tych praktyk:

• Pliki dziennika mogą być dość duże, więc upewnij się, że w katalogu plików dziennika jest wystarczająco dużo miejsca. Zapoznaj się z sekcjami Gdzie są przechowywane pliki dziennika i Jak zmienić domyślny katalog plików dziennika.
• Usuwaj lub przenoś pliki dziennika do osobnego katalogu archiwum co najmniej raz w tygodniu.
• Jeśli Twoja zasada polega na usuwaniu logów, możesz użyć polecenia interfejsu wiersza poleceń edgemicro log -c, aby usunąć (wyczyścić) starsze logi.

Konwencja nazewnictwa plików dziennika

Każda instancja Edge Microgateway generuje 3 rodzaje plików dziennika:

• api – rejestruje wszystkie żądania i odpowiedzi przepływające przez Edge Microgateway. W tym pliku rejestrowane są też liczniki interfejsu API (statystyki) i błędy.
• err – rejestruje wszystko, co jest wysyłane do stderr.
• out – rejestruje wszystko, co jest wysyłane do stdout.

Obowiązuje ta konwencja nazewnictwa:

edgemicro-<Host Name>-<Instance ID>-<Log Type>.log

Na przykład:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log
edgemicro-mymachine-local-MTQzNTg1NDMODAyMQ-err.log
edgemicro-mymachine-local-mtqzntgndmxodaymq-out.log

Informacje o zawartości pliku dziennika

Dodano w wersji 2.3.3

Domyślnie usługa rejestrowania pomija pliki JSON pobranych serwerów proxy, produktów i tokenów sieciowych JSON (JWT). Jeśli chcesz zapisywać te obiekty w plikach dziennika, ustaw wartość DEBUG=* podczas uruchamiania Edge Microgateway. Na przykład:

DEBUG=* edgemicro start -o docs -e test -k abc123 -s xyz456

Zawartość pliku logu „api”

Plik dziennika „api” zawiera szczegółowe informacje o przepływie żądań i odpowiedzi przez Edge Microgateway. Pliki logu „api” mają nazwy w tym formacie:

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

W przypadku każdego żądania wysłanego do Edge Microgateway w pliku dziennika „api” rejestrowane są 4 zdarzenia:

• Żądanie przychodzące od klienta
• Wysłanie żądania wychodzącego do miejsca docelowego
• Odpowiedź z miejsca docelowego
• Odpowiedź wychodząca do klienta

Każdy z tych wpisów jest reprezentowany w postaci skróconej, aby pliki dziennika były bardziej zwięzłe. Oto 4 przykładowe wpisy reprezentujące każde z tych 4 zdarzeń. W pliku dziennika wyglądają one tak (numery wierszy służą tylko do celów informacyjnych w dokumencie, nie pojawiają się w pliku dziennika).

(1) 1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0
(2) 1436403888665 info treq m=GET, u=/, h=127.0.0.18080, i=0
(3) 1436403888672 info tres s=200, d=7, i=0
(4) 1436403888676 info res s=200, d=11, i=0

Przyjrzyjmy się im po kolei:

1. Przykładowe żądanie przychodzące od klienta:

1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0

• 1436403888651 – sygnatura czasowa w formacie Unix
• info – zależy od kontekstu. Może to być informacja, ostrzeżenie lub błąd, w zależności od poziomu dziennika. Może to być „stats” w przypadku rekordu statystyk, „warn” w przypadku ostrzeżeń lub „error” w przypadku błędów.
• req – identyfikuje zdarzenie. W tym przypadku żądanie pochodzi od klienta.
• m – czasownik HTTP użyty w żądaniu.
• u – część adresu URL następująca po ścieżce podstawowej.
• h – nazwa hosta i numer portu, na którym nasłuchuje Edge Microgateway.
• r – zdalny host i port, z którego pochodzi żądanie klienta.
• i – identyfikator prośby. Wszystkie 4 wpisy wydarzeń będą miały ten identyfikator. Każde żądanie otrzymuje unikalny identyfikator. Korelacja rekordów logów według identyfikatora żądania może dostarczyć cennych informacji o opóźnieniu docelowym.
• d – czas trwania w milisekundach od momentu otrzymania żądania przez Edge Microgateway. W powyższym przykładzie odpowiedź na żądanie 0 została odebrana po 7 milisekundach (wiersz 3), a następnie wysłana do klienta po kolejnych 4 milisekundach (wiersz 4). Innymi słowy, łączne opóźnienie żądania wyniosło 11 milisekund, z czego 7 milisekund zajęło docelowe miejsce docelowe, a 4 milisekundy – sam Edge Microgateway.

2. Przykładowe żądanie wychodzące wysłane do miejsca docelowego:

1436403888665 info treq m=GET, u=/, h=127.0.0.1:8080, i=0

• 1436403888651 – sygnatura czasowa w formacie Unix
• info – zależy od kontekstu. Może to być informacja, ostrzeżenie lub błąd, w zależności od poziomu dziennika. Może to być „stats” w przypadku rekordu statystyk, „warn” w przypadku ostrzeżeń lub „error” w przypadku błędów.
• treq – identyfikuje zdarzenie. W tym przypadku żądanie kierowania.
• m – czasownik HTTP użyty w żądaniu docelowym.
• u – część adresu URL następująca po ścieżce podstawowej.
• h – host i numer portu docelowego backendu.
• i – identyfikator wpisu logu. Wszystkie 4 wpisy wydarzeń będą miały ten sam identyfikator.

3. Przykładowa odpowiedź z miejsca docelowego

1436403888672 info tres s=200, d=7, i=0

1436403888651 – sygnatura czasowa w formacie Unix

• info – zależy od kontekstu. Może to być informacja, ostrzeżenie lub błąd, w zależności od poziomu dziennika. Może to być „stats” w przypadku rekordu statystyk, „warn” w przypadku ostrzeżeń lub „error” w przypadku błędów.
• tres – identyfikuje zdarzenie. W tym przypadku odpowiedź docelowa.
• s – stan odpowiedzi HTTP.
• d – czas trwania w milisekundach. Czas wywołania interfejsu API przez element docelowy.
• i – identyfikator wpisu logu. Wszystkie 4 wpisy wydarzeń będą miały ten sam identyfikator.

4. Przykładowa odpowiedź do klienta

1436403888676 info res s=200, d=11, i=0

1436403888651 – sygnatura czasowa w formacie Unix

• info – zależy od kontekstu. Może to być informacja, ostrzeżenie lub błąd, w zależności od poziomu dziennika. Może to być „stats” w przypadku rekordu statystyk, „warn” w przypadku ostrzeżeń lub „error” w przypadku błędów.
• res – identyfikuje zdarzenie. W tym przypadku odpowiedź dla klienta.
• s – stan odpowiedzi HTTP.
• d – czas trwania w milisekundach. Jest to łączny czas trwania wywołania interfejsu API, w tym czas trwania wywołania docelowego interfejsu API i czas trwania wywołania samego Edge Microgateway.
• i – identyfikator wpisu logu. Wszystkie 4 wpisy wydarzeń będą miały ten sam identyfikator.

Harmonogram plików dziennika

Pliki dziennika są rotowane w interwale określonym przez rotate_interval. Wpisy będą dodawane do tego samego pliku dziennika do momentu wygaśnięcia interwału rotacji. Jednak za każdym razem, gdy Edge Microgateway jest ponownie uruchamiany, otrzymuje nowy identyfikator UID i tworzy nowy zestaw plików dziennika z tym identyfikatorem. Zobacz też sprawdzone metody konserwacji plików dziennika.

Komunikaty o błędach

Niektóre wpisy logu będą zawierać komunikaty o błędach. Aby dowiedzieć się, gdzie i dlaczego występują błędy, zapoznaj się z informacjami o błędach Edge Microgateway.

Odwołanie do konfiguracji Edge Microgateway

Lokalizacja pliku konfiguracji

Atrybuty konfiguracji opisane w tej sekcji znajdują się w pliku konfiguracyjnym Edge Microgateway. Zobacz też Wprowadzanie zmian w konfiguracji.

Atrybuty edge_config

Te ustawienia służą do konfigurowania interakcji między instancją Edge Microgateway a Apigee Edge.

• bootstrap: (domyślnie: brak) adres URL, który wskazuje usługę specyficzną dla Edge Microgateway działającą w Apigee Edge. Edge Microgateway używa tej usługi do komunikowania się z Apigee Edge. Ten adres URL jest zwracany po wykonaniu polecenia generującego parę kluczy publiczny/prywatny: edgemicro genkeys. Szczegółowe informacje znajdziesz w artykule Konfigurowanie Edge Microgateway.
• jwt_public_key: (domyślnie: brak) adres URL wskazujący serwer proxy Edge Microgateway wdrożony w Apigee Edge. Ten serwer proxy służy jako punkt końcowy uwierzytelniania do wydawania klientom podpisanych tokenów dostępu. Ten adres URL jest zwracany po wykonaniu polecenia wdrażania proxy: edgemicro configure. Szczegółowe informacje znajdziesz w artykule Konfigurowanie Edge Microgateway.
• quotaUri: ustaw tę właściwość konfiguracji, jeśli chcesz zarządzać limitami za pomocą serwera proxy edgemicro-auth wdrożonego w Twojej organizacji. Jeśli ta właściwość nie jest skonfigurowana, punkt końcowy limitu domyślnie przyjmuje wewnętrzny punkt końcowy Edge Microgateway.

  edge_config:
    quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
  

  Aby korzystać z tej funkcji, musisz najpierw wdrożyć w swojej organizacji wersję 3.0.5 lub nowszą serwera proxy edgemicro-auth. Szczegółowe informacje znajdziesz w artykule Uaktualnianie serwera proxy edgemicro-auth.

atrybuty edgemicro

Te ustawienia konfigurują proces Edge Microgateway.

• port: (domyślnie: 8000) numer portu, na którym nasłuchuje proces Edge Microgateway.
• max_connections: (domyślnie: -1) określa maksymalną liczbę jednoczesnych połączeń przychodzących, które może odbierać Edge Microgateway. Jeśli ta liczba zostanie przekroczona, zwracany jest ten stan:
  
  res.statusCode = 429; // Too many requests
  
• max_connections_hard: (domyślnie: -1) maksymalna liczba jednoczesnych żądań, które Edge Microgateway może odbierać przed zamknięciem połączenia. To ustawienie ma na celu zapobieganie atakom typu DoS. Zwykle ustawia się ją na liczbę większą niż max_connections.
• logowanie:
  • level: (domyślnie: error)
    • info – rejestruje wszystkie żądania i odpowiedzi przepływające przez instancję Edge Microgateway.
    • warn – rejestruje tylko komunikaty ostrzegawcze.
    • error – rejestruje tylko komunikaty o błędach.
  • dir: (domyślnie: /var/tmp) katalog, w którym są przechowywane pliki dziennika.
  • stats_log_interval: (domyślnie: 60) interwał w sekundach, w którym rekord statystyk jest zapisywany w pliku dziennika interfejsu API.
  • rotate_interval: (domyślnie: 24) interwał w godzinach, po którym następuje rotacja plików dziennika.

• wtyczki: wtyczki dodają funkcje do Edge Microgateway. Szczegółowe informacje o tworzeniu wtyczek znajdziesz w artykule Tworzenie wtyczek niestandardowych.

• dir: ścieżka względna z katalogu ./gateway do katalogu ./plugins lub ścieżka bezwzględna.
• sequence: lista modułów wtyczek do dodania do instancji Edge Microgateway. Moduły będą wykonywane w kolejności określonej tutaj.

• debug: dodaje debugowanie zdalne do procesu Edge Microgateway.
  • port: numer portu, na którym ma nasłuchiwać serwer. Na przykład skonfiguruj debuger środowiska IDE, aby nasłuchiwał na tym porcie.
  • args: argumenty procesu debugowania. Na przykład: args --nolazy
    
• config_change_poll_interval: (domyślnie: 600 sekund) Edge Microgateway okresowo wczytuje nową konfigurację i wykonuje ponowne wczytanie, jeśli coś się zmieniło. Sondażowanie wykrywa wszelkie zmiany wprowadzone w Edge (zmiany w produktach, serwerach proxy obsługujących mikrobramy itp.), a także zmiany wprowadzone w lokalnym pliku konfiguracji.
  
• disable_config_poll_interval: (domyślnie: false) ustaw na true, aby wyłączyć automatyczne sprawdzanie zmian.
• request_timeout: ustawia limit czasu dla żądań kierowania. Czas oczekiwania jest ustawiany w sekundach. Jeśli wystąpi przekroczenie limitu czasu, Edge Microgateway odpowie kodem stanu 504. (Dodano w wersji 2.4.x)

atrybuty nagłówków,

Te ustawienia określają sposób traktowania niektórych nagłówków HTTP.

• x-forwarded-for: (domyślnie: true) ustaw wartość false, aby zapobiec przekazywaniu nagłówków x-forwarded-for do miejsca docelowego. Pamiętaj, że jeśli w żądaniu znajduje się nagłówek x-forwarded-for, jego wartość zostanie ustawiona na wartość client-ip w Edge Analytics.
• x-forwarded-host: (domyślnie: true) ustaw wartość false, aby zapobiec przekazywaniu nagłówków x-forwarded-host do miejsca docelowego.
• x-request-id: (domyślnie: true) ustaw wartość false, aby zapobiec przekazywaniu nagłówków x-request-id do miejsca docelowego.
• x-response-time: (domyślnie: true) ustaw na false, aby zapobiec przekazywaniu nagłówków x-response-time do miejsca docelowego.
• via: (domyślnie: true) ustaw wartość false, aby zapobiec przekazywaniu nagłówków via do miejsca docelowego.

atrybuty oauth

Te ustawienia konfigurują sposób wymuszania uwierzytelniania klienta przez Edge Microgateway.

• allowNoAuthorization: (domyślnie: false) jeśli ma wartość true, wywołania interfejsu API mogą przechodzić przez Edge Microgateway bez nagłówka Authorization. Ustaw wartość false, aby wymagać nagłówka autoryzacji (domyślnie).
• allowInvalidAuthorization: (domyślnie: false) jeśli ma wartość true, wywołania interfejsu API są dozwolone, jeśli token przekazany w nagłówku Authorization jest nieprawidłowy lub wygasł. Ustaw wartość „false”, aby wymagać ważnych tokenów (domyślnie).
• authorization-header: (domyślnie: Authorization: Bearer) nagłówek używany do wysyłania tokena dostępu do Edge Microgateway. Możesz zmienić ustawienie domyślne, jeśli miejsce docelowe musi używać nagłówka Authorization do innych celów.
• api-key-header: (domyślnie: x-api-key) nazwa nagłówka lub parametru zapytania używanego do przekazywania klucza interfejsu API do Edge Microgateway. Zobacz też Korzystanie z klucza interfejsu API.
• keep-authorization-header: (domyślnie: false) jeśli ma wartość true, nagłówek Authorization wysłany w żądaniu jest przekazywany do miejsca docelowego (jest zachowywany).
• allowOAuthOnly – jeśli ta wartość jest ustawiona na „true”, każdy interfejs API musi zawierać nagłówek Authorization z tokenem dostępu Bearer. Umożliwia zezwolenie tylko na model zabezpieczeń OAuth (przy zachowaniu zgodności z wcześniejszymi wersjami). (Dodano w wersji 2.4.x)
• allowAPIKeyOnly – jeśli ma wartość „true”, każdy interfejs API musi zawierać nagłówek x-api-key (lub niestandardową lokalizację) z kluczem interfejsu API.Umożliwia zezwolenie tylko na model zabezpieczeń klucza interfejsu API (przy zachowaniu zgodności wstecznej). (Dodano w wersji 2.4.x)
• gracePeriod – ten parametr pomaga zapobiegać błędom spowodowanym niewielkimi rozbieżnościami między zegarem systemowym a czasem „Not Before” (nbf) lub „Issued At” (iat) określonym w tokenie autoryzacji JWT. Ustaw ten parametr na liczbę sekund, w których dopuszczalne są takie rozbieżności. (Dodano w wersji 2.5.7)

Atrybuty specyficzne dla wtyczki

Szczegółowe informacje o atrybutach, które można skonfigurować w przypadku poszczególnych wtyczek, znajdziesz w artykule Korzystanie z wtyczek.

Filtrowanie serwerów proxy

Możesz filtrować, które serwery proxy obsługujące mikrobramę będą przetwarzane przez instancję Edge Microgateway. Po uruchomieniu Edge Microgateway pobiera wszystkie serwery proxy obsługujące mikrobramę w organizacji, z którą jest powiązana. Skonfiguruj poniższe ustawienia, aby ograniczyć liczbę serwerów proxy, które będą przetwarzane przez mikrobramę. Na przykład ta konfiguracja ogranicza liczbę serwerów proxy, które będzie przetwarzać mikrobrama, do 3: edgemicro_proxy-1, edgemicro_proxy-2 i edgemicro_proxy-3:

proxies:
  - edgemicro_proxy-1
  - edgemicro_proxy-2
  - edgemicro_proxy-3

Konfigurowanie częstotliwości wysyłania danych analitycznych

Za pomocą tych parametrów konfiguracji możesz kontrolować częstotliwość, z jaką Edge Microgateway wysyła dane analityczne do Apigee:

• bufferSize (opcjonalny): maksymalna liczba rekordów analitycznych, które bufor może przechowywać, zanim zacznie usuwać najstarsze rekordy. Domyślnie: 10000
• batchSize (opcjonalny): maksymalny rozmiar grupy rekordów analitycznych wysyłanych do Apigee. Domyślnie: 500
• flushInterval (opcjonalnie): liczba milisekund między każdym opróżnianiem grupy rekordów Analytics wysyłanych do Apigee. Domyślnie: 5000

Na przykład:

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

Maskowanie danych analitycznych

Poniższa konfiguracja uniemożliwia wyświetlanie informacji o ścieżce żądania w analizach Edge. Aby zamaskować identyfikator URI żądania lub ścieżkę żądania, dodaj do konfiguracji mikrobramy te elementy: Pamiętaj, że identyfikator URI składa się z nazwy hosta i ścieżki żądania.

analytics:
  mask_request_uri: 'string_to_mask'
  mask_request_path: 'string_to_mask'

Rozdzielanie wywołań interfejsu API w Edge Analytics

Wtyczkę Analytics możesz skonfigurować tak, aby wydzielać określoną ścieżkę API, dzięki czemu będzie ona wyświetlana jako oddzielny serwer proxy na panelach Edge Analytics. Możesz na przykład oddzielić w panelu interfejs API kontroli stanu, aby nie mylić go z rzeczywistymi wywołaniami proxy interfejsu API. W panelu Analytics wydzielone serwery proxy mają nazwy zgodne z tym wzorcem:

edgemicro_proxyname-health

Na ilustracji poniżej w panelu Analytics widać 2 oddzielne serwery proxy: edgemicro_hello-health i edgemicro_mock-health:

Użyj tych parametrów, aby rozdzielić ścieżki względne i bezwzględne na panelu Analytics jako osobne serwery proxy:

• relativePath (opcjonalnie): określa ścieżkę względną do wydzielenia w panelu Analytics. Jeśli na przykład podasz /healthcheck, wszystkie wywołania interfejsu API zawierające ścieżkę /healthcheck będą wyświetlane w panelu jako edgemicro_proxyname-health. Pamiętaj, że ta flaga ignoruje ścieżkę podstawową serwera proxy. Aby dokonać podziału na podstawie pełnej ścieżki, w tym ścieżki podstawowej, użyj flagi proxyPath.
• proxyPath (opcjonalnie): określa pełną ścieżkę proxy interfejsu API, w tym podstawową ścieżkę proxy, która ma być oddzielona na panelu analitycznym. Jeśli na przykład określisz /mocktarget/healthcheck, gdzie /mocktarget to ścieżka podstawowa serwera proxy, wszystkie wywołania interfejsu API ze ścieżką /mocktarget/healthcheck będą wyświetlane w panelu jako edgemicro_proxyname-health.

Na przykład w tej konfiguracji wtyczka analityczna będzie rozdzielać każdą ścieżkę interfejsu API, która zawiera /healthcheck. Oznacza to, że /foo/healthcheck i /foo/bar/healthcheck będą rozdzielone jako osobny serwer proxy o nazwie edgemicro_proxyname-health na pulpicie analitycznym.

analytics:
  uri: >-
    https://xx/edgemicro/ax/org/docs/environment/test
  bufferSize: 100
  batchSize: 50
  flushInterval: 500
  relativePath: /healthcheck

W tej konfiguracji każdy interfejs API ze ścieżką serwera proxy /mocktarget/healthcheck będzie traktowany jako osobny serwer proxy o nazwie edgemicro_proxyname-health na panelu analitycznym.

analytics:
  uri: >-
    https://xx/edgemicro/ax/org/docs/environment/test
  bufferSize: 100
  batchSize: 50
  flushInterval: 500
  proxyPath: /mocktarget/healthcheck

Konfigurowanie Edge Microgateway za zaporą sieciową firmy

Obsługiwane wersje 2.4.x

Jeśli Edge Microgateway jest zainstalowany za zaporą sieciową, brama może nie być w stanie komunikować się z Apigee Edge. W takim przypadku masz 2 opcje:

Opcja 1:

Pierwsza opcja polega na ustawieniu w pliku konfiguracji mikrobramy wartości „true” dla opcji edgemicro: proxy_tunnel:

edge_config:

    proxy: http://10.224.16.85:3128
    proxy_tunnel: true

Gdy wartość parametru proxy_tunnel to true, Edge Microgateway używa metody HTTP CONNECT do tunelowania żądań HTTP przez jedno połączenie TCP. (To samo dotyczy sytuacji, gdy zmienne środowiskowe do konfigurowania serwera proxy mają włączony protokół TLS).

Opcja 2:

Druga opcja to określenie serwera proxy i ustawienie wartości proxy_tunnel na false w pliku konfiguracyjnym mikrobramy. Na przykład:

edge_config:
     proxy: http://10.224.16.85:3128
     proxy_tunnel: false

W tym przypadku możesz ustawić te zmienne, aby kontrolować hosty dla każdego serwera proxy HTTP, którego chcesz używać, lub hosty, które nie powinny obsługiwać serwerów proxy Edge Microgateway: HTTP_PROXY, HTTPS_PROXY i NO_PROXY.

Możesz ustawić NO_PROXY jako listę domen oddzielonych przecinkami, do których Edge Microgateway nie powinien przekazywać żądań. Na przykład:

export NO_PROXY='localhost,localhost:8080'

Ustaw zmienne HTTP_PROXY i HTTPS_PROXY na punkt końcowy serwera proxy HTTP, do którego Edge Microgateway może wysyłać wiadomości. Na przykład:

export HTTP_PROXY='http://localhost:3786'

export HTTPS_PROXY='https://localhost:3786'

Więcej informacji o tych zmiennych znajdziesz na stronie https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables.

Zobacz też

Jak skonfigurować Edge Microgateway za firewallem firmy na forum Apigee Community.

Używanie symboli wieloznacznych w proxy obsługujących Microgateway

W ścieżce podstawowej serwera proxy edgemicro_* (obsługującego Microgateway) możesz użyć co najmniej jednego symbolu wieloznacznego „*”. Na przykład ścieżka podstawowa /team/*/members umożliwia klientom wywoływanie adresów https://[host]/team/blue/members i https://[host]/team/green/members bez konieczności tworzenia nowych serwerów proxy interfejsu API do obsługi nowych zespołów. Pamiętaj, że znak /**/ nie jest obsługiwany.

Ważne: Apigee NIE obsługuje używania symbolu wieloznacznego „*” jako pierwszego elementu ścieżki podstawowej. Na przykład NIE jest obsługiwane wyszukiwanie /*/.

Rotacja kluczy JWT

Po wygenerowaniu JWT możesz w pewnym momencie zmienić parę kluczy publiczny/prywatny przechowywaną w zaszyfrowanym KVM Edge. Proces generowania nowej pary kluczy nazywa się rotacją kluczy.

Jak Edge Microgateway korzysta z tokenów JWT

Token sieciowy JSON (JWT) to standard tokena opisany w dokumencie RFC7519. Token JWT umożliwia podpisanie zestawu deklaracji, które odbiorca tokena JWT może wiarygodnie zweryfikować.

Edge Microgateway używa tokenów JWT jako tokenów okaziciela do zabezpieczeń OAuth. Gdy wygenerujesz token OAuth dla Edge Microgateway, otrzymasz token JWT. Następnie możesz użyć JWT w nagłówku autoryzacji wywołań interfejsu API. Na przykład:

curl -i http://localhost:8000/hello -H "Authorization: Bearer eyJhbGciOiJ..dXDefZEA"

Generowanie nowego tokena JWT

Token JWT dla Edge Microgateway możesz wygenerować za pomocą polecenia edgemicro token lub interfejsu API. Na przykład:

edgemicro token get -o docs -e test -i G0IAeU864EtBo99NvUbn6Z4CBwVcS2 -s uzHTbwNWvoSmOy

To polecenie powoduje, że Apigee Edge generuje token JWT, który można następnie wykorzystać do weryfikacji wywołań interfejsu API. Parametry -i i -s to identyfikator konsumenta i wartości tajne z aplikacji dewelopera w organizacji Apigee Edge.

Możesz też wygenerować token JWT za pomocą interfejsu Management API:

curl -i -X POST "http://org-env.apigee.net/edgemicro-auth/token" \
  -H "Content-Type: application/json" \
  -d '{
    "client_id": "your consumer key",
    "client_secret": "your consumer secret",
    "grant_type": "client_credentials"
  }'

Gdzie:

• org to nazwa Twojej organizacji Edge (musisz być administratorem organizacji).
• env to środowisko w Twojej organizacji (np. „test” lub „prod”).
• client_id to identyfikator konsumenta w utworzonej wcześniej aplikacji dewelopera.
• client_secret to tajny klucz klienta w utworzonej wcześniej aplikacji dla deweloperów.

Co to jest rotacja kluczy?

Po wygenerowaniu JWT możesz w pewnym momencie zmienić parę kluczy publiczny/prywatny przechowywaną w zaszyfrowanym KVM Edge. Proces generowania nowej pary kluczy nazywa się rotacją kluczy. Podczas rotacji kluczy generowana jest nowa para kluczy prywatny/publiczny, która jest przechowywana w pamięci KVM „mikrobrany” w organizacji lub środowisku Apigee Edge. Dodatkowo stary klucz publiczny jest zachowywany wraz z pierwotną wartością identyfikatora klucza.

Aby wygenerować token JWT, Edge używa informacji przechowywanych w zaszyfrowanym KVM. Podczas wstępnej konfiguracji Edge Microgateway utworzono i wypełniono kluczami mapę klucz-wartość o nazwie microgateway. Klucze w KVM służą do podpisywania i szyfrowania tokena JWT.

Klucze KVM obejmują:

• private_key – najnowszy (ostatnio utworzony) klucz prywatny RSA używany do podpisywania tokenów JWT.

• public_key – najnowszy (utworzony w najpóźniejszym terminie) certyfikat używany do weryfikowania tokenów JWT podpisanych za pomocą klucza private_key.

• private_key_kid – identyfikator najnowszego (ostatnio utworzonego) klucza prywatnego. Ten identyfikator klucza jest powiązany z wartością private_key i służy do obsługi rotacji kluczy.

• public_key1_kid – identyfikator najnowszego (ostatnio utworzonego) klucza publicznego. Ten klucz jest powiązany z wartością public_key1 i służy do obsługi rotacji kluczy. Ta wartość jest taka sama jak identyfikator klucza prywatnego.

• public_key1 – najnowszy (ostatnio utworzony) klucz publiczny.

Podczas rotacji kluczy istniejące wartości kluczy są zastępowane na mapie, a nowe klucze są dodawane w celu zachowania starych kluczy publicznych. Na przykład:

• public_key2_kid – identyfikator starego klucza publicznego. Ten klucz jest powiązany z wartością public_key2 i służy do obsługi rotacji kluczy.

• public_key2 – stary klucz publiczny.

Tokeny JWT przedstawione do weryfikacji będą weryfikowane za pomocą nowego klucza publicznego. Jeśli weryfikacja się nie powiedzie, stary klucz publiczny będzie używany do momentu wygaśnięcia (po 30 minutach). W ten sposób możesz „obracać” klucze bez natychmiastowego zakłócania ruchu w interfejsie API.

Jak przeprowadzić rotację klucza

Z tej sekcji dowiesz się, jak przeprowadzić rotację kluczy.

Jeśli instancja Edge Microgateway została skonfigurowana przed wersją 2.5.2

Jeśli instancja Edge Microgateway została skonfigurowana przed wersją 2.5.2, musisz uruchomić te 2 polecenia, aby uaktualnić KVM i zasady uwierzytelniania:

upgradekvm -o org -e env -u username

Więcej informacji o tym poleceniu znajdziesz w artykule Uaktualnianie KVM.

Następne polecenie aktualizuje serwer proxy edgemicro-oauth, który został wdrożony w Twojej organizacji Apigee podczas konfigurowania Edge Microgateway. Ten serwer proxy udostępnia usługi wymagane do generowania tokenów.

upgradeauth -o org -e env -u username

Więcej informacji o tym poleceniu znajdziesz w artykule Uaktualnianie serwera proxy edgemicro-auth.

Rotacja kluczy

Dodaj do pliku ~/.edgemicro/org-env-config.yaml ten wiersz, w którym musisz określić tę samą organizację i środowisko, które zostały skonfigurowane do używania przez mikrobramę:

jwk_public_keys: 'https://org-env.apigee.net/edgemicro-auth/jwkPublicKeys'

Aby dokonać rotacji kluczy, uruchom polecenie rotacji kluczy. (Więcej informacji o tym poleceniu znajdziesz w artykule Wykonywanie rotacji kluczy).

edgemicro rotatekey -o org -e env -u username -k kid_value

Na przykład:

edgemicro rotatekey -o jdoe -e test -u jdoe@google.com -k 2
current nodejs version is v12.5.0
current edgemicro version is 3.0.2
password:
Checking if private key exists in the KVM...
Checking for certificate...
Found Certificate
Generating New key/cert pair...
Extract new public key
Key Rotation successfully completed!

Parametr -k określa identyfikator klucza (kid). Ten identyfikator służy do dopasowywania konkretnego klucza. Edge Microgateway używa tej wartości do wyboru spośród zestawu kluczy podczas rotacji kluczy. Więcej informacji znajdziesz w sekcji 4.5 specyfikacji klucza sieciowego JSON.

Po rotacji klucza Edge zwraca do Edge Microgateway wiele kluczy. Zwróć uwagę, że w przykładzie poniżej każdy klucz ma unikalną wartość „kid” (identyfikator klucza). Mikrobrama używa tych kluczy do weryfikacji tokenów autoryzacji. Jeśli weryfikacja tokena się nie powiedzie, mikrobrama sprawdzi, czy w zestawie kluczy znajduje się starszy klucz, i spróbuje go użyć. Format zwracanych kluczy to JSON Web Key (JWK). Więcej informacji o tym formacie znajdziesz w dokumencie RFC 7517.

{
  "keys": [
    {
      "kty": "RSA",
      "n": "nSl7R_0wKLiWi6cO3n8aOJwYGBtinq723Jgg8i7KKWTSTYoszOjgGsJf_MX4JEW1YCScwpE5o4o8ccQN09iHVTlIhk8CNiMZNPipClmRVjaL_8IWvMQp1iN66qy4ldWXzXnHfivUZZogCkBNqCz7VSC5rw2Jf57pdViULVvVDGwTgf46sYveW_6h8CAGaD0KLd3vZffxIkoJubh0yMy0mQP3aDOeIGf_akeZeZ6GzF7ltbKGd954iNTiKmdm8IKhz6Y3gLpC9iwQ-kex_j0CnO_daHl1coYxUSCIdv4ziWIeM3dmjQ5_2dEvUDIGG6_Az9hTpNgPE5J1tvrOHAmunQ",
      "e": "AQAB",
      "kid": "2"
    },
    {
      "kty": "RSA",
      "n": "8BKwzx34BMUcHwTuQtmp8LFRCMxbkKg_zsWD6eOMIUTAsORexTGJsTy7z-4aH0wJ3fT-3luAAUPLBQwGcuHo0P1JnbtPrpuYjaJKSZOeIMOnlryJCspmv-1xG4qAqQ9XaZ9C97oecuj7MMoNwuaZno5MvsY-oi5B_gqED3vIHUjaWCErd4reONyFSWn047dvpE6mwRhZbcOTkAHT8ZyKkHISzopkFg8CD-Mij12unxA3ldcTV7yaviXgxd3eFSD1_Z4L7ZRsDUukCJkJ-8qY2-GWjewzoxl-mAW9D1tLK6qAdc89yFem3JHRW6L1le3YK37-bs6b2a_AqJKsKm5bWw",
      "e": "AQAB",
      "kid": "1"
    }
  ]
}

Filtrowanie pobranych serwerów proxy

Domyślnie Edge Microgateway pobiera wszystkie proxy w organizacji Edge, które zaczynają się od prefiksu „edgemicro_”. Możesz zmienić to ustawienie domyślne, aby pobierać proxy, których nazwy pasują do wzorca.

1. Otwórz plik konfiguracyjny Edge Micro: ~/.edgemicro/org-env-config.yaml
2. Dodaj element proxyPattern w sekcji edge_config. Na przykład ten wzorzec pobierze serwery proxy, takie jak edgemicro_foo, edgemicro_fast i edgemicro_first.

   edge_config:
   …
   proxyPattern: edgemicro_f*

Określanie usług bez proxy interfejsów API

W Apigee Edge możesz utworzyć usługę API, która nie zawiera żadnych proxy interfejsów API. Ta konfiguracja usługi umożliwia używanie klucza interfejsu API powiązanego z tą usługą w przypadku dowolnego serwera proxy wdrożonego w Twojej organizacji. Od wersji 2.5.4 Edge Microgateway obsługuje tę konfigurację usługi.

Debugowanie i rozwiązywanie problemów

Łączenie z debugerem

Edge Microgateway możesz uruchomić z debugerem, np. node-inspector. Jest to przydatne podczas rozwiązywania problemów i debugowania wtyczek niestandardowych.

1. Uruchom ponownie Edge Microgateway w trybie debugowania. Aby to zrobić, dodaj znak DEBUG=* na początku polecenia start. Na przykład:

   DEBUG=* edgemicro start -o  myorg -e test -k
         db4e9e8a95aa7fabfdeacbb1169d0a8cbe42bec19c6b98129e02 -s
         6e56af7c1b26dfe93dae78a735c8afc9796b077d105ae5618ce7ed

2. Uruchom debuger i ustaw go tak, aby nasłuchiwał numeru portu w procesie debugowania.
3. Możesz teraz przechodzić przez kod Edge Microgateway, ustawiać punkty przerwania, obserwować wyrażenia itp.

Możesz określić standardowe flagi Node.js związane z trybem debugowania. Na przykład --nolazy pomaga w debugowaniu kodu asynchronicznego.

Sprawdzanie plików dziennika

Jeśli masz problemy, sprawdź pliki dziennika, aby uzyskać szczegółowe informacje o wykonaniu i błędach. Więcej informacji znajdziesz w artykule Zarządzanie plikami dziennika.

Korzystanie z zabezpieczeń klucza interfejsu API

Klucze interfejsu API zapewniają prosty mechanizm uwierzytelniania klientów wysyłających żądania do Edge Microgateway. Klucz interfejsu API możesz uzyskać, kopiując wartość klucza klienta (nazywanego też identyfikatorem klienta) z usługi Apigee Edge, która zawiera serwer proxy uwierzytelniania Edge Microgateway.

Buforowanie kluczy

Klucze interfejsu API są wymieniane na tokeny dostępu, które są przechowywane w pamięci podręcznej. Pamięć podręczną możesz wyłączyć, ustawiając nagłówek Cache-Control: no-cache w przypadku żądań przychodzących do Edge Microgateway.

Korzystanie z klucza interfejsu API

Klucz interfejsu API możesz przekazać w żądaniu do interfejsu API jako parametr zapytania lub w nagłówku. Domyślnie nazwa nagłówka i parametru zapytania to x-api-key.

Przykład parametru zapytania:

curl http://localhost:8000/foobar?x-api-key=JG616Gjz7xs4t0dvpvVsGdI49G34xGsz

Przykładowy nagłówek:

curl http://localhost:8000/foobar -H "x-api-key:JG616Gjz7xs4t0dvpvVsGdI49G34xGsz"

Konfigurowanie nazwy klucza interfejsu API

Domyślnie x-api-key jest nazwą używaną zarówno w przypadku nagłówka klucza interfejsu API, jak i parametru zapytania. Możesz zmienić to ustawienie domyślne w pliku konfiguracji, jak opisano w sekcji Wprowadzanie zmian w konfiguracji. Aby na przykład zmienić nazwę na apiKey:

oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  api-key-header: apiKey

W tym przykładzie zarówno parametr zapytania, jak i nazwa nagłówka zostały zmienione na apiKey. Nazwa x-api-key przestanie działać w obu przypadkach. Zobacz też Wprowadzanie zmian w konfiguracji.

Na przykład:

curl http://localhost:8000/foobar -H "apiKey:JG616Gjz7xs4t0dvpvVsGdI49G34xGsz"

Więcej informacji o używaniu kluczy interfejsu API z żądaniami proxy znajdziesz w artykule Secure Edge Microgateway.

Włączanie kodów odpowiedzi z serwera nadrzędnego

Domyślnie wtyczka oauth zwraca tylko kody stanu błędu 4xx, jeśli odpowiedź nie ma stanu 200. Możesz zmienić to zachowanie, aby zawsze zwracać dokładny kod 4xx lub 5xx w zależności od błędu. (Wprowadzono w wersji 3.0.7)

Aby włączyć tę funkcję, dodaj właściwość oauth.useUpstreamResponse: true do konfiguracji Edge Microgateway. Na przykład:

oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  gracePeriod: 10
  useUpstreamResponse: true

Korzystanie z zabezpieczeń tokena OAuth2

Z tej sekcji dowiesz się, jak uzyskać tokeny dostępu i tokeny odświeżania OAuth2. Tokeny dostępu służą do wykonywania bezpiecznych wywołań interfejsu API za pomocą mikrobramy. Tokeny odświeżania służą do uzyskiwania nowych tokenów dostępu.

Jak uzyskać token dostępu

W tej sekcji dowiesz się, jak używać serwera proxy edgemicro-auth do uzyskiwania tokena dostępu.

Token dostępu możesz też uzyskać za pomocą polecenia edgemicro token CLI. Więcej informacji o interfejsie CLI znajdziesz w artykule Zarządzanie tokenami.

Interfejs API 1. Przesyłanie danych logowania jako parametrów treści

W adresie URL zastąp nazwy organizacji i środowiska, a w parametrach żądania client_id i client_secret zastąp wartości identyfikatora klienta i tajnego klucza klienta uzyskane z aplikacji deweloperskiej w Apigee Edge:

curl -i -X POST "http://<org>-<test>.apigee.net/edgemicro-auth/token" \
-d '{"grant_type": "client_credentials", "client_id": "your_client_id", \
"client_secret": "your_client_secret"}' -H "Content-Type: application/json"

Interfejs API 2. Przesyłanie danych logowania w nagłówku uwierzytelniania podstawowego

Wyślij dane logowania klienta jako nagłówek uwierzytelniania podstawowego, a parametr grant_type jako parametr formularza. Ten format polecenia jest też omówiony w dokumencie RFC 6749: The OAuth 2.0 Authorization Framework.

http://<org>-<test>.apigee.net/edgemicro-auth/token -v -u your_client_id:your_client_secret \
-d 'grant_type=client_credentials' -H "Content-Type: application/x-www-form-urlencoded"

Przykładowe dane wyjściowe

{
"token": "eyJraWQiOiIxIiwidHlwIjoi",
"access_token": "eyJraWQiOiIxIiwid",
"token_type": "bearer",
"expires_in": "108000"
}

Jak uzyskać token odświeżania

Aby uzyskać token odświeżania, wywołaj interfejs API w punkcie końcowym /token proxy edgemicro-auth. To wywołanie interfejsu API MUSISZ wykonać z użyciem typu przyznania dostępu password. Poniżej znajdziesz opis tego procesu.

1. Uzyskaj token dostępu i token odświeżania za pomocą interfejsu /token API. Pamiętaj, że typ przyznania dostępu to password:

   curl -X POST \
     https://your_organization-your_environment.apigee.net/edgemicro-auth/token \
     -H 'Content-Type: application/json' \
     -d '{
      "client_id":"mpK6l1Bx9oE5zLdifoDbF931TDnDtLq",
      "client_secret":"bUdDcFgv3nXffnU",
      "grant_type":"password",
      "username":"mpK6lBx9RoE5LiffoDbpF931TDnDtLq",
      "password":"bUdD2FvnMsXffnU"
   }'

   Interfejs API zwraca token dostępu i token odświeżania. Odpowiedź wygląda mniej więcej tak:

   {
       "token": "your-access-token",
       "access_token": "your-access-token",
       "token_type": "bearer",
       "expires_in": "108000",
       "refresh_token": "your-refresh-token",
       "refresh_token_expires_in": "431999",
       "refresh_token_issued_at": "1562087304302",
       "refresh_token_status": "approved"
   }

2. Teraz możesz użyć tokena odświeżania, aby uzyskać nowy token dostępu, wywołując punkt końcowy /refresh tego samego interfejsu API. Na przykład:

   curl -X POST \
     https://willwitman-test.apigee.net/edgemicro-auth/refresh \
     -H 'Content-Type: application/json' \
     -d '{
      "client_id":"mpK6l1Bx9RoE5zLifoDbpF931TDnDtLq",
      "client_secret":"bUdDc2Fv3nMXffnU",
      "grant_type":"refresh_token",
      "refresh_token":"your-refresh-token"
   }'

   Interfejs API zwraca nowy token dostępu. Odpowiedź wygląda mniej więcej tak:

   {
       "token": "your-new-access-token"
       }

Stałe monitorowanie

Forever to narzędzie Node.js, które automatycznie ponownie uruchamia aplikację Node.js, jeśli proces ulegnie awarii lub wystąpi w nim błąd. Edge Microgateway ma plik forever.json, który możesz skonfigurować, aby określić, ile razy i w jakich odstępach czasu Edge Microgateway ma być ponownie uruchamiany. Ten plik konfiguruje usługę Forever o nazwie forever-monitor, która zarządza Forever programowo.

Plik forever.json znajdziesz w katalogu głównym instalacji Edge Microgateway. Zobacz Gdzie jest zainstalowana usługa Edge Microgateway. Szczegółowe informacje o opcjach konfiguracji znajdziesz w dokumentacji forever-monitor.

Polecenie edgemicro forever zawiera flagi, które umożliwiają określenie lokalizacji pliku forever.json (flaga -f) oraz rozpoczęcie i zatrzymanie procesu monitorowania Forever (flaga -a). Na przykład:

edgemicro forever -f ~/mydir/forever.json -a start

Więcej informacji znajdziesz w sekcji Forever monitoring w dokumentacji referencyjnej CLI.

Określanie punktu końcowego pliku konfiguracyjnego

Jeśli uruchamiasz wiele instancji Edge Microgateway, możesz zarządzać ich konfiguracjami z jednego miejsca. Możesz to zrobić, określając punkt końcowy HTTP, z którego Edge Micro może pobrać plik konfiguracji. Możesz określić ten punkt końcowy podczas uruchamiania Edge Micro za pomocą flagi -u.

Na przykład:

edgemicro start -o jdoe -e test -u http://mylocalserver/mgconfig -k public_key -s secret_key

gdzie punkt końcowy mgconfig zwraca zawartość pliku konfiguracji. Jest to plik, który domyślnie znajduje się w ~/.edgemicro i ma nazwę zgodną z tą konwencją: org-env-config.yaml.

Wyłączanie buforowania danych połączenia TCP

Możesz użyć atrybutu konfiguracji nodelay, aby wyłączyć buforowanie danych w przypadku połączeń TCP używanych przez Edge Microgateway.

Połączenia TCP domyślnie używają algorytmu Nagle do buforowania danych przed ich wysłaniem. Ustawienie nodelay na true wyłącza to działanie (dane będą wysyłane natychmiast za każdym razem, gdy zostanie wywołana funkcja socket.write()). Więcej informacji znajdziesz w dokumentacji Node.js.

Aby włączyć nodelay, zmodyfikuj plik konfiguracji Edge Micro w ten sposób:

edgemicro:
  nodelay: true
  port: 8000
  max_connections: 1000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

Uruchamianie Edge Microgateway w trybie samodzielnym

Możesz uruchomić Edge Microgateway całkowicie odłączony od wszelkich zależności Apigee Edge. W tym scenariuszu, zwanym trybem samodzielnym, możesz uruchamiać i testować Edge Microgateway bez połączenia z internetem.

W trybie samodzielnym nie działają te funkcje, ponieważ wymagają połączenia z Apigee Edge:

• OAuth i klucz interfejsu API
• Limit
• Analytics

Z drugiej strony wtyczki niestandardowe i ograniczanie nagłych wzrostów działają normalnie, ponieważ nie wymagają połączenia z Apigee Edge. Oprócz tego nowy wtyczka o nazwie extauth umożliwia autoryzowanie wywołań interfejsu API do mikrobramy za pomocą tokena JWT w trybie samodzielnym.

Konfigurowanie i uruchamianie bramy

Aby uruchomić Edge Microgateway w trybie samodzielnym:

1. Upewnij się, że masz zainstalowaną wersję Edge Microgateway 3.0.1 lub nowszą. Jeśli nie, musisz uruchomić to polecenie, aby przejść na najnowszą wersję:

   npm install -g edgemicro

   Jeśli potrzebujesz pomocy, przeczytaj artykuł Instalowanie Edge Microgateway.

2. Utwórz plik konfiguracyjny o nazwie: $HOME/.edgemicro/org_name-env_name-config.yaml

   Na przykład:

   vi $HOME/.edgemicro/foo-bar-config.yaml

3. Wklej do pliku ten kod:

   edgemicro:
     port: 8000
     max_connections: 1000
     config_change_poll_interval: 600
     logging:
       level: error
       dir: /var/tmp
       stats_log_interval: 60
       rotate_interval: 24
     plugins:
       sequence:
         - extauth
         - spikearrest
   headers:
     x-forwarded-for: true
     x-forwarded-host: true
     x-request-id: true
     x-response-time: true
     via: true
   extauth:
     publickey_url: https://www.googleapis.com/oauth2/v1/certs
   spikearrest:
     timeUnit: second
     allow: 10
     buffersize: 0

4. Wyeksportuj tę zmienną środowiskową z wartością „1”:

   export EDGEMICRO_LOCAL=1

5. Uruchom to polecenie start, podając wartości, aby utworzyć lokalny serwer proxy:

   edgemicro start -o org_name -e environment_name -a local_proxy_name \
     -v local_proxy_version -t target_url -b base_path

   Gdzie:

   • your_org to nazwa „org”, której użyto w nazwie pliku konfiguracji.
   • your_environment to nazwa „env”, której użyto w nazwie pliku konfiguracji.
   • local_proxy_name to nazwa lokalnego serwera proxy, który zostanie utworzony. Możesz użyć dowolnej nazwy.
   • local_proxy_version to numer wersji serwera proxy.
   • target_url to adres URL celu proxy. (Cel to usługa, do której wywołania kieruje proxy).
   • base_path to podstawowa ścieżka proxy. Ta wartość musi zaczynać się od ukośnika. W przypadku głównej ścieżki bazowej podaj tylko ukośnik, np. „/”.

   Na przykład:

   edgemicro start -o local -e test -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /

6. Przetestuj konfigurację.

   curl http://localhost:8000/echo  { "error" : "missing_authorization" }

   Ponieważ wtyczka extauth znajduje się w pliku foo-bar-config.yaml, występuje błąd „missing_authorization”. Ta wtyczka weryfikuje token JWT, który musi być obecny w nagłówku Authorization wywołania interfejsu API. W następnej sekcji uzyskasz token JWT, który umożliwi wywoływanie interfejsu API bez błędu.

Przykład: uzyskiwanie tokena autoryzacji

Poniższy przykład pokazuje, jak uzyskać token JWT z punktu końcowego tokena JWT Edge Microgateway w Apigee Edge (edgemicro-auth/jwkPublicKeys). Ten punkt końcowy jest wdrażany podczas standardowej konfiguracji Edge Microgateway. Aby uzyskać JWT z punktu końcowego Apigee, musisz najpierw przeprowadzić standardową konfigurację Edge Microgateway i mieć połączenie z internetem. Punkt końcowy Apigee jest tutaj używany wyłącznie na potrzeby przykładu i nie jest wymagany. Możesz użyć innego punktu końcowego tokena JWT. Jeśli tak, musisz uzyskać token JWT za pomocą interfejsu API udostępnionego dla tego punktu końcowego.

Poniżej opisujemy, jak uzyskać token za pomocą punktu końcowego edgemicro-auth/jwkPublicKeys:

1. Aby wdrożyć serwer proxy edgemicro-auth w organizacji lub środowisku w Apigee Edge, musisz przeprowadzić standardową konfigurację Edge Microgateway. Jeśli ten krok został już wykonany, nie musisz go powtarzać.
2. Jeśli Edge Microgateway został wdrożony w Apigee Cloud, musisz mieć połączenie z internetem, aby uzyskać JWT z tego punktu końcowego.
3. Zatrzymaj Edge Microgateway:

   edgemicro stop

4. W utworzonym wcześniej pliku konfiguracji ($HOME/.edgemicro/org-env-config.yaml) ustaw atrybut extauth:publickey_url na punkt końcowy edgemicro-auth/jwkPublicKeys w organizacji/środowisku Apigee Edge. Na przykład:

   extauth:
     publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'

5. Uruchom ponownie Edge Microgateway w taki sam sposób jak wcześniej, używając nazw organizacji i środowiska, które zostały użyte w nazwie pliku konfiguracji. Na przykład:

   edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /

6. Uzyskaj token JWT z punktu końcowego autoryzacji. Ponieważ używasz punktu końcowego edgemicro-auth/jwkPublicKeys, możesz użyć tego polecenia interfejsu CLI:

Token JWT dla Edge Microgateway możesz wygenerować za pomocą polecenia edgemicro token lub interfejsu API. Na przykład:

edgemicro token get -o your_org -e your_env \
  -i G0IAeU864EtBo99NvUbn6Z4CBwVcS2 -s uzHTbwNWvoSmOy

Gdzie:

• your_org to nazwa Twojej organizacji Apigee, dla której wcześniej skonfigurowano Edge Microgateway.
• your_env to środowisko w organizacji.
• Opcja i określa klucz klienta z aplikacji dewelopera, która ma usługę zawierającą serwer proxy edgemicro-auth.
• Opcja s określa tajny klucz klienta z aplikacji dewelopera, która ma produkt obejmujący serwer proxy edgemicro-auth.

To polecenie powoduje, że Apigee Edge generuje token JWT, który można następnie wykorzystać do weryfikacji wywołań interfejsu API.

Testowanie konfiguracji autonomicznej

Aby przetestować konfigurację, wywołaj interfejs API z tokenem dodanym w nagłówku Authorization w następujący sposób:

curl http://localhost:8000/echo -H "Authorization: Bearer your_token

Przykład:

curl http://localhost:8000/echo -H "Authorization: Bearer eyJraWQiOiIxIiwidHlwIjo...iryF3kwcDWNv7OQ"

Przykładowe dane wyjściowe:

{
   "headers":{
      "user-agent":"curl/7.54.0",
      "accept":"*/*",
      "x-api-key":"DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP",
      "client_received_start_timestamp":"1535134472699",
      "x-authorization-claims":"eyJhdDbiO...M1OTE5MTA1NDkifQ==",
      "target_sent_start_timestamp":"1535134472702",
      "x-request-id":"678e3080-a7ae-11e8-a70f-87ae30db3896.8cc81cb0-a7c9-11e8-a70f-87ae30db3896",
      "x-forwarded-proto":"http",
      "x-forwarded-host":"localhost:8000",
      "host":"mocktarget.apigee.net",
      "x-cloud-trace-context":"e2ac4fa0112c2d76237e5473714f1c85/1746478453618419513",
      "via":"1.1 localhost, 1.1 google",
      "x-forwarded-for":"::1, 216.98.205.223, 35.227.194.212",
      "connection":"Keep-Alive"
   },
   "method":"GET",
   "url":"/",
   "body":""
}

Korzystanie z trybu lokalnego serwera proxy

W trybie lokalnego serwera proxy Edge Microgateway nie wymaga wdrożenia w Apigee Edge serwera proxy obsługującego mikrobramę. Zamiast tego konfigurujesz „lokalny serwer proxy”, podając nazwę lokalnego serwera proxy, ścieżkę podstawową i docelowy adres URL podczas uruchamiania mikrobramy. Wywołania interfejsu API do mikrobramy są następnie wysyłane do docelowego adresu URL lokalnego serwera proxy. Pod każdym innym względem tryb lokalnego serwera proxy działa dokładnie tak samo jak Edge Microgateway w trybie normalnym. Uwierzytelnianie działa tak samo jak ochrona przed nagłymi wzrostami ruchu, egzekwowanie limitów, wtyczki niestandardowe itp.

Przypadek użycia i przykład

Tryb lokalnego serwera proxy jest przydatny, gdy chcesz powiązać tylko jeden serwer proxy z instancją Edge Microgateway. Możesz na przykład wstrzyknąć Edge Microgateway do Kubernetes jako pomocniczy serwer proxy, w którym mikrogateway i usługa działają w jednym podzie, a mikrogateway zarządza ruchem do i z powiązanej z nim usługi. Na ilustracji poniżej przedstawiono tę architekturę, w której Edge Microgateway działa jako pomocnicze proxy w klastrze Kubernetes. Każda instancja mikrobramy komunikuje się tylko z jednym punktem końcowym w usłudze towarzyszącej:

Zaletą tego stylu architektury jest to, że Edge Microgateway zapewnia zarządzanie interfejsami API dla poszczególnych usług wdrożonych w środowisku kontenerowym, takim jak klaster Kubernetes.

Konfigurowanie lokalnego trybu proxy

Aby skonfigurować Edge Microgateway do działania w trybie lokalnego serwera proxy, wykonaj te czynności:

1. Upewnij się, że masz zainstalowaną wersję Edge Microgateway 3.0.1 lub nowszą. Jeśli nie, musisz uruchomić to polecenie, aby przejść na najnowszą wersję:

   npm install -g edgemicro

   Jeśli potrzebujesz pomocy, przeczytaj artykuł Instalowanie Edge Microgateway.

2. Uruchom edgemicro init, aby skonfigurować lokalne środowisko konfiguracji, dokładnie tak samo jak w przypadku typowej konfiguracji Edge Microgateway. Zobacz też Konfigurowanie Edge Microgateway.
3. Uruchom edgemicro configure, tak jak w przypadku typowej konfiguracji Edge Microgateway. Na przykład:

   edgemicro configure -o your_org -e your_env -u your_apigee_username

   To polecenie wdraża w Edge zasadę edgemicro-auth i zwraca klucz oraz tajny klucz, które będą potrzebne do uruchomienia mikrobramy. Jeśli potrzebujesz pomocy, przeczytaj artykuł Konfigurowanie Edge Microgateway.

4. W Apigee Edge utwórz usługę API z tymi obowiązkowymi wymaganiami konfiguracyjnymi (wszystkie inne konfiguracje możesz zarządzać w dowolny sposób):
   • Musisz dodać do produktu serwer proxy edgemicro-auth. Ten serwer proxy został wdrożony automatycznie po uruchomieniu polecenia edgemicro configure.
   • Musisz podać ścieżkę zasobu. Apigee zaleca dodanie do produktu tej ścieżki: /**. Więcej informacji znajdziesz w artykule Konfigurowanie działania ścieżki zasobu. Więcej informacji znajdziesz w artykule Tworzenie usług API w dokumentacji Edge.

5. W Apigee Edge utwórz dewelopera lub użyj istniejącego dewelopera, jeśli chcesz. Więcej informacji znajdziesz w artykule Dodawanie programistów za pomocą interfejsu zarządzania Edge.

6. W Apigee Edge utwórz aplikację dewelopera. Musisz dodać do niej utworzony przed chwilą produkt interfejsu API. Więcej informacji znajdziesz w artykule Rejestrowanie aplikacji w interfejsie zarządzania Edge.
7. Na komputerze, na którym jest zainstalowana usługa Edge Microgateway, wyeksportuj tę zmienną środowiskową z wartością „1”:

   export EDGEMICRO_LOCAL_PROXY=1

8. Uruchom to polecenie start:

   edgemicro start -o your_org -e your_environment -k your_key -s your_secret \
       -a local_proxy_name -v local_proxy_version -t target_url -b base_path

   Gdzie:

   • your_org to Twoja organizacja Apigee.
   • your_environment to środowisko w Twojej organizacji.
   • your_key to klucz zwrócony po uruchomieniu polecenia edgemicro configure.
   • your_secret to tajny klucz zwrócony po uruchomieniu polecenia edgemicro configure.
   • local_proxy_name to nazwa lokalnego serwera proxy, który zostanie utworzony.
   • local_proxy_version to numer wersji serwera proxy.
   • target_url to adres URL miejsca docelowego serwera proxy (usługi, którą serwer proxy będzie wywoływać).
   • base_path to podstawowa ścieżka proxy. Ta wartość musi zaczynać się od ukośnika. W przypadku głównej ścieżki bazowej podaj tylko ukośnik, np. „/”.

   Na przykład:

   edgemicro start -o your_org -e test -k 7eb6aae644cbc09035a...d2eae46a6c095f \
     -s e16e7b1f5d5e24df...ec29d409a2df853163a -a proxy1 -v 1 \
     -t http://mocktarget.apigee.net -b /echo

Testowanie konfiguracji

Możesz przetestować konfigurację lokalnego serwera proxy, wywołując punkt końcowy serwera proxy. Jeśli na przykład określisz ścieżkę podstawową /echo, możesz wywołać serwer proxy w ten sposób:

curl  http://localhost:8000/echo
{
  "error" : "missing_authorization",
  "error_description" : "Missing Authorization header"
}

Ten pierwszy wywołanie interfejsu API zwróciło błąd, ponieważ nie podano prawidłowego klucza interfejsu API. Klucz znajdziesz w utworzonej wcześniej aplikacji dla deweloperów. Otwórz aplikację w interfejsie Edge, skopiuj klucz konsumenta i użyj go w ten sposób:

curl  http://localhost:8000/echo -H 'x-api-key:your_api_key'

Na przykład:

curl  http://localhost:8000/echo -H "x-api-key:DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP"

Przykładowe dane wyjściowe:

{
  "headers":{
    "user-agent":"curl/7.54.0",
    "accept":"*/*",
    "x-api-key":"DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP",
    "client_received_start_timestamp":"1535134472699",
    "x-authorization-claims":"eyJhdWQiOi...TQ0YmUtOWNlOS05YzM1OTE5MTA1NDkifQ==",
    "target_sent_start_timestamp":"1535134472702",
    "x-request-id":"678e3080-a7ae-11e8-a70f-87ae30db3896.8cc81cb0-a7c9-11e8-a70f-87ae30db3896",
    "x-forwarded-proto":"http",
    "x-forwarded-host":"localhost:8000",
    "host":"mocktarget.apigee.net",
    "x-cloud-trace-context":"e2ac4fa0112c2d76237e5473714f1c85/1746478453618419513",
    "via":"1.1 localhost, 1.1 google",
    "x-forwarded-for":"::1, 216.98.205.223, 35.227.194.212",
    "connection":"Keep-Alive"
  },
  "method":"GET",
  "url":"/",
  "body":""
}