Dokumentacja operacji i konfiguracji Edge Microgateway

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

Edge Microgateway w wersji 2.4.x

Przegląd

W tym artykule znajdziesz informacje o zarządzaniu i konfigurowaniu Edge Microgateway, w tym o monitorowaniu, rejestrowaniu i debugowaniu.

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ć. Szczegółowe informacje o ustawieniach pliku konfiguracyjnego znajdziesz w artykule Informacje o konfiguracji Edge Microgateway.

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 katalog z prefiksem npm. Zobacz Gdzie jest zainstalowana usługa Edge Microgateway.

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

  1. Zadzwoń: edgemicro init
  2. Zadzwoń: edgemicro configure [params]
  3. Zadzwoń: edgemicro start [params]

Domyślny plik konfiguracyjny nowo zainicjowanych instancji Edge Microgateway

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

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

  1. edgemicro stop
  2. edgemicro configure [params]
  3. 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 potem ponownie je wczytywać bez przestojów. 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] -e [env] -k [key] -s [secret]

    Gdzie:

    • org to nazwa Twojej organizacji Edge (musisz być administratorem organizacji).
    • env to środowisko w Twojej organizacji (np. testowe lub produkcyjne).
    • 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 701e70ee718ce6dc188016b3c39177d64a88754d615c74e1f78b6181d000723 -s 05c14356e42ed136b8dd35cf8a18531ff52d7299134677e30ef4e34ab0cc824

Jeśli Edge Microgateway jest zatrzymany:

  1. Uruchom ponownie Edge Microgateway:
    edgemicro start -o [org] -e [env] -k [key] -s [secret]

    Gdzie:

    • org to nazwa Twojej organizacji Edge (musisz być administratorem organizacji).
    • env to środowisko w Twojej organizacji (np. testowe lub produkcyjne).
    • key to klucz zwrócony wcześniej przez polecenie configure.
    • secret to klucz zwrócony wcześniej przez polecenie configure.

    Przykład

    edgemicro start -o docs -e test -k 701e70ee718ce6dc188016b3c39177d64a88754d615c74e1f78b6181d000723 -s 05c14356e42ed136b8dd35cf8a18531ff52d7299134677e30ef4e34ab0cc824

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

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 poniższej tabeli. Szczegółowe informacje o modyfikowaniu konfiguracji Edge Microgateway znajdziesz w artykule Wprowadzanie zmian w konfiguracji. 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 ze skonfigurowanym protokołem 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:

Opcja Opis
key Ścieżka do pliku ca.key (w formacie PEM).
cert Ścieżka do pliku ca.cert (w formacie PEM).
pfx Ścieżka do pliku pfx zawierającego klucz prywatny, certyfikat i certyfikaty urzędu certyfikacji klienta w formacie PFX.
passphrase Ciąg zawierający hasło wielowyrazowe klucza prywatnego lub pliku PFX.
ca Ścieżka do pliku zawierającego listę zaufanych certyfikatów w formacie PEM.
ciphers Ciąg znaków opisujący szyfry do użycia, rozdzielone znakiem „:”.
rejectUnauthorized Jeśli wartość to „true”, certyfikat serwera jest weryfikowany na podstawie listy podanych urzędów certyfikacji. Jeśli weryfikacja się nie powiedzie, zwracany jest błąd.
secureProtocol Metoda SSL do użycia. Na przykład SSLv3_method, aby wymusić użycie protokołu SSL w wersji 3.
servername Nazwa serwera dla rozszerzenia TLS SNI (Server Name Indication).
requestCert wartość „true” w przypadku dwukierunkowego protokołu SSL, „false” w przypadku jednokierunkowego protokołu SSL.

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:

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:

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:

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:

Opcja Opis
pfx Ścieżka do pliku pfx zawierającego klucz prywatny, certyfikat i certyfikaty urzędu certyfikacji klienta w formacie PFX.
key Ścieżka do pliku ca.key (w formacie PEM).
passphrase Ciąg zawierający hasło wielowyrazowe klucza prywatnego lub pliku PFX.
cert Ścieżka do pliku ca.cert (w formacie PEM).
ca Ścieżka do pliku zawierającego listę zaufanych certyfikatów w formacie PEM.
ciphers Ciąg znaków opisujący szyfry do użycia, rozdzielone znakiem „:”.
rejectUnauthorized Jeśli wartość to „true”, certyfikat serwera jest weryfikowany na podstawie listy podanych urzędów certyfikacji. Jeśli weryfikacja się nie powiedzie, zwracany jest błąd.
secureProtocol Metoda SSL do użycia. Na przykład SSLv3_method, aby wymusić użycie protokołu SSL w wersji 3.
servername Nazwa serwera dla rozszerzenia TLS SNI (Server Name Indication).

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. Szczegółowe informacje o wprowadzaniu zmian w konfiguracji znajdziesz w artykule 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 logowania: info, warn i error. Zalecany jest poziom INFO. Rejestruje wszystkie żądania i odpowiedzi interfejsu API. Jest to ustawienie domyślne.

Jak zmienić interwały logowania

Te interwały możesz skonfigurować w pliku konfiguracyjnym Edge Microgateway. Szczegółowe informacje o wprowadzaniu zmian w konfiguracji znajdziesz w artykule 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

Uwaga: zarchiwizowane pliki logu nie są kompresowane. Gdy rozpocznie się interwał, zostanie utworzony nowy plik logu z nowym sygnaturą czasową.

Sprawdzone metody konserwacji 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

Uwaga: w systemie Windows użyj SET DEBUG=*.

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 prowadzenia dzienników.

Dokumentacja konfiguracji Edge Microgateway

Lokalizacja pliku konfiguracji

Atrybuty konfiguracji opisane w tej sekcji znajdują się w pliku konfiguracyjnym Edge Microgateway. Szczegółowe informacje o wprowadzaniu zmian w konfiguracji znajdziesz w artykule 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 i 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 i konfigurowanie Edge Microgateway.

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.
  • 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 wartość 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.
  • keepAuthHeader: (domyślnie: false) jeśli ma wartość true, nagłówek autoryzacji wysłany w żądaniu jest przekazywany do miejsca docelowego (jest zachowywany).
  • allowOAuthOnly – jeśli ma wartość „true”, każde wywołanie interfejsu 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 4.2.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 to zezwolenie tylko na model zabezpieczeń klucza interfejsu API (przy zachowaniu zgodności wstecznej). (Dodano w wersji 4.2.x)

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

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'

Konfigurowanie Edge Microgateway za zaporą sieciową firmy

Obsługiwana wersja 4.2.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ść proxy_tunnel to true, Edge Microgateway używa metody HTTP CONNECT do tunelowania żądań HTTP przez pojedyncze 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, przez które 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 w tych artykułach:

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 mikrobramę) 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 wyszukiwanie /*/ NIE jest obsługiwane.


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 uruchamiania. Na przykład:

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

    Uwaga: w systemie Windows użyj SET DEBUG=*.

  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 zabezpieczeń tokena OAuth2

Szczegółowe informacje o używaniu tokena OAuth w przypadku żądań proxy znajdziesz w artykule Zabezpieczanie Edge Microgateway.

Korzystanie z klucza interfejsu API

Więcej informacji o używaniu kluczy interfejsu API w przypadku żądań proxy znajdziesz w artykule Zabezpieczanie Edge Microgateway.

Konfigurowanie nazwy klucza interfejsu API

Domyślnie x-api-key to nazwa używana w nagłówku klucza interfejsu API lub w parametrze zapytania. Możesz zmienić tę wartość domyślną w pliku konfiguracyjnym, 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