Google używa technologii AI do tłumaczenia treści na Twój preferowany język. Tłumaczenia wygenerowane przez AI mogą zawierać błędy.

Dokumentacja operacji i konfiguracji Edge Microgateway

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

Edge Microgateway w wersji 3.3.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.

Aby przejść na najnowszą wersję Edge Microgateway, uruchom to polecenie npm:
```
npm upgrade edgemicro -g
```
Aby zainstalować konkretną wersję Edge Microgateway, musisz podać numer wersji w poleceniu instalacji. Aby na przykład zainstalować wersję 3.2.3, użyj tego polecenia:
```
npm install edgemicro@3.2.3 -g
```

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

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

Na koniec uaktualnij serwer proxy edgemicro-auth do najnowszej wersji:
```
edgemicro upgradeauth -o $ORG -e $ENV -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):

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. „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:

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. „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:

Wideo	Opis
Konfigurowanie jednokierunkowego protokołu TLS w kierunku północnym	Dowiedz się więcej o konfigurowaniu TLS w Apigee Edge Microgateway. Ten film zawiera omówienie protokołu TLS i jego znaczenia, wprowadzenie do TLS w Edge Microgateway oraz pokazuje, jak skonfigurować jednokierunkowy protokół TLS w kierunku północnym.
Konfigurowanie dwukierunkowego protokołu TLS w kierunku północnym	To drugi film o konfigurowaniu protokołu TLS w Apigee Edge Microgateway. Z tego filmu dowiesz się, jak skonfigurować dwukierunkowy protokół TLS w kierunku północnym.
Konfigurowanie jednokierunkowego i dwukierunkowego protokołu TLS w kierunku południowym	Ten trzeci film o konfigurowaniu protokołu TLS w Apigee Edge Microgateway wyjaśnia, jak skonfigurować jednokierunkowy i dwukierunkowy protokół TLS w kierunku południowym.

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:

Wygeneruj lub uzyskaj certyfikat SSL i klucz za pomocą narzędzia openssl lub dowolnej innej metody.

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

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:

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. Pamiętaj, że możesz określić wiele konkretnych wartości docelowych. Poniżej znajdziesz przykład wielu celów.

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

Jeśli chcesz zastosować ustawienia TLS/SSL do wielu konkretnych miejsc docelowych, musisz określić pierwszego hosta w konfiguracji jako „pustego”, co umożliwi uniwersalne żądania, a następnie określić konkretnych hostów w dowolnej kolejności. W tym przykładzie ustawienia są stosowane do wielu konkretnych hostów:

targets:
 - host:   ## Note that this value must be "empty"
   ssl:
     client:
       key: /Users/myname/twowayssl/ssl/client.key
       cert: /Users/myname/twowayssl/ssl/ca.crt
       passphrase: admin123
       rejectUnauthorized: true
 - host: 'myserver1.example.com'
   ssl:
     client:
       key: /Users/myname/twowayssl/ssl/client.key
       cert: /Users/myname/twowayssl/ssl/ca.crt
       rejectUnauthorized: true
 - host: 'myserver2.example.com'
   ssl:
     client:
       key: /Users/myname/twowayssl/ssl/client.key
       cert: /Users/myname/twowayssl/ssl/ca.crt
       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

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.

Ważne: jeśli zastąpisz domyślny serwer proxy uwierzytelniania, nowy serwer proxy lub usługa musi zwracać format odpowiedzi identyczny z domyślnym serwerem proxy edgemicro-auth.

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

Poziom logów, który ma być używany, określa się w konfiguracji edgemicro. Pełną listę poziomów logowania i ich opisów znajdziesz w artykule Atrybuty edgemicro.

Na przykład ta konfiguracja ustawia poziom logowania na debug:

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

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

Jak złagodzić rygorystyczne uprawnienia do plików dziennika

Domyślnie Edge Microgateway generuje plik dziennika aplikacji (api-log.log) z poziomem uprawnień ustawionym na 0600. Ten poziom uprawnień nie pozwala aplikacjom ani użytkownikom zewnętrznym odczytywać pliku dziennika. Aby złagodzić ten rygorystyczny poziom uprawnień, ustaw logging:disableStrictLogFile na true. Gdy ten atrybut ma wartość true, plik logu jest tworzony z uprawnieniami do pliku ustawionymi na 0755. Jeśli false lub atrybut nie jest podany, domyślne uprawnienia to 0600.

Dodano w wersji 3.2.3.

Na przykład:

edgemicro:
 logging:
   disableStrictLogFile: true

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 plik dziennika z rozszerzeniem .log. Konwencja nazewnictwa plików dziennika jest następująca:

edgemicro-HOST_NAME-INSTANCE_ID-api.log

Na przykład:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.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 wyświetlać te obiekty w konsoli, ustaw flagę wiersza poleceń DEBUG=* podczas uruchamiania Edge Microgateway. Na przykład:

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

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 – poziom rejestrowania. Ta wartość zależy od kontekstu transakcji i poziomu logowania ustawionego w konfiguracji edgemicro. Zobacz Jak ustawić poziom rejestrowania. W przypadku rekordów statystyk poziom jest ustawiony na stats. Rekordy statystyk są raportowane w regularnych odstępach czasu określonych w konfiguracji stats_log_interval. Zobacz też Jak zmieniać interwały logowania.
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 – poziom rejestrowania. Ta wartość zależy od kontekstu transakcji i poziomu logowania ustawionego w konfiguracji edgemicro. Zobacz Jak ustawić poziom rejestrowania. W przypadku rekordów statystyk poziom jest ustawiony na stats. Rekordy statystyk są raportowane w regularnych odstępach czasu określonych w konfiguracji stats_log_interval. Zobacz też Jak zmieniać interwały logowania.
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 – poziom rejestrowania. Ta wartość zależy od kontekstu transakcji i poziomu logowania ustawionego w konfiguracji edgemicro. Zobacz Jak ustawić poziom rejestrowania. W przypadku rekordów statystyk poziom jest ustawiony na stats. Rekordy statystyk są raportowane w regularnych odstępach czasu określonych w konfiguracji stats_log_interval. Zobacz też Jak zmieniać interwały logowania.
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 – poziom rejestrowania. Ta wartość zależy od kontekstu transakcji i poziomu logowania ustawionego w konfiguracji edgemicro. Zobacz Jak ustawić poziom rejestrowania. W przypadku rekordów statystyk poziom jest ustawiony na stats. Rekordy statystyk są raportowane w regularnych odstępach czasu określonych w konfiguracji stats_log_interval. Zobacz też Jak zmieniać interwały logowania.
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
```

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 – (zalecane) rejestruje wszystkie żądania i odpowiedzi przepływające przez instancję Edge Microgateway.
  - warn – rejestruje tylko komunikaty ostrzegawcze.
  - error – rejestruje tylko komunikaty o błędach.
  - debug – rejestruje komunikaty debugowania wraz z komunikatami informacyjnymi, ostrzeżeniami i błędami.
  - trace – rejestruje informacje o śledzeniu błędów wraz z komunikatami info, warn i error.
  - none – nie tworzy pliku dziennika.
