Ta strona została przetłumaczona przez Cloud Translation API.

Dokumentacja operacji i konfiguracji Edge Microgateway

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

Edge Microgateway wer. 3.3.x

W tym temacie omówiono sposób zarządzania i konfigurowania Edge Microgateway.

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

Ta sekcja wyjaśnia, jak uaktualnić istniejącą instalację Edge Microgateway. Jeśli korzystasz z urządzenia bez połączenia z internetem, zapoznaj się z artykułem Czy mogę zainstalować Edge Microgateway bez połączenia z internetem?.

Apigee zaleca przetestowanie istniejącej konfiguracji przy użyciu nowej wersji przed uaktualnieniem środowiska produkcyjnego.

Wykonaj to polecenie npm, aby uaktualnić Edge Microgateway do najnowszej wersji:
```
npm upgrade edgemicro -g
```
Aby zainstalować konkretną wersję Edge Microgateway, musisz w poleceniu instalacji podać numer wersji. Jeśli na przykład chcesz zainstalować wersję 3.2.3, użyj tego polecenia:
```
npm install edgemicro@3.2.3 -g
```

Sprawdź numer wersji. Jeśli na przykład masz zainstalowaną 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ć, obejmują:

Domyślny plik konfiguracji systemu
Domyślny plik konfiguracji nowo zainicjowanej instancji Edge Microgateway
Dynamiczny plik konfiguracji na potrzeby uruchomionych instancji

W tej sekcji omawiamy te pliki i to, co musisz wiedzieć o ich zmianie.

Domyślny plik konfiguracji systemu

Gdy instalujesz Edge Microgateway, w tym miejscu zostanie umieszczony domyślny plik konfiguracji systemu:

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

Gdzie prefix to katalog prefiksów npm. Jeśli nie możesz znaleźć tego katalogu, zobacz Gdzie zainstalowano Edge Microgateway.

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

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

Domyślny plik konfiguracyjny dla nowo zainicjowanych instancji Edge Microgateway

Po uruchomieniu edgemicro init plik konfiguracji systemu (opisany powyżej) default.yaml jest umieszczany w katalogu ~/.edgemicro.

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

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

Plik konfiguracji dynamicznej dla uruchomionych instancji

Po uruchomieniu edgemicro configure [params] w ~/.edgemicro tworzony jest plik konfiguracji dynamicznej. Nazwa pliku jest zgodna z tym wzorcem: org-env-config.yaml, gdzie org i env to nazwy organizacji i środowisk Apigee Edge. Za pomocą tego pliku możesz wprowadzić zmiany w konfiguracji, a następnie ponownie załadować je z zerowym czasem przestoju. Jeśli na przykład dodasz i skonfigurujesz wtyczkę, możesz ponownie załadować konfigurację bez przerw w działaniu usługi, jak opisano poniżej.

Jeśli Edge Microgateway działa (opcja zerowego przestoju):

Załaduj ponownie konfigurację Edge Microgateway:
```
edgemicro reload -o $ORG -e $ENV -k $KEY -s $SECRET
```
Gdzie:
- $ORG to nazwa Twojej organizacji Edge (musisz być jej administratorem).
- $ENV to środowisko w Twojej organizacji (np. „test” lub „prod”).
- $KEY to klucz zwrócony wcześniej przez polecenie konfiguracji.
- $SECRET to klucz zwrócony wcześniej przez polecenie konfiguracji.
Przykład
```
edgemicro reload -o docs -e test -k 701e70ee718ce6dc188...78b6181d000723 \
  -s 05c14356e42ed1...4e34ab0cc824
```

Jeśli mikrofon Edge Microgateway został zatrzymany:

Ponowne uruchamianie Edge Microgateway:
```
edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET
```
Gdzie:
- $ORG to nazwa Twojej organizacji Edge (musisz być jej administratorem).
- $ENV to środowisko w Twojej organizacji (np. „testowe” lub „produkcyjne”).
- $KEY to klucz zwrócony wcześniej przez polecenie konfiguracji.
- $SECRET to klucz zwrócony wcześniej przez polecenie konfiguracji.
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 konfiguracji znajdziesz w dokumentacji konfiguracji Edge Microgateway (w języku angielskim).

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 dotyczących organizacji i środowiska Edge, a także klucz i tajny klucz potrzebne do uruchomienia Edge Microgateway, mogą być przechowywane w tych zmiennych środowiskowych:

EDGEMICRO_ORG
EDGEMICRO_ENV
EDGEMICRO_KEY
EDGEMICRO_SECRET

Ustawienie tych zmiennych jest opcjonalne. Jeśli je ustawisz, nie będzie trzeba określać ich wartości podczas konfigurowania i uruchamiania Edge Microgateway za pomocą interfejsu wiersza poleceń (CLI).

Konfigurowanie SSL na serwerze Edge Microgateway

Obejrzyj te filmy, aby dowiedzieć się więcej o konfigurowaniu 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, omówienie protokołu TLS w Microsoft Edge Microgateway oraz sposobu konfigurowania jednokierunkowego protokołu TLS w kierunku północnym.
Skonfiguruj dwukierunkowy protokół TLS w kierunku północnym	To drugi film na temat konfigurowania protokołu TLS w mikrogateway Apigee Edge. Ten film wyjaśnia, jak skonfigurować dwukierunkowy protokół TLS kierowany na północ.
Skonfiguruj jedno- i dwukierunkowe protokół TLS w południowej części	Trzeci film na temat konfigurowania protokołu TLS w Apigee Edge Microgateway wyjaśnia, jak skonfigurować jedno- i dwukierunkowy protokół TLS w kierunku południowym.

Serwer Microgateway możesz skonfigurować do korzystania z SSL. Na przykład po skonfigurowaniu SSL możesz wywoływać interfejsy API przez Edge Microgateway z użyciem protokołu „https” w ten sposób:

https://localhost:8000/myapi

Aby skonfigurować protokół SSL na serwerze Microgateway, wykonaj następujące czynności:

Wygeneruj lub uzyskaj certyfikat i klucz SSL za pomocą narzędzia openssl lub preferowanej 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 edytowanego pliku konfiguracji: pliku domyślnego lub pliku 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`, który zawiera klucz prywatny, certyfikat i certyfikaty urzędów certyfikacji klienta w formacie PFX.
`passphrase`	Ciąg tekstowy zawierający hasło klucza prywatnego lub pliku PFX.
`ca`	Ścieżka do pliku zawierającego listę zaufanych certyfikatów w formacie PEM.
`ciphers`	Ciąg opisujący mechanizmy szyfrowania, oddzielony znakiem „:”.
`rejectUnauthorized`	Jeśli ma wartość true (prawda), certyfikat serwera jest weryfikowany pod kątem listy dostarczonych urzędów certyfikacji. Jeśli weryfikacja się nie powiedzie, zostanie zwrócony błąd.
`secureProtocol`	Metoda SSL, która ma być używana. Przykład: metoda SSLv3_method wymusza stosowanie protokołu SSL do wersji 3.
`servername`	Nazwa serwera dla rozszerzenia TLS SNI (Server Name Indication).
`requestCert`	Prawda dla dwukierunkowego protokołu SSL, Fałsz dla jednokierunkowego protokołu SSL

Korzystanie z opcji SSL/TLS klienta

Podczas nawiązywania połączenia z docelowymi punktami końcowymi możesz skonfigurować Edge Microgateway jako klienta TLS lub SSL. W pliku konfiguracji Microgateway użyj elementu „target”, aby ustawić opcje SSL/TLS. Pamiętaj, że możesz określić wiele konkretnych celów. Poniżej znajdziesz przykład z wieloma miejscami docelowymi.

W tym przykładzie przedstawiono 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 zostały zastosowane 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 obsługi protokołu 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 celów, musisz określić pierwszego hosta w konfiguracji jako „pusty”, co umożliwia stosowanie żądań uniwersalnych, a następnie określić konkretne hosty w dowolnej kolejności. W tym przykładzie ustawienia zostały zastosowane 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`, który zawiera klucz prywatny, certyfikat i certyfikaty urzędów certyfikacji klienta w formacie PFX.
`key`	Ścieżka do pliku `ca.key` (w formacie PEM).
`passphrase`	Ciąg tekstowy zawierający hasło 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 opisujący mechanizmy szyfrowania, oddzielony znakiem „:”.
`rejectUnauthorized`	Jeśli ma wartość true (prawda), certyfikat serwera jest weryfikowany pod kątem listy dostarczonych urzędów certyfikacji. Jeśli weryfikacja się nie powiedzie, zostanie zwrócony błąd.
`secureProtocol`	Metoda SSL, która ma być używana. Przykład: metoda SSLv3_method wymusza stosowanie protokołu SSL do wersji 3.
`servername`	Nazwa serwera dla rozszerzenia TLS SNI (Server Name Indication).

Dostosowywanie serwera proxy uwierzytelniania Edgemicro

Domyślnie Edge Microgateway używa serwera proxy wdrożonego w Apigee Edge do uwierzytelniania OAuth2. Ten serwer proxy jest wdrażany przy pierwszym uruchomieniu programu edgemicro configure. Możesz zmienić domyślną konfigurację tego serwera proxy, aby dodać obsługę deklaracji niestandardowych do tokena sieciowego JSON (JWT), skonfigurować datę ważności tokena i wygenerować 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 przy pierwszym uruchomieniu programu edgemicro configure. Domyślnie adres URL tego serwera proxy jest określony w pliku konfiguracyjnym Edge Microgateway w następujący sposób:

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

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

Ważne: jeśli zastąpisz domyślny serwer proxy uwierzytelniania, nowy serwer 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 logów zawierają przydatne informacje przy debugowaniu i rozwiązywaniu problemów.

Miejsce przechowywania plików dziennika

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

Jak zmienić domyślny katalog pliku logu

Katalog, w którym są przechowywane pliki logów, 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 wskazać inny katalog pliku dziennika.

Wysyłaj logi do konsoli

Możesz skonfigurować logowanie w taki sposób, aby informacje logu były wysyłane na standardowe dane wyjściowe, a nie do pliku logu. Ustaw flagę to_console na „true” (prawda) w ten sposób:

edgemicro:
  logging:
    to_console: true

Przy tym ustawieniu dzienniki będą wysyłane do stanu standardowego. Obecnie nie można wysyłać logów zarówno do stdout, jak i do pliku logu.

Jak ustawić poziom rejestrowania

Poziom logowania określasz w konfiguracji edgemicro. Pełną listę poziomów logu i ich opisy znajdziesz w artykule o atrybutach Edgemicro.

Na przykład taka 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 logu

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

Atrybuty, które można skonfigurować:

stats_log_interval: (domyślnie: 60) Odstęp w sekundach, podczas którego rekord statystyk jest zapisywany w pliku dziennika interfejsu API.
rotate_interval: (domyślnie: 24) interwał, w godzinach, podczas których rotacja plików dziennika jest wykonywana. 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 pliku dziennika

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

Dodano w wersji 3.2.3.

Na przykład:

edgemicro:
 logging:
   disableStrictLogFile: true

Sprawdzone metody konserwacji plików dziennika

W miarę gromadzenia danych w pliku logu Apigee zaleca zastosowanie tych metod:

Pliki dziennika mogą być dość duże, dlatego upewnij się, że katalog pliku dziennika ma wystarczającą ilość miejsca. Zapoznaj się z sekcjami Gdzie są przechowywane pliki dziennika i Jak zmienić domyślny katalog pliku dziennika.
Co najmniej raz w tygodniu usuwaj lub przenieś pliki dziennika do osobnego katalogu archiwum.
Jeśli zasadą jest usuwanie logów, możesz usunąć (oczyścić) starsze logi za pomocą polecenia interfejsu wiersza poleceń edgemicro log -c.

Konwencja nazewnictwa plików dziennika

Każda instancja Edge Microgateway tworzy plik dziennika z rozszerzeniem .log. Konwencja nazewnictwa plików dziennika jest taka:

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 logowania pomija plik JSON z pobranymi serwerami proxy, usługami i tokenem sieciowym JSON (JWT). Jeśli chcesz wyświetlić te obiekty w konsoli, przy uruchamianiu Edge Microgateway ustaw flagę wiersza poleceń DEBUG=*. Na przykład:

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

W systemie Windows użyj SET DEBUG=*

Zawartość pliku dziennika „api”

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

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

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

Żądanie przychodzące od klienta
Żądanie wychodzące wysłane do środowiska docelowego
Przychodząca odpowiedź z środowiska docelowego
Odpowiedź wychodząca do klienta

Każdy z tych wpisów jest przedstawiony w notacji skróconej, dzięki czemu pliki logów są bardziej kompaktowe. Oto 4 przykładowe wpisy reprezentujące każde z 4 zdarzeń. W pliku dziennika wyglądają one tak (numery wierszy są używane tylko w celach informacyjnych w dokumencie i nie są widoczne 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 pojedynczo:

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

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

1436403888651 – znacznik daty uniksowej
info – poziom logowania. Ta wartość zależy od kontekstu transakcji i poziomu logowania ustawionego w konfiguracji edgemicro. Zobacz, jak ustawić poziom rejestrowania. Rekord statystyk to stats. Rekordy statystyk są raportowane w regularnych odstępach czasu ustawianych za pomocą konfiguracji stats_log_interval. Zobacz też Jak zmienić interwały logu.
req – identyfikuje zdarzenie. W takim przypadku wyślij żądanie od klienta.
m – czasownik HTTP użyty w żądaniu.
u – część adresu URL po ścieżce bazowej.
h – host i numer portu, na którym nasłuchuje Edge Microgateway.
r – host zdalny i port, z którego wyszło żądanie klienta.
i – identyfikator żądania. Wszystkie cztery wpisy wydarzenia będą miały ten identyfikator. Do każdego żądania jest przypisywany unikalny identyfikator. Korelowanie rekordów logów według identyfikatora żądania może dać cenny wgląd w czas oczekiwania w celu.
d – czas w milisekundach od momentu odebrania żądania przez Edge Microgateway. W powyższym przykładzie odpowiedź celu na żądanie 0 została otrzymana po 7 milisekundach (wiersz 3), a odpowiedź do klienta została wysłana po upływie dodatkowych 4 milisekund (wiersz 4). Innymi słowy, całkowity czas oczekiwania na żądanie wynosił 11 milisekund, z czego 7 milisekund zostało wykonane przez serwer docelowy, a 4 milisekundy przez Edge Microgateway.

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

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

1436403888651 – znacznik daty uniksowej
info – poziom logowania. Ta wartość zależy od kontekstu transakcji i poziomu logowania ustawionego w konfiguracji edgemicro. Zobacz, jak ustawić poziom rejestrowania. Rekord statystyk to stats. Rekordy statystyk są raportowane w regularnych odstępach czasu ustawianych za pomocą konfiguracji stats_log_interval. Zobacz też Jak zmienić interwały logu.
treq – identyfikuje zdarzenie. W takim przypadku jest to żądanie docelowe.
m – czasownik HTTP używany w żądaniu docelowym.
u – część adresu URL po ścieżce bazowej.
h – host i numer portu docelowego backendu.
i – identyfikator wpisu logu. Wszystkie 4 wpisy dotyczące wydarzenia będą miały ten identyfikator.

3. Przykładowa odpowiedź przychodząca z środowiska docelowego

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

1436403888651 – znacznik daty uniksowej

info – poziom logowania. Ta wartość zależy od kontekstu transakcji i poziomu logowania ustawionego w konfiguracji edgemicro. Zobacz, jak ustawić poziom rejestrowania. Rekord statystyk to stats. Rekordy statystyk są raportowane w regularnych odstępach czasu ustawianych za pomocą konfiguracji stats_log_interval. Zobacz też Jak zmienić interwały logu.
tres – identyfikuje zdarzenie. W tym przypadku jest to odpowiedź docelowa.
s – stan odpowiedzi HTTP.
d – czas w milisekundach. Czas potrzebny na wywołanie interfejsu API przez element docelowy.
i – identyfikator wpisu logu. Wszystkie 4 wpisy dotyczące wydarzenia będą miały ten identyfikator.

4. Próbka odpowiedzi wychodzącej dla klienta

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

1436403888651 – znacznik daty uniksowej

info – poziom logowania. Ta wartość zależy od kontekstu transakcji i poziomu logowania ustawionego w konfiguracji edgemicro. Zobacz, jak ustawić poziom rejestrowania. Rekord statystyk to stats. Rekordy statystyk są raportowane w regularnych odstępach czasu ustawianych za pomocą konfiguracji stats_log_interval. Zobacz też Jak zmienić interwały logu.
res – identyfikuje zdarzenie. W tym przypadku odpowiedź dla klienta.
s – stan odpowiedzi HTTP.
d – czas w milisekundach. Jest to łączny czas potrzebny na wywołanie interfejsu API, w tym czas przeznaczony przez docelowy interfejs API oraz przez samą usługę Edge Microgateway.
i – identyfikator wpisu logu. Wszystkie 4 wpisy dotyczące wydarzenia będą miały ten identyfikator.

Harmonogram plików dziennika

Pliki logów są rotowane co interwałem określonym przez atrybut konfiguracji rotate_interval. Wpisy będą nadal dodawane do tego samego pliku logu, dopóki nie upłynie okres rotacji. Jednak przy każdym ponownym uruchomieniu Edge Microgateway otrzymuje nowy identyfikator UID i tworzy nowy zestaw plików logów z tym identyfikatorem. Zapoznaj się też ze sprawdzonymi metodami konserwacji plików logów.

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.

Dokumentacja konfiguracji Edge Microgateway

Lokalizacja pliku konfiguracji

Atrybuty konfiguracji opisane w tej sekcji znajdują się w pliku konfiguracji 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) URL wskazujący usługę Edge Microgateway działającą w Apigee Edge. Edge Microgateway używa tej usługi do komunikacji z Apigee Edge. Ten URL jest zwracany podczas wykonywania polecenia generującego parę kluczy publiczny/prywatny: edgemicro genkeys. Więcej informacji znajdziesz w artykule Konfigurowanie Edge Microgateway.
jwt_public_key: (domyślnie: brak) URL wskazujący serwer proxy Edge Microgateway wdrożony w Apigee Edge. Ten serwer proxy służy jako punkt końcowy uwierzytelniania przy wystawianiu podpisanych tokenów dostępu klientom. Ten adres URL jest zwracany po wykonaniu polecenia wdrożenia serwera proxy: edgemicro configure. Więcej informacji znajdziesz w artykule Konfigurowanie Edge Microgateway.
quotaUri: ustaw tę właściwość konfiguracji, jeśli chcesz zarządzać limitami przez serwer proxy edgemicro-auth wdrożony w Twojej organizacji. Jeśli ta właściwość nie jest ustawiona, domyślnie punkt końcowy limitu to wewnętrzny punkt końcowy Edge Microgateway.
```
edge_config:
  quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
```

atrybuty Edgemicro

Te ustawienia służą do konfigurowania procesu Edge Microgateway.

port: (domyślnie: 8000) numer portu, na którym nasłuchuje proces Edge Microgateway.
max_connections: (wartość domyślna: -1) określa maksymalną liczbę jednoczesnych połączeń przychodzących, które może odebrać 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 odebrać przed wyłączeniem połączenia. To ustawienie ma zapobiegać atakom typu DoS. Zwykle należy ustawić wartość większą niż max_connections.
logging:
- level (domyślnie: błąd)
  - info (zalecane) rejestruje wszystkie żądania i odpowiedzi, które przechodzą przez instancję Edge Microgateway.
  - warn (ostrzeżenie) – rejestrowane są tylko komunikaty ostrzegawcze.
  - error (błąd) – rejestrowane są tylko komunikaty o błędach.
  - debugowanie – rejestruje komunikaty debugowania wraz z informacjami, ostrzeżeniami i komunikatami o błędach.
  - trace (ślad) – rejestruje informacje z śladu pod kątem błędów, a także komunikaty, ostrzeżenia i komunikaty o błędach.
  - none (brak) – nie twórz pliku dziennika.
- dir (domyślnie: /var/tmp) katalog, w którym są przechowywane pliki dziennika.
- stats_log_interval: (domyślnie: 60) Odstęp w sekundach, podczas którego rekord statystyk jest zapisywany w pliku dziennika interfejsu API.
- rotate_interval: (domyślnie: 24) interwał, w godzinach, podczas których rotacja plików dziennika jest wykonywana.

Wtyczki: wtyczki dodają funkcje do Edge Microgateway. Szczegółowe informacje na temat tworzenia wtyczek znajdziesz w artykule Tworzenie wtyczek niestandardowych.

dir: ścieżka względna z katalogu ./gateway do katalogu ./Wtyczki lub ścieżka bezwzględna.
sequence: lista modułów wtyczek, które chcesz dodać do instancji Edge Microgateway. Moduły będą uruchamiane w kolejności, w której zostały tu określone.

debugowanie: dodaje debugowanie zdalne do procesu Edge Microgateway.
- port: numer portu na potrzeby nasłuchiwania. Możesz na przykład skonfigurować debuger IDE tak, 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 co jakiś czas wczytuje nową konfigurację i jeśli coś się zmieni. Odpytywanie wykrywa wszystkie zmiany wprowadzone w Edge (zmiany w usługach, serwery proxy rozpoznające mikrobramę itp.), a także zmiany wprowadzone w lokalnym pliku konfiguracji.
disable_config_poll_interval: (domyślnie: fałsz) ustaw wartość true, aby wyłączyć automatyczne odpytywanie zmian.
request_timeout: ustawia czas oczekiwania dla żądań docelowych. Limit czasu jest ustawiany w sekundach. Jeśli limit czasu zostanie przekroczony, Edge Microgateway wyśle odpowiedź z kodem stanu 504. (Dodano wersję 2.4.x)
keep_alive_timeout: ta właściwość umożliwia ustawienie czasu oczekiwania na Edge Microgateway (w milisekundach). (Domyślnie: 5 sekund) (dodano wersję 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 ten ustawia w żądaniach atrybut Node.js Server.headersTimeout. (Domyślnie: o 5 sekund dłużej niż czas ustawiony w edgemicro.keep_alive_timeout). To ustawienie domyślne zapobiega omyłkowemu odrzucaniu połączenia przez systemy równoważenia obciążenia i serwery proxy. (Dodano wersję 3.1.1)
noRuleMatchAction: (ciąg znaków) działanie, które ma być wykonane (zezwolenie na dostęp lub odmowa dostępu), jeśli reguła dopasowania określona we wtyczce accesscontrol nie zostanie rozwiązana (jest niedopasowana). Prawidłowe wartości: ALLOW lub DENY Wartość domyślna: ALLOW (dodana: wersja 3.1.7)
enableAnalytics: (domyślnie: true) ustaw wartość atrybutu na false, aby uniemożliwić wczytanie wtyczki Analytics. W takim przypadku żadne wywołania statystyk Apigee Edge nie będą wykonywane. Jeśli ma wartość true lub nie jest określony, wtyczka Analytics będzie działać w zwykły sposób. Więcej informacji znajdziesz w artykule o atrybutach Edgemicro. (Dodano wersję 3.1.8).
Przykład:
```
edgemicro
  enableAnalytics=false|true
```
Jeśli atrybut enableAnalytics ma wartość false, ale Edge Microgateway korzysta z wtyczki Metrics, to wtyczka do analityki będzie działać normalnie, ponieważ wtyczka metryk do jej działania wymaga wtyczki analitycznej. Więcej informacji o wtyczce wskaźników znajdziesz w informacjach o wersji 1.3.6 Edge Microgateway.

on_target_response_abort: ten atrybut pozwala kontrolować zachowanie Edge Microgateway w przypadku przedwczesnego zamknięcia połączenia między klientem (Edge Microgateway) a serwerem docelowym.

Wartość	Opis
Domyślnie	Jeśli `on_target_response_abort` nie jest określony, domyślnym działaniem jest obcinanie odpowiedzi bez wyświetlania błędu. W plikach logów wyświetla się komunikat ostrzegawczy z `targetResponse aborted` i kodem odpowiedzi 502.
`appendErrorToClientResponseBody`	Niestandardowy błąd `TargetResponseAborted` jest zwracany klientowi. W plikach logów wyświetla się komunikat ostrzegawczy z `targetResponse aborted` i kodem odpowiedzi 502. Dodatkowo błąd `TargetResponseAborted` jest logowany z komunikatem `Target response ended prematurely.`
`abortClientRequest`	Edge Microgateway przerywa żądanie i w plikach logu zapisywanych 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 obsługi niektórych nagłówków HTTP.

x-forwarded-for: (domyślnie: true) ustaw na false (fałsz), aby uniemożliwić przekazywanie do elementu docelowego nagłówków x-forwarded-for. 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 na wartość false (fałsz), aby uniemożliwić przekazywanie nagłówków x-forwarded-host do elementu docelowego.
x-request-id: (domyślnie: true) ustaw na false, by uniemożliwić przesyłanie nagłówków x-request-id do elementu docelowego.
x-response-time: (domyślnie: true) ustaw wartość false (fałsz), aby uniemożliwić przesyłanie nagłówków x-response-time do elementu docelowego.
via: (domyślnie: prawda) ustaw na false, aby zapobiec przekazywaniu za pomocą nagłówków do elementu docelowego.

atrybuty protokołu OAuth

Te ustawienia określają sposób wymuszania uwierzytelniania klientów przez Edge Microgateway.

allowNoAuthorization: (domyślnie: false) jeśli zasada ma wartość Prawda, wywołania interfejsu API mogą przechodzić przez Edge Microgateway bez żadnego nagłówka autoryzacji. Aby wymagać nagłówka autoryzacji (domyślnie), ustaw wartość false (fałsz).
allowInvalidAuthorization: (domyślnie: false) jeśli ustawiona jest wartość true, wywołania interfejsu API mogą być przekazywane, jeśli token przekazany w nagłówku autoryzacji jest nieprawidłowy lub wygasł. Aby wymagać prawidłowych tokenów (domyślnie), ustaw tę wartość na false (fałsz).
authorization-header: (domyślnie: Authorization: Bearer) nagłówek używany do wysyłania tokena dostępu do Edge Microgateway. Możesz zmienić wartość domyślną, jeśli cel musi używać nagłówka autoryzacji do innych celów.
api-key-header: (domyślnie: x-api-key) nazwa nagłówka lub parametru zapytania używanego do przekazania klucza interfejsu API do Edge Microgateway. Patrz też Używanie klucza interfejsu API.
keep-authorization-header: (domyślnie: fałsz) Jeśli ta zasada ma wartość Prawda, nagłówek autoryzacji wysłany w żądaniu jest przekazywany do elementu docelowego (zachowywany).
allowOAuthOnly – jeśli ma wartość Prawda, każdy interfejs API musi mieć nagłówek Authorization z tokenem dostępu okaziciela. Pozwala zezwolić tylko na model zabezpieczeń OAuth (przy zachowaniu zgodności wstecznej). (Dodano wersję 2.4.x)
allowAPIKeyOnly – jeśli ma wartość Prawda, każdy interfejs API musi mieć nagłówek x-api-key (lub niestandardową lokalizację) z kluczem interfejsu API.Pozwala zezwolić na używanie tylko modelu zabezpieczeń klucza interfejsu API (z zachowaniem zgodności wstecznej). (Dodano 2.4.x)
Nie ustawiaj wartości prawda zarówno dla allowOAuthOnly, jak i allowAPIKeyOnly. Domyślnie obie flagi mają wartość false (fałsz) (na potrzeby zgodności wstecznej).
gracePeriod – ten parametr pomaga zapobiegać błędom spowodowanym przez niewielkie rozbieżności między zegarem systemowym a czasami nieprzed (nbf) lub Issued At (iat) określonymi w tokenie autoryzacji JWT. Aby umożliwić wystąpienie takich rozbieżności, ustaw w tym parametrze liczbę sekund. (Dodano 2.5.7)

Atrybuty konkretnej wtyczki

Szczegółowe informacje o konfigurowalnych atrybutach dla każdej wtyczki znajdziesz w sekcji Korzystanie z wtyczek.

Filtrowanie serwerów proxy

Możesz filtrować serwery proxy z uwzględnieniem mikrobramy, które będzie przetwarzać instancja Edge Microgateway. Po uruchomieniu Edge Microgateway pobiera wszystkie serwery proxy rozpoznające mikrobramy w organizacji, z którą jest powiązana. Użyj poniższej konfiguracji, aby ograniczyć serwery proxy, które będzie przetwarzać mikrobrama. Na przykład ta konfiguracja ogranicza serwery proxy przetwarzane przez mikrobramę do 3 serwerów: 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ę usług interfejsu API pobieranych i przetwarzanych przez Edge Microgateway. Aby filtrować pobrane produkty, dodaj parametr zapytania productnamefilter do interfejsu API /products 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'

Wartość parametru zapytania musi być określona w formacie wyrażenia regularnego i zakodowana na potrzeby adresu URL. Na przykład wyrażenie regularne ^[Ee]dgemicro.*$ wykrywa nazwy takie jak: „edgemicro-test-1”, „edgemicro_demo” i „Edgemicro_New_Demo”. Wartość zakodowana w adresie URL, odpowiednia do użycia w parametrze zapytania, to: %5E%5BEe%5Ddgemicro.%2A%24.

Te dane wyjściowe debugowania pokazują, że zostały pobrane tylko odfiltrowane 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 użytkownika Edge wybierz serwer proxy edgemicro_auth w organizacji/środowisku, w którym skonfigurowano Edge Microgateway.
W przycisku Programuj otwórz w edytorze zasadę JavaCallout.
Dodaj atrybut niestandardowy z kluczem products.filter.attributes i listą nazw atrybutów rozdzielonych przecinkami. Do Edge Microgateway będą zwracane tylko produkty, które zawierają jakiekolwiek nazwy atrybutów niestandardowych.
Możesz opcjonalnie wyłączyć sprawdzanie, czy usługa jest włączona w bieżącym środowisku, ustawiając dla atrybutu niestandardowego products.filter.env.enable wartość false. (Wartość domyślna to true).
(Tylko chmura Private Cloud) Jeśli korzystasz z Edge dla Private Cloud, ustaw właściwość org.noncps na true, aby pobierać usługi 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>

Konfigurowanie częstotliwości przekazywania powiadomień w Analytics

Użyj tych parametrów konfiguracji, aby kontrolować częstotliwość, z jaką Edge Microgateway wysyła dane analityczne do Apigee:

bufferSize (opcjonalnie): maksymalna liczba rekordów Analytics, które może przechowywać bufor przed rozpoczęciem usuwania najstarszych rekordów. Wartość domyślna: 10 000
batchSize (opcjonalnie): maksymalny rozmiar wsadu rekordów analitycznych wysyłanych do Apigee. Domyślnie: 500.
flushInterval (opcjonalnie): liczba milisekund między każdym usunięciem danych w grupie rekordów analitycznych wysł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 analityce Edge. Dodaj poniższy kod do konfiguracji mikrobramy, aby zamaskować identyfikator URI żądania lub ścieżkę żądania. Pamiętaj, że identyfikator URI składa się z nazwy hosta i części ścieżki żądania.

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

Segregowanie wywołań interfejsu API w Edge Analytics

Możesz skonfigurować wtyczkę do analityki w taki sposób, aby segregowała określoną ścieżkę interfejsu API, tak aby była wyświetlana jako oddzielny serwer proxy w panelach Edge Analytics. Możesz na przykład zagregować w panelu interfejs API kontroli stanu, aby uniknąć pomylenia go z rzeczywistymi wywołaniami serwera proxy interfejsu API. W panelu Analytics segregowane serwery proxy mają następujący wzorzec nazewnictwa:

edgemicro_proxyname-health

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

Za pomocą tych parametrów możesz segregować ścieżki względne i bezwzględne w panelu Analytics jako osobne serwery proxy:

relativePath (opcjonalna): określa względną ścieżkę do segregacji 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ę bazową serwera proxy. Do segregacji na podstawie pełnej ścieżki, w tym ścieżki bazowej, użyj flagi proxyPath.
proxyPath (opcjonalnie): określa pełną ścieżkę serwera proxy interfejsu API, w tym ścieżkę bazową serwera proxy, która jest rozdzielona w panelu statystyk. Jeśli na przykład podasz /mocktarget/healthcheck, gdzie /mocktarget to ścieżka bazowa 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 wszystkie ścieżki interfejsu API zawierające /healthcheck zostaną rozdzielone przez wtyczkę Analytics. Oznacza to, że /foo/healthcheck i /foo/bar/healthcheck będą rozdzielone w panelu statystyk jako oddzielne serwery proxy o nazwie edgemicro_proxyname-health.

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 zostanie oddzielony w panelu statystyk jako oddzielny serwer proxy o nazwie edgemicro_proxyname-health.

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

Konfiguruję Edge Microgateway za firmową zaporą sieciową

Używanie serwera proxy HTTP do komunikacji z Apigee Edge

Dodano w wersji 3.1.2.

Aby używać serwera proxy HTTP do komunikacji między Edge Microgateway a Apigee Edge, wykonaj te czynności:

Ustaw zmienne środowiskowe HTTP_PROXY, HTTPS_PROXY i NO_PROXY. Te zmienne kontrolują hosty każdego serwera proxy HTTP, którego chcesz używać do komunikacji z Apigee Edge lub które hosty nie powinny obsługiwać komunikacji z Apigee Edge. 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ć rozdzielaną przecinkami listą domen, do których Edge Microgateway nie ma serwera proxy.

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 docelowej

Dodano w wersji 3.1.2.

Aby używać serwera proxy HTTP do komunikacji między mikrobramą Edge a celami backendu, wykonaj te czynności:

Dodaj do pliku konfiguracyjnego mikrobramy tę konfigurację:
```
edgemicro:
  proxy:
    tunnel: true | false
    url: proxy_url
    bypass: target_host # target hosts to bypass the proxy.
    enabled: true | false
```
Gdzie:
- tunel: (opcjonalnie) jeśli ma wartość prawda, Edge Microgateway używa metody połączenia HTTP do tunelowania żądań HTTP przez pojedyncze połączenie TCP. (To samo dzieje się, jeśli zmienne środowiskowe, jak wspomniano poniżej, 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 rozdzielany przecinkami adres URL docelowego hosta, który ma pomijać serwer proxy HTTP. Jeśli ta właściwość nie jest ustawiona, użyj zmiennej środowiskowej NO_PROXY, aby określić docelowe adresy URL, które mają być pomijane.
- enabled: jeśli ma wartość Prawda i jest ustawiona proxy.url, użyj wartości proxy.url jako serwera proxy HTTP. Jeśli wartość prawda i proxy.url nie są ustawione, używaj serwerów proxy określonych w zmiennych środowiskowych serwera proxy HTTP HTTP_PROXY i HTTPS_PROXY zgodnie z opisem w sekcji 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: jeśli parametr edgemicro.proxy zostanie pominięty w pliku konfiguracyjnym lub parametr edgemicro.proxy.enabled ma wartość false, Edge Microgateway nie będzie używać serwera proxy HTTP do komunikacji docelowej.
Ponownie uruchom Edge Microgateway.

Korzystanie z symboli wieloznacznych w serwerach proxy rozpoznających Microgateway

W ścieżce bazowej serwera proxy edgemicro_* (ang. Microgateway-aware) możesz użyć co najmniej jednego symbolu wieloznacznego „*”. Na przykład ścieżka bazowa /team/*/members pozwala klientom wywoływać adresy 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 /**/ nie jest obsługiwany.

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

Przeprowadzanie rotacji kluczy JWT

Jak Edge Microgateway wykorzystuje JWT

Token internetowy JSON (JWT) to standard tokena opisany w RFC7519. JWT umożliwia podpisanie zestawu deklaracji, które mogą być niezawodnie zweryfikowane przez odbiorcę.

Token JWT możesz wygenerować za pomocą interfejsu wiersza poleceń i użyć go w nagłówku autoryzacji wywołań interfejsu API zamiast klucza interfejsu 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 sekcji Generowanie tokena.

Co to jest rotacja klucza?

Jakiś czas po początkowym wygenerowaniu tokena JWT może być konieczna zmiana pary kluczy (publicznego/prywatnego) przechowywanej w KVM z szyfrowaniem Edge. Ten proces generowania nowej pary kluczy jest nazywany rotacją kluczy. Podczas rotacji kluczy nowa para kluczy prywatny/publiczny jest generowana i przechowywana w maszynie wirtualnej „microgateway” w organizacji/środowisku Apigee Edge. Oprócz tego stary klucz publiczny zostaje zachowany wraz z pierwotną wartością identyfikatora klucza.

Aby wygenerować token JWT, Edge używa informacji z zaszyfrowanej maszyny wirtualnej. Podczas początkowej konfiguracji (konfiguracji) Edge Microgateway został utworzony KVM o nazwie microgateway i zawarte w nim klucze. Klucze w KVM służą do podpisywania i szyfrowania tokena JWT.

Klucze KVM to między innymi:

private_key – najnowszy (ostatnio utworzony) klucz prywatny RSA używany do podpisywania tokenów JWT.
public_key – najnowszy (ostatnio utworzony) certyfikat używany do weryfikacji tokenów JWT podpisanych za pomocą private_key.
private_key_kid – najnowszy (ostatnio utworzony) identyfikator klucza prywatnego. Ten identyfikator klucza jest powiązany z wartością klucza private_key i służy do obsługi rotacji kluczy.
public_key1_kid – najnowszy (ostatnio utworzony) identyfikator klucza publicznego. Ten klucz jest powiązany z wartością public_key1 i używany do obsługi rotacji kluczy. Ta wartość jest taka sama jak w przypadku dziecka 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, aby zachować stare klucze publiczne. Na przykład:

public_key2_kid – stary identyfikator klucza publicznego. Ten klucz jest powiązany z wartością public_key2 i używany do obsługi rotacji kluczy.
public_key2 – stary klucz publiczny.

Tokeny JWT przedstawione do weryfikacji zostaną zweryfikowane za pomocą nowego klucza publicznego. Jeśli weryfikacja się nie powiedzie, będzie używany stary klucz publiczny, dopóki token JWT nie wygaśnie (po upływie okresu token_expiry*, domyślnie 30 minut). Dzięki temu można „rotować” klucze bez natychmiastowego zakłócania ruchu przez interfejs API.

Jak wykonać rotację kluczy

W tej sekcji dowiesz się, jak wykonać rotację klucza.

Aby uaktualnić KVM, użyj polecenia edgemicro upgradekvm. Szczegółowe informacje o uruchamianiu tego polecenia znajdziesz w sekcji Uaktualnianie KVM. Wystarczy, że zrobisz to tylko raz.
Aby uaktualnić serwer proxy edgemicro-oauth, użyj polecenia edgemicro upgradeauth. Więcej informacji o uruchamianiu tego polecenia znajdziesz w artykule o wykorzystywaniu serwera proxy uwierzytelniania Edgemicro. Wystarczy, że zrobisz to tylko raz.
Dodaj do pliku ~/.edgemicro/org-env-config.yaml ten wiersz, w którym musisz podać tę samą organizację i środowisko, w którym skonfigurowano mikrobramę:
```
jwk_public_keys: 'https://$ORG-$ENV.apigee.net/edgemicro-auth/jwkPublicKeys'
```

Uruchom polecenie rotacji kluczy, aby wykonać rotację kluczy. Szczegółowe informacje o tym poleceniu znajdziesz w artykule o rotacji 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 wiele kluczy do Edge Microgateway. Uwaga: w poniższym przykładzie każdy klucz ma unikalną wartość „kid” (identyfikator klucza). Mikrobrama używa następnie tych kluczy do weryfikacji tokenów autoryzacji. Jeśli weryfikacja tokena się nie powiedzie, mikrobrama sprawdzi, czy w zestawie kluczy nie ma starszego klucza, i spróbuje go użyć. Format zwracanych kluczy to klucz internetowy JSON (JWK). Informacje na temat tego formatu 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”

W wersjach 3.1.5 i starszych nowy klucz prywatny wygenerowany przez polecenie rotatekey zaczął obowiązywać natychmiast, a nowe tokeny zostały podpisane nowym kluczem prywatnym. Nowy klucz publiczny był jednak dostępny dla instancji Edge Microgateway co 10 minut (domyślnie) tylko podczas odświeżania konfiguracji mikrobramy. Z powodu tego opóźnienia między podpisywaniem tokenów a odświeżaniem instancji mikrobramy tokeny podpisane najnowszym kluczem będą odrzucane, dopóki wszystkie instancje nie otrzymają najnowszego publicznego klucza.

W przypadkach, gdy istnieje wiele instancji mikrobramy, opóźnienie klucza publicznego czasami powodowało przejściowe błędy środowiska wykonawczego o stanie 403, ponieważ weryfikacja tokena przechodziła do jednej instancji, ale kończyła się niepowodzeniem w innej, dopóki wszystkie instancje nie zostaną odświeżone.

Począwszy od wersji 3.1.6 nowa flaga w poleceniu rotatekey umożliwia określenie opóźnienia przed zastosowaniem nowego klucza prywatnego, co da czas na odświeżenie wszystkich instancji mikrobramy i otrzymanie nowego klucza publicznego. Nowa flaga to --nbf, co oznacza „nie wcześniej”. Ta flaga 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 warto ustawić opóźnienie na wartość większą 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 serwery proxy w organizacji Edge, które zaczynają się od prefiksu „edgemicro_”. Możesz zmienić to ustawienie domyślne, aby pobierać serwery 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 produktów bez serwerów proxy interfejsu API

W Apigee Edge możesz utworzyć usługę API, która nie zawiera żadnych serwerów proxy API. Ta konfiguracja usługi umożliwia użycie klucza interfejsu API powiązanego z tą usługą z dowolnym serwerem proxy wdrożonym w organizacji. Od wersji 2.5.4 Edge Microgateway obsługuje tę konfigurację usługi.

Debugowanie i rozwiązywanie problemów

Łączenie się z debugerem

Edge Microgateway możesz uruchomić z debugerem, takim jak node-inspector. Przydaje się to przy rozwiązywaniu problemów i debugowaniu niestandardowych wtyczek.

Ponownie uruchom Edge Microgateway w trybie debugowania. Aby to zrobić, dodaj 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 skierować 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 skonfiguruj go, aby nasłuchiwał na numerze portu.
Możesz teraz zapoznać się z kodem Edge Microgateway, ustawić punkty przerwania, obserwować wyrażenia itd.

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

Sprawdzam pliki dziennika

Jeśli wystąpią problemy, sprawdź pliki dziennika pod kątem szczegółów wykonania i informacji o błędach. Więcej informacji znajdziesz w temacie Zarządzanie plikami dziennika.

Korzystanie z 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.

Pamięć podręczna kluczy

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

Używanie klucza API

Klucz interfejsu API możesz przekazać w żądaniu interfejsu API w postaci parametru zapytania lub nagłówka. Domyślnie nagłówek i nazwa parametru zapytania mają wartość 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ą w nagłówku klucza interfejsu API i parametrze zapytania. Możesz zmienić to ustawienie w pliku konfiguracji, zgodnie z opisem 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 są zmieniane na apiKey. W żadnym z tych przypadków nazwa x-api-key nie będzie już działać. 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 serwera proxy znajdziesz w artykule Secure Edge Microgateway.

Włącz kody odpowiedzi (wysyłanie wiadomości)

Domyślnie wtyczka oauth zwraca tylko kody stanu błędu 4xx, jeśli odpowiedź nie ma stanu 200. Możesz zmienić to działanie tak, aby zawsze zwracało 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 OAuth2 i tokeny odświeżania. 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 uzyskać token dostępu za pomocą serwera proxy edgemicro-auth.

Token dostępu możesz też uzyskać za pomocą polecenia interfejsu wiersza poleceń edgemicro token. Szczegółowe informacje o interfejsie wiersza poleceń znajdziesz w artykule Zarządzanie tokenami.

Interfejs API 1. Wysyłaj dane logowania jako parametry treści

Zastąp nazwy organizacji i środowisk w adresie URL oraz zastąp wartości identyfikatora klienta i tajnego klucza klienta uzyskane z aplikacji programisty w Apigee Edge parametrami treści client_id i client_secret:

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"

API 2. Wysyłaj dane logowania w nagłówku uwierzytelniania podstawowego

Wyślij dane logowania klienta jako nagłówek uwierzytelniania podstawowego i grant_type jako parametr formularza. Ten formularz polecenia został również omówiony w dokumencie RFC 6749: platforma autoryzacji OAuth 2.0.

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ź JSON. Zwróć uwagę, że nie ma różnicy między właściwościami token i access_token. Możesz używać dowolnego z tych sposobów. 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, wykonaj wywołanie interfejsu API do punktu końcowego /token serwera proxy edgemicro-auth. To wywołanie interfejsu API MUSI być wykonywane z typem uwierzytelnienia password. Poniżej znajdziesz opis czynności, które musisz wykonać.

Uzyskaj token dostępu i odśwież za pomocą interfejsu API /token. Pamiętaj, że typ uwierzytelnienia 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 podobnie do tej. Pamiętaj, że expires_in to liczby całkowite i są podawane 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"
}

Możesz teraz użyć tokena odświeżania, aby uzyskać nowy token dostępu, wywołując punkt końcowy /refresh tego samego interfejsu API. 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 zwróci nowy token dostępu. Odpowiedź wygląda mniej więcej tak:

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

Nieustanne monitorowanie

Usunięto: ta funkcja interfejsu wiersza poleceń została usunięta z Edge Microgateway w wersji 3.3.3. Możesz zastąpić filtr forever-monitor PM2. Więcej informacji znajdziesz w poście na karcie Społeczność Apigee: Edgemicro + PM2: uruchamianie Edgemicro jako usługi. Zobacz też informacje o wersji 3.3.3 Edge.

Określanie punktu końcowego pliku konfiguracyjnego

Jeśli korzystasz z wielu instancji Edge Microgateway, możesz zarządzać ich konfiguracjami z jednej lokalizacji. Aby to zrobić, określ punkt końcowy HTTP, z którego Edge Micro może pobrać swój 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. To plik, który domyślnie znajduje się w lokalizacji ~/.edgemicro i ma określoną konwencję nazewnictwa: org-env-config.yaml.

Wyłączanie buforowania danych połączenia TCP

Za pomocą atrybutu konfiguracji nodelay możesz wyłączyć buforowanie danych w przypadku połączeń TCP używanych przez Edge Microgateway.

Domyślnie połączenia TCP używają algorytmu Nagle do buforowania danych przed ich wysłaniem. Ustawienie wartości nodelay na true wyłącza to zachowanie (dane od razu uruchamiają się po każdym wywołaniu metody socket.write()). Więcej informacji znajdziesz w dokumentacji Node.js.

Aby włączyć nodelay, zmodyfikuj plik konfiguracyjny 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

Uruchamiam Edge Microgateway w trybie samodzielnym

Edge Microgateway można uruchomić całkowicie bez połączenia z dowolną zależność Apigee Edge. Ten scenariusz, nazywany trybem samodzielnym, pozwala uruchomić i przetestować Edge Microgateway bez połączenia z internetem.

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

Klucz OAuth i interfejs API
Limit
Analityka

Z drugiej strony niestandardowe wtyczki i zatrzymanie zatrzymywane przy użyciu szybkiego dostępu działają normalnie, ponieważ nie wymagają połączenia z Apigee Edge. Dodatkowo nowa wtyczka o nazwie extauth umożliwia autoryzację 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 konfiguracji o następującej nazwie: $HOME/.edgemicro/$ORG-$ENV-config.yaml
Możesz użyć dowolnych wartości w nazwie pliku $ORG i $ENV. Kombinacja organizacji i środowiska to po prostu konwencja, która umożliwia Edge Microgateway znalezienie pliku podczas jego 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 konfiguracyjny zawiera specjalną, opcjonalną wtyczkę o nazwie extauth. Ta wtyczka weryfikuje prawidłowy token JWT przekazany do mikrobramy. W kolejnym kroku dowiesz się, jak uzyskać token i go używać. Pamiętaj też, że dołączono wtyczkę spikearrest, ponieważ nie wymaga ona połączenia z Edge. Wtyczki quota, oauth i analytics są wykluczone, ponieważ bazują na połączeniach z Edge i nie będą działać w trybie rozłączenia. Niestandardowe wtyczki są dozwolone i będą działać zgodnie z oczekiwaniami.
Wyeksportuj tę zmienną środowiskową o wartości „1”:
```
export EDGEMICRO_LOCAL=1
```
Wykonaj to polecenie start, podając wartości tworzące instancję lokalnego serwera 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 „organizacji” użyta w nazwie pliku konfiguracji.
- $ENV to nazwa „env” użyta 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 miejsca docelowego serwera proxy. (Miejsce docelowe to usługa wywoływana przez serwer proxy).
- $BASE_PATH to ścieżka bazowa serwera 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" }
```
Wtyczka extauth znajduje się w pliku foo-bar-config.yaml, dlatego pojawia się błąd „missing_authorization”. Ta wtyczka weryfikuje token JWT, który musi znajdować się w nagłówku Authorization wywołania interfejsu API. W następnej sekcji otrzymasz token JWT, który pozwoli na wykonywanie wywołań interfejsu API bez błędu.

Przykład: uzyskiwanie tokena autoryzacji

Poniższy przykład pokazuje, jak uzyskać token JWT z punktu końcowego JWT Edge Microgateway w Apigee Edge (edgemicro-auth/jwkPublicKeys). Ten punkt końcowy jest wdrażany podczas wykonywania standardowej konfiguracji i konfiguracji Edge Microgateway. Aby uzyskać token JWT z punktu końcowego Apigee, musisz najpierw wykonać standardową konfigurację Edge Microgateway i mieć połączenie z internetem. Punkt końcowy Apigee jest używany tutaj tylko w celach poglądowych i nie jest wymagany. Jeśli chcesz, 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 ją dodasz, musisz podać prawidłowy token JWT w nagłówku autoryzacji dla wywołań interfejsu API.

Z podanych niżej instrukcji dowiesz się, 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 w Apigee Cloud wdrożysz Edge Microgateway, musisz mieć połączenie z internetem, aby uzyskać token JWT z tego punktu końcowego.
Zatrzymuj Edge Microgateway:
```
edgemicro stop
```
W utworzonym wcześniej pliku konfiguracji ($HOME/.edgemicro/org–env-config.yaml) wskaż atrybut extauth:publickey_url na punkt końcowy edgemicro-auth/jwkPublicKeys w organizacji/środowisku Apigee Edge. Przykład:
```
extauth:
  publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'
```
Ponownie uruchom Edge Microgateway, używając nazw organizacji i środowisk podanych w nazwie pliku konfiguracji. Przykład:
```
edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
```
Pobierz token JWT z punktu końcowego autoryzacji. Ponieważ używasz punktu końcowego edgemicro-auth/jwkPublicKeys, możesz użyć tego polecenia interfejsu wiersza poleceń:
W tym kroku będziesz potrzebować połączenia z internetem. Poniższe polecenie pobiera token z Apigee Edge. Aby wykonać ten krok, musisz mieć organizację Apigee, w której przeprowadzono standardową konfigurację i konfigurację Edge Microgateway. Gdy to zrobisz, nie będzie trzeba mieć połączenia z internetem. Token będzie działać w trybie samodzielnym, dopóki nie wygaśnie.

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 skonfigurowano wcześniej Edge Microgateway.
your_env to środowisko w organizacji.
Opcja i określa klucz klienta z aplikacji dewelopera, która zawiera usługę zawierającą serwer proxy edgemicro-auth.
Opcja s określa tajny klucz klienta z aplikacji dewelopera, która zawiera usługę zawierającą serwer proxy edgemicro-auth.

To polecenie prosi Apigee Edge o wygenerowanie tokena JWT, którego można później używać do weryfikowania wywołań interfejsu API.

Zobacz też Generowanie tokena.

Testowanie samodzielnej konfiguracji

Aby przetestować konfigurację, wywołaj interfejs API z tokenem dodanym w nagłówku Authorization w ten 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":""
}

Używanie lokalnego trybu proxy

W trybie lokalnego serwera proxy Edge Microgateway nie wymaga wdrażania serwera proxy microgateway w Apigee Edge. Zamiast tego skonfigurujesz „lokalny serwer proxy”, podając nazwę lokalnego serwera proxy, ścieżkę bazową i docelowy adres URL przy uruchamianiu mikrobramy. Wywołania interfejsu API kierowane do mikrobramy są następnie wysyłane na docelowy adres URL lokalnego serwera proxy. Pod każdym względem lokalny tryb proxy działa tak samo jak uruchamianie Edge Microgateway w zwykłym trybie. Uwierzytelnianie działa tak samo, jak zwiększanie liczby zatrzymań i wymuszania limitów, niestandardowych wtyczek itd.

Dwie ważne różnice między trybem lokalnym a standardową konfiguracją Edge Microgateway: (1) w trybie lokalnym nie musisz tworzyć serwera proxy rozpoznającego mikrobramę w Apigee Edge oraz (2) podczas tworzenia usługi API w Edge możesz dodać do niego tylko jeden serwer proxy – edgemicro-auth. Nie musisz dodawać żadnych innych serwerów proxy do usługi.

Przypadek użycia i przykład

Tryb lokalnego serwera proxy jest przydatny, gdy chcesz powiązać tylko 1 pojedynczy serwer proxy z instancją Edge Microgateway. Możesz na przykład wprowadzić do Kubernetes jako pomocnicze serwer proxy Edge Microgateway, w którym mikrobrama i usługa działają w 1 podzie, gdzie mikrobrama zarządza ruchem do i z usługi towarzyszącej. Poniższy rysunek przedstawia tę architekturę, w której Edge Microgateway działa jako pomocniczy serwer proxy w klastrze Kubernetes. Każda instancja mikrobramy komunikuje się tylko z jednym punktem końcowym w swojej usłudze towarzyszącej:

Edgemicro jako Sidecar

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

Konfigurowanie trybu lokalnego serwera proxy

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

Uruchom edgemicro init, aby skonfigurować lokalne środowisko konfiguracji dokładnie w taki sposób, jak w przypadku typowej konfiguracji Edge Microgateway. Zobacz też Konfigurowanie Edge Microgateway.
Uruchom edgemicro configure, tak jak w przypadku typowej procedury konfiguracji Edge Microgateway. Na przykład:
```
edgemicro configure -o your_org -e your_env -u your_apigee_username
```
To polecenie wdraża zasadę edgemicro-auth w Edge i zwraca klucz oraz obiekt tajny, których potrzebujesz do uruchomienia mikrobramy. Jeśli potrzebujesz pomocy, zapoznaj się z informacjami o konfigurowaniu Edge Microgateway.
W Apigee Edge utwórz usługę API zgodnie z tymi obowiązkowymi wymaganiami konfiguracyjnymi (możesz zarządzać wszystkimi innymi konfiguracjami według własnego uznania):
- Do usługi musisz dodać serwer proxy edgemicro-auth. Ten serwer proxy został wdrożony automatycznie podczas uruchamiania edgemicro configure.
- Musisz podać ścieżkę zasobu. Apigee zaleca dodanie do usługi tej ścieżki: /**. Więcej informacji znajdziesz w artykule na temat konfigurowania zachowania ścieżki zasobu. Przeczytaj też artykuł o tworzeniu usług API w dokumentacji Edge.
W Apigee Edge utwórz dewelopera lub, jeśli chcesz, możesz skorzystać z usług istniejącego programisty. Pomoc znajdziesz w artykule Dodawanie deweloperów za pomocą interfejsu zarządzania brzegiem sieci.
W Apigee Edge utwórz aplikację dewelopera. Musisz dodać do aplikacji utworzoną przed chwilą usługę API. Więcej informacji znajdziesz w sekcji Rejestrowanie aplikacji w interfejsie zarządzania Edge.
Na komputerze, na którym zainstalowano Edge Microgateway, wyeksportuj podaną poniżej zmienną środowiskową z wartością „1”.
```
export EDGEMICRO_LOCAL_PROXY=1
```
Wykonaj 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 podczas uruchamiania edgemicro configure.
- your_secret to obiekt tajny zwrócony podczas uruchamiania 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 wywoływanej przez serwer proxy).
- base_path to ścieżka bazowa serwera 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ę bazową /echo, możesz wywołać serwer proxy w ten sposób:

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

To pierwsze wywołanie interfejsu API spowodowało błąd, ponieważ nie podano prawidłowego klucza interfejsu API. Klucz znajdziesz w utworzonej wcześniej aplikacji programisty. Otwórz aplikację w interfejsie użytkownika Edge, skopiuj klucz klienta i użyj tego klucza 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 wyjaśniono, jak używać synchronizatora – opcjonalnej funkcji, która zwiększa odporność Edge Microgteway przez umożliwienie jej pobierania danych konfiguracji z Apigee Edge i zapisywania ich w lokalnej bazie danych Redis. Gdy instancja synchronizatora jest uruchomiona, inne instancje Edge Microgateway działające w różnych węzłach mogą pobierać swoją konfigurację bezpośrednio z tej bazy danych.

Funkcja synchronizacji jest obecnie obsługiwana do pracy z Redis 5.0.x.

Co to jest synchronizator?

Synchronizator zapewnia poziom odporności dla Edge Microgateway. Pomaga to mieć pewność, że każda instancja Edge Microgateway używa tej samej konfiguracji, a w przypadku przerwy w działaniu internetu instancje Edge Microgateway mogą się prawidłowo uruchamiać i działać.

Domyślnie instancje Edge Microgateway muszą mieć możliwość komunikacji z Apigee Edge, aby pobierać i odświeżać swoje dane konfiguracji, takie jak konfiguracje serwera proxy interfejsu API i usługi API. Jeśli połączenie internetowe z urządzeniem Edge zostanie zakłócone, instancje mikrobramy mogą nadal działać, ponieważ najnowsze dane konfiguracji są przechowywane w pamięci podręcznej. Nowe instancje mikrobramy nie mogą jednak uruchomić się bez wyraźnego połączenia. Poza tym zakłócenia w internecie mogą spowodować, że co najmniej 1 instancja mikrobramy uruchomionej z informacjami o konfiguracji nie będzie zsynchronizowana z innymi instancjami.

Synchronizator Edge Microgateway zapewnia alternatywny mechanizm dla instancji Edge Microgateway, umożliwiający pobieranie danych konfiguracji wymaganych do uruchomienia i przetwarzania ruchu serwera proxy interfejsu API. Dane konfiguracji pobierane z wywołań Apigee Edge obejmują: wywołanie jwk_public_keys, jwt_public_key, wywołanie wczytywania i wywołanie usług API. Synchronizator umożliwia prawidłowe uruchamianie i synchronizację wszystkich instancji Edge Microgateway działających w różnych węzłach nawet w przypadku zakłócenia połączenia internetowego między Edge Microgateway a Apigee Edge.

Synchronizator to specjalnie skonfigurowana instancja Edge Microgateway. Jego jedynym przeznaczeniem jest odpytywanie Apigee Edge (czas, który można skonfigurować), pobieranie danych konfiguracji i zapisywanie ich w lokalnej bazie danych Redis. Instancja synchronizatora nie może przetwarzać ruchu serwera proxy interfejsu API. Inne instancje Edge Microgateway działające w różnych węzłach można skonfigurować tak, aby pobierały dane konfiguracyjne z bazy danych Redis, a nie z Apigee. Wszystkie instancje mikrobram pobierają dane konfiguracyjne z lokalnej bazy danych, dlatego mogą uruchamiać i przetwarzać żądania do interfejsu API nawet w przypadku przerw w działaniu internetu.

Konfigurowanie instancji synchronizatora

Dodaj tę konfigurację do pliku org-env/config.yaml 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, która ma być używana. Domyślnie: 0.
`redisPassword`	Hasło do Twojej bazy danych.

Do zastąpienia parametru edgemicro.redisPassword możesz użyć zmiennej środowiskowej EDGEMICRO_REDIS_PASSWORD. Zobacz też Ustawianie atrybutów konfiguracji za pomocą wartości zmiennych środowiskowych.

Na koniec zapisz plik konfiguracji i uruchom instancję Edge Microgateway. Rozpocznie się odpytywanie Apigee Edge i zapisywanie pobranych danych konfiguracji 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 serwera proxy interfejsu API. Możesz jednak skonfigurować te instancje tak, aby pobierały swoje dane konfiguracyjne z bazy danych Redis, a nie z Apigee Edge.

Dodaj tę konfigurację do każdego dodatkowego pliku org-env/config.yaml węzła Edge Microgateway. Pamiętaj, że właściwość synchronizerMode jest ustawiona na 0. Ta właściwość powoduje, że instancja będzie działać jako zwykła instancja Edge Microgateway, która przetwarza ruch z serwera proxy interfejsu API, i 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

Dodano poniższe właściwości konfiguracji w celu obsługi synchronizatora:

Atrybut Wartości Opis

Atrybut	Wartości	Opis
`edge_config.synchronizerMode`	0 lub 1	Jeśli wartość domyślna to 0 (wartość domyślna), Edge Microgateway działa w trybie standardowym. Jeśli wartość to 1, uruchom instancję Edge Microgateway, aby działać jako synchronizator. W tym trybie instancja pobierze dane konfiguracji z Apigee Edge i zapisze je w lokalnej bazie danych Redis. Ta instancja nie może przetwarzać żądań serwera proxy interfejsu API. Jej jedynym przeznaczeniem jest odpytywanie Apigee Edge w celu uzyskania danych konfiguracji i zapisanie ich w lokalnej bazie danych. Następnie musisz skonfigurować inne instancje mikrobramy do odczytu z bazy danych.
`edge_config.redisBasedConfigCache`	prawda lub fałsz	Jeśli ma wartość prawda, instancja Edge Microgateway pobiera swoje dane konfiguracji z bazy danych Redis, a nie z Apigee Edge. Baza danych Redis musi być tą samą, w której synchronizator jest skonfigurowany do zapisu. Jeśli baza danych Redis jest niedostępna lub pusta, mikrobrama szuka istniejącego pliku `cache-config.yaml` w swojej konfiguracji. Jeśli ma wartość fałsz (wartość domyślna), instancja Edge Microgateway w zwykły sposób pobiera dane konfiguracji z Apigee Edge.
`edgemicro.config_change_poll_interval`	Odstęp czasu w sekundach	Określa interwał sondowania, z których synchronizator będzie pobierać dane z Apigee Edge.

edge_config.synchronizerMode

0 lub 1

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

Jeśli wartość to 1, uruchom instancję Edge Microgateway, aby działać jako synchronizator. W tym trybie instancja pobierze dane konfiguracji z Apigee Edge i zapisze je w lokalnej bazie danych Redis. Ta instancja nie może przetwarzać żądań serwera proxy interfejsu API. Jej jedynym przeznaczeniem jest odpytywanie Apigee Edge w celu uzyskania danych konfiguracji i zapisanie ich w lokalnej bazie danych. Następnie musisz skonfigurować inne instancje mikrobramy do odczytu z bazy danych.

edge_config.redisBasedConfigCache

prawda lub fałsz

Jeśli ma wartość prawda, instancja Edge Microgateway pobiera swoje dane konfiguracji z bazy danych Redis, a nie z Apigee Edge. Baza danych Redis musi być tą samą, w której synchronizator jest skonfigurowany do zapisu. Jeśli baza danych Redis jest niedostępna lub pusta, mikrobrama szuka istniejącego pliku cache-config.yaml w swojej konfiguracji.

Jeśli ma wartość fałsz (wartość domyślna), instancja Edge Microgateway w zwykły sposób pobiera dane konfiguracji z Apigee Edge.

edgemicro.config_change_poll_interval Odstęp czasu w sekundach Określa interwał sondowania, z których synchronizator będzie pobierać dane z Apigee Edge.

Konfigurowanie wykluczających adresów URL wtyczek

Możesz skonfigurować mikrobramę tak, by pomijała przetwarzanie wtyczek dla określonych adresów URL. Możesz konfigurować te „wykluczane” adresy URL globalnie (w przypadku 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ń serwera proxy interfejsu API ze ścieżkami /hello lub /proxy_one. Dodatkowo wtyczka json2xml zostanie pominięta w przypadku interfejsów API, które w ścieżce mają wartość /hello/xml.

Nie możesz wykluczyć wtyczki analytics.

Ustawianie atrybutów konfiguracji z wartościami zmiennych środowiskowych

Zmienne środowiskowe możesz określić za pomocą tagów w pliku konfiguracji. Podane tagi zmiennych środowiskowych są zastępowane rzeczywistymi wartościami zmiennych środowiskowych. Zamienniki są przechowywane tylko w pamięci i nie są przechowywane w oryginalnej konfiguracji ani 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łkowitą i wartości logiczne, użyj wewnętrznych tagów <n> i <b>, jak pokazano w poniższych przykładach.

Uwaga: tag zmiennej środowiskowej nie jest obsługiwany w przypadku tych atrybutów konfiguracji:

edge_config:
  bootstrap:
  authUri:
  baseUri:

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 wskazywania 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 wskazywania wartości logicznej (tzn. prawda lub fałsz).

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