Dokumentacja operacji i konfiguracji Edge Microgateway

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Edge Microgateway wer. 2.5.x

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

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

1. Aby uaktualnić Edge do najnowszej wersji, wykonaj to polecenie npm Mikrobrama:

   npm upgrade edgemicro -g

   Aby przejść na określoną wersję Edge Microgateway, musisz podać wersję number (numer) w poleceniu uaktualniania. Jeśli nie podasz numeru wersji, zostanie zainstalowana najnowsza wersja. Aby na przykład uaktualnić go do wersji 2.5.26, skorzystaj z to polecenie:

   npm upgrade edgemicro@2.5.26 -g

2. Sprawdź numer wersji. Jeśli na przykład masz zainstalowaną wersję 2.5.26:

   edgemicro --version
   current nodejs version is v8.9.0
   current edgemicro version is 2.5.26
       

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

   edgemicro upgradeauth -o org_name -e env_name -u username

Wprowadzanie zmian w konfiguracji

Pliki konfiguracji, 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 init
edgemicro 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 stop
edgemicro 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):

1. Załaduj ponownie konfigurację Edge Microgateway:

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

   Gdzie:

   • org_name to nazwa Twojej organizacji Edge (musisz być organizacją) administratora).
   • env_name 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:

1. Ponowne uruchamianie Edge Microgateway:

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

   Gdzie:

   • org_name to nazwa Twojej organizacji Edge (musisz być organizacją) administratora).
   • env_name 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

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:

1. Wygeneruj lub uzyskaj certyfikat i klucz SSL przy użyciu narzędzia openssl lub dowolnej innej metody.
2. 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

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

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 .

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

Oto lista wszystkich obsługiwanych opcji klientów:

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

Możesz ustawić te poziomy rejestrowania: informacje, ostrzeżenie i . Zalecany jest poziom informacyjny. Rejestruje wszystkie żądania i odpowiedzi do interfejsu API, i jest to ustawienie domyślne.

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

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 3 typy plików logów:

• api – rejestruje wszystkie żądania i odpowiedzi, które przechodzą przez Edge. Mikrobrama. W tym pliku są również rejestrowane liczniki zdarzeń (statystyk) i błędy interfejsu API.
• err – rejestruje wszystkie dane wysłane do stderr.
• out – rejestruje wszystkie dane wysłane do stdout.

Oto konwencja nazewnictwa:

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

Na przykład:

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

Informacje o zawartości pliku dziennika

Dodano w wersji 2.3.3

Domyślnie usługa logowania pomija kod JSON pobranych serwerów proxy, produktów i pliku JSON Token internetowy (JWT). Jeśli chcesz przesłać te obiekty do plików dziennika, ustaw atrybut 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 – zależy od kontekstu. Może to być informacja, ostrzeżenie lub błąd, w zależności od poziomu logowania. Może to być statystyka jako statystyka, ostrzeżenie przed ostrzeżeniami lub dla błędów.
• 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 – zależy od kontekstu. Może to być informacja, ostrzeżenie lub błąd, w zależności od poziomu logowania. Może to być statystyka jako statystyka, ostrzeżenie przed ostrzeżeniami lub dla błędów.
• 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 – zależy od kontekstu. Może to być informacja, ostrzeżenie lub błąd, w zależności od poziomu logowania. Może to być statystyka jako statystyka, ostrzeżenie przed ostrzeżeniami lub dla błędów.
• 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 – zależy od kontekstu. Może to być informacja, ostrzeżenie lub błąd, w zależności od poziomu logowania. Może to być statystyka jako statystyka, ostrzeżenie przed ostrzeżeniami lub dla błędów.
• 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.

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 – rejestruje wszystkie żądania i odpowiedzi, które przechodzą przez Instancja Edge Microgateway.
    • warn – rejestruje tylko komunikaty ostrzegawcze.
    • error (błąd) – rejestrowane są tylko komunikaty o błędach.
  • 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.

• 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)

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:

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

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 jako edgemicro_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 flagi proxyPath.
• 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 jako edgemicro_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

Obsługiwana wersja 2.4.x

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

Opcja 1.

Pierwszą opcją jest ustawienie opcji Edgemicro: proxy_tunnel na true (prawda) w kluczu plik konfiguracyjny microgateway:

edge_config:

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

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

Opcja 2:

Drugą opcją jest określenie serwera proxy i ustawienie serwera proxy_tunnel na false w polu . Na przykład:

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

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

Możesz ustawić NO_PROXY jako rozdzieloną przecinkami listę domen, które Edge Mikrogateway nie powinno korzystać z serwera proxy. Na przykład:

export NO_PROXY='localhost,localhost:8080'

Ustaw HTTP_PROXY i HTTPS_PROXY jako serwer proxy HTTP. Punkt końcowy Edge Microgateway może wysyłać do niego wiadomości. Na przykład:

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

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

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

Zobacz też

Jak skonfigurować Edge Microgateway za firmową zaporą sieciową w społeczności Apigee.

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

Edge Microgateway używa tokenów JWT jako tokenów okaziciela, aby zapewnić bezpieczeństwo OAuth. Gdy generujesz token OAuth dla Edge Microgateway, otrzymasz z powrotem token JWT. Następnie możesz używać tokena JWT w Nagłówek autoryzacji wywołań interfejsu API. Na przykład:

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

Generowanie nowego tokena JWT

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

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

To polecenie prosi Apigee Edge o wygenerowanie tokena JWT, którego można potem użyć do zweryfikowania interfejsu API połączeń. Parametry -i i -s to identyfikator klienta i wartości klucza tajnego z aplikacji dewelopera w organizacji Apigee Edge.

Token JWT możesz też wygenerować za pomocą interfejsu API do zarządzania:

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

Gdzie:

• org to nazwa Twojej organizacji Edge (musisz być jej administratorem).
• env to środowisko w Twojej organizacji (np. „test” lub „prod”).
• client_id to identyfikator klienta w utworzonej wcześniej aplikacji dewelopera.
• client_secret to tajny klucz klienta w utworzonej przez Ciebie aplikacji związanej z programistą wcześniej.

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 i weryfikacja się nie powiedzie, używany będzie stary klucz publiczny, aż do utraty ważności (po 30 minutach). 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.

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

Jeśli instancja Edge Microgateway została skonfigurowana w wersji wcześniejszej niż 2.5.2, musisz uruchomić następujące 2 polecenia do uaktualnienia KVM i zasady uwierzytelniania:

upgradekvm -o org -e env -u username

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

Następne polecenie uaktualnia serwer proxy edgemicro-oauth, który został wdrożony w Twojej organizacji Apigee po skonfigurowaniu Edge Microgateway. Ten serwer proxy zapewnia usługi wymagane do generowania tokenów.

upgradeauth -o org -e env -u username

Więcej informacji o tym poleceniu znajdziesz w sekcji Uaktualnianie Edgemicro-auth proxy.

Rotacja kluczy

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. Więcej informacji o tym poleceniu znajdziesz w Klawisze rotacyjne).

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

Na przykład:

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

Parametr -k określa identyfikator klucza (kid). Służy on do dopasowania do konkretnego klucza. Edge Microgateway używa tej wartości do wybierania spośród zbioru kluczy podczas rotacji kluczy. Więcej informacji można znaleźć w sekcji 4.5 Specyfikacja klucza internetowego JSON.

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

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.

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

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

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

2. Uruchom debuger i ustaw go tak, aby nasłuchiwał na numerze portu w trakcie procesu debugowania.
3. 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.

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

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

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

Przykładowe dane wyjściowe

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

Jak uzyskać token odświeżania

Aby uzyskać token odświeżania, wywołaj interfejs API 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.

1. Uzyskiwanie tokena dostępu i odświeżanie go 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: to:

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

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

Forever to narzędzie Node.js, które automatycznie uruchamia ponownie aplikację Node.js w przypadku awarii procesu lub błędu. Krawędź Microgateway ma plik forever.json, który możesz skonfigurować, aby kontrolować liczbę oraz w jakich odstępach czasu ma być uruchamiany ponownie Edge Microgateway. Ten plik konfiguruje Usługa bezterminowa o nazwie monitorowanie na zawsze, która zarządza bezterminowo automatycznie.

Plik forever.json znajdziesz w głównej instalacji Edge Microgateway. katalogu. Zobacz Gdzie jest zainstalowana Edge Microgateway. Szczegółowe informacje o opcjach konfiguracji znajdziesz tutaj: dokumentacji dotyczącej ciągłego monitorowania.

Polecenie edgemicro forever zawiera flagi, które umożliwiają określenie lokalizacji plik forever.json (flaga -f) i uruchomić/zatrzymać monitorowanie bezterminowe; (flaga -a). Na przykład:

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

Więcej informacji znajdziesz w artykule na temat ciągłego monitorowania w dokumentacji interfejsu wiersza poleceń.

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:

1. Upewnij się, że masz zainstalowaną usługę Edge Microgateway w wersji 2.5.25 lub nowszej. Jeśli nie, musisz wykonaj to polecenie, by uaktualnić go do najnowszej wersji:

   npm install -g edgemicro

   Jeśli potrzebujesz pomocy, zobacz Instalowanie Edge Microgateway.

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

   Na przykład:

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

3. Wklej do pliku ten kod:

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

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

   export EDGEMICRO_LOCAL=1

5. Wykonaj podane niżej polecenie start, podając w nim wartości do utworzenia instancji lokalny serwer proxy:

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

   Gdzie:

   • your_org to „organizacja” użytą w nazwie pliku konfiguracji.
   • Parametr your_environment 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 /

6. Przetestuj konfigurację.

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

   Wtyczka extauth znajduje się w pliku foo-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:

1. 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ć.
2. 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.
3. Zatrzymywanie Edge Microgateway:

   edgemicro stop

4. W utworzonym wcześniej pliku konfiguracji ($HOME/.edgemicro/org–env-config.yaml): Wskaż extauth:publickey_url do punktu końcowego edgemicro-auth/jwkPublicKeys w organizacji/środowisku Apigee Edge. Na przykład:

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

5. 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 /

6. 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 proxy edgemicro-auth.
• Opcja s określa tajny klucz klienta z aplikacji dewelopera, która ma atrybut produkt zawierający serwer proxy edgemicro-auth.

To polecenie prosi Apigee Edge o wygenerowanie tokena JWT, którego można potem użyć do zweryfikowania interfejsu API połączeń.

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:

1. Upewnij się, że masz zainstalowaną usługę Edge Microgateway w wersji 2.5.25 lub nowszej. Jeśli nie, musisz wykonaj to polecenie, by uaktualnić go do najnowszej wersji:

   npm install -g edgemicro

   Jeśli potrzebujesz pomocy, zobacz Instalowanie Edge Microgateway.

2. Uruchom edgemicro init, aby dokładnie skonfigurować lokalne środowisko konfiguracji tak jak w typowej konfiguracji Edge Microgateway. Zobacz też Skonfiguruj Edge Microgateway.
3. 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.

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

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

6. 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.
7. Na komputerze, na którym zainstalowano Edge Microgateway, wyeksportuj następujące dane: zmienną środowiskową o wartości „1”.

   export EDGEMICRO_LOCAL_PROXY=1

8. Uruchom to polecenie start:

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

   Gdzie:

   • your_org to Twoja organizacja Apigee.
   • your_environment to środowisko w Twojej organizacji.
   • your_key to klucz zwrócony 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":""
}