- 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)
keep_alive_timeout: ta właściwość umożliwia ustawienie limitu czasu Edge Microgateway (w milisekundach). (Domyślnie: 5 sekund) (Dodano w wersji 3.0.6)
headers_timeout: ten atrybut ogranicza czas (w milisekundach), przez jaki parser HTTP będzie czekać na otrzymanie pełnych nagłówków HTTP.
Na przykład:
```
edgemicro:
  keep_alive_timeout: 6000
  headers_timeout: 12000
```
Wewnętrznie parametr ustawia atrybut Node.js Server.headersTimeout w żądaniach. (Domyślnie: 5 sekund więcej niż czas ustawiony za pomocą edgemicro.keep_alive_timeout. To ustawienie domyślne zapobiega przypadkowemu przerwaniu połączenia przez systemy równoważenia obciążenia lub serwery proxy). (Dodano w wersji 3.1.1)
noRuleMatchAction: (String) Działanie do wykonania (zezwolenie lub odmowa dostępu), jeśli reguła dopasowania określona we wtyczce accesscontrol nie zostanie rozwiązana (nie będzie pasować). Prawidłowe wartości: ALLOW lub DENY. Wartość domyślna: ALLOW (dodano w wersji 3.1.7).
enableAnalytics: (domyślnie: true) Ustaw atrybut na false, aby zapobiec wczytywaniu wtyczki analitycznej. W takim przypadku nie będą wykonywane żadne wywołania do analiz Apigee Edge. Jeśli zasada ma wartość true lub ten atrybut nie jest podany, wtyczka analityczna będzie działać jak zwykle. Szczegółowe informacje znajdziesz w sekcji Atrybuty edgemicro. (Dodano w wersji 3.1.8).
Przykład:
```
edgemicro
  enableAnalytics=false|true
```
Jeśli wartość enableAnalytics jest ustawiona na false, ale Edge Microgateway jest uruchamiana za pomocą wtyczki danych, wtyczka analityczna będzie działać normalnie, ponieważ wtyczka danych potrzebuje wtyczki analitycznej do działania. Więcej informacji o wtyczce do pomiarów znajdziesz w informacjach o wersji Edge Microgateway 1.3.6.

on_target_response_abort: ten atrybut umożliwia kontrolowanie zachowania Edge Microgateway, jeśli połączenie między klientem (Edge Microgateway) a serwerem docelowym zostanie przedwcześnie zamknięte.

Wartość	Opis
Domyślny	Jeśli parametr `on_target_response_abort` nie jest określony, domyślnym działaniem jest obcięcie odpowiedzi bez wyświetlania błędu. W plikach dzienników wyświetla się komunikat ostrzegawczy z wartością `targetResponse aborted` i kodem odpowiedzi 502.
`appendErrorToClientResponseBody`	Klientowi zwracany jest błąd niestandardowy `TargetResponseAborted`. W plikach dzienników wyświetla się komunikat ostrzegawczy z wartością `targetResponse aborted` i kodem odpowiedzi 502. Dodatkowo błąd `TargetResponseAborted` jest rejestrowany z komunikatem `Target response ended prematurely.`.
`abortClientRequest`	Edge Microgateway przerywa żądanie, a w plikach dziennika zapisywane jest ostrzeżenie:`TargetResponseAborted` z kodem stanu żądania 502.

Przykład:

edgemicro:
 on_target_response_abort: appendErrorToClientResponseBody | abortClientRequest

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)
Nie ustawiaj jednocześnie wartości allowOAuthOnly i allowAPIKeyOnly na true. Domyślnie oba te flagi mają wartość false (na potrzeby zgodności wstecznej).
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:

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

Filtrowanie produktów według nazwy

Użyj tej konfiguracji, aby ograniczyć liczbę produktów API, które Edge Microgateway pobiera i przetwarza. Aby filtrować pobrane produkty, dodaj parametr zapytania productnamefilter do interfejsu /products API wymienionego w pliku Edge Microgateway *.config.yaml. Na przykład:

edge_config:
  bootstrap: >-
    https://edgemicroservices.apigee.net/edgemicro/bootstrap/organization/willwitman/environment/test
  jwt_public_key: 'https://myorg-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://myorg-test.apigee.net/edgemicro-auth/products?productnamefilter=%5E%5BEe%5Ddgemicro.%2A%24'

Pamiętaj, że wartość parametru zapytania musi być podana w formacie wyrażenia regularnego i zakodowana na potrzeby adresu URL. Na przykład wyrażenie regularne ^[Ee]dgemicro.*$ pasuje do nazw takich jak: „edgemicro-test-1”, „edgemicro_demo” i „Edgemicro_New_Demo”. Wartość zakodowana na potrzeby adresu URL, odpowiednia do użycia w parametrze zapytania, to: %5E%5BEe%5Ddgemicro.%2A%24.

Poniższe dane wyjściowe debugowania pokazują, że pobrano tylko przefiltrowane produkty:

...
2020-05-27T03:13:50.087Z [76060] [microgateway-config network] products download from https://gsc-demo-prod.apigee.net/edgemicro-auth/products?productnamefilter=%5E%5BEe%5Ddgemicro.%2A%24 returned 200 OK
...
....
....
{
   "apiProduct":[
      {
         "apiResources":[

         ],
         "approvalType":"auto",
         "attributes":[
            {
               "name":"access",
               "value":"public"
            }
         ],
         "createdAt":1590549037549,
         "createdBy":"k***@g********m",
         "displayName":"test upper case in name",
         "environments":[
            "prod",
            "test"
         ],
         "lastModifiedAt":1590549037549,
         "lastModifiedBy":"k***@g********m",
         "name":"Edgemicro_New_Demo",
         "proxies":[
            "catchall"
         ],
         "quota":"null",
         "quotaInterval":"null",
         "quotaTimeUnit":"null",
         "scopes":[

         ]
      },
      {
         "apiResources":[

         ],
         "approvalType":"auto",
         "attributes":[
            {
               "name":"access",
               "value":"public"
            }
         ],
         "createdAt":1590548328998,
         "createdBy":"k***@g********m",
         "displayName":"edgemicro test 1",
         "environments":[
            "prod",
            "test"
         ],
         "lastModifiedAt":1590548328998,
         "lastModifiedBy":"k***@g********m",
         "name":"edgemicro-test-1",
         "proxies":[
            "Lets-Encrypt-Validation-DoNotDelete"
         ],
         "quota":"null",
         "quotaInterval":"null",
         "quotaTimeUnit":"null",
         "scopes":[

         ]
      },
      {
         "apiResources":[
            "/",
            "/**"
         ],
         "approvalType":"auto",
         "attributes":[
            {
               "name":"access",
               "value":"public"
            }
         ],
         "createdAt":1558182193472,
         "createdBy":"m*********@g********m",
         "displayName":"Edge microgateway demo product",
         "environments":[
            "prod",
            "test"
         ],
         "lastModifiedAt":1569077897465,
         "lastModifiedBy":"m*********@g********m",
         "name":"edgemicro_demo",
         "proxies":[
            "edgemicro-auth",
            "edgemicro_hello"
         ],
         "quota":"600",
         "quotaInterval":"1",
         "quotaTimeUnit":"minute",
         "scopes":[

         ]
      }
   ]
}

Filtrowanie produktów według atrybutów niestandardowych

Aby filtrować produkty na podstawie atrybutów niestandardowych:

W interfejsie Edge wybierz serwer proxy edgemicro_auth w organizacji lub środowisku, w którym skonfigurowano Edge Microgateway.
Na karcie Develop (Tworzenie) otwórz w edytorze zasadę JavaCallout.
Dodaj atrybut niestandardowy z kluczem products.filter.attributes zawierający rozdzieloną przecinkami listę nazw atrybutów. Do Edge Microgateway będą zwracane tylko produkty zawierające dowolną z nazw atrybutów niestandardowych.
Możesz opcjonalnie wyłączyć sprawdzanie, czy produkt jest włączony w bieżącym środowisku, ustawiając atrybut niestandardowy products.filter.env.enable na false. (Wartość domyślna to true).
(Tylko w przypadku chmury prywatnej) Jeśli korzystasz z Edge for Private Cloud, ustaw właściwość org.noncps na true, aby pobierać produkty dla środowisk innych niż CPS.

Na przykład:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<JavaCallout async="false" continueOnError="false" enabled="true" name="JavaCallout">
    <DisplayName>JavaCallout</DisplayName>
    <FaultRules/>
    <Properties>
        <Property name="products.filter.attributes">attrib.one, attrib.two</Property>
        <Property name="products.filter.env.enable">false</Property>
        <Property name="org.noncps">true</Property>
    </Properties>
    <ClassName>io.apigee.microgateway.javacallout.Callout</ClassName>
    <ResourceURL>java://micro-gateway-products-javacallout-2.0.0.jar</ResourceURL>
</JavaCallout>

Filtrowanie produktów według stanu wycofania

Produkty API mają 3 kody stanu: Oczekujący, Zatwierdzony i Cofnięty. Do zasady Ustaw zmienne JWT w proxy edgemicro-auth została dodana nowa właściwość o nazwie allowProductStatus. Aby użyć tej właściwości do filtrowania produktów interfejsu API wymienionych w JWT:

Otwórz serwer proxy edgemicro-auth w edytorze serwerów proxy Apigee.

Dodaj właściwość allowProductStatus do kodu XML zasady SetJWTVariables i określ listę kodów stanu rozdzieloną przecinkami, według których chcesz filtrować. Aby na przykład filtrować według stanu Oczekująca i Cofnięta:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Javascript timeLimit="20000" async="false" continueOnError="false"
    enabled="true" name="Set-JWT-Variables">
    <DisplayName>Set JWT Variables</DisplayName>
    <FaultRules/>
    <Properties>
        <Property name="allowProductStatus">Pending,Revoked</Property>
    </Properties>
    <ResourceURL>jsc://set-jwt-variables.js</ResourceURL>
</Javascript>

Jeśli chcesz, aby wyświetlane były tylko produkty zatwierdzone, ustaw właściwość w ten sposób:

<Property name="allowProductStatus">Approved</Property>

Zapisz serwer proxy.
Jeśli tag Property nie jest obecny, w tokenie JWT zostaną wymienione produkty ze wszystkimi kodami stanu.

Aby używać tej nowej właściwości, musisz uaktualnić serwer proxy edgemicro-auth.

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

Używanie serwera proxy HTTP do komunikacji z Apigee Edge

Dodano w wersji 3.1.2.

Aby użyć serwera proxy HTTP do komunikacji między Edge Microgateway a Apigee Edge:

Ustaw zmienne środowiskowe HTTP_PROXY, HTTPS_PROXY i NO_PROXY. Te zmienne określają hosty poszczególnych serwerów proxy HTTP, których chcesz używać do komunikacji z Apigee Edge, lub hosty, które nie powinny obsługiwać komunikacji z Apigee Edge. Na przykład:
```
export HTTP_PROXY='http://localhost:3786'
export HTTPS_PROXY='https://localhost:3786'
export NO_PROXY='localhost,localhost:8080'
```
Pamiętaj, że NO_PROXY może być listą domen rozdzieloną przecinkami, do których Edge Microgateway nie powinien przekazywać żądań.

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

Używanie serwera proxy HTTP do komunikacji z miejscem docelowym

Dodano w wersji 3.1.2.

Aby użyć serwera proxy HTTP do komunikacji między Edge Microgateway a docelowymi backendami:

Dodaj tę konfigurację do pliku konfiguracji mikrobramy:
```
edgemicro:
  proxy:
    tunnel: true | false
    url: proxy_url
    bypass: target_host # target hosts to bypass the proxy.
    enabled: true | false
```
Gdzie:
- tunnel: (Opcjonalnie) Jeśli ma wartość true, Edge Microgateway używa metody HTTP CONNECT do tunelowania żądań HTTP przez jedno połączenie TCP. (To samo dotyczy sytuacji, gdy zmienne środowiskowe wymienione poniżej, które służą do konfigurowania serwera proxy, mają włączony protokół TLS). Domyślnie: false
- url: adres URL serwera proxy HTTP.
- bypass: (Opcjonalnie) określa co najmniej jeden adres URL hosta docelowego rozdzielony przecinkami, który powinien pomijać serwer proxy HTTP. Jeśli ta właściwość nie jest ustawiona, użyj zmiennej środowiskowej NO_PROXY, aby określić, które docelowe adresy URL mają być pomijane.
- enabled: jeśli wartość to „true” i ustawiono parametr proxy.url, użyj wartości proxy.url dla serwera proxy HTTP. Jeśli wartość to „true” i nie ustawiono zmiennej proxy.url, użyj serwerów proxy określonych w zmiennych środowiskowych serwera proxy HTTP HTTP_PROXY i HTTPS_PROXY, zgodnie z opisem w artykule Używanie serwera proxy HTTP do komunikacji z Apigee Edge.
Na przykład:
```
edgemicro:
  proxy:
    tunnel: true
    url: 'http://localhost:3786'
    bypass: 'localhost','localhost:8080' # target hosts to bypass the proxy.
    enabled: true
```
UWAGA: Uwaga: jeśli w pliku konfiguracyjnym pominięto edgemicro.proxy lub jeśli edgemicro.proxy.enabled ma wartość false, Edge Microgateway nie będzie używać serwera proxy HTTP do komunikacji z usługą docelową.
Ponownie uruchom Edge Microgateway.

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ć.

Możesz wygenerować JWT za pomocą interfejsu CLI i użyć go w nagłówku autoryzacji wywołań interfejsu API zamiast klucza API. Na przykład:

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

Informacje o generowaniu tokenów JWT za pomocą interfejsu wiersza poleceń znajdziesz w artykule Generowanie tokena.

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, używany będzie stary klucz publiczny, dopóki JWT nie wygaśnie (po upływie interwału token_expiry*, domyślnie 30 minut). 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.

Aby uaktualnić KVM, użyj polecenia edgemicro upgradekvm. Szczegółowe informacje o uruchamianiu tego polecenia znajdziesz w artykule Uaktualnianie KVM. Wystarczy wykonać ten krok tylko raz.
Aby uaktualnić serwer proxy edgemicro-oauth, użyj polecenia edgemicro upgradeauth. Szczegółowe informacje o uruchamianiu tego polecenia znajdziesz w artykule Uaktualnianie serwera proxy edgemicro-auth. Wystarczy wykonać ten krok tylko raz.
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. Szczegółowe informacje o tym poleceniu znajdziesz w artykule Rotacja kluczy.

edgemicro rotatekey -o $ORG -e $ENV -k $KEY -s $SECRET

Na przykład:

edgemicro rotatekey -o docs -e test \
-k 27ee39567c75e4567a66236cbd4e86d1cc93df6481454301bd5fac4d3497fcbb \
-s 4618b0008a6185d7327ebf53bee3c50282ccf45a3cceb1ed9828bfbcf1148b47

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"
    }
  ]
}

Konfigurowanie opóźnienia „nie wcześniej niż”

W przypadku wersji 3.1.5 i starszych nowy klucz prywatny wygenerowany przez polecenie rotatekey zaczynał obowiązywać od razu, a nowe tokeny były podpisywane nowym kluczem prywatnym. Nowy klucz publiczny był jednak udostępniany instancjom Edge Microgateway tylko co 10 minut (domyślnie) podczas odświeżania konfiguracji mikrobramy. Ze względu na to opóźnienie między podpisaniem tokena a odświeżeniem instancji mikrobramy tokeny podpisane najnowszym kluczem będą odrzucane, dopóki wszystkie instancje nie otrzymają najnowszego klucza publicznego.

W przypadku istnienia wielu instancji mikrobramy opóźnienie klucza publicznego czasami powodowało sporadyczne błędy środowiska wykonawczego o stanie 403, ponieważ weryfikacja tokena przechodziła w jednej instancji, ale kończyła się niepowodzeniem w innej, dopóki wszystkie instancje nie zostały odświeżone.

Od wersji 3.1.6 nowe polecenie w rotatekey umożliwia określenie opóźnienia, po którym nowy klucz prywatny zacznie obowiązywać. Dzięki temu wszystkie instancje mikrobramy będą miały czas na odświeżenie i otrzymanie nowego klucza publicznego. Nowa flaga to --nbf, co oznacza „nie wcześniej niż”. Ten parametr przyjmuje wartość całkowitą, czyli liczbę minut opóźnienia.

W tym przykładzie opóźnienie jest ustawione na 15 minut:

edgemicro rotatekey -o docs -e test \
-k 27ee39567c75e4567a66236cbd4e86d1cc93df6481454301bd5fac4d3497fcbb \
-s 4618b0008a6185d7327ebf53bee3c50282ccf45a3cceb1ed9828bfbcf1148b47 \
--nbf 15

Pamiętaj, że dobrą praktyką jest ustawienie opóźnienia dłuższego niż ustawienie konfiguracji config_change_poll_internal, które domyślnie wynosi 10 minut. Zobacz też atrybuty edgemicro.

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.

Otwórz plik konfiguracyjny Edge Micro: ~/.edgemicro/org-env-config.yaml
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.

Uruchom ponownie Edge Microgateway w trybie debugowania. Aby to zrobić, dodaj znak DEBUG=* na początku polecenia start:
```
DEBUG=* edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET
```
UWAGA: w systemie Windows użyj SET DEBUG=*
.
Aby przekierować dane wyjściowe debugowania do pliku, możesz użyć tego polecenia:
```
export DEBUG=* nohup edgemicro start \
-o $ORG -e $ENV -k $KEY -s $SECRET 2>&1 | tee /tmp/file.log
```
Uruchom debuger i ustaw go tak, aby nasłuchiwał numeru portu w procesie debugowania.
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.

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

Interfejs API zwraca odpowiedź w formacie JSON. Pamiętaj, że nie ma różnicy między właściwościami token i access_token. Możesz użyć dowolnego z nich. Pamiętaj, że expires_in to liczba całkowita podana w sekundach.

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

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.

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: Pamiętaj, że expires_in to liczby całkowite podane w sekundach.

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

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

Usunięto: ta funkcja interfejsu wiersza poleceń została usunięta w wersji 3.3.3 Edge Microgateway. Ciąg forever-monitor możesz zastąpić wartością PM2. Więcej informacji znajdziesz w tym poście na forum społeczności Apigee: Edgemicro + PM2: Starting edgemicro as a service (Edgemicro + PM2: uruchamianie edgemicro jako usługi). Zobacz też informacje o wersji Edge Microgateway 3.3.3.

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:

Utwórz plik konfiguracyjny o nazwie: $HOME/.edgemicro/$ORG-$ENV-config.yaml
W nazwie pliku możesz użyć dowolnych wartości dla $ORG i $ENV. Połączenie organizacji i środowiska to po prostu konwencja, która umożliwia Edge Microgateway znalezienie pliku podczas uruchamiania.

Na przykład:
```
vi $HOME/.edgemicro/foo-bar-config.yaml
```
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
```
Plik konfiguracji zawiera specjalną, opcjonalną wtyczkę o nazwie extauth. Ta wtyczka weryfikuje prawidłowy token JWT przekazany do mikrobramy. W dalszej części dowiesz się, jak uzyskać i używać tokena. Pamiętaj też, że wtyczka spikearrest jest uwzględniona, ponieważ nie zależy od połączenia z Edge. Wtyczki quota, oauth i analytics są wykluczone, ponieważ wymagają połączenia z Edge i nie będą działać w trybie odłączonym. Wtyczki niestandardowe są dozwolone i będą działać zgodnie z oczekiwaniami.
Wyeksportuj tę zmienną środowiskową z wartością „1”:
```
export EDGEMICRO_LOCAL=1
```
Uruchom to polecenie start, podając wartości, aby utworzyć lokalny serwer proxy:
```
edgemicro start -o $ORG -e $ENV -a $LOCAL_PROXY_NAME \
  -v $LOCAL_PROXY_VERSION -t $TARGET_URL -b $BASE_PATH
```
Gdzie:
- $ORG to nazwa „org”, której użyto w nazwie pliku konfiguracji.
- $ENV 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 /
```
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.

Uwzględnienie wtyczki extauth w konfiguracji mikrobramy jest opcjonalne, ale jeśli to zrobisz, będziesz musiał(-a) podać prawidłowy token JWT w nagłówku Authorization w przypadku wywołań interfejsu API.

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

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ć.
Jeśli Edge Microgateway został wdrożony w Apigee Cloud, musisz mieć połączenie z internetem, aby uzyskać JWT z tego punktu końcowego.
Zatrzymaj Edge Microgateway:
```
edgemicro stop
```
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'
```
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 /
```
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:
Na tym etapie potrzebne będzie połączenie z internetem. To polecenie pobiera token z Apigee Edge. Aby wykonać ten krok, musisz mieć organizację Apigee, w której przeprowadzono standardową konfigurację Edge Microgateway. Po wykonaniu tego kroku nie musisz mieć połączenia z internetem. Token będzie działać w trybie samodzielnym do momentu wygaśnięcia.

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.

Zobacz też Generowanie tokena.

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.

Dwie ważne różnice między trybem lokalnym a zwykłą konfiguracją Edge Microgateway to: (1) w trybie lokalnym nie musisz tworzyć w Apigee Edge serwera proxy obsługującego mikrobramę i (2) gdy tworzysz produkt API w Edge, musisz dodać do niego tylko 1 serwer proxy, czyli serwer proxy edgemicro-auth. Nie musisz dodawać do produktu żadnych innych serwerów proxy.

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:

Edgemicro jako kontener pomocniczy

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:

Uruchom edgemicro init, aby skonfigurować lokalne środowisko konfiguracji, dokładnie tak samo jak w przypadku typowej konfiguracji Edge Microgateway. Zobacz też Konfigurowanie Edge Microgateway.
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.
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.
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.
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.
Na komputerze, na którym jest zainstalowana usługa Edge Microgateway, wyeksportuj tę zmienną środowiskową z wartością „1”:
```
export EDGEMICRO_LOCAL_PROXY=1
```
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":""
}

Korzystanie z synchronizatora

W tej sekcji opisujemy, jak używać synchronizatora, czyli opcjonalnej funkcji, która zwiększa odporność Edge Microgateway, umożliwiając mu pobieranie danych konfiguracyjnych z Apigee Edge i zapisywanie ich w lokalnej bazie danych Redis. Gdy działa instancja synchronizatora, inne instancje Edge Microgateway działające na różnych węzłach mogą pobierać konfigurację bezpośrednio z tej bazy danych.

Funkcja synchronizatora jest obecnie obsługiwana w przypadku Redis w wersji 5.0.x.

Czym jest synchronizator?

Synchronizator zapewnia pewien poziom odporności Edge Microgateway. Pomaga to zapewnić, że każda instancja Edge Microgateway korzysta z tej samej konfiguracji, a w przypadku awarii internetu instancje Edge Microgateway mogą się uruchamiać i działać prawidłowo.

Domyślnie instancje Edge Microgateway muszą mieć możliwość komunikowania się z Apigee Edge w celu pobierania i odświeżania danych konfiguracyjnych, takich jak konfiguracje proxy interfejsu API i produktu API. Jeśli połączenie internetowe z Edge zostanie przerwane, instancje mikrobramy mogą nadal działać, ponieważ najnowsze dane konfiguracyjne są przechowywane w pamięci podręcznej. Jednak nowe instancje mikrobramy nie mogą się uruchomić bez wyraźnego połączenia. Ponadto zakłócenie działania internetu może spowodować, że co najmniej jedna instancja mikrobramy będzie działać z informacjami o konfiguracji, które nie są zsynchronizowane z innymi instancjami.

Synchronizator Edge Microgateway zapewnia alternatywny mechanizm pobierania przez instancje Edge Microgateway danych konfiguracyjnych, które są im potrzebne do uruchomienia i przetwarzania ruchu proxy interfejsu API. Dane konfiguracyjne pobierane z wywołań Apigee Edge obejmują: wywołanie jwk_public_keys, wywołanie jwt_public_key, wywołanie bootstrap i wywołanie produktów API. Synchronizator umożliwia prawidłowe uruchamianie wszystkich instancji Edge Microgateway działających na różnych węzłach i utrzymywanie ich synchronizacji nawet w przypadku przerwania połączenia internetowego między Edge Microgateway a Apigee Edge.

Synchronizator to specjalnie skonfigurowana instancja Edge Microgateway. Jego jedynym celem jest odpytywanie Apigee Edge (czas jest konfigurowalny), pobieranie danych konfiguracyjnych i zapisywanie ich w lokalnej bazie danych Redis. Sama instancja synchronizatora nie może przetwarzać ruchu proxy interfejsu API. Inne instancje Edge Microgateway działające na różnych węzłach można skonfigurować tak, aby pobierały dane konfiguracyjne z bazy danych Redis, a nie z Apigee Edge. Ponieważ wszystkie instancje mikrobramy pobierają dane konfiguracyjne z lokalnej bazy danych, mogą uruchamiać się i przetwarzać żądania interfejsu API nawet w przypadku przerw w dostępie do internetu.

Konfigurowanie instancji synchronizatora

Dodaj do pliku org-env/config.yaml następującą konfigurację dla instalacji Edge Microgateway, której chcesz używać jako synchronizatora:

edgemicro:
  redisHost: host_IP
  redisPort: host_port
  redisDb: database_index
  redisPassword: password
edge_config:
  synchronizerMode: 1
  redisBasedConfigCache: true

Na przykład:

edgemicro:
  redisHost: 192.168.4.77
  redisPort: 6379
  redisDb: 0
  redisPassword: codemaster
edge_config:
  synchronizerMode: 1
  redisBasedConfigCache: true

Opcja	Opis
`redisHost`	Host, na którym działa instancja Redis. Domyślnie: 127.0.0.1
`redisPort`	Port instancji Redis. Domyślnie: 6379
`redisDb`	Baza danych Redis do użycia. Domyślnie: 0
`redisPassword`	hasło do bazy danych,

Możesz użyć zmiennej środowiskowej EDGEMICRO_REDIS_PASSWORD, aby zastąpić parametr edgemicro.redisPassword. Zobacz też Ustawianie atrybutów konfiguracji za pomocą wartości zmiennych środowiskowych.

Na koniec zapisz plik konfiguracji i uruchom instancję Edge Microgateway. Rozpocznie on odpytywanie Apigee Edge i przechowywanie pobranych danych konfiguracyjnych w bazie danych Redis.

Konfigurowanie zwykłych instancji Edge Microgateway

Po uruchomieniu synchronizatora możesz skonfigurować dodatkowe węzły Edge Microgateway, aby uruchamiać zwykłe instancje mikrobramy, które przetwarzają ruch proxy interfejsu API. Możesz jednak skonfigurować te instancje tak, aby pobierały dane konfiguracyjne z bazy danych Redis, a nie z Apigee Edge.

Dodaj tę konfigurację do pliku org-env/config.yaml każdego dodatkowego węzła Edge Microgateway. Właściwość synchronizerMode ma wartość 0. Ta właściwość ustawia instancję tak, aby działała jako zwykła instancja Edge Microgateway, która przetwarza ruch proxy interfejsu API, a instancja będzie pobierać dane konfiguracyjne z bazy danych Redis.

edgemicro:
  redisHost: host_IP
  redisPort: host_port
  redisDb: database_index
  redisPassword: password
edge_config:
  synchronizerMode: 0
  redisBasedConfigCache: true

Na przykład:

edgemicro:
  redisHost: 192.168.4.77
  redisPort: 6379
  redisDb: 0
  redisPassword: codemaster
edge_config:
  synchronizerMode: 0
  redisBasedConfigCache: true

Właściwości konfiguracji

Aby umożliwić korzystanie z synchronizatora, dodaliśmy te właściwości konfiguracji:

Atrybut Wartości Opis

Atrybut	Wartości	Opis
`edge_config.synchronizerMode`	0 lub 1	Jeśli wartość to 0 (domyślnie), Edge Microgateway działa w trybie standardowym. Jeśli wartość to 1, uruchom instancję Edge Microgateway, aby działała jako synchronizator. W tym trybie instancja pobiera dane konfiguracyjne z Apigee Edge i przechowuje je w lokalnej bazie danych Redis. Ta instancja nie może przetwarzać żądań serwera proxy interfejsu API. Jej jedynym celem jest odpytywanie Apigee Edge o dane konfiguracyjne i zapisywanie ich w lokalnej bazie danych. Następnie musisz skonfigurować inne instancje mikrobramy tak, aby odczytywały dane z bazy danych.
`edge_config.redisBasedConfigCache`	true or false	Jeśli ma wartość „true”, instancja Edge Microgateway pobiera dane konfiguracyjne z bazy danych Redis zamiast z Apigee Edge. Baza danych Redis musi być tą samą bazą, do której synchronizator jest skonfigurowany do zapisywania danych. Jeśli baza danych Redis jest niedostępna lub pusta, mikrobrama szuka istniejącego pliku `cache-config.yaml` do konfiguracji. Jeśli wartość to false (domyślnie), instancja Edge Microgateway pobiera dane konfiguracyjne z Apigee Edge jak zwykle.
`edgemicro.config_change_poll_interval`	Przedział czasu w sekundach	Określa odstęp sondowania, w jakim synchronizator pobiera dane z Apigee Edge.

edge_config.synchronizerMode

0 lub 1

Jeśli wartość to 0 (domyślnie), Edge Microgateway działa w trybie standardowym.

Jeśli wartość to 1, uruchom instancję Edge Microgateway, aby działała jako synchronizator. W tym trybie instancja pobiera dane konfiguracyjne z Apigee Edge i przechowuje je w lokalnej bazie danych Redis. Ta instancja nie może przetwarzać żądań serwera proxy interfejsu API. Jej jedynym celem jest odpytywanie Apigee Edge o dane konfiguracyjne i zapisywanie ich w lokalnej bazie danych. Następnie musisz skonfigurować inne instancje mikrobramy tak, aby odczytywały dane z bazy danych.

edge_config.redisBasedConfigCache

true or false

Jeśli ma wartość „true”, instancja Edge Microgateway pobiera dane konfiguracyjne z bazy danych Redis zamiast z Apigee Edge. Baza danych Redis musi być tą samą bazą, do której synchronizator jest skonfigurowany do zapisywania danych. Jeśli baza danych Redis jest niedostępna lub pusta, mikrobrama szuka istniejącego pliku cache-config.yaml do konfiguracji.

Jeśli wartość to false (domyślnie), instancja Edge Microgateway pobiera dane konfiguracyjne z Apigee Edge jak zwykle.

edgemicro.config_change_poll_interval Przedział czasu w sekundach Określa odstęp sondowania, w jakim synchronizator pobiera dane z Apigee Edge.

Konfigurowanie wykluczonych adresów URL w przypadku wtyczek

Możesz skonfigurować mikrobramę tak, aby pomijała przetwarzanie wtyczek w przypadku określonych adresów URL. Możesz skonfigurować te adresy URL „wykluczone” globalnie (dla wszystkich wtyczek) lub dla konkretnych wtyczek.

Na przykład:

...
edgemicro:
  ...
  plugins:
    excludeUrls: '/hello,/proxy_one' # global exclude urls
    sequence:
      - oauth
      - json2xml
      - quota
json2xml:
  excludeUrls: '/hello/xml'  # plugin level exclude urls
...

W tym przykładzie wtyczki nie będą przetwarzać przychodzących wywołań proxy interfejsu API ze ścieżkami /hello ani /proxy_one. Dodatkowo wtyczka json2xml będzie pomijana w przypadku interfejsów API, których ścieżka zawiera /hello/xml.

Nie możesz wykluczyć wtyczki analytics.

Ustawianie atrybutów konfiguracji za pomocą wartości zmiennych środowiskowych

Zmienne środowiskowe możesz określić za pomocą tagów w pliku konfiguracji. Określone tagi zmiennych środowiskowych są zastępowane rzeczywistymi wartościami zmiennych środowiskowych. Zamienniki są przechowywane tylko w pamięci i nie są zapisywane w oryginalnej konfiguracji ani w plikach pamięci podręcznej.

Uwaga: domyślnie tag <E> analizuje wartości zmiennych jako ciągi znaków. Aby określić dodatnie liczby całkowite i wartości logiczne, użyj wewnętrznych tagów <n> i <b>, jak pokazano w przykładach poniżej.

W tym przykładzie atrybut key jest zastępowany wartością zmiennej środowiskowej TARGETS_SSL_CLIENT_KEY itd.

targets:
  - ssl:
      client:
        key: <E>TARGETS_SSL_CLIENT_KEY</E>
        cert: <E>TARGETS_SSL_CLIENT_CERT</E>
        passphrase: <E>TARGETS_SSL_CLIENT_PASSPHRASE</E>

W tym przykładzie tag <n> służy do wskazania wartości całkowitej. Obsługiwane są tylko dodatnie liczby całkowite.

edgemicro:
  port: <E><n>EMG_PORT</n></E>

W tym przykładzie tag <b> służy do wskazania wartości logicznej (czyli prawda lub fałsz).

quotas:
  useRedis: <E><b>EMG_USE_REDIS</b></E>