Przeglądasz dokumentację Apigee Edge.
Przejdź do
Dokumentacja Apigee X. informacje.
Edge Microgateway wer. 3.3.x
W tym artykule omówiono sposób zarządzania i konfigurowania Edge Microgateway.
Uaktualnianie Edge Microgateway, jeśli masz połączenie z internetem
W tej sekcji wyjaśniono, jak uaktualnić istniejącą instalację Edge Microgateway. Jeśli korzystasz z urządzenia bez połączenia z internetem, zapoznaj się z sekcją Czy mogę zainstalować Edge Microgateway bez połączenia z internetem?
Apigee zaleca przetestowanie istniejącej konfiguracji nową wersję przed uaktualnieniem środowiska produkcyjnego.
- Aby uaktualnić Edge do najnowszej wersji, wykonaj to polecenie
npm
Mikrobrama:npm upgrade edgemicro -g
Aby zainstalować konkretną wersję Edge Microgateway, musisz podać wersję number w poleceniu instalacji. Na przykład, aby zainstalować w wersji 3.2.3, użyj to polecenie:
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, o których musisz wiedzieć:
- Domyślny plik konfiguracji systemu
- Domyślny plik konfiguracyjny dla nowo zainicjowanej instancji Edge Microgateway
- Plik konfiguracji dynamicznej do uruchomienia instancji
W tej sekcji omówione są te pliki oraz wszystkie niezbędne informacje na temat ich zmiany.
Domyślna konfiguracja systemu plik
Podczas instalacji Edge Microgateway w tym miejscu umieszczany jest domyślny plik konfiguracji systemu:
prefix/lib/node_modules/edgemicro/config/default.yaml
Gdzie prefix to katalog prefiksów npm
. Zobacz
Gdzie jest zainstalowana Edge Microgateway, jeśli nie możesz znaleźć tego katalogu.
Jeśli zmienisz plik konfiguracji systemu, musisz ponownie zainicjować, skonfigurować i ponownie uruchomić Edge Mikrobrama:
edgemicro initedgemicro configure [params]
edgemicro start [params]
Domyślny plik konfiguracyjny dla nowo zainicjowanych instancji Edge Microgateway
Po uruchomieniu polecenia edgemicro init
systemowy plik konfiguracyjny (opisany)
powyżej) default.yaml
znajduje się w katalogu ~/.edgemicro
.
Jeśli zmienisz plik konfiguracyjny w usłudze ~/.edgemicro
, musisz skonfigurować ją ponownie i uruchomić ponownie
Mikrobrama Edge:
edgemicro stopedgemicro configure [params]
edgemicro start [params]
Dynamiczna, plik konfiguracji do uruchomionych instancji
Jeśli używasz edgemicro configure [params]
, dynamiczne reklamy
jest tworzony w ~/.edgemicro
. Plik ma taką nazwę
wzór: org-env-config.yaml
, gdzie org i
env są
nazwy organizacji Apigee Edge i środowisk. Możesz użyć tego pliku do utworzenia konfiguracji
zmian i wczytywać je ponownie z zerowym czasem przestoju. Jeśli na przykład dodasz i skonfigurujesz wtyczkę,
możesz ponownie załadować konfigurację bez żadnych przestojów, jak opisano poniżej.
Jeśli działa Edge Microgateway (opcja zero przestojów):
- 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ć organizacją) administratora).
- $ENV to środowisko w Twojej organizacji (np. „test” lub „prod”).
- $KEY to klucz zwrócony wcześniej przez polecenie „config”.
- $SECRET to klucz zwrócony wcześniej przez polecenie „config”.
Przykład
edgemicro reload -o docs -e test -k 701e70ee718ce6dc188...78b6181d000723 \ -s 05c14356e42ed1...4e34ab0cc824
Jeśli Edge Microgateway zostanie zatrzymany:
- Ponowne uruchamianie Edge Microgateway:
edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET
Gdzie:
- $ORG to nazwa Twojej organizacji Edge (musisz być organizacją) administratora).
- $ENV to środowisko w Twojej organizacji (np. „test” lub „prod”).
- $KEY to klucz zwrócony wcześniej przez polecenie „config”.
- $SECRET to klucz zwrócony wcześniej przez polecenie „config”.
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.
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
poleceń interfejsu wiersza poleceń, które wymagają wartości dla organizacji Edge i , a klucz i obiekt tajny potrzebne do uruchomienia Edge Microgateway mogą być przechowywane w tych zmienne środowiskowe:
EDGEMICRO_ORG
EDGEMICRO_ENV
EDGEMICRO_KEY
EDGEMICRO_SECRET
Ustawienie tych zmiennych jest opcjonalne. Jeśli je ustawisz, nie musisz określać ich wartości gdy używasz interfejsu wiersza poleceń (CLI) do konfigurowania i uruchamiania Edge Microgateway.
Konfigurowanie SSL w Edge Microgateway serwer
Obejrzyj te filmy, aby dowiedzieć się więcej o konfigurowaniu protokołu TLS w Apigee Edge Microgateway:
Wideo | Opis |
---|---|
Konfigurowanie jednokierunkowego połączenia TLS z kierunkiem północnym | Dowiedz się więcej o konfigurowaniu protokołu TLS w Apigee Edge Microgateway. W tym filmie omówiliśmy protokół TLS i jego znaczenie. Przedstawiliśmy też protokół TLS w Edge Microgateway i pokazuje, jak skonfigurować jednokierunkowy protokół TLS w kierunku Northbound. |
Konfigurowanie dwukierunkowego połączenia TLS w kierunku północnym | To jest 2 film o konfigurowaniu protokołu TLS w Apigee Edge Microgateway. Ten film wyjaśnia, jak skonfigurować dwukierunkową transmisję danych TLS ukierunkowaną na północ. |
Konfigurowanie jednokierunkowego i dwukierunkowego połączenia TLS w kierunku południowym | W trzecim filmie omawiającym konfigurowanie protokołu TLS w Apigee Edge Microgateway jak skonfigurować jednokierunkowe połączenia TLS południowe i dwukierunkowe. |
Serwer Microgateway możesz skonfigurować do używania protokołu SSL. Na przykład, jeśli masz skonfigurowany protokół SSL, może wywoływać interfejsy API za pomocą Edge Microgateway za pomocą protokołu „https” w następujący 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 przy użyciu narzędzia openssl lub dowolnej innej metody.
- Dodaj atrybut
edgemicro:ssl
do pliku konfiguracji Edge Microgateway. Pełną listę znajdziesz w tabeli poniżej. 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
- Uruchom ponownie Edge Microgateway. Wykonaj czynności opisane w Wprowadzanie zmian w konfiguracji w zależności od tego, edytowany plik konfiguracji: plik domyślny lub plik konfiguracji środowiska wykonawczego.
Oto przykład sekcji edgemicro
pliku konfiguracyjnego z protokołem SSL
skonfigurowano:
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 CA
klienta w formacie PFX. |
passphrase |
Ciąg tekstowy zawierający hasło klucza prywatnego lub PFX. |
ca |
Ścieżka do pliku zawierającego listę zaufanych certyfikatów w formacie PEM. |
ciphers |
Ciąg opisujący stosowane mechanizmy szyfrowania, rozdzielone znakiem „:”. |
rejectUnauthorized |
Jeśli ma wartość true (prawda), certyfikat serwera jest weryfikowany pod kątem listy podanych urzędów certyfikacji. Jeśli ale weryfikacja się nie powiedzie, zwracany jest błąd. |
secureProtocol |
Stosowana metoda SSL. Na przykład SSLv3_method wymusza stosowanie SSL w wersji 3. |
servername |
Nazwa serwera rozszerzenia TLS (SNI (Server Name Indication). |
requestCert |
true (prawda) dla dwukierunkowego protokołu SSL; wartość false dla jednokierunkowego protokołu SSL |
Korzystanie z opcji SSL/TLS klienta
Możesz skonfigurować Edge Microgateway, aby był klientem TLS lub SSL podczas nawiązywania połączenia z miejscem docelowym i punktów końcowych. Użyj elementu docelowego w pliku konfiguracji Microgateway, aby ustawić protokół SSL/TLS . Pamiętaj, że możesz określić wiele konkretnych celów. Przykład z wieloma miejscami docelowymi poniżej.
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 użycia 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 podać pierwszy host w konfiguracji jako „pusty”, co uaktywnia żądania uniwersalne, a następnie określa określone 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 klientów:
Opcja | Opis |
---|---|
pfx |
Ścieżka do pliku pfx zawierającego klucz prywatny, certyfikat i certyfikaty CA
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 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 stosowane mechanizmy szyfrowania, rozdzielone znakiem „:”. |
rejectUnauthorized |
Jeśli ma wartość true (prawda), certyfikat serwera jest weryfikowany pod kątem listy podanych urzędów certyfikacji. Jeśli ale weryfikacja się nie powiedzie, zwracany jest błąd. |
secureProtocol |
Stosowana metoda SSL. Na przykład SSLv3_method wymusza stosowanie SSL w wersji 3. |
servername |
Nazwa serwera 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 podczas początkowego uruchamiania edgemicro configure
. Możesz zmienić
domyślna konfiguracja tego serwera proxy dodająca obsługę deklaracji niestandardowych do tokena internetowego JSON
(JWT), skonfiguruj datę wygaśnięcia tokena i wygeneruj tokeny odświeżania. Szczegółowe informacje znajdziesz na stronie edgemicro-auth w GitHubie.
Korzystanie z niestandardowej usługi uwierzytelniania
Domyślnie Edge Microgateway używa serwera proxy wdrożonego w Apigee Edge do uwierzytelniania OAuth2.
Ten serwer proxy jest wdrażany podczas początkowego uruchamiania edgemicro configure
. Domyślnie ta wartość
URL 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 wskazująca Twoją usługę. Możesz mieć na przykład
usługi, która do weryfikacji tożsamości używa LDAP.
Zarządzanie plikami dziennika
Edge Microgateway rejestruje informacje o każdym żądaniu i odpowiedzi. Pliki dzienników zapewniają przeznaczone do debugowania i rozwiązywania problemów.
Gdzie są przechowywane pliki dziennika
Domyślnie pliki dziennika są przechowywane w folderze /var/tmp
.
Jak zmienić domyślny dziennik katalog plików
Katalog, w którym są przechowywane pliki logów, jest określony w konfiguracji Edge Microgateway . Więcej informacji znajdziesz w artykule Tworzenie konfiguracji. zmian.
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 logu.
Wyślij logi do konsoli
Możesz skonfigurować logowanie w taki sposób, aby informacje dziennika były wysyłane na standardowe dane wyjściowe zamiast do
pliku dziennika. Ustaw flagę to_console
na „true” w ten sposób:
edgemicro: logging: to_console: true
Przy tym ustawieniu logi będą wysyłane do standardowego wyjścia. Obecnie nie można wysyłać logów do obu stdout i plik dziennika.
Jak ustawić poziom rejestrowania
Określasz poziom logowania, który ma być używany w konfiguracji edgemicro
. Dla
Pełną listę poziomów logu i ich opisy znajdziesz w sekcji Atrybuty Edgemicro.
Na przykład ta konfiguracja ustawia poziom rejestrowania 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 odstępy możesz skonfigurować w pliku konfiguracji Edge Microgateway. Zapoznaj się też z sekcją Wprowadzanie zmian w konfiguracji.
Atrybuty, które można skonfigurować:
- stats_log_interval: (domyślnie: 60) interwał w sekundach, w którym statystyki rekord jest zapisywany w pliku dziennika interfejsu API.
- rotate_interval: (domyślnie: 24) interwał w godzinach, w którym pliki dziennika są obrócono. 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 uprawnieniami do pliku
ustawiony na 0600. Ten poziom uprawnień nie zezwala na zewnętrzne aplikacje ani użytkowników
aby odczytać plik dziennika. Aby złagodzić ten rygorystyczny poziom uprawnień, ustaw logging:disableStrictLogFile
do: true
. Jeśli atrybut ma wartość true
, plik dziennika jest tworzony za pomocą
ustaw uprawnienia do pliku na 0755. Jeśli false
lub atrybut nie jest podany, wartość domyślna to 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 dziennika Apigee zaleca wdrożenie tego metody:
- Pliki dziennika mogą być dość duże, dlatego upewnij się, że w katalogu wystarczającą ilość miejsca. Zapoznaj się z sekcjami Gdzie są przechowywane pliki dziennika oraz Jak zmienić domyślny plik dziennika? katalogu.
- Co najmniej raz w tygodniu usuwaj pliki dzienników lub przenoś je do osobnego katalogu archiwum.
- Jeśli Twoją zasadą jest usuwanie logów, możesz użyć polecenia interfejsu wiersza poleceń
edgemicro log -c
w celu usunięcia (czystych) starszych logów.
Konwencja nazewnictwa plików logów
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 kod JSON pobranych serwerów proxy, produktów i pliku JSON
Token internetowy (JWT). Jeśli chcesz wyeksportować te obiekty do konsoli, ustaw flagę wiersza poleceń
DEBUG=*
po uruchomieniu Edge Microgateway. Na przykład:
DEBUG=* edgemicro start -o docs -e test -k abc123 -s xyz456
Zawartość pola „api” plik dziennika
Interfejs API plik dziennika zawiera szczegółowe informacje o przepływie żądań i odpowiedzi za pomocą Edge Microgateway. Interfejs API pliki dziennika mają taką nazwę:
edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log
Dla każdego żądania wysłanego do Edge Microgateway w interfejsie „api” są rejestrowane 4 zdarzenia dziennik plik:
- Przychodzące żądanie od klienta
- Żądanie wychodzące wysłane do miejsca docelowego
- Odpowiedź przychodząca z celu
- Odpowiedź wychodząca do klienta
Każdy z tych wpisów jest przedstawiony w formie skróconej, aby ułatwić utworzenie dziennika są bardziej kompaktowe. Poniżej przedstawiamy 4 przykładowe wpisy reprezentujące każde z 4 zdarzeń. W dzienniku wyglądają następująco (numery wierszy są w dokumencie tylko w celach informacyjnych, nie są wyświetlane 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 – znacznik daty Unix
- info – poziom rejestrowania. Ta wartość zależy od kontekstu transakcji i ustawionego poziomu logowania.
w konfiguracji
edgemicro
. Zobacz Jak ustawić poziom rejestrowania. Poziom zapisu statystyk tostats
. Statystyki są raportowane regularnego interwału ustawionego za pomocą konfiguracjistats_log_interval
. Zobacz też Jak zmienić interwały logu. - req – identyfikuje zdarzenie. W takim przypadku poproś użytkownika klienta.
- m – czasownik HTTP używany w żądaniu;
- u – część adresu URL występująca po ścieżce bazowej.
- h – host i numer portu, na których jest Edge Microgateway. nasłuchiwanie.
- r – host zdalny i port, do którego chce uzyskać dostęp klient. .
- i – identyfikator żądania. Wszystkie 4 wydarzenia będą miały ten identyfikator. Każdy do żądania zostaje przypisany unikalny identyfikator. Korelowanie rekordów logu według identyfikatora żądania może zapewnić cennych informacji na temat czasu oczekiwania dla celu.
- d – czas w milisekundach od otrzymania żądania przez Edge Microgateway. W powyższym przykładzie otrzymano odpowiedź celu na żądanie 0 po 7 milisekundach (wiersz 3), a odpowiedź została wysłana do klienta po kolejnych 4 milisekundy (wiersz 4). Innymi słowy, łączny czas oczekiwania na żądanie wyniósł 11 milisekund z których 7 milisekund było zajęte przez wartość docelową, 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 Unix
- info – poziom rejestrowania. Ta wartość zależy od kontekstu transakcji i ustawionego poziomu logowania.
w konfiguracji
edgemicro
. Zobacz Jak ustawić poziom rejestrowania. Poziom zapisu statystyk tostats
. Statystyki są raportowane regularnego interwału ustawionego za pomocą konfiguracjistats_log_interval
. Zobacz też Jak zmienić interwały logu. - treq – identyfikuje zdarzenie. W tym przypadku jest to żądanie docelowe.
- m – czasownik HTTP używany w żądaniu docelowym.
- u – część adresu URL występująca po ścieżce bazowej.
- h – host i numer portu celu backendu.
- i – identyfikator wpisu w dzienniku. Będzie to widoczne dla wszystkich 4 wydarzeń ID.
3. Przykładowa odpowiedź przychodząca z celu
1436403888672 info tres s=200, d=7, i=0
1436403888651 – znacznik daty Unix
- info – poziom rejestrowania. Ta wartość zależy od kontekstu transakcji i ustawionego poziomu logowania.
w konfiguracji
edgemicro
. Zobacz Jak ustawić poziom rejestrowania. Poziom zapisu statystyk tostats
. Statystyki są raportowane regularnego interwału ustawionego za pomocą konfiguracjistats_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 trwania w milisekundach. Czas potrzebny na wywołanie interfejsu API przez wartość docelową.
- i – identyfikator wpisu w dzienniku. Będzie to widoczne dla wszystkich 4 wydarzeń ID.
4. Przykład odpowiedzi wychodzącej do klienta
1436403888676 info res s=200, d=11, i=0
1436403888651 – znacznik daty Unix
- info – poziom rejestrowania. Ta wartość zależy od kontekstu transakcji i ustawionego poziomu logowania.
w konfiguracji
edgemicro
. Zobacz Jak ustawić poziom rejestrowania. Poziom zapisu statystyk tostats
. Statystyki są raportowane regularnego interwału ustawionego za pomocą konfiguracjistats_log_interval
. Zobacz też Jak zmienić interwały logu. - res – identyfikuje zdarzenie. W takim przypadku odpowiedź na żądanie klienta.
- s – stan odpowiedzi HTTP.
- d – czas trwania w milisekundach. To jest całkowity czas potrzebny według wywołania interfejsu API, w tym czas poświęcony przez docelowy interfejs API oraz czas, jaki upłynął od brzegu Mikrobrama.
- i – identyfikator wpisu w dzienniku. Będzie to widoczne dla wszystkich 4 wydarzeń ID.
Harmonogram plików dziennika
Pliki logów są poddawane rotacji zgodnie z interwałem określonym przez parametr rotate_interval atrybut konfiguracji. Wpisy będą nadal dodawane do ten sam plik dziennika aż do wygaśnięcia interwału rotacji. Jednak za każdym razem, gdy uruchomiono go ponownie, otrzymuje nowy identyfikator UID i tworzy nowy zestaw plików dziennika z tym identyfikatorem UID. Zobacz też Dobra obsługa pliku dziennika .
Komunikaty o błędach
Niektóre wpisy dziennika będą zawierać komunikaty o błędach. Aby pomóc w określeniu, gdzie i dlaczego występują błędy, zobacz błąd Edge Microgateway odniesienie.
Dokumentacja konfiguracji Edge Microgateway
Lokalizacja plik konfiguracji
Atrybuty konfiguracji opisane w tej sekcji znajdują się w Edge Microgateway . Więcej informacji znajdziesz w artykule Tworzenie konfiguracji. zmian.
atrybuty Edge_config
Te ustawienia służą do konfigurowania interakcji między instancją Edge Microgateway Apigee Edge
- loadtrap: (domyślnie: brak) adres URL wskazujący stronę brzegową.
Usługa specyficzna dla Microgateway, która działa w Apigee Edge. Edge Microgateway używa tej usługi do:
komunikują się z Apigee Edge. Ten adres URL jest zwracany, gdy wykonasz polecenie generujące
para kluczy publiczny/prywatny:
edgemicro genkeys
. Zapoznaj się z sekcją Konfiguracja i skonfigurowanie Edge Microgateway. - jwt_public_key: (domyślnie: brak) adres URL wskazujący Edge Microgateway. serwera proxy wdrożonego w Apigee Edge. Ten serwer proxy służy jako punkt końcowy uwierzytelniania dla wystawiania podpisanych tokenów dostępu klientom. Ten adres URL jest zwracany, gdy wykonasz polecenie wdrożyć serwer proxy: edgemicroconfigure. Zapoznaj się z sekcją Konfiguracja i skonfigurowanie Edge Microgateway.
- quotaUri: ustaw tę konfigurację.
jeśli chcesz zarządzać limitami przez serwer proxy
edgemicro-auth
, który jest została wdrożona w Twojej organizacji. Jeśli ta właściwość nie jest skonfigurowana, punkt końcowy limitu jest domyślnie ustawiony na wewnętrzny punkt końcowy Edge Microgateway.edge_config: quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
Atrybuty Edgemicro
Te ustawienia umożliwiają skonfigurowanie procesu Edge Microgateway.
- port: (domyślnie: 8000) numer portu, na którym działa Edge Microgateway nasłuchuje.
- max_connections: (domyślnie: -1) określa maksymalną liczbę połączeń
jednoczesne połączenia przychodzące, które może odbierać Edge Microgateway. Jeśli ten numer to
został przekroczony, zwracany jest następujący stan:
res.statusCode = 429; // Too many requests
- max_connections_hard: (domyślnie: –1) maksymalna liczba jednoczesnych połączeń, które może odbierać Edge Microgateway przed zamknięciem połączenia. To ustawienie ma udaremniać ataki typu DoS. Zwykle należy ustawić wartość większą niż max_connections.
-
logowanie:
-
level: (domyślnie: error)
- info – (zalecane) rejestruje wszystkie żądania i odpowiedzi przechodzące przez Instancja Edge Microgateway.
- warn – rejestruje tylko komunikaty ostrzegawcze.
- error (błąd) – rejestrowane są tylko komunikaty o błędach.
- debug – rejestruje komunikaty debugowania wraz z informacjami, ostrzeżeniami i komunikatami o błędach.
- trace – rejestruje informacje śledzenia błędów wraz z informacjami, ostrzeżeniami i komunikatami o błędach.
- none – nie twórz pliku dziennika.
- dir: (domyślnie: /var/tmp) katalog, w którym znajdują się pliki dziennika zapisane.
- stats_log_interval: (domyślnie: 60) interwał w sekundach, w którym statystyki rekord jest zapisywany w pliku dziennika interfejsu API.
- rotate_interval: (domyślnie: 24) interwał w godzinach, w którym pliki dziennika są obrócono.
-
level: (domyślnie: error)
- Wtyczki: wtyczki zwiększają funkcjonalność Edge Microgateway. Więcej informacji o tworzeniu wtyczek znajdziesz w artykule Tworzenie wtyczek niestandardowych.
- dir: ścieżka względna z katalogu ./gateway do katalogu Katalog ./typy lub ścieżka bezwzględna.
- sequence (sekwencja): lista modułów wtyczek, które możesz dodać do Edge Microgateway. instancji. Moduły będą wykonywane w określonej tutaj kolejności.
-
debug : dodaje do procesu Edge Microgateway zdalne debugowanie.
- port: numer portu nasłuchującego. Na przykład skonfiguruj debuger 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 w razie potrzeby odświeża stronę. Ankiety
rejestruje wszystkie zmiany wprowadzone w Edge (zmiany w produktach, serwery proxy rozpoznające mikrobramy itp.),
oraz zmiany wprowadzone w lokalnym pliku konfiguracyjnym.
- disable_config_poll_interval: (domyślnie: false) ustaw na true (prawda), by wyłączyć automatyczne sondowanie zmian.
- request_timeout: ustawia limit czasu żądań docelowych. Czas oczekiwania jest ustawiony w sek. Jeśli upłynie czas oczekiwania, Edge Microgateway zwróci kod stanu 504. (Dodane v2.4.x)
- keep_alive_timeout: ta właściwość umożliwia skonfigurowanie mikrobramy Edge limit czasu (w milisekundach). (Domyślnie: 5 sekund) (Dodano wersję 3.0.6)
- headers_timeout: ten atrybut ogranicza czas (w milisekundach).
parser HTTP będzie czekać na odebranie
pełne nagłówki HTTP.
Na przykład:
edgemicro: keep_alive_timeout: 6000 headers_timeout: 12000
Wewnętrznie parametr ustawia środowisko Node.js
Server.headersTimeout
dla żądań. (Domyślnie: 5 sekund dłużej niż ustawionym naedgemicro.keep_alive_timeout
. To ustawienie domyślne zapobiega błędnemu odrzucaniu połączenia przez systemy równoważenia obciążenia lub serwery proxy. (Dodano wersję 3.1.1) - noRuleMatchAction: (ciąg znaków) działanie, które należy podjąć (zezwalając na dostęp lub odmów go), jeśli
reguła dopasowania określona we wtyczce
accesscontrol
nie jest rozpoznawana (jest niedopasowana). Prawidłowe wartości:ALLOW
lubDENY
Wartość domyślna:ALLOW
(dodana: wersja 3.1.7) - enableAnalytics: (domyślnie: true) ustaw dla atrybutu wartość false na
blokowanie wtyczki analitycznej
przed wczytaniem. W takim przypadku nie będą wykonywane żadne wywołania analityki Apigee Edge. Jeśli ma wartość true lub gdy
ten atrybut nie został podany, wtyczka Analytics będzie działać w zwykły sposób. Zobacz
edgemicro dla
. (Dodano wersję 3.1.8).
Przykład:
edgemicro enableAnalytics=false|true
- on_target_response_abort: ten atrybut pozwala kontrolować
jak działa Edge Microgateway, gdy połączenie między klientem (Edge Microgateway) a
serwer docelowy jest zamykany przedwcześnie.
Wartość Opis Domyślny Jeśli on_target_response_abort
nie jest określony, działanie domyślne jest skrócenie odpowiedzi bez wyświetlania błędu. W plikach dziennika pojawi się ostrzeżenie jest wyświetlany z kodemtargetResponse aborted
i kodem odpowiedzi 502.appendErrorToClientResponseBody
Błąd niestandardowy TargetResponseAborted
jest zwracany do funkcji klienta. W plikach dziennika pojawi się ostrzeżenie jest wyświetlany z kodemtargetResponse aborted
i kodem odpowiedzi 502. W dodatkowo zostanie zarejestrowany błądTargetResponseAborted
z komunikatemTarget response ended prematurely.
abortClientRequest
Edge Microgateway przerwie żądanie i w plikach dziennika zostanie zapisane 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 x-forwarded-for nagłówki, które mają być przekazywane do miejsca docelowego. Pamiętaj, że jeśli 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 (fałsz), aby zapobiec nagłówki x-forwarded-host, które mają zostać przekazane do miejsca docelowego.
- x-request-id: (domyślnie: true) ustaw na false, by zapobiec x-request-id, które mają być przekazywane do miejsca docelowego.
- x-response-time: (domyślnie: true) ustaw wartość false (fałsz), aby zapobiec. nagłówki x-response-time, które mają zostać przekazane do miejsca docelowego.
- via: (domyślnie: true) ustaw wartość false, by zapobiec wykorzystywaniu nagłówków trafiła do celu.
atrybuty OAuth
Te ustawienia konfiguruje sposób wymuszania uwierzytelniania klienta przez Edge Microgateway.
- allowNoAuthorization: (domyślnie: false), jeśli ma wartość prawda, wywołania interfejsu API są mogą przechodzić przez Edge Microgateway bez żadnego nagłówka autoryzacji. Ustaw na false, aby wymagać nagłówka autoryzacji (domyślnie).
- allowInvalidAuthorization: (domyślnie: false), jeśli ma wartość prawda, wywołania interfejsu API są może zostać przekazana, jeśli token przekazany w nagłówku autoryzacji jest nieprawidłowy lub stracił ważność. Ustaw na false, aby wymagać prawidłowych tokenów (domyślnie).
- authorization-header: (domyślnie: Authorization: Bearer) nagłówek używany do wyślij token dostępu do Edge Microgateway. Możesz zmienić domyślną wartość wtedy, gdy element docelowy musi używać nagłówka autoryzacji w innym celu.
- api-key-header: (domyślnie: x-api-key) nazwa nagłówka lub zapytania. służący do przekazywania klucza interfejsu API do Edge Microgateway. Zobacz też Korzystanie z: klucz interfejsu API.
- keep-authorization-header: (domyślnie: false) jeśli ma wartość Prawda, nagłówek autoryzacji wysłane w żądaniu jest przekazywane do celu (jest zachowywane).
- allowOAuthOnly – jeśli ma wartość true (prawda), każdy interfejs API musi mieć autoryzację nagłówek z tokenem dostępu okaziciela. Zezwala tylko na model zabezpieczeń OAuth (podczas gdy zachowania zgodności wstecznej). (Dodano 2.4.x)
- allowAPIKeyOnly – jeśli ma wartość true (prawda), każdy interfejs API musi zawierać parametr Nagłówek x-api-key (lub lokalizacja niestandardowa) z kluczem interfejsu API.Pozwala na wyłącznie z modelu bezpieczeństwa klucza interfejsu API (z zachowaniem zgodności wstecznej). (Dodano 2.4.x)
- gracePeriod – ten parametr zapobiega błędom spowodowanemu rozbieżności między zegarem systemowym a czasem przed (nbf) lub wystawionym (iat) podany w tokenie autoryzacji JWT. Ustaw ten parametr na dozwoloną liczbę sekund takich rozbieżności. (Dodano 2.5.7)
Wtyczki atrybuty
Szczegółowe informacje o konfigurowalnych atrybutach każdej wtyczki znajdziesz w sekcji Korzystanie z wtyczek.
Filtrowanie serwerów proxy
Możesz filtrować serwery proxy rozpoznające mikrobramę, które będzie przetwarzać instancja Edge Microgateway.
Po uruchomieniu Edge Microgateway pobierze wszystkie serwery proxy rozpoznające bramę
organizacji, z którą jest powiązana. Użyj tej konfiguracji, aby ograniczyć serwery proxy
microgateway. Na przykład ta konfiguracja ogranicza serwery proxy w mikrobramie
przetworzy trzy zmiany: 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 API używanych przez Edge Microgateway
pobieranie i przetwarzanie danych. Aby filtrować pobrane produkty, dodaj productnamefilter
parametr zapytania do interfejsu API /products
wymienionego w 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
być zakodowany. Wyrażenie regularne ^[Ee]dgemicro.*$
wykrywa na przykład takie nazwy:
„edgemicro-test-1” , "edgemicro_demo" i „Edgemicro_New_Demo”. Zakodowana wartość adresu URL, odpowiednia dla
zostanie użyty 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 Edge wybierz serwer proxy edgemicro_auth w organizacji/środowisku. w której skonfigurowano Edge Microgateway.
- W sekcji Programowanie otwórz w edytorze zasadę JavaCallout.
- Dodaj atrybut niestandardowy o kluczu
products.filter.attributes
rozdzielonym przecinkami z listą nazw atrybutów. Tylko produkty, które zawierają dowolną z nazw atrybutów niestandardowych. wróci do Edge Microgateway. - Możesz opcjonalnie wyłączyć sprawdzanie
aby sprawdzić, czy usługa jest włączona w bieżącym środowisku, ustawiając
atrybut niestandardowy
products.filter.env.enable
dofalse
. (wartością domyślną jest true (prawda). - (Tylko chmura Private Cloud) Jeśli korzystasz z Edge dla Private Cloud, ustaw właściwość
Z
org.noncps
dotrue
, aby pobrać usługi w środowiskach 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 danych analitycznych
Użyj tych parametrów konfiguracji, aby kontrolować częstotliwość wysyłania przez Edge Microgateway Analytics do Apigee:
- bufferSize (opcjonalny): maksymalna liczba rekordów Analytics, które zostały utworzone w buforze przed rozpoczęciem usuwania najstarszych rekordów. Domyślnie: 10 000
- batchSize (opcjonalny): maksymalny rozmiar grupy rekordów Analytics. wysłano do Apigee. Domyślnie: 500
- flushInterval (opcjonalny): liczba milisekund między każdym usunięciem wartości grupę rekordów Analytics wysłanych do Apigee. Domyślnie: 5000
Na przykład:
analytics: bufferSize: 15000 batchSize: 1000 flushInterval: 6000
Maskowanie danych analitycznych
Ta konfiguracja zapobiega wyświetlaniu informacji o ścieżce żądania w Edge Analytics. Dodaj do konfiguracji mikrobramy poniższy fragment, aby zamaskować identyfikator URI żądania lub ścieżki żądania. Pamiętaj, że identyfikator URI składa się z nazwy hosta i ścieżek żą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, aby segregować konkretną ścieżkę interfejsu API, tak aby wyglądała tak: osobnego serwera proxy w panelach Edge Analytics. Możesz na przykład: i segregować interfejs API kontroli stanu w panelu, aby uniknąć pomylenia go z rzeczywistymi wywołaniami serwera proxy interfejsu API. W W panelu Analytics segregowane serwery proxy mają następujący wzorzec nazewnictwa:
edgemicro_proxyname-health
Ilustracja poniżej przedstawia 2 oddzielne serwery proxy w panelu Analytics: edgemicro_hello-health
oraz
edgemicro_mock-health
:
Użyj tych parametrów służących do oddzielania ścieżek względnych i bezwzględnych w panelu informacyjnym Analytics jako osobnych serwerów proxy:
- relativePath (opcjonalny): określa ścieżkę względną do oddzielenia w tagu
Panel Analytics. Jeśli na przykład określisz
/healthcheck
, wszystkie wywołania interfejsu API zawierające ścieżkę/healthcheck
pojawi się w panelu jakoedgemicro_proxyname-health
. Pamiętaj, że ta flaga ignoruje ścieżkę bazową serwera proxy. Aby segregować je na podstawie pełnej ścieżki (łącznie ze ścieżką bazową), użyj flagiproxyPath
. - proxyPath (opcjonalnie): określa pełną ścieżkę serwera proxy interfejsu API, łącznie z serwerem proxy.
ścieżki podstawowej. Jeśli na przykład wpiszesz
/mocktarget/healthcheck
, gdzie/mocktarget
jest ścieżką bazową serwera proxy, wszystkie wywołania interfejsu API ze ścieżką/mocktarget/healthcheck
są wyświetlane w panelu jakoedgemicro_proxyname-health
.
Na przykład w poniższej konfiguracji każda ścieżka interfejsu API zawierająca /healthcheck
będzie
być oddzielone przez wtyczkę analityczną. Oznacza to, że /foo/healthcheck
i /foo/bar/healthcheck
będzie rozdzielona jako osobny serwer proxy o nazwie edgemicro_proxyname-health
w panelu statystyk.
analytics: uri: >- https://xx/edgemicro/ax/org/docs/environment/test bufferSize: 100 batchSize: 50 flushInterval: 500 relativePath: /healthcheck
W tej konfiguracji dowolny interfejs API ze ścieżką serwera proxy /mocktarget/healthcheck
będzie
będzie rozdzielany jako osobny serwer proxy o nazwie edgemicro_proxyname-health
w
panelu statystyk.
analytics: uri: >- https://xx/edgemicro/ax/org/docs/environment/test bufferSize: 100 batchSize: 50 flushInterval: 500 proxyPath: /mocktarget/healthcheck
Konfigurowanie Edge Microgateway za firmowa zapora sieciowa
Używaj 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 :
- Ustawianie zmiennych środowiskowych
HTTP_PROXY
,HTTPS_PROXY
iNO_PROXY
. Te zmienne kontrolują hosty każdego serwera proxy HTTP, który ma być używany 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ą rozdzielonych przecinkami domen, które Edge Microgateway nie powinien pośredniczyć w przekierowywaniu do.Więcej informacji o tych zmiennych znajdziesz na stronie https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables
- Uruchom ponownie Edge Microgateway.
Używanie serwera proxy HTTP na potrzeby komunikacji docelowej
Dodano w wersji 3.1.2.
Aby używać serwera proxy HTTP do komunikacji między Edge Microgateway a miejscami docelowymi backendu, wykonaj te czynności:
- Dodaj do tego pliku konfiguracji microgateway:
edgemicro: proxy: tunnel: true | false url: proxy_url bypass: target_host # target hosts to bypass the proxy. enabled: true | false
Gdzie:
- tunel: (opcjonalnie) w przypadku wartości true (prawda) Edge Microgateway używa metody HTTP CONNECT do tunelowania HTTP
w ramach pojedynczego połączenia TCP. (To samo dotyczy zmiennych środowiskowych,
wspomniane poniżej,
do konfigurowania serwera proxy musisz włączyć TLS). Domyślny:
false
- url: adres URL serwera proxy HTTP.
- bypass: (opcjonalny) określa co najmniej jeden docelowy adres URL hosta, który jest rozdzielany przecinkami. powinien ominąć serwer proxy HTTP. Jeśli ta właściwość nie jest skonfigurowana, użyj funkcji NO_PROXY zmienną środowiskową określającą, które docelowe adresy URL mają być pomijane.
- enabled: jeśli ma wartość prawda i
proxy.url
, użyj wartościproxy.url
dla serwera proxy HTTP. Jeśli zasada ma wartość prawda, a zasadaproxy.url
jest nieskonfigurowana, używaj serwerów proxy określonych w serwerze proxy HTTP. zmiennych środowiskowychHTTP_PROXY
iHTTPS_PROXY
, jak opisano w Używaj 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
- tunel: (opcjonalnie) w przypadku wartości true (prawda) Edge Microgateway używa metody HTTP CONNECT do tunelowania HTTP
w ramach pojedynczego połączenia TCP. (To samo dotyczy zmiennych środowiskowych,
wspomniane poniżej,
do konfigurowania serwera proxy musisz włączyć TLS). Domyślny:
- Uruchom ponownie Edge Microgateway.
Używanie symboli wieloznacznych w przypadku użycia w usłudze Microgateway serwery proxy
Możesz użyć jednego lub więcej znaków „*” symbole wieloznaczne w ścieżce podstawowej
edgemicro_* (zgodny z mikrobramą). Na przykład ścieżka podstawowa
/team/*/members pozwala klientom dzwonić
https://[host]/team/blue/members i
https://[host]/team/green/members bez konieczności tworzenia nowych serwerów proxy interfejsów API;
wspierać nowe zespoły. Pamiętaj, że /**/
nie jest obsługiwany.
Ważne: Apigee NIE obsługuje użycia symbolu wieloznacznego „*” jako
pierwszego elementu ścieżki podstawowej. Na przykład to NIE jest obsługiwane: wyszukiwanie za pomocą /*/
.
Rotacja kluczy JWT
W pewnym momencie po pierwszym wygenerowaniu tokena JWT może być konieczna zmiana Para kluczy publiczny/prywatny przechowywana w zaszyfrowanej na brzegu maszynie wirtualnej. Ten proces generowania nowego klucza jest nazywany rotacją kluczy.
Jak Edge Microgateway używa tokenów JWT
Token internetowy JSON (JWT) to standard tokenów opisany w RFC7519. JWT umożliwia podpisywanie zbioru deklaracji, które może zostać wiarygodnie zweryfikowane przez odbiorcę tokena JWT.
Token JWT możesz wygenerować za pomocą interfejsu wiersza poleceń i użyć go w Nagłówek 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 kluczy?
W pewnym momencie po pierwszym wygenerowaniu tokena JWT może być konieczna zmiana Para kluczy publiczny/prywatny przechowywana w zaszyfrowanej na brzegu maszynie wirtualnej. Ten proces generowania nowego klucza jest nazywany rotacją kluczy. Podczas rotacji kluczy generowana jest nowa para kluczy prywatny/publiczny są przechowywane w „mikrobramie” KVM w organizacji lub środowisku Apigee Edge. Dodatkowo Stary klucz publiczny zostanie zachowany wraz z pierwotną wartością identyfikatora klucza.
Aby wygenerować token JWT, Edge używa informacji przechowywanych w zaszyfrowanej maszynie wirtualnej. O
Usługa KVM o nazwie microgateway
została utworzona i wypełniona kluczami podczas wstępnej konfiguracji
Edge Microgateway. Klucze w KVM służą do podpisywania i szyfrowania tokena JWT.
Klucze KVM obejmują:
-
private_key – najnowszy (ostatni) klucz prywatny RSA używany do podpisywania. Tokeny JWT.
-
public_key – najnowszy (ostatnio utworzony) certyfikat używany do weryfikacji tokenów JWT podpisano za pomocą klucza private_key.
-
private_key_kid – najnowszy (ostatni) identyfikator 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 – najnowszy (ostatni) identyfikator klucza publicznego. Ten klucz jest powiązana z wartością public_key1 i służy do obsługi rotacji klucza. Ta wartość jest taki sam jak klucz prywatny.
-
public_key1 – najnowszy (ostatni) klucz publiczny.
Podczas rotacji kluczy istniejące pary klucz-wartość są zastępowane na mapie, a nowe aby zachować stare klucze publiczne. Na przykład:
-
public_key2_kid – stary identyfikator klucza publicznego. Ten klucz jest powiązany z 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 nie uda się zweryfikować, będzie używany stary klucz publiczny do momentu wygaśnięcia tokena JWT (po odstępie token_expiry*, domyślnie 30 minut). W w ten sposób można „obrócić” bez natychmiastowego zakłócania ruchu API.
Jak wykonać rotację klucza
W tej sekcji dowiesz się, jak wykonać rotację klucza.
- Aby uaktualnić KVM, użyj polecenia
edgemicro upgradekvm
. Więcej informacji zapoznaj się z sekcją Uaktualnianie KVM. Wystarczy to zrobić raz. - Aby uaktualnić serwer proxy edgemicro-oauth, użyj polecenia
edgemicro upgradeauth
. Szczegółowe informacje na temat uruchamiania tego polecenia znajdziesz w sekcji Zmień serwer proxy uwierzytelniania Edgemicro. Wystarczy to zrobić raz. - Dodaj ten wiersz do pliku
~/.edgemicro/org-env-config.yaml
tam, gdzie musisz określ tę samą organizację i środowisko, z których ma korzystać mikrobrama: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 sekcji Klawisze rotacyjne.
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 kluczy Edge zwraca wiele kluczy do Edge Microgateway. Uwaga w sekcji w poniższym przykładzie, każdy klucz ma unikalny identyfikator „kid” (Identyfikator klucza). Mikrobrama używa następnie tych kluczy do weryfikowania tokenów autoryzacji. Jeśli weryfikacja tokena się nie powiedzie, mikrobrama szuka sprawdź, czy w zestawie kluczy jest starszy klucz, i spróbuje go użyć. Format pliku zwrócone klucze to JSON Web Key (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" } ] }
Konfiguracja ustawienia „nie wcześniej” opóźnienie
W przypadku wersji 3.1.5 i starszych nowy klucz prywatny wygenerowany przez polecenie rotatekey
został
natychmiast, a wygenerowane tokeny były podpisywane nowym kluczem prywatnym. Pamiętaj jednak:
nowy klucz publiczny był dostępny tylko dla instancji Edge Microgateway co 10 minut (domyślnie)
gdy konfiguracja mikrobram została odświeżona. Z powodu tego opóźnienia między podpisywaniem tokena
i odświeżenia instancji microgateway, tokeny podpisane najnowszym kluczem będą odrzucane do
wszystkie instancje otrzymały najnowszy klucz publiczny.
W sytuacjach, gdy istnieje wiele instancji mikrobram, opóźnienie klucza publicznego czasami skutkowało w przypadku okresowych błędów środowiska wykonawczego o stanie 403, ponieważ weryfikacja tokena zakończyła się niepowodzeniem w instancji, ale kończy się niepowodzeniem w innej instancji, dopóki wszystkie instancje nie zostaną odświeżone.
Począwszy od wersji 3.1.6 nowa flaga polecenia rotatekey
umożliwia określenie opóźnienia dla nowego polecenia
klucza prywatnego, co pozwala na odświeżenie wszystkich instancji microgateway
po otrzymaniu nowego klucza publicznego. Nowa flaga to --nbf
i 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 większe niż wartość ustawienia konfiguracji config_change_poll_internal
.
który domyślnie wynosi 10 minut. Zobacz też atrybuty Edgemicro.
Filtrowanie pobranych serwerów proxy
Domyślnie Edge Microgateway pobiera wszystkie serwery proxy z organizacji Edge rozpoczyna się od prefiksu „edgemicro_”. Możesz zmienić tę wartość domyślną, 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 polu Edge_config. Na przykład poniższy wzorzec pozwoli
pobierania serwerów proxy takich jak Edgemicro_foo, Edgemicro_fast i Edgemicro_first.
edge_config: … proxyPattern: edgemicro_f*
Określanie produktów bez 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 korzystanie z klucza interfejsu API powiązanego z tą usługą na serwer proxy wdrożony w organizacji. Od wersji 2.5.4 tę usługę obsługuje Edge Microgateway konfiguracji.
Debugowanie i rozwiązywanie problemów
Łączenie z debugerem
Edge Microgateway możesz uruchomić za pomocą debugera, np. node-inspector. Przydaje się to w przypadku rozwiązywania problemów i debugowania wtyczek niestandardowych.
- Uruchom ponownie Edge Microgateway w trybie debugowania. Aby to zrobić, dodaj
DEBUG=*
do początek poleceniastart
:DEBUG=* edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET
Aby bezpośrednio zapisać dane wyjściowe debugowania w 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ł na numerze portu w trakcie procesu debugowania.
- Możesz teraz przeglądać kod Edge Microgateway, ustawiać punkty przerwania, obserwować wyrażenia i tak dalej.
Możesz określić standardowe flagi Node.js związane z trybem debugowania. Przykład:
--nolazy
pomaga w debugowaniu kodu asynchronicznego.
Sprawdzam pliki dziennika
W razie problemów sprawdź pliki dziennika pod kątem szczegółów wykonania i błędów i informacjami o nich. Więcej informacji znajdziesz w artykule Zarządzanie plikami dziennika.
Korzystanie z bezpieczeństwa klucza interfejsu API
Klucze interfejsu API zapewniają prosty mechanizm uwierzytelniania klientów wysyłających żądania do Edge Mikrobrama. 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 API są wymieniane na tokeny okaziciela, które są przechowywane w pamięci podręcznej. Aby wyłączyć buforowanie, ustaw
nagłówek Cache-Control: no-cache
w żądaniach przychodzących do Edge
Mikrobrama.
Używanie klucza API
Klucz interfejsu API możesz przekazać w żądaniu interfejsu API jako parametr zapytania lub w nagłówku. Domyślnie
nazwa nagłówka i 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ą zarówno w nagłówku klucza interfejsu API, jak i w parametrze zapytania.
Możesz zmienić to ustawienie domyślne w pliku konfiguracji, zgodnie z opisem w sekcji Wprowadzanie zmian w konfiguracji. Na przykład, aby zmienić
nazwę do apiKey:
oauth: allowNoAuthorization: false allowInvalidAuthorization: false api-key-header: apiKey
W tym przykładzie zarówno parametr zapytania, jak i nazwa nagłówka zostają zmienione na apiKey
.
nazwa x-api-key
nie będzie już działać w żadnym z tych przypadków. 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 sekcji Secure Edge Microgateway.
Włącz nadrzędne kody odpowiedzi
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 kod 4xx lub 5xx zależnie od błędu.
Aby włączyć tę funkcję, dodaj oauth.useUpstreamResponse: true
do konfiguracji Edge Microgateway. Na przykład:
oauth: allowNoAuthorization: false allowInvalidAuthorization: false gracePeriod: 10 useUpstreamResponse: true
Korzystanie z zabezpieczeń tokenów OAuth2
Ta sekcja wyjaśnia, jak uzyskać tokeny dostępu OAuth2 i tokeny odświeżania. Tokeny dostępu są używane do tworzenia dla bezpiecznych wywołań interfejsu API przez mikrobramę. Tokeny odświeżania są używane do uzyskiwania nowych tokenów dostępu.
Jak uzyskać token dostępu
Ta sekcja wyjaśnia, 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
.
Więcej informacji o interfejsie wiersza poleceń znajdziesz w artykule Zarządzanie tokenami.
API 1: wysyłanie danych logowania jako parametrów treści
Zastąp nazwy organizacji i środowisk w adresie URL. zastąpić identyfikator konsumenta i wartość tajnego klucza klienta uzyskane z aplikacji dewelopera w Apigee Edge dla parametrów 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łanie danych logowania w nagłówku uwierzytelniania podstawowego
Wyślij dane logowania klienta w nagłówku uwierzytelniania podstawowego oraz
grant_type
jako parametr formularza. Ten formularz polecenia jest też omówiony w
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. Nie ma różnicy między wartościamitoken
a
Usługi: access_token
. Możesz używać dowolnej z tych opcji. Zwróć uwagę, że expires_in
to
jest liczbą całkowitą określoną 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 do punktu końcowego /token
Serwer proxy edgemicro-auth
. Musisz wykonać to wywołanie interfejsu API za pomocą funkcji password
typu uwierzytelnienia. Poniżej znajdziesz opis tego procesu.
- Uzyskiwanie tokena dostępu i odświeżanie go za pomocą interfejsu API
/token
. Pamiętaj, że typ uwierzytelnienia topassword
: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: to osiągnąć. Pamiętaj, że
expires_in
ma wartości liczby całkowite i podawana 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
punktu końcowego
/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 podobnie do tej:
{ "token": "your-new-access-token" }
Nieprzerwane monitorowanie
Określanie punktu końcowego pliku konfiguracji
Jeśli korzystasz z wielu instancji Edge Microgateway, możesz zarządzać ich konfiguracjami z jednego miejsca. Możesz to zrobić, określając punkt końcowy HTTP, w którym Edge Micro pobierz plik konfiguracyjny. Możesz określić ten punkt końcowy po uruchomieniu Edge Micro za pomocą flagę -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 jest plik
który domyślnie znajduje się w lokalizacji ~/.edgemicro
i jest zgodny z konwencją nazewnictwa:
org-env-config.yaml
Wyłączam buforowanie danych połączenia TCP
Możesz użyć atrybutu konfiguracji nodelay
, aby wyłączyć buforowanie danych dla:
Połączenia TCP używane przez Edge Microgateway.
Domyślnie połączenia TCP korzystają z interfejsu Nagle
algorytm buforuje dane przed ich wysłaniem. Ustawiam nodelay
na true
,
wyłącza tę funkcję (dane są natychmiast uruchamiane za każdym razem,
socket.write()
). Zobacz też artykuł Node.js
dokumentacji.
Aby włączyć usługę 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
Uruchamianie Edge Microgateway w trybie samodzielnym
Możesz uruchomić Edge Microgateway bez połączenia z Zależność Apigee Edge. Ten scenariusz, nazywany trybem samodzielnym, pozwala uruchamiać i testować Edge Microgateway bez połączenia z internetem.
W trybie samodzielnym poniższe funkcje nie działają, ponieważ wymagają połączenia Do Apigee Edge:
- Protokół OAuth i klucz interfejsu API
- Limit
- Analytics
Z kolei wtyczki niestandardowe i zatrzymanie nagłych wzrostów działają normalnie, ponieważ
wymaga połączenia z Apigee Edge. Ponadto nowa wtyczka o nazwie extauth
umożliwia
autoryzuj wywołania 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 nazwie
$HOME/.edgemicro/$ORG
-
$ENV-config.yamlNa 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
- Wyeksportuj zmienną środowiskową z wartością „1”:
export EDGEMICRO_LOCAL=1
- Wykonaj podane niżej polecenie
start
, podając w nim wartości do utworzenia instancji 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 „organizacja” użytą w nazwie pliku konfiguracji.
- Parametr $ENV to „env” nazwa użyta w pliku konfiguracji; imię i nazwisko.
- $LOCAL_PROXY_NAME to nazwa lokalnego serwera proxy, który zostanie utworzony. Za pomocą dowolną nazwę.
- $LOCAL_PROXY_VERSION to numer wersji serwera proxy.
- $TARGET_URL to URL środowiska docelowego serwera proxy. (Wartość docelowa to usługę wywoływaną przez serwer proxy).
- $BASE_PATH to ścieżka podstawowa serwera proxy. Ta wartość musi zaczynać się od zdarzenia ukośnik prawy. Jako główną ścieżkę podstawową 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 plikufoo-bar-config.yaml
, pobierz „missing_authorization” . Ta wtyczka weryfikuje token JWT, który musi znajdować się w autoryzacji w nagłówku wywołania interfejsu API. W następnej sekcji otrzymasz token JWT, który umożliwi wywołania interfejsu API bez błędu.
Przykład: uzyskiwanie tokena autoryzacji
Przykład poniżej 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 standardowej konfiguracji Edge Microgateway.
Aby uzyskać token JWT z punktu końcowego Apigee, musisz najpierw przeprowadzić standardową konfigurację Edge Microgateway oraz
być połączone z internetem. Punkt końcowy Apigee jest tutaj używany np. do celów
i nie jest wymagany. Jeśli chcesz, możesz użyć innego punktu końcowego tokena JWT. Jeśli to zrobisz, musisz uzyskać token JWT za pomocą
interfejs API udostępniony dla tego punktu końcowego.
Poniższe kroki wyjaśniają, jak uzyskać token za pomocą punktu końcowego edgemicro-auth/jwkPublicKeys
:
- Musisz wykonać standardową
konfiguracja i konfiguracja Edge Microgateway w celu wdrożenia serwera proxy
edgemicro-auth
. w Apigee Edge dla Twojej organizacji lub środowiska. Jeśli ten krok został już wykonany, nie musisz go powtarzać. - Jeśli wdrożono Edge Microgateway w Apigee Cloud, musisz mieć połączenie z internetem, aby można było uzyskać token JWT z tego punktu końcowego.
-
Zatrzymywanie Edge Microgateway:
edgemicro stop
- W utworzonym wcześniej pliku konfiguracji (
$HOME/.edgemicro
/org–env-config.yaml
): Wskażextauth:publickey_url
do punktu końcowegoedgemicro-auth/jwkPublicKeys
w organizacji/środowisku Apigee Edge. Na przykład:extauth: publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'
-
Ponownie uruchom Edge Microgateway, tak jak poprzednio, używając nazw organizacji/env użytych 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 usługi
edgemicro-auth/jwkPublicKeys
punktu końcowego, możesz użyć tego polecenia interfejsu wiersza poleceń:
Token JWT możesz wygenerować dla Edge Microgateway za pomocą polecenia edgemicro token
lub
i nie tylko. Na przykład:
edgemicro token get -o your_org -e your_env \ -i G0IAeU864EtBo99NvUbn6Z4CBwVcS2 -s uzHTbwNWvoSmOy
Gdzie:
- your_org to nazwa organizacji Apigee, dla której wcześniej Edge Microgateway.
- your_env to środowisko w organizacji.
- Opcja
i
określa klucz klienta z aplikacji dewelopera zawierającej produkt obejmujący serwer proxyedgemicro-auth
. - Opcja
s
określa tajny klucz klienta z aplikacji dewelopera, która ma atrybut produkt zawierający serwer proxyedgemicro-auth
.
To polecenie prosi Apigee Edge o wygenerowanie tokena JWT, którego można potem użyć do zweryfikowania interfejsu API połączeń.
Zobacz też Generowanie tokena.Testowanie samodzielnej konfiguracji
Aby przetestować konfigurację, wywołaj interfejs API z tokenem dodanym w nagłówku autoryzacji 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":"" }
Używanie trybu lokalnego serwera proxy
W trybie lokalnego serwera proxy Edge Microgateway nie wymaga Serwer proxy microgateway do wdrożenia w Apigee Edge. Zamiast tego musisz skonfigurować „lokalny serwer proxy” przez podanie nazwę lokalnego serwera proxy, ścieżkę bazową i docelowy adres URL. i uruchomić mikrobramę. Wywołania interfejsu API mikrobramy są następnie wysyłane do środowiska docelowego. Adres URL lokalnego serwera proxy. Pod każdym innym względem lokalny tryb proxy działa dokładnie tak samo jak uruchamianie. Edge Microgateway w trybie normalnym. Uwierzytelnianie działa tak samo, jak wzrost wymuszanie aresztowania i egzekwowania limitów, wtyczki niestandardowe itd.
Przypadek użycia i przykład
Lokalny tryb serwera proxy jest przydatny, gdy z Edge Microgateway trzeba powiązać tylko jeden serwer proxy instancji. Możesz na przykład wstrzyknąć Edge Microgateway do Kubernetes jako pomocniczy serwer proxy, gdzie bramka mikrobramowa i usługa są uruchamiane w jednym podzie, w którym mikrobrama zarządza ruchem do oraz od usługi towarzyszącej. Poniższy rysunek przedstawia architekturę, w której Edge Microgateway działa jako pomocniczy serwer proxy w klastrze Kubernetes. Każda instancja mikrobramy komunikuje tylko do jednego punktu końcowego w jego usłudze towarzyszącej:
Zaletą tego stylu architektury jest to, że Edge Microgateway udostępnia interfejs API. zarządzania poszczególnymi usługami wdrożonymi w środowisku kontenera, takimi jak w klastrze Kubernetes.
Konfigurowanie trybu lokalnego serwera proxy
Aby skonfigurować Edge Microgateway do działania w trybie lokalnego serwera proxy, wykonaj te czynności:
- Uruchom
edgemicro init
, aby dokładnie skonfigurować lokalne środowisko konfiguracji tak jak w typowej konfiguracji Edge Microgateway. Zobacz też Skonfiguruj Edge Microgateway. - Uruchom
edgemicro configure
w taki sam sposób 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 zasadę edgemicro-auth w Edge i zwraca klucz i obiekt tajny, który będzie potrzebny do uruchomienia mikrobramy. Jeśli potrzebujesz pomocy, zobacz Skonfiguruj Edge Microgateway.
- W Apigee Edge utwórz usługę API z tą obowiązkową konfiguracją
wymagania (wszystkimi pozostałymi konfiguracjami możesz zarządzać według własnego uznania):
- Musisz dodać do usługi serwer proxy edgemicro-auth. Ten serwer proxy
został wdrożony automatycznie podczas uruchamiania
edgemicro configure
. - Musisz podać ścieżkę zasobu. Apigee zaleca dodanie tej ścieżki do
usługa:
/**
. Więcej informacji znajdziesz w artykule Konfigurowanie zachowania ścieżki zasobu. Zapoznaj się też z artykułem Tworzenie interfejsu API znajdziesz w dokumentacji Edge.
- Musisz dodać do usługi serwer proxy edgemicro-auth. Ten serwer proxy
został wdrożony automatycznie podczas uruchamiania
W Apigee Edge utwórz programistę. Możesz też użyć istniejącego życzenie. Pomocne informacje znajdziesz w artykule Dodawanie programistów przy użyciu interfejsu zarządzania urządzeniami brzegowymi.
- W Apigee Edge utwórz aplikację dewelopera. Musisz dodać usługę API, właśnie utworzonej aplikacji. Aby uzyskać pomoc, zobacz Rejestrowanie aplikacji w Edge za pomocą interfejsu zarządzania.
- Na komputerze, na którym zainstalowano Edge Microgateway, wyeksportuj następujące dane:
zmienną środowiskową o 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 podczas uruchamiania
edgemicro configure
- your_secret to obiekt tajny, który został 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, której serwer proxy będzie ).
- base_path to ścieżka podstawowa serwera proxy. Ta wartość musi zaczynać się od zdarzenia ukośnik prawy. Jako główną ścieżkę podstawową 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. Przykład:
Jeśli podasz ś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 dla deweloperów. Otwórz aplikację w interfejsie Edge, skopiuj Klucz klienta, a następnie użyj go w następujący 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 omówiono sposób korzystania z synchronizatora, czyli opcjonalnej funkcji, zwiększa odporność Edge Microgteway, zezwalając aby pobrać dane konfiguracji z Apigee Edge i zapisać je w lokalnej bazie danych Redis. Na działająca instancja synchronizatora, inne instancje Edge Microgateway działające w różnych węzłach, może pobrać swoją konfigurację bezpośrednio z tej bazy danych.
Funkcja synchronizatora jest obecnie obsługiwana do pracy z Redis 5.0.x.
Co to jest synchronizator?
Synchronizator zapewnia poziom odporności Edge Microgateway. Pomaga to zapewnić, że każda instancja Edge Microgateway używa tej samej konfiguracji; w przypadku zakłócenia połączenia z internetem instancje Edge Microgateway mogą się uruchamiać i uruchamiać bez obaw.
Domyślnie instancje Edge Microgateway muszą mieć możliwość komunikacji z Apigee Edge pobierania i odświeżania danych konfiguracji, takich jak serwer proxy interfejsu API i konfiguracje usług API. Jeśli połączenie internetowe z Edge zostanie zakłócone, instancje mikrobramek mogą nadal , ponieważ najnowsze dane konfiguracji są przechowywane w pamięci podręcznej. Jednak nowe instancje microgateway nie można uruchomić bez wyraźnego połączenia. Ponadto istnieje możliwość, że internet zakłócenia w działaniu co najmniej 1 instancji microgateway z konfiguracją które nie są zsynchronizowane z innymi instancjami.
Synchronizator Edge Microgateway zapewnia alternatywny mechanizm Edge Microgateway
do pobierania danych konfiguracyjnych, które są wymagane do uruchomienia i przetworzenia ruchu przez serwer proxy interfejsu API.
Dane konfiguracji pobrane z wywołań do Apigee Edge obejmują: wywołanie jwk_public_keys
,
wywołanie jwt_public_key
, wywołanie wczytywania i wywołanie usług API.
Synchronizator umożliwia korzystanie z całej bramy Edge Microgateway
instancji działających w różnych węzłach, aby prawidłowo uruchamiały się i pozostawały zsynchronizowane, nawet jeśli
połączenie internetowe między Edge Microgateway a Apigee Edge zostanie zakłócone.
Synchronizator to specjalnie skonfigurowana instancja Edge Microgateway. Jego jedyny cel to sondowanie Apigee Edge (czas można skonfigurować), pobieranie danych konfiguracyjnych; i zapisać go w lokalnej bazie danych Redis. Sama instancja synchronizatora nie może przetworzyć serwera proxy interfejsu API ruchu. Inne instancje Edge Microgateway działające w różnych węzłach mogą zostać skonfigurowana tak, aby pobierała dane konfiguracji z bazy danych Redis, a nie z Apigee Edge. Ponieważ wszystkie instancje mikrobram pobierają swoje dane konfiguracyjne z mogą uruchamiać i przetwarzać żądania do interfejsu API nawet w przypadku, gdy internet działa nie jest zakłócona.
Konfigurowanie instancji synchronizatora
Dodaj do pliku org-env/config.yaml
tę konfigurację:
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 Twoja instancja Redis. Domyślnie: 127.0.0.1 |
redisPort |
Port instancji Redis. Domyślnie: 6379 |
redisDb |
Baza danych Redis, która ma zostać użyta. Domyślnie: 0 |
redisPassword |
Hasło do bazy danych. |
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
Gdy synchronizator jest uruchomiony, możesz skonfigurować dodatkowe węzły Edge Microgateway aby uruchamiać zwykłe instancje mikrobram, które przetwarzają ruch przez serwer proxy interfejsów API. Musisz jednak skonfigurować aby te instancje pobierały dane konfiguracyjne z bazy danych Redis, a nie z Apigee Edge
Dodaj poniższą konfigurację do każdego dodatkowego węzła Edge Microgateway
org-env/config.yaml
. Pamiętaj, że w polu synchronizerMode
jest ustawiona na 0
. Ta właściwość powoduje, że instancja funkcjonuje w zwykły sposób.
instancję Edge Microgateway, która przetwarza ruch serwera proxy interfejsów API, przez co instancja uzyska
jego danych konfiguracyjnych 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
Poniższe właściwości konfiguracji zostały dodane w celu obsługi synchronizatora:
Atrybut | Wartości | Opis |
---|---|---|
edge_config.synchronizerMode |
0 lub 1 | Jeśli wartość domyślna to 0, Edge Microgateway działa w trybie standardowym. Jeśli wartość wynosi 1, uruchom instancję Edge Microgateway, aby działać jako synchronizator. W tym w trybie działania instancji będzie pobierać dane konfiguracyjne z Apigee Edge i przechowywać je w w lokalnej bazie danych Redis. Ta instancja nie może przetwarzać żądań serwera proxy interfejsu API. jej jedynym celem jest sondowanie Apigee Edge pod kątem danych konfiguracyjnych i zapisanie ich w lokalnym w bazie danych. Musisz następnie skonfigurować inne instancje mikrobramek do odczytu z bazy danych. |
edge_config.redisBasedConfigCache |
prawda lub fałsz | Jeśli ma wartość prawda, instancja Edge Microgateway pobiera swoje dane konfiguracyjne z
Baza danych Redis, a nie Apigee Edge. Baza danych Redis musi być tą samą
w którym synchronizator jest skonfigurowany do zapisywania. Jeśli baza danych Redis jest niedostępna lub
jeśli baza danych jest pusta, mikrobrama szuka istniejącego obiektu cache-config.yaml
jego konfiguracji.
Jeśli ma wartość fałsz (wartość domyślna), instancja Edge Microgateway pobiera dane konfiguracyjne z Apigee Edge jak zwykle. |
edgemicro.config_change_poll_interval |
Przedział czasu w sekundach | Określa interwał sondowania, po którym synchronizator ma pobierać dane z Apigee Edge. |
Konfigurowanie wykluczonych adresów URL dla wtyczek
Możesz skonfigurować mikrobramę tak, aby pomijała przetwarzanie wtyczek określonych adresów URL. Możesz skonfigurować „wykluczanie” Adresy URL globalnie (dla wszystkich wtyczek) lub 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 z użyciem
ścieżki /hello
lub /proxy_one
. Ponadto json2xml
wtyczka zostanie pominięta w przypadku interfejsów API, w których ścieżka ma /hello/xml
.
Ustawianie atrybutów konfiguracji z wartościami zmiennych środowiskowych
Zmienne środowiskowe możesz określić za pomocą tagów w konfiguracji . Podane tagi zmiennych środowiskowych są zastępowane rzeczywistym środowiskiem. wartości zmiennych. Zamiany są przechowywane tylko w pamięci, a nie w oryginalnej plików konfiguracji i pamięci podręcznej.
W tym przykładzie atrybut key
został zastąpiony wartością atrybutu
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 do wskazywania liczby całkowitej służy tag <n>
. Tylko pozytywne
liczby całkowite są obsługiwane.
edgemicro: port: <E><n>EMG_PORT</n></E>
W tym przykładzie tag <b>
służy do wskazywania wartości logicznej (
czyli prawda lub
false).
quotas: useRedis: <E><b>EMG_USE_REDIS</b></E>