Dokumentacja operacji i konfiguracji Edge Microgateway

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X.
Informacje

Edge Microgateway wersja 3.3.x

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

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

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

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

  1. Wykonaj to polecenie npm, aby uaktualnić Edge Microgateway do najnowszej wersji:
    npm upgrade edgemicro -g

    Aby zainstalować konkretną wersję Edge Microgateway, musisz w poleceniu instalacji podać numer wersji. Aby na przykład zainstalować ją w wersji 3.2.3, użyj tego polecenia:

    npm install edgemicro@3.2.3 -g
  2. 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
        
  3. Na koniec zaktualizuj serwer proxy edgemicro-auth do najnowszej wersji:
    edgemicro upgradeauth -o $ORG -e $ENV -u $USERNAME

Wprowadzanie zmian w konfiguracji

Pliki konfiguracji, które musisz znać, zawierają:

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

W tej sekcji omawiamy te pliki oraz informacje o tym, co musisz wiedzieć o ich przekształcaniu.

Domyślny plik konfiguracji systemu

Gdy instalujesz Edge Microgateway, w tym miejscu znajduje się domyślny plik konfiguracji systemu:

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

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

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

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

Domyślny plik konfiguracji dla nowo zainicjowanych instancji Edge Microgateway

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

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

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

Dynamiczny plik konfiguracji do uruchamiania instancji

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

Jeśli Edge Microgateway jest uruchomiona (opcja zerowa przestoju):

  1. Załaduj ponownie konfigurację Edge Microgateway:
    edgemicro reload -o $ORG -e $ENV -k $KEY -s $SECRET

    Gdzie:

    • $ORG to nazwa organizacji Edge (musisz być jej administratorem).
    • $ENV to środowisko w Twojej organizacji (np. „test” lub „prod”).
    • $KEY to klucz zwrócony wcześniej przez polecenie konfiguracji.
    • $SECRET to klucz zwrócony wcześniej przez polecenie konfiguracji.

    Przykład

    edgemicro reload -o docs -e test -k 701e70ee718ce6dc188...78b6181d000723 \
      -s 05c14356e42ed1...4e34ab0cc824

Jeśli Edge Microgateway jest zatrzymana:

  1. Ponownie uruchom Edge Microgateway:
    edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET

    Gdzie:

    • $ORG to nazwa organizacji Edge (musisz być jej administratorem).
    • $ENV to środowisko w Twojej organizacji (np. „test” lub „prod”).
    • $KEY to klucz zwrócony wcześniej przez polecenie konfiguracji.
    • $SECRET to klucz zwrócony wcześniej przez polecenie konfiguracji.

    Na przykład:

    edgemicro start -o docs -e test -k 701e70ee718ce...b6181d000723 \
      -s 05c1435...e34ab0cc824

Oto przykładowy plik konfiguracyjny. Szczegółowe informacje o ustawieniach pliku konfiguracji znajdziesz w dokumentacji konfiguracji Edge Microgateway (w języku angielskim).

edge_config:
  bootstrap: >-
    https://edgemicroservices-us-east-1.apigee.net/edgemicro/bootstrap/organization/docs/environment/test
  jwt_public_key: 'https://docs-test.apigee.net/edgemicro-auth/publicKey'
  managementUri: 'https://api.enterprise.apigee.com'
  vaultName: microgateway
  authUri: 'https://%s-%s.apigee.net/edgemicro-auth'
  baseUri: >-
    https://edgemicroservices.apigee.net/edgemicro/%s/organization/%s/environment/%s
  bootstrapMessage: Please copy the following property to the edge micro agent config
  keySecretMessage: The following credentials are required to start edge micro
  products: 'https://docs-test.apigee.net/edgemicro-auth/products'
edgemicro:
  port: 8000
  max_connections: 1000
  max_connections_hard: 5000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - oauth
headers:
  x-forwarded-for: true
  x-forwarded-host: true
  x-request-id: true
  x-response-time: true
  via: true
oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  verify_api_key_url: 'https://docs-test.apigee.net/edgemicro-auth/verifyApiKey'
analytics:
  uri: >-
    https://edgemicroservices-us-east-1.apigee.net/edgemicro/axpublisher/organization/docs/environment/test

Ustawianie zmiennych środowiskowych

Polecenia interfejsu wiersza poleceń, które wymagają wartości dla organizacji i środowiska Edge, oraz klucz i obiekt tajny potrzebne do uruchomienia Edge Microgateway, mogą być przechowywane w tych zmiennych środowiskowych:

  • EDGEMICRO_ORG
  • EDGEMICRO_ENV
  • EDGEMICRO_KEY
  • EDGEMICRO_SECRET

Ustawianie tych zmiennych jest opcjonalne. Jeśli je ustawisz, nie musisz określać ich wartości podczas konfigurowania i uruchamiania Edge Microgateway za pomocą interfejsu wiersza poleceń.

Konfigurowanie SSL na serwerze Edge Microgateway

Obejrzyj te filmy, aby dowiedzieć się więcej o konfigurowaniu TLS w Apigee Edge Microgateway:

Wideo Opis
Konfigurowanie jednokierunkowego protokołu TLS w kierunku północnym Dowiedz się więcej o konfigurowaniu TLS w Apigee Edge Microgateway. W tym filmie omawiamy protokół TLS i jego znaczenie, omawiamy protokół TLS w Microsoft Edge Microgateway i pokazujemy, jak skonfigurować jednokierunkowy protokół TLS w kierunku północnym.
Konfigurowanie dwukierunkowego protokołu TLS w kierunku północnym To drugi film na temat konfigurowania TLS w Apigee Edge Microgateway. Z tego filmu dowiesz się, jak skonfigurować dwukierunkowy protokół TLS skierowany na północ.
Konfigurowanie jednokierunkowego i dwukierunkowego protokołu TLS w południowej części Trzeci film na temat konfigurowania protokołu TLS w Apigee Edge Microgateway wyjaśnia, jak skonfigurować jedno- i dwukierunkową komunikację TLS w kierunku południowym.

Możesz skonfigurować serwer Microgateway, aby używał SSL. Na przykład po skonfigurowaniu SSL możesz wywoływać interfejsy API przez Edge Microgateway, korzystając z protokołu „https” w ten 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 preferowanej metody.
  2. Dodaj atrybut edgemicro:ssl do pliku konfiguracji Edge Microgateway. Pełną listę opcji znajdziesz w poniższej tabeli. Na przykład:
    edgemicro:
      ssl:
       key: <absolute path to the SSL key file>
       cert: <absolute path to the SSL cert file>
       passphrase: admin123 #option added in v2.2.2
       rejectUnauthorized: true #option added in v2.2.2
       requestCert: true
  3. Ponownie uruchom Edge Microgateway. Wykonaj czynności opisane w sekcji Wprowadzanie zmian w konfiguracji w zależności od tego, który plik konfiguracji został zmieniony: plik domyślny lub plik konfiguracji środowiska wykonawczego.

Oto przykład sekcji edgemicro pliku konfiguracyjnego ze skonfigurowanym protokołem SSL:

edgemicro:
  port: 8000
  max_connections: 1000
  max_connections_hard: 5000
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - oauth
  ssl:
    key: /MyHome/SSL/em-ssl-keys/server.key
    cert: /MyHome/SSL/em-ssl-keys/server.crt
    passphrase: admin123 #option added in v2.2.2
    rejectUnauthorized: true #option added in v2.2.2

Oto lista wszystkich obsługiwanych opcji serwera:

Option Opis
key Ścieżka do pliku ca.key (w formacie PEM).
cert Ścieżka do pliku ca.cert (w formacie PEM).
pfx Ścieżka do pliku pfx zawierającego klucz prywatny, certyfikat i certyfikaty urzędów certyfikacji klienta w formacie PFX.
passphrase Ciąg znaków zawierający hasło klucza prywatnego lub pliku PFX.
ca Ścieżka do pliku zawierającego listę zaufanych certyfikatów w formacie PEM.
ciphers Ciąg tekstowy opisujący mechanizmy szyfrowania, których należy użyć, oddzielony znakiem „:”.
rejectUnauthorized Jeśli ma wartość true (prawda), certyfikat serwera jest weryfikowany pod kątem listy urzędów certyfikacji. Jeśli weryfikacja się nie powiedzie, zostanie zwrócony błąd.
secureProtocol Metoda SSL, której chcesz użyć. Przykładem może być SSLv3_method, aby wymuszać protokół SSL do wersji 3.
servername Nazwa serwera dla rozszerzenia TLS SNI (Server Name Indication).
requestCert Wartość true dla dwukierunkowego protokołu SSL; false dla jednokierunkowego protokołu SSL

Korzystanie z opcji SSL/TLS klienta

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

W tym przykładzie przedstawiono ustawienia, które zostaną zastosowane do wszystkich hostów:

edgemicro:
...
targets:
  ssl:
    client:
      key: /Users/jdoe/nodecellar/twowayssl/ssl/client.key
      cert: /Users/jdoe/nodecellar/twowayssl/ssl/ca.crt
      passphrase: admin123
      rejectUnauthorized: true

W tym przykładzie ustawienia zostały zastosowane tylko do określonego hosta:

edgemicro:
...
targets:
  - host: 'myserver.example.com'
    ssl:
      client:
        key: /Users/myname/twowayssl/ssl/client.key
        cert: /Users/myname/twowayssl/ssl/ca.crt
        passphrase: admin123
        rejectUnauthorized: true

Oto przykład z protokołem TLS:

edgemicro:
...
targets:
  - host: 'myserver.example.com'
    tls:
      client:
        pfx: /Users/myname/twowayssl/ssl/client.pfx
        passphrase: admin123
        rejectUnauthorized: true

Jeżeli chcesz zastosować ustawienia TLS/SSL do wielu konkretnych celów, musisz określić pierwszego hosta w konfiguracji jako „pusty”, co umożliwia stosowanie żądań uniwersalnych, a następnie określić konkretne hosty w dowolnej kolejności. W tym przykładzie ustawienia zostały zastosowane do wielu konkretnych hostów:

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

Oto lista wszystkich obsługiwanych opcji klienckich:

Option Opis
pfx Ścieżka do pliku pfx zawierającego klucz prywatny, certyfikat i certyfikaty urzędów certyfikacji klienta w formacie PFX.
key Ścieżka do pliku ca.key (w formacie PEM).
passphrase Ciąg znaków zawierający hasło klucza prywatnego lub pliku PFX.
cert Ścieżka do pliku ca.cert (w formacie PEM).
ca Ścieżka do pliku zawierającego listę zaufanych certyfikatów w formacie PEM.
ciphers Ciąg tekstowy opisujący mechanizmy szyfrowania, których należy użyć, oddzielony znakiem „:”.
rejectUnauthorized Jeśli ma wartość true (prawda), certyfikat serwera jest weryfikowany pod kątem listy urzędów certyfikacji. Jeśli weryfikacja się nie powiedzie, zostanie zwrócony błąd.
secureProtocol Metoda SSL, której chcesz użyć. Przykładem może być SSLv3_method, aby wymuszać protokół SSL do wersji 3.
servername Nazwa serwera dla rozszerzenia TLS SNI (Server Name Indication).

Dostosowywanie serwera proxy uwierzytelniania Edgemicro

Domyślnie Edge Microgateway używa serwera proxy wdrożonego w Apigee Edge do uwierzytelniania OAuth2. Ten serwer proxy jest wdrażany przy pierwszym uruchomieniu przeglądarki edgemicro configure. Możesz zmienić domyślną konfigurację tego serwera proxy, aby dodać obsługę deklaracji niestandardowych do tokena internetowego JSON (JWT), skonfigurować wygaśnięcie tokena i wygenerować tokeny odświeżania. Szczegółowe informacje znajdziesz na stronie edgemicro-auth w GitHubie.

Korzystanie z niestandardowej usługi uwierzytelniania

Domyślnie Edge Microgateway używa serwera proxy wdrożonego w Apigee Edge do uwierzytelniania OAuth2. Ten serwer proxy jest wdrażany przy pierwszym uruchomieniu przeglądarki edgemicro configure. Domyślnie adres URL tego serwera proxy jest określony w pliku konfiguracyjnym Edge Microgateway w następujący sposób:

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

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

Zarządzanie plikami dziennika

Edge Microgateway loguje informacje o każdym żądaniu i odpowiedzi. Pliki logów zawierają przydatne informacje podczas debugowania i rozwiązywania problemów.

Miejsce przechowywania plików dziennika

Domyślnie pliki dziennika są przechowywane w usłudze /var/tmp.

Jak zmienić domyślny katalog plików dziennika

Katalog, w którym są przechowywane pliki logów, jest określony w pliku konfiguracji Edge Microgateway. Zobacz też Wprowadzanie zmian w konfiguracji.

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

Zmień wartość dir, aby wskazać inny katalog pliku dziennika.

Wysyłaj logi do konsoli

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

edgemicro:
  logging:
    to_console: true

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

Jak ustawić poziom rejestrowania

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

Na przykład 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ć odstępy w logu

Te odstępy możesz skonfigurować w pliku konfiguracyjnym Edge Microgateway. Zobacz też Wprowadzanie zmian w konfiguracji.

Atrybuty, które można skonfigurować:

  • stats_log_interval: (domyślnie: 60) interwał, w sekundach, podczas którego rekord statystyk jest zapisywany w pliku dziennika interfejsu API.
  • rotate_interval: (domyślnie: 24) interwał, w godzinach, podczas którego rotacja plików dziennika jest rotowana. Na przykład:
edgemicro:
  home: ../gateway
  port: 8000
  max_connections: -1
  max_connections_hard: -1
  logging:
    level: info
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

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

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

Dodano w wersji 3.2.3.

Na przykład:

edgemicro:
 logging:
   disableStrictLogFile: true

Sprawdzone metody konserwacji plików dziennika

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

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

Konwencja nazewnictwa plików dziennika

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

edgemicro-HOST_NAME-INSTANCE_ID-api.log

Na przykład:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log

Zawartość pliku dziennika

Dodano w wersji 2.3.3

Domyślnie usługa logowania pomija plik JSON z pobranymi serwerami proxy, produktami i tokenem sieciowym JSON (JWT). Jeśli chcesz wyświetlać te obiekty w konsoli, podczas uruchamiania Edge Microgateway ustaw flagę wiersza poleceń DEBUG=*. Na przykład:

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

Zawartość pliku dziennika „api”

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

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

W przypadku każdego żądania wysłanego do Edge Microgateway plik dziennika „api” rejestruje 4 zdarzenia:

  • Żądanie przychodzące od klienta
  • Żądanie wychodzące wysłane do środowiska docelowego
  • Odpowiedź przychodząca od środowiska docelowego
  • Odpowiedź wychodząca dla klienta

Każdy z tych wpisów jest ujęty w zapisie skróconym, dzięki czemu pliki logów są bardziej kompaktowe. Oto 4 przykładowe wpisy reprezentujące każde z 4 zdarzeń. W pliku dziennika wyglądają one tak (numery wierszy służą tylko do celów referencyjnych w dokumencie, nie występują 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

Omówmy je kolejno:

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

1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0
  • 1436403888651 – znacznik daty uniksowej
  • info – poziom logowania. Ta wartość zależy od kontekstu transakcji i poziomu logowania określonego w konfiguracji edgemicro. Zobacz artykuł Jak ustawić poziom rejestrowania. Jeśli chodzi o statystyki, poziom jest ustawiony na stats. Rekordy statystyk są raportowane w regularnych odstępach czasu za pomocą konfiguracji stats_log_interval. Zobacz też Jak zmieniać odstępy w logu.
  • req – identyfikuje zdarzenie. W tym przypadku żądanie od klienta.
  • m – czasownik HTTP użyty w żądaniu.
  • u – część adresu URL podążająca za ścieżką bazową.
  • h – host i numer portu, na którym nasłuchuje Edge Microgateway.
  • r – host zdalny i port, z którego wyszło żądanie klienta.
  • i – identyfikator żądania. Wszystkie 4 wpisy dotyczące wydarzenia będą miały ten sam identyfikator. Każde żądanie ma przypisany unikalny identyfikator. Korelowanie rekordów logów według identyfikatora żądania może dostarczyć cennych informacji o czasie oczekiwania celu.
  • d – czas w milisekundach od momentu odebrania żądania przez Edge Microgateway. W powyższym przykładzie odpowiedź obiektu docelowego na żądanie 0 została odebrana po 7 milisekundach (wiersz 3), a odpowiedź do klienta została wysłana do klienta po dodatkowych 4 milisekundach (wiersz 4). Inaczej mówiąc, łączny czas oczekiwania na żądanie wyniósł 11 milisekund, z czego 7 milisekund zostało wykonane przez serwer docelowy i 4 milisekundy przez samą usługę Edge Microgateway.

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

1436403888665 info treq m=GET, u=/, h=127.0.0.1:8080, i=0
  • 1436403888651 – znacznik daty uniksowej
  • info – poziom logowania. Ta wartość zależy od kontekstu transakcji i poziomu logowania określonego w konfiguracji edgemicro. Zobacz artykuł Jak ustawić poziom rejestrowania. Jeśli chodzi o statystyki, poziom jest ustawiony na stats. Rekordy statystyk są raportowane w regularnych odstępach czasu za pomocą konfiguracji stats_log_interval. Zobacz też Jak zmieniać odstępy w logu.
  • treq – identyfikuje zdarzenie. W takim przypadku jest to żądanie docelowe.
  • m – czasownik HTTP użyty w żądaniu docelowym.
  • u – część adresu URL podążająca za ścieżką bazową.
  • h – host i numer portu docelowego backendu.
  • i – identyfikator wpisu logu. Wszystkie 4 wpisy dotyczące wydarzenia będą miały ten sam identyfikator.

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

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

1436403888651 – znacznik daty uniksowej

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

4. Przykładowa odpowiedź wychodząca dla klienta

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

1436403888651 – znacznik daty uniksowej

  • info – poziom logowania. Ta wartość zależy od kontekstu transakcji i poziomu logowania określonego w konfiguracji edgemicro. Zobacz artykuł Jak ustawić poziom rejestrowania. Jeśli chodzi o statystyki, poziom jest ustawiony na stats. Rekordy statystyk są raportowane w regularnych odstępach czasu za pomocą konfiguracji stats_log_interval. Zobacz też Jak zmieniać odstępy w logu.
  • res – identyfikuje zdarzenie. W tym przypadku odpowiedź dla klienta.
  • s – stan odpowiedzi HTTP.
  • d – czas w milisekundach. Jest to łączny czas potrzebny na wywołanie interfejsu API, w tym czas potrzebny na użycie docelowego interfejsu API, a także przez samą Edge Microgateway.
  • i – identyfikator wpisu logu. Wszystkie 4 wpisy dotyczące wydarzenia będą miały ten sam identyfikator.

Harmonogram plików dziennika

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

Komunikaty o błędach

Niektóre wpisy w dzienniku zawierają komunikaty o błędach. Aby dowiedzieć się, gdzie i dlaczego występują błędy, zapoznaj się z informacjami o błędach Edge Microgateway.

Dokumentacja konfiguracji Edge Microgateway

Lokalizacja pliku konfiguracji

Atrybuty konfiguracji opisane w tej sekcji znajdują się w pliku konfiguracji Edge Microgateway. Zobacz też Wprowadzanie zmian w konfiguracji.

atrybuty Edge_config

Te ustawienia służą do konfigurowania interakcji między instancją Edge Microgateway a Apigee Edge.

  • bootstrap: (domyślnie: brak) adres URL wskazujący usługę Edge Microgateway działającą w Apigee Edge. Edge Microgateway korzysta z tej usługi do komunikacji z Apigee Edge. Ten URL jest zwracany po wykonaniu polecenia do wygenerowania pary kluczy publicznego/prywatnego: edgemicro genkeys. Więcej informacji znajdziesz w artykule o konfigurowaniu i konfigurowaniu Edge Microgateway.
  • jwt_public_key: (domyślnie: brak) URL wskazujący serwer proxy Edge Microgateway wdrożony w Apigee Edge. Ten serwer proxy służy jako punkt końcowy uwierzytelniania przy wystawianiu podpisanych tokenów dostępu klientom. Ten adres URL jest zwracany po wykonaniu polecenia wdrożenia serwera proxy: edgemicro configure. Więcej informacji znajdziesz w artykule o konfigurowaniu i konfigurowaniu Edge Microgateway.
  • quotaUri: ustaw tę właściwość konfiguracji, jeśli chcesz zarządzać limitami przez serwer proxy edgemicro-auth wdrożony w organizacji. Jeśli ta właściwość nie jest ustawiona, domyślnie punkt końcowy limitu to wewnętrzny punkt końcowy Edge Microgateway.
    edge_config:
      quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
    

atrybuty Edgemicro

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

  • port: (domyślnie: 8000) numer portu, na którym nasłuchuje proces Edge Microgateway.
  • max_connections: (domyślnie: -1) określa maksymalną liczbę jednoczesnych połączeń przychodzących, które może odebrać Edge Microgateway. Jeśli ta liczba zostanie przekroczona, zwracany jest ten stan:

    res.statusCode = 429; // Too many requests
  • max_connections_hard: (domyślnie: -1) maksymalna liczba jednoczesnych żądań, które może otrzymać firma Edge Microgateway przed wyłączeniem połączenia. To ustawienie ma zapobiegać atakom typu DoS. Zwykle należy go ustawić na wartość większą niż max_connections.
  • logging:
    • level: (domyślnie: błąd)
      • info – (zalecane) rejestruje wszystkie żądania i odpowiedzi przechodzące przez instancję Edge Microgateway.
      • warn – rejestrowane są tylko komunikaty ostrzegawcze.
      • error – rejestrowane są tylko komunikaty o błędach.
      • debugowanie – rejestruje komunikaty debugowania wraz z informacjami, ostrzeżeniami i komunikatami o błędach.
      • trace (ślady) – rejestruje informacje z logów czasu pod kątem błędów, a także komunikaty informacyjne, ostrzeżenia i komunikaty o błędach.
      • none (brak) – nie twórz pliku dziennika.
    • dir: (domyślnie: /var/tmp) katalog, w którym są przechowywane pliki dziennika.
    • stats_log_interval: (domyślnie: 60) interwał, w sekundach, podczas którego rekord statystyk jest zapisywany w pliku dziennika interfejsu API.
    • rotate_interval: (domyślnie: 24) interwał, w godzinach, podczas którego rotacja plików dziennika jest rotowana.
  • dir: ścieżka względna z katalogu ./gateway do katalogu ./Wtyczki lub ścieżka bezwzględna.
  • sequence: lista modułów wtyczek, które należy dodać do instancji Edge Microgateway. Moduły będą wykonywane w kolejności, w jakiej zostały tu określone.
  • debugowanie: dodaje debugowanie zdalne do procesu Edge Microgateway.
    • port: numer portu na potrzeby nasłuchiwania. Na przykład ustaw debuger IDE tak, aby nasłuchiwał na tym porcie.
    • args: argumenty procesu debugowania. Na przykład: args --nolazy
  • config_change_poll_interval: (domyślnie: 600 sekund) Edge Microgateway okresowo wczytuje nową konfigurację i uruchamia ponowne załadowanie, jeśli coś się zmieni. Odpytywanie wykrywa wszystkie zmiany wprowadzone w Edge (zmiany usług, serwerów proxy rozpoznających mikrobramy itp.), a także zmiany wprowadzone w lokalnym pliku konfiguracji.
  • disable_config_poll_interval: (domyślnie: fałsz) ustaw wartość true, aby wyłączyć automatyczne odpytywanie zmian.
  • request_timeout: określa czas oczekiwania dla żądań docelowych. Limit czasu jest ustawiany w sekundach. W przypadku przekroczenia limitu czasu Edge Microgateway wysyła kod stanu 504. (Dodano wersję 2.4.x)
  • keep_alive_timeout: ta właściwość umożliwia ustawienie czasu oczekiwania na Edge Microgateway (w milisekundach). (Domyślnie: 5 sekund) (Dodano wersję 3.0.6)
  • headers_timeout: ten atrybut ogranicza czas (w milisekundach), przez jaki parser HTTP będzie czekać na otrzymanie pełnych nagłówków HTTP.

    Na przykład:

    edgemicro:
      keep_alive_timeout: 6000
      headers_timeout: 12000

    Wewnętrznie parametr ten ustawia w żądaniach atrybut Node.js Server.headersTimeout. (Domyślnie: o 5 sekund dłużej niż czas ustawiony w polu edgemicro.keep_alive_timeout). To ustawienie domyślne zapobiega omyłkowemu zerwaniu połączenia przez systemy równoważenia obciążenia i serwery proxy. (Dodana wersja 3.1.1)

  • noRuleMatchAction: (ciąg znaków) działanie, jakie należy podjąć (zezwolenie na dostęp lub odmowa dostępu), jeśli reguła dopasowania określona we wtyczce accesscontrol nie zostanie rozpoznana (jest niedopasowana). Prawidłowe wartości: ALLOW lub DENY Domyślne: ALLOW (dodane: wersja 3.1.7)
  • enableAnalytics: (domyślnie: true) ustaw wartość atrybutu na false, aby uniemożliwić wczytanie wtyczki Analytics. W takim przypadku żadne wywołania analityki Apigee Edge nie zostaną wykonane. Jeśli ma wartość true lub nie jest określony, wtyczka analytics będzie działać w zwykły sposób. Więcej informacji znajdziesz w sekcji o atrybutach Edgemicro. (Dodano wersję 3.1.8).

    Przykład:

    edgemicro
      enableAnalytics=false|true
  • on_target_response_abort: ten atrybut pozwala kontrolować zachowanie Edge Microgateway w przypadku przedwczesnego zamknięcia połączenia między klientem (Edge Microgateway) a serwerem docelowym.
    Wartość Opis
    Domyślne Jeśli właściwość on_target_response_abort nie jest określona, domyślnym działaniem jest skrócenie odpowiedzi bez wyświetlania błędu. W plikach logów wyświetla się komunikat ostrzegawczy z targetResponse aborted i kodem odpowiedzi 502.
    appendErrorToClientResponseBody Niestandardowy błąd TargetResponseAborted jest zwracany klientowi. W plikach logów wyświetla się komunikat ostrzegawczy z targetResponse aborted i kodem odpowiedzi 502. Dodatkowo błąd TargetResponseAborted jest logowany z komunikatem Target response ended prematurely.
    abortClientRequest Edge Microgateway przerywa żądanie i w plikach logu pojawia się ostrzeżenie: TargetResponseAborted z kodem stanu żądania 502.

Przykład:

edgemicro:
 on_target_response_abort: appendErrorToClientResponseBody | abortClientRequest

atrybuty nagłówków

Te ustawienia określają sposób obsługi określonych nagłówków HTTP.

  • x-forwarded-for: (default: true) ustaw na „false” (fałsz), aby uniemożliwić przekazywanie nagłówków do elementu docelowego (x-forwarded-for). Pamiętaj, że jeśli w żądaniu znajduje się nagłówek x-forwarded-for, jego wartość zostanie ustawiona na wartość client-ip w Edge Analytics.
  • x-forwarded-host: (domyślnie: true) ustaw wartość false, by uniemożliwić przesyłanie nagłówków x-forwarded-host do środowiska docelowego.
  • x-request-id: (domyślnie: true) ustaw na „false”, by uniemożliwić przesyłanie nagłówków x-request-id do elementu docelowego.
  • x-response-time: (domyślnie: prawda) ustaw na „false” (fałsz), aby uniemożliwić przekazywanie nagłówków x-response-time do elementu docelowego.
  • via: (default: true) ustaw na wartość false, aby uniemożliwić przesyłanie nagłówków do elementu docelowego.

atrybuty OAuth

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

  • allowNoAuthorization: (domyślnie: false) jeśli zasada ma wartość prawda, wywołania interfejsu API mogą przechodzić przez Edge Microgateway bez nagłówka Authorization. Ustaw tę wartość na false, aby wymagać nagłówka autoryzacji (domyślnie).
  • allowInvalidAuthorization: (domyślnie: false) jeśli zasada ma wartość true (prawda), wywołania interfejsu API mogą być przekazywane, gdy token przekazany w nagłówku autoryzacji jest nieprawidłowy lub wygasł. Ustaw tę wartość na false, aby wymagać prawidłowych tokenów (domyślnie).
  • authorization-header: (domyślnie: Authorization: Bearer) nagłówek używany do wysłania tokena dostępu do Edge Microgateway. Możesz zmienić wartość domyślną, jeśli cel musi używać nagłówka autoryzacji w innym celu.
  • api-key-header: (domyślnie: x-api-key) nazwa nagłówka lub parametru zapytania używanego do przekazania klucza interfejsu API do Edge Microgateway. Zapoznaj się też z informacjami o używaniu klucza interfejsu API.
  • keep-authorization-header: (domyślnie: fałsz) Jeśli ma wartość Prawda, nagłówek autoryzacji wysłany w żądaniu jest przekazywany do elementu docelowego (zachowywany).
  • allowOAuthOnly – jeśli zasada ma wartość prawda, każdy interfejs API musi mieć nagłówek autoryzacji z tokenem dostępu okaziciela. Pozwala zezwolić tylko na model zabezpieczeń OAuth (przy zachowaniu zgodności wstecznej). (Dodano wersję 2.4.x)
  • allowAPIKeyOnly – jeśli ma wartość Prawda, każdy interfejs API musi mieć nagłówek x-api-key (lub niestandardową lokalizację) z kluczem interfejsu API.Pozwala na zezwolenie tylko na model zabezpieczeń klucza interfejsu API (przy zachowaniu zgodności wstecznej). (Dodano 2.4.x)
  • gracePeriod – ten parametr zapobiega błędom powodowanym przez niewielkie rozbieżności między zegarem systemowym a czasem not before (nbf) lub Issued At (iat) określonym w tokenie autoryzacji JWT. Aby umożliwić wystąpienie takich rozbieżności, ustaw w tym parametrze liczbę sekund. (Dodano 2.5.7)

Atrybuty konkretnych wtyczek

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

Filtrowanie serwerów proxy

Możesz przefiltrować serwery proxy rozpoznające mikrobramy, które będzie przetwarzać instancja Edge Microgateway. Po uruchomieniu Edge Microgateway pobiera wszystkie rozpoznające mikrobramy w organizacji, z którą jest powiązana. Użyj tej konfiguracji, aby ograniczyć serwery proxy przetwarzane przez mikrobramę. Na przykład ta konfiguracja ogranicza serwery proxy, które będzie przetwarzać mikrobrama: 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, które Edge Microgateway pobiera i przetwarza. Aby przefiltrować pobrane produkty, dodaj parametr zapytania productnamefilter do interfejsu API /products wymienionego w pliku Edge Microgateway *.config.yaml. Na przykład:

edge_config:
  bootstrap: >-
    https://edgemicroservices.apigee.net/edgemicro/bootstrap/organization/willwitman/environment/test
  jwt_public_key: 'https://myorg-test.apigee.net/edgemicro-auth/publicKey'
  managementUri: 'https://api.enterprise.apigee.com'
  vaultName: microgateway
  authUri: 'https://%s-%s.apigee.net/edgemicro-auth'
  baseUri: >-
    https://edgemicroservices.apigee.net/edgemicro/%s/organization/%s/environment/%s
  bootstrapMessage: Please copy the following property to the edge micro agent config
  keySecretMessage: The following credentials are required to start edge micro
  products: 'https://myorg-test.apigee.net/edgemicro-auth/products?productnamefilter=%5E%5BEe%5Ddgemicro.%2A%24'

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

Te wyniki 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:

  1. W interfejsie użytkownika Edge wybierz serwer proxy edgemicro_auth w organizacji lub środowisku, w którym skonfigurowano Edge Microgateway.
  2. W sekcji Programowanie otwórz w edytorze zasadę JavaCallout.
  3. Dodaj atrybut niestandardowy z kluczem products.filter.attributes i listą nazw atrybutów rozdzielonych przecinkami. Do Edge Microgateway będą zwracane tylko produkty, które zawierają jakiekolwiek nazwy atrybutów niestandardowych.
  4. Możesz opcjonalnie wyłączyć sprawdzanie, czy usługa jest włączona w bieżącym środowisku, ustawiając atrybut niestandardowy products.filter.env.enable na false. (Wartość domyślna to true (prawda).
  5. (Tylko chmura prywatna) Jeśli używasz Edge dla chmury prywatnej, ustaw właściwość org.noncps na true, aby pobierać usługi dla środowisk bez CPS.
  6. 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>
    

Konfiguruję częstotliwość przekazywania danych w Analytics

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

  • bufferSize (opcjonalnie): maksymalna liczba rekordów Analytics, które może przechowywać bufor, zanim zacznie się usuwać najstarsze rekordy. Domyślnie: 10 000.
  • batchSize (opcjonalnie): maksymalny rozmiar wsadu rekordów analitycznych wysyłanych do Apigee. Domyślnie: 500.
  • flushInterval (opcjonalnie): liczba milisekund między każdym usunięciem grupy rekordów analitycznych wysłanych do Apigee. Domyślnie: 5000

Na przykład:

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

Maskowanie danych analitycznych

Ta konfiguracja uniemożliwia wyświetlanie informacji o ścieżce żądania w analityce Edge. Dodaj poniższy kod do konfiguracji mikrobramy, aby zamaskować identyfikator URI żądania lub ścieżkę żądania. Zwróć uwagę, że identyfikator URI składa się z nazwy hosta i ścieżki żądania.

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

Segregowanie wywołań interfejsu API w Edge Analytics

Możesz skonfigurować wtyczkę Analytics w taki sposób, aby agregowała konkretną ścieżkę interfejsu API, tak aby była wyświetlana jako oddzielny serwer proxy w panelach Edge Analytics. Możesz na przykład podzielić w panelu interfejs API kontroli stanu, aby uniknąć pomylenia go z rzeczywistymi wywołaniami serwera proxy interfejsu API. W panelu Analytics oddzielone serwery proxy są zgodne z tym wzorcem nazewnictwa:

edgemicro_proxyname-health

Poniższy obraz przedstawia 2 segregowane serwery proxy w panelu Analytics: edgemicro_hello-health i edgemicro_mock-health:

Użyj tych parametrów do rozdzielania ścieżek względnych i bezwzględnych w panelu Analytics jako osobnych serwerów proxy:

  • relativePath (opcjonalna): określa względną ścieżkę segregacji w panelu Analytics. Jeśli na przykład podasz /healthcheck, wszystkie wywołania interfejsu API zawierające ścieżkę /healthcheck będą wyświetlane w panelu jako edgemicro_proxyname-health. Pamiętaj, że ta flaga ignoruje ścieżkę bazową serwera proxy. Aby segregować dane na podstawie pełnej ścieżki, w tym ścieżki bazowej, użyj flagi proxyPath.
  • proxyPath (opcjonalnie): określa pełną ścieżkę serwera proxy interfejsu API, w tym ścieżkę bazową serwera proxy, do rozdzielenia w panelu statystyk. Jeśli na przykład podasz /mocktarget/healthcheck, gdzie /mocktarget to ścieżka bazowa serwera proxy, wszystkie wywołania interfejsu API o ścieżce /mocktarget/healthcheck będą wyświetlane w panelu jako edgemicro_proxyname-health.

Na przykład w tej konfiguracji każda ścieżka interfejsu API zawierająca /healthcheck zostanie oddzielona przez wtyczkę Analytics. Oznacza to, że /foo/healthcheck i /foo/bar/healthcheck będą rozdzielone w panelu statystyk jako osobny serwer proxy o nazwie edgemicro_proxyname-health.

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

W poniższej konfiguracji każdy interfejs API ze ścieżką serwera proxy /mocktarget/healthcheck będzie oddzielony w panelu statystyk jako oddzielny serwer proxy o nazwie edgemicro_proxyname-health.

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

Konfigurowanie Edge Microgateway za firmową zaporą sieciową

Komunikacja z Apigee Edge przy użyciu serwera proxy HTTP

Dodano w wersji 3.1.2.

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

  1. Ustaw zmienne środowiskowe HTTP_PROXY, HTTPS_PROXY i NO_PROXY. Te zmienne kontrolują hosty każdego serwera proxy HTTP, którego chcesz używać do komunikacji z Apigee Edge lub które nie powinny obsługiwać komunikacji z Apigee Edge. Przykład:
    export HTTP_PROXY='http://localhost:3786'
    export HTTPS_PROXY='https://localhost:3786'
    export NO_PROXY='localhost,localhost:8080'

    Pamiętaj, że NO_PROXY może być rozdzielaną przecinkami listą domen, do których Edge Microgateway nie ma przekierowywać.

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

  2. Ponownie uruchom Edge Microgateway.

Używaj serwera proxy HTTP do komunikacji docelowej

Dodano w wersji 3.1.2.

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

  1. Dodaj do pliku konfiguracyjnego mikrobramy tę konfigurację:
    edgemicro:
      proxy:
        tunnel: true | false
        url: proxy_url
        bypass: target_host # target hosts to bypass the proxy.
        enabled: true | false

    Gdzie:

    • tunnel: (opcjonalnie) jeśli ma wartość prawda, Edge Microgateway używa metody połączenia HTTP do tunelowania żądań HTTP przez pojedyncze połączenie TCP. (To samo dotyczy zmiennych środowiskowych, jak jak wspomnieliśmy poniżej, do konfigurowania serwera proxy przy użyciu protokołu TLS). Domyślnie: false
    • url: adres URL serwera proxy HTTP.
    • bypass: (opcjonalnie) określa co najmniej 1 rozdzielany przecinkami adres URL docelowego hosta, który ma pomijać serwer proxy HTTP. Jeśli ta właściwość jest nieskonfigurowana, użyj zmiennej środowiskowej NO_PROXY, aby określić docelowe adresy URL, które mają być pomijane.
    • enabled: jeśli ma wartość prawda i proxy.url, używaj wartości proxy.url dla serwera proxy HTTP. Jeśli zasada ma wartość prawda i proxy.url, używaj serwerów proxy określonych w zmiennych środowiskowych serwera proxy HTTP HTTP_PROXY i HTTPS_PROXY zgodnie z opisem w sekcji Używanie serwera proxy HTTP do komunikacji z Apigee Edge.

    Na przykład:

    edgemicro:
      proxy:
        tunnel: true
        url: 'http://localhost:3786'
        bypass: 'localhost','localhost:8080' # target hosts to bypass the proxy.
        enabled: true

  2. Ponownie uruchom Edge Microgateway.

Korzystanie z symboli wieloznacznych w serwerach proxy obsługiwanych przez Microgateway

W ścieżce bazowej serwera proxy edgemicro_* (ang. Microgateway-aware) możesz użyć co najmniej jednego symbolu wieloznacznego „*”. Na przykład ścieżka bazowa /team/*/members pozwala klientom wywoływać strony https://[host]/team/blue/members i https://[host]/team/green/members bez konieczności tworzenia nowych serwerów proxy interfejsu API do obsługi nowych zespołów. Pamiętaj, że /**/ nie jest obsługiwany.

Ważne: Apigee NIE obsługuje użycia symbolu wieloznacznego „*” jako pierwszego elementu ścieżki podstawowej. Na przykład takie elementy NIE są obsługiwane: wyszukiwanie w polu /*/.

Rotacja kluczy JWT

Jakiś czas po początkowym wygenerowaniu tokena JWT może być konieczna zmiana pary kluczy (publicznego/prywatnego) przechowywanej w KVM z szyfrowaniem Edge. Proces generowania nowej pary kluczy jest nazywany rotacją kluczy.

Jak Edge Microgateway korzysta z tokenów JWT

Token internetowy JSON (JWT) to standard tokena opisany w RFC7519. JWT udostępnia sposób podpisywania zestawu deklaracji, który może zostać bezpiecznie zweryfikowany przez odbiorcę.

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

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

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

Co to jest rotacja kluczy?

Jakiś czas po początkowym wygenerowaniu tokena JWT może być konieczna zmiana pary kluczy (publicznego/prywatnego) przechowywanej w KVM z szyfrowaniem Edge. Proces generowania nowej pary kluczy jest nazywany rotacją kluczy. Gdy rotacja kluczy jest wykonywana, generowana jest nowa para kluczy prywatny/publiczny i jest przechowywana w KVM „microgateway” w organizacji/środowisku Apigee Edge. Poza tym stary klucz publiczny zostanie zachowany razem z pierwotną wartością identyfikatora klucza.

Aby wygenerować token JWT, Edge używa informacji przechowywanych w zaszyfrowanej maszynie wirtualnej. Podczas początkowej konfiguracji (skonfigurowanej) Edge Microgateway został utworzony KVM o nazwie microgateway, który zawiera klucze. Klucze w KVM służą do podpisywania i szyfrowania tokena JWT.

Klucze KVM to:

  • private_key – najnowszy (ostatni utworzony) klucz prywatny RSA używany do podpisywania tokenów JWT.

  • public_key – najnowszy (ostatni utworzony) certyfikat używany do weryfikacji tokenów JWT podpisanych kluczem private_key.

  • private_key_kid – najnowszy (ostatni utworzony) identyfikator klucza prywatnego. Ten identyfikator klucza jest powiązany z wartością klucza private_key i służy do obsługi rotacji kluczy.

  • public_key1_kid – najnowszy (ostatni utworzony) identyfikator klucza publicznego. Ten klucz jest powiązany z wartością public_key1 i używany do obsługi rotacji kluczy. Ta wartość jest taka sama jak w przypadku obiektu podrzędnego klucza prywatnego.

  • public_key1 – najnowszy (ostatnio utworzony) klucz publiczny.

Podczas rotacji kluczy istniejące wartości kluczy są zastępowane na mapie, a nowe klucze są dodawane, aby zachować stare klucze publiczne. Na przykład:

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

  • public_key2 – stary klucz publiczny.

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

Jak wykonać rotację klucza

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

  1. Aby uaktualnić KVM, użyj polecenia edgemicro upgradekvm. Szczegółowe informacje o uruchamianiu tego polecenia znajdziesz w sekcji Uaktualnianie KVM. Wystarczy wykonać ten krok tylko raz.
  2. Aby uaktualnić serwer proxy edgemicro-oauth, użyj polecenia edgemicro upgradeauth. Szczegółowe informacje o uruchamianiu tego polecenia znajdziesz w artykule o uaktualnianiu serwera proxy Edgemicro-auth. Wystarczy wykonać ten krok tylko raz.
  3. Dodaj ten wiersz do pliku ~/.edgemicro/org-env-config.yaml, gdzie musisz określić tę samą organizację i środowisko, do których chcesz używać mikrobramy:
    jwk_public_keys: 'https://$ORG-$ENV.apigee.net/edgemicro-auth/jwkPublicKeys'
  4. Uruchom polecenie rotacji kluczy, aby wykonać rotację kluczy. Szczegółowe informacje o tym poleceniu znajdziesz w artykule o rotacji kluczy.

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

    Na przykład:

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

Po rotacji kluczy Edge zwraca wiele kluczy do Edge Microgateway. W przykładzie poniżej każdy klucz ma unikalną wartość „kid” (identyfikator klucza). Mikrobrama używa następnie tych kluczy do weryfikowania tokenów autoryzacji. Jeśli weryfikacja tokena się nie powiedzie, mikrobrama sprawdzi, czy w zestawie kluczy jest starszy klucz, i spróbuje go użyć. Zwracane klucze mają format klucza internetowego JSON (JWK). Informacje na temat tego formatu znajdziesz w dokumencie RFC 7517.

{
  "keys": [
    {
      "kty": "RSA",
      "n": "nSl7R_0wKLiWi6cO3n8aOJwYGBtinq723Jgg8i7KKWTSTYoszOjgGsJf_MX4JEW1YCScwpE5o4o8ccQN09iHVTlIhk8CNiMZNPipClmRVjaL_8IWvMQp1iN66qy4ldWXzXnHfivUZZogCkBNqCz7VSC5rw2Jf57pdViULVvVDGwTgf46sYveW_6h8CAGaD0KLd3vZffxIkoJubh0yMy0mQP3aDOeIGf_akeZeZ6GzF7ltbKGd954iNTiKmdm8IKhz6Y3gLpC9iwQ-kex_j0CnO_daHl1coYxUSCIdv4ziWIeM3dmjQ5_2dEvUDIGG6_Az9hTpNgPE5J1tvrOHAmunQ",
      "e": "AQAB",
      "kid": "2"
    },
    {
      "kty": "RSA",
      "n": "8BKwzx34BMUcHwTuQtmp8LFRCMxbkKg_zsWD6eOMIUTAsORexTGJsTy7z-4aH0wJ3fT-3luAAUPLBQwGcuHo0P1JnbtPrpuYjaJKSZOeIMOnlryJCspmv-1xG4qAqQ9XaZ9C97oecuj7MMoNwuaZno5MvsY-oi5B_gqED3vIHUjaWCErd4reONyFSWn047dvpE6mwRhZbcOTkAHT8ZyKkHISzopkFg8CD-Mij12unxA3ldcTV7yaviXgxd3eFSD1_Z4L7ZRsDUukCJkJ-8qY2-GWjewzoxl-mAW9D1tLK6qAdc89yFem3JHRW6L1le3YK37-bs6b2a_AqJKsKm5bWw",
      "e": "AQAB",
      "kid": "1"
    }
  ]
}

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

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

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

Począwszy od wersji 3.1.6 nowa flaga w poleceniu rotatekey umożliwia określenie opóźnienia, po którym nowy klucz prywatny zacznie obowiązywać. Umożliwi to odświeżenie wszystkich instancji mikrobramy i otrzymanie nowego klucza publicznego. Nowa flaga to --nbf, co oznacza „nie wcześniej”. Ta flaga przyjmuje wartość całkowitą, czyli liczbę minut opóźnienia.

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

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

Warto ustawić opóźnienie na wartość większą niż ustawienie konfiguracji config_change_poll_internal, które domyślnie wynosi 10 minut. Zobacz też atrybuty Edgemicro.

Filtrowanie pobranych serwerów proxy

Domyślnie Edge Microgateway pobiera wszystkie serwery proxy w organizacji Edge, których nazwa zaczyna się od prefiksu „edgemicro_”. Możesz zmienić to ustawienie domyślne, 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 sekcji Edge_config. Na przykład ten wzorzec pobierze serwery proxy, takie jak Edgemicro_foo, Edgemicro_fast i Edgemicro_first.
    edge_config:
    …
    proxyPattern: edgemicro_f*

Określanie produktów bez serwerów proxy interfejsu API

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

Debugowanie i rozwiązywanie problemów

Łączenie z debugerem

Edge Microgateway możesz uruchomić przy użyciu debugera, takiego jak node-inspector. Przydaje się to do rozwiązywania problemów i debugowania niestandardowych wtyczek.

  1. Ponownie uruchom Edge Microgateway w trybie debugowania. Aby to zrobić, dodaj DEBUG=* na początku polecenia start:
    DEBUG=* edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET

    Aby przekierować dane wyjściowe debugowania do pliku, możesz użyć tego polecenia:

    export DEBUG=* nohup edgemicro start \
    -o $ORG -e $ENV -k $KEY -s $SECRET 2>&1 | tee /tmp/file.log

  2. Uruchom debuger i skonfiguruj go, aby nasłuchiwał na numerze portu podczas procesu debugowania.
  3. Możesz teraz przejść przez kod Edge Microgateway, ustawiać punkty przerwania, obserwować wyrażenia itd.

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

Sprawdzam pliki dziennika

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

Korzystanie z zabezpieczeń klucza interfejsu API

Klucze interfejsu API zapewniają prosty mechanizm uwierzytelniania klientów wysyłających żądania do Edge Microgateway. Klucz interfejsu API możesz uzyskać, kopiując wartość klucza klienta (nazywanego też identyfikatorem klienta) z usługi Apigee Edge, która zawiera serwer proxy uwierzytelniania Edge Microgateway.

Buforowanie kluczy

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

Używanie klucza API

Klucz interfejsu API możesz przekazać w żądaniu interfejsu API jako parametr zapytania lub w nagłówku. Domyślnie nazwa nagłówka i parametru zapytania to x-api-key.

Przykład parametru zapytania:

curl http://localhost:8000/foobar?x-api-key=JG616Gjz7xs4t0dvpvVsGdI49G34xGsz

Przykładowy nagłówek:

curl http://localhost:8000/foobar -H "x-api-key:JG616Gjz7xs4t0dvpvVsGdI49G34xGsz"

Konfigurowanie nazwy klucza interfejsu API

Domyślnie x-api-key jest nazwą używaną w nagłówku klucza interfejsu API i parametrze zapytania. Możesz zmienić to ustawienie w pliku konfiguracji, zgodnie z opisem w sekcji Wprowadzanie zmian w konfiguracji. Aby na przykład zmienić nazwę na apiKey:

oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  api-key-header: apiKey

W tym przykładzie zarówno parametr zapytania, jak i nazwa nagłówka są zmieniane na apiKey. 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 na stronie Microsoft Secure Edge Microgateway.

Włącz kody odpowiedzi z klienta na serwer

Domyślnie wtyczka oauth zwraca tylko kody stanu błędu 4xx, jeśli odpowiedź ma stan inny niż 200. Możesz zmienić to działanie tak, aby zawsze zwracało dokładny kod 4xx lub 5xx, w zależności od błędu.

Aby włączyć tę funkcję, dodaj właściwość oauth.useUpstreamResponse: true do konfiguracji Edge Microgateway. Na przykład:

oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  gracePeriod: 10
  useUpstreamResponse: true

Korzystanie z zabezpieczeń tokena OAuth2

W tej sekcji dowiesz się, jak uzyskać tokeny dostępu OAuth2 i tokeny odświeżania. Tokeny dostępu służą do wykonywania bezpiecznych wywołań interfejsu API przez mikrobramę. Tokeny odświeżania służą do uzyskiwania nowych tokenów dostępu.

Jak uzyskać token dostępu

W tej sekcji dowiesz się, jak uzyskać token dostępu za pomocą serwera proxy edgemicro-auth.

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

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

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

curl -i -X POST "http://<org>-<test>.apigee.net/edgemicro-auth/token" \
-d '{"grant_type": "client_credentials", "client_id": "your_client_id", \
"client_secret": "your_client_secret"}' -H "Content-Type: application/json"

API 2. Wysyłanie danych logowania w nagłówku uwierzytelniania podstawowego

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

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

Przykładowe wyniki

Interfejs API zwraca odpowiedź JSON. Zwróć uwagę, że nie ma różnicy między właściwościami token i access_token. Możesz użyć dowolnej z tych opcji. Pamiętaj, że expires_in to wartość całkowita określona w sekundach.
{
"token": "eyJraWQiOiIxIiwidHlwIjoi",
"access_token": "eyJraWQiOiIxIiwid",
"token_type": "bearer",
"expires_in": 1799
}

Jak uzyskać token odświeżania

Aby uzyskać token odświeżania, wykonaj wywołanie interfejsu API do punktu końcowego /token serwera proxy edgemicro-auth. To wywołanie interfejsu API MUSI wywołać z typem uwierzytelnienia password. Poniżej znajdziesz opis całego procesu.

  1. Uzyskaj token dostępu i odśwież za pomocą interfejsu API /token. Pamiętaj, że typ przyznania to password:
    curl -X POST \
      https://your_organization-your_environment.apigee.net/edgemicro-auth/token \
      -H 'Content-Type: application/json' \
      -d '{
       "client_id":"mpK6l1Bx9oE5zLdifoDbF931TDnDtLq",
       "client_secret":"bUdDcFgv3nXffnU",
       "grant_type":"password",
       "username":"mpK6lBx9RoE5LiffoDbpF931TDnDtLq",
       "password":"bUdD2FvnMsXffnU"
    }'

    Interfejs API zwraca token dostępu i token odświeżania. Odpowiedź wygląda podobnie do tej. Pamiętaj, że expires_in przypisuje wartość liczbom całkowitym i są podawane w sekundach.

    {
        "token": "your-access-token",
        "access_token": "your-access-token",
        "token_type": "bearer",
        "expires_in": 108,
        "refresh_token": "your-refresh-token",
        "refresh_token_expires_in": 431,
        "refresh_token_issued_at": "1562087304302",
        "refresh_token_status": "approved"
    }
  2. Możesz teraz użyć tokena odświeżania, aby uzyskać nowy token dostępu, wywołując punkt końcowy /refresh tego samego interfejsu API. Przykład:
    curl -X POST \
      https://willwitman-test.apigee.net/edgemicro-auth/refresh \
      -H 'Content-Type: application/json' \
      -d '{
       "client_id":"mpK6l1Bx9RoE5zLifoDbpF931TDnDtLq",
       "client_secret":"bUdDc2Fv3nMXffnU",
       "grant_type":"refresh_token",
       "refresh_token":"your-refresh-token"
    }'

    Interfejs API zwróci nowy token dostępu. Odpowiedź wygląda mniej więcej tak:

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

Stałe monitorowanie

Forever to narzędzie Node.js, które automatycznie ponownie uruchamia aplikację Node.js w przypadku awarii lub błędu. Edge Microgateway zawiera plik forever.json, który możesz skonfigurować, aby kontrolować, ile razy i w jakim czasie należy ponownie uruchamiać Edge Microgateway. Ten plik konfiguruje usługę zawsze o nazwie forever-monitor, która zarządza nią automatycznie.

Plik forever.json znajdziesz w głównym katalogu instalacyjnym Edge Microgateway. Zobacz, gdzie jest zainstalowana Edge Microgateway. Szczegółowe informacje o opcjach konfiguracji znajdziesz w dokumentacji stałego monitorowania.

Polecenie edgemicro forever zawiera flagi umożliwiające określenie lokalizacji pliku forever.json (flaga -f) oraz uruchamianie i zatrzymywanie procesu ciągłego monitorowania (flaga -a). Na przykład:

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

Więcej informacji znajdziesz w sekcji Ciągłe monitorowanie w dokumentacji interfejsu wiersza poleceń.

Określanie punktu końcowego pliku konfiguracji

Jeśli używasz wielu instancji Edge Microgateway, możesz zarządzać ich konfiguracjami z jednej lokalizacji. Aby to zrobić, określ punkt końcowy HTTP, z którego Edge Micro może pobrać swój plik konfiguracji. Możesz określić ten punkt końcowy przy uruchamianiu Edge Micro za pomocą flagi -u.

Na przykład:

edgemicro start -o jdoe -e test -u http://mylocalserver/mgconfig -k public_key -s secret_key

gdzie punkt końcowy mgconfig zwraca zawartość pliku konfiguracji. Jest to plik, który domyślnie znajduje się w lokalizacji ~/.edgemicro i ma konwencję nazewnictwa: org-env-config.yaml.

Wyłączam buforowanie danych połączeń TCP

Możesz użyć atrybutu konfiguracji nodelay, aby wyłączyć buforowanie danych w przypadku połączeń TCP używanych przez Edge Microgateway.

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

Aby włączyć usługę nodelay, zmodyfikuj plik konfiguracyjny Edge 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 odłączoną całkowicie od dowolnej zależności Apigee Edge. Ten scenariusz, nazywany trybem samodzielnym, umożliwia uruchomienie i przetestowanie Edge Microgateway bez połączenia z internetem.

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

  • Klucz OAuth i interfejsu API
  • Limit
  • Analityka

Z drugiej strony niestandardowe wtyczki i aresztowanie skokowe działają normalnie, ponieważ nie wymagają połączenia z Apigee Edge. Dodatkowo nowa wtyczka o nazwie extauth umożliwia autoryzowanie wywołań interfejsu API mikrobramy za pomocą tokena JWT w trybie samodzielnym.

Konfigurowanie i uruchamianie bramy

Aby uruchomić Edge Microgateway w trybie samodzielnym:

  1. Utwórz plik konfiguracji o nazwie: $HOME/.edgemicro/$ORG-$ENV-config.yaml

    Na przykład:

    vi $HOME/.edgemicro/foo-bar-config.yaml
  2. Wklej do tego 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
  3. Wyeksportuj tę zmienną środowiskową z wartością „1”:
    export EDGEMICRO_LOCAL=1
  4. Wykonaj to polecenie start, podając wartości tworzące instancję lokalnego serwera proxy:
    edgemicro start -o $ORG -e $ENV -a $LOCAL_PROXY_NAME \
      -v $LOCAL_PROXY_VERSION -t $TARGET_URL -b $BASE_PATH

    Gdzie:

    • $ORG to nazwa organizacji użyta w nazwie pliku konfiguracji.
    • $ENV to nazwa „środka” użyta w nazwie pliku konfiguracji.
    • $LOCAL_PROXY_NAME to nazwa lokalnego serwera proxy, który zostanie utworzony. Możesz użyć dowolnej nazwy.
    • $LOCAL_PROXY_VERSION to numer wersji serwera proxy.
    • $TARGET_URL to adres URL miejsca docelowego serwera proxy. (Cel to usługa wywoływana przez serwer proxy).
    • $BASE_PATH to ścieżka bazowa serwera proxy. Ta wartość musi zaczynać się od ukośnika. W przypadku głównej ścieżki bazowej podaj tylko ukośnik, np. „/”.

    Na przykład:

    edgemicro start -o local -e test -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
  5. Przetestuj konfigurację.
    curl http://localhost:8000/echo  { "error" : "missing_authorization" }

    Wtyczka extauth znajduje się w pliku foo-bar-config.yaml, dlatego pojawia się błąd „missing_authorization”. Ta wtyczka weryfikuje token JWT, który musi znajdować się w nagłówku Authorization wywołania interfejsu API. W następnej sekcji otrzymasz token JWT, który umożliwi wywołania interfejsu API bez błędu.

Przykład: uzyskiwanie tokena autoryzacji

Poniższy przykład pokazuje, jak uzyskać token JWT z punktu końcowego JWT Edge Microgateway w Apigee Edge (edgemicro-auth/jwkPublicKeys). Ten punkt końcowy jest wdrażany podczas wykonywania standardowej konfiguracji i konfiguracji Edge Microgateway. Aby uzyskać token JWT z punktu końcowego Apigee, najpierw musisz wykonać standardową konfigurację Edge Microgateway i mieć połączenie z internetem. Punkt końcowy Apigee jest używany tutaj tylko w celach poglądowych i nie jest wymagany. Jeśli chcesz, możesz użyć innego punktu końcowego tokena JWT. Jeśli tak, musisz uzyskać token JWT za pomocą interfejsu API udostępnionego dla tego punktu końcowego.

Poniżej znajdziesz instrukcje uzyskania tokena za pomocą punktu końcowego edgemicro-auth/jwkPublicKeys.

  1. Aby wdrożyć serwer proxy edgemicro-auth w organizacji lub środowisku w Apigee Edge, musisz przeprowadzić standardową konfigurację i konfigurację Edge Microgateway. 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 uzyskać token JWT z tego punktu końcowego.
  3. Zatrzymać Edge Microgateway:
    edgemicro stop
  4. W utworzonym wcześniej pliku konfiguracji ($HOME/.edgemicro/orgenv-config.yaml) wskaż atrybut extauth:publickey_url na punkt końcowy edgemicro-auth/jwkPublicKeys w organizacji lub środowisku Apigee Edge. Przykład:
    extauth:
      publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'
  5. Ponownie uruchom Edge Microgateway tak jak wcześniej, używając nazw organizacji i środowiska użytych w nazwie pliku konfiguracji. Przykład:
    edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
  6. Pobierz token JWT z punktu końcowego autoryzacji. Ponieważ używasz punktu końcowego edgemicro-auth/jwkPublicKeys, możesz użyć tego polecenia interfejsu wiersza poleceń:

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

edgemicro token get -o your_org -e your_env \
  -i G0IAeU864EtBo99NvUbn6Z4CBwVcS2 -s uzHTbwNWvoSmOy

Gdzie:

  • your_org to nazwa Twojej organizacji Apigee, dla której wcześniej skonfigurowano Edge Microgateway.
  • your_env to środowisko w organizacji.
  • Opcja i określa klucz klienta z aplikacji dewelopera, która zawiera usługę obejmującą serwer proxy edgemicro-auth.
  • Opcja s określa tajny klucz klienta z aplikacji dewelopera, która zawiera usługę obejmującą serwer proxy edgemicro-auth.

To polecenie prosi Apigee Edge o wygenerowanie tokena JWT, którego można następnie użyć do weryfikowania wywołań interfejsu API.

Zobacz też Generowanie tokena.

Testowanie konfiguracji samodzielnej

Aby przetestować konfigurację, wywołaj interfejs API z tokenem dodanym w nagłówku Authorization w ten sposób:

curl http://localhost:8000/echo -H "Authorization: Bearer your_token

Przykład:

curl http://localhost:8000/echo -H "Authorization: Bearer eyJraWQiOiIxIiwidHlwIjo...iryF3kwcDWNv7OQ"

Przykładowe dane wyjściowe:

{
   "headers":{
      "user-agent":"curl/7.54.0",
      "accept":"*/*",
      "x-api-key":"DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP",
      "client_received_start_timestamp":"1535134472699",
      "x-authorization-claims":"eyJhdDbiO...M1OTE5MTA1NDkifQ==",
      "target_sent_start_timestamp":"1535134472702",
      "x-request-id":"678e3080-a7ae-11e8-a70f-87ae30db3896.8cc81cb0-a7c9-11e8-a70f-87ae30db3896",
      "x-forwarded-proto":"http",
      "x-forwarded-host":"localhost:8000",
      "host":"mocktarget.apigee.net",
      "x-cloud-trace-context":"e2ac4fa0112c2d76237e5473714f1c85/1746478453618419513",
      "via":"1.1 localhost, 1.1 google",
      "x-forwarded-for":"::1, 216.98.205.223, 35.227.194.212",
      "connection":"Keep-Alive"
   },
   "method":"GET",
   "url":"/",
   "body":""
}

Używanie lokalnego trybu proxy

W trybie lokalnego serwera proxy Edge Microgateway nie wymaga wdrożenia serwera proxy rozpoznawanego przez mikrobramy w Apigee Edge. Zamiast tego konfigurujesz „lokalny serwer proxy”, podając lokalną nazwę serwera proxy, ścieżkę bazową i docelowy URL podczas uruchamiania mikrobramy. Wywołania interfejsu API wysyłane do mikrobramy są następnie wysyłane na docelowy adres URL lokalnego serwera proxy. We wszystkich pozostałych przypadkach lokalny tryb proxy działa tak samo jak uruchamianie Edge Microgateway w zwykłym trybie. Uwierzytelnianie działa tak samo jak wymuszanie ich narzucania, wymuszanie ich stosowania, niestandardowe wtyczki itp.

Przypadek użycia i przykład

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

Edgemicro jako Sidecar

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

Konfigurowanie lokalnego trybu proxy

Aby skonfigurować działanie Edge Microgateway w trybie lokalnego serwera proxy, wykonaj następujące czynności:

  1. Uruchom edgemicro init, aby skonfigurować lokalne środowisko konfiguracji dokładnie w taki sam sposób jak w przypadku typowej konfiguracji Edge Microgateway. Zobacz też Konfigurowanie Edge Microgateway.
  2. Uruchom edgemicro configure w taki sam sposób jak w typowej procedurze konfiguracji Edge Microgateway. Na przykład:
    edgemicro configure -o your_org -e your_env -u your_apigee_username

    To polecenie wdraża zasadę edgemicro-auth w Edge i zwraca klucz oraz obiekt tajny, których potrzebujesz do uruchomienia mikrobramy. Jeśli potrzebujesz pomocy, zobacz Konfigurowanie Edge Microgateway.

  3. W Apigee Edge utwórz usługę API z tymi obowiązkowymi wymaganiami konfiguracyjnymi (możesz zarządzać wszystkimi innymi konfiguracjami według własnego uznania):
    • Do usługi musisz dodać serwer proxy edgemicro-auth. Ten serwer proxy został wdrożony automatycznie podczas uruchamiania programu edgemicro configure.
    • Musisz podać ścieżkę do zasobu. Apigee zaleca dodanie do usługi tej ścieżki: /**. Więcej informacji znajdziesz w artykule Konfigurowanie zachowania ścieżki zasobu. Zapoznaj się też z sekcją o tworzeniu usług API w dokumentacji Edge.
  4. W Apigee Edge utwórz programistę. Jeśli chcesz, możesz skorzystać z usług istniejącego programisty. Aby uzyskać pomoc, zobacz Dodawanie programistów przy użyciu interfejsu zarządzania brzegiem sieci.

  5. Utwórz aplikację programisty w Apigee Edge. Musisz dodać do aplikacji utworzoną przed chwilą usługę API. Jeśli potrzebujesz pomocy, przeczytaj sekcję Rejestrowanie aplikacji w interfejsie zarządzania Edge.
  6. Na komputerze, na którym zainstalowano Edge Microgateway, wyeksportuj podaną poniżej zmienną środowiskową z wartością „1”.
    export EDGEMICRO_LOCAL_PROXY=1
  7. Wykonaj to polecenie start:
    edgemicro start -o your_org -e your_environment -k your_key -s your_secret \
        -a local_proxy_name -v local_proxy_version -t target_url -b base_path

    Gdzie:

    • your_org to Twoja organizacja Apigee.
    • your_environment to środowisko w Twojej organizacji.
    • your_key to klucz zwrócony podczas uruchamiania edgemicro configure.
    • your_secret to obiekt tajny zwrócony podczas uruchamiania edgemicro configure.
    • local_proxy_name to nazwa lokalnego serwera proxy, który zostanie utworzony.
    • local_proxy_version to numer wersji serwera proxy.
    • target_url to adres URL miejsca docelowego serwera proxy (wywołanej przez niego usługi).
    • base_path to ścieżka bazowa serwera proxy. Ta wartość musi zaczynać się od ukośnika. W przypadku głównej ścieżki bazowej podaj tylko ukośnik, np. „/”.

    Na przykład:

    edgemicro start -o your_org -e test -k 7eb6aae644cbc09035a...d2eae46a6c095f \
      -s e16e7b1f5d5e24df...ec29d409a2df853163a -a proxy1 -v 1 \
      -t http://mocktarget.apigee.net -b /echo

Testowanie konfiguracji

Możesz przetestować konfigurację lokalnego serwera proxy, wywołując punkt końcowy serwera proxy. Na 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. Znajdziesz go w utworzonej wcześniej aplikacji dewelopera. Otwórz aplikację w interfejsie Edge, skopiuj klucz klienta i użyj tego klucza w ten sposób:

curl  http://localhost:8000/echo -H 'x-api-key:your_api_key'

Na przykład:

curl  http://localhost:8000/echo -H "x-api-key:DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP"

Przykładowe dane wyjściowe:

{
  "headers":{
    "user-agent":"curl/7.54.0",
    "accept":"*/*",
    "x-api-key":"DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP",
    "client_received_start_timestamp":"1535134472699",
    "x-authorization-claims":"eyJhdWQiOi...TQ0YmUtOWNlOS05YzM1OTE5MTA1NDkifQ==",
    "target_sent_start_timestamp":"1535134472702",
    "x-request-id":"678e3080-a7ae-11e8-a70f-87ae30db3896.8cc81cb0-a7c9-11e8-a70f-87ae30db3896",
    "x-forwarded-proto":"http",
    "x-forwarded-host":"localhost:8000",
    "host":"mocktarget.apigee.net",
    "x-cloud-trace-context":"e2ac4fa0112c2d76237e5473714f1c85/1746478453618419513",
    "via":"1.1 localhost, 1.1 google",
    "x-forwarded-for":"::1, 216.98.205.223, 35.227.194.212",
    "connection":"Keep-Alive"
  },
  "method":"GET",
  "url":"/",
  "body":""
}

Korzystanie z synchronizatora

W tej sekcji wyjaśniono, jak używać synchronizatora – opcjonalnej funkcji zwiększającej odporność Edge Microgteway, która umożliwia pobieranie danych konfiguracji z Apigee Edge i zapisywanie ich w lokalnej bazie danych Redis. Gdy instancja synchronizatora jest uruchomiona, inne instancje Edge Microgateway uruchomione w różnych węzłach mogą pobierać swoją konfigurację bezpośrednio z tej bazy danych.

Funkcja synchronizacji jest obecnie obsługiwana przez Redis 5.0.x.

Co to jest synchronizator?

Moduł synchronizacji zapewnia poziom odporności dla Edge Microgateway. Pomaga to mieć pewność, że każda instancja Edge Microgateway korzysta z tej samej konfiguracji, a w przypadku przerwy w działaniu internetu instancje Edge Microgateway uruchamiają się i działają prawidłowo.

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

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

Moduł synchronizacji to specjalnie skonfigurowana instancja Edge Microgateway. Jedynym celem usługi jest odpytywanie Apigee Edge (czas, który można skonfigurować), pobieranie danych konfiguracji i zapisywanie ich w lokalnej bazie danych Redis. Sama instancja synchronizatora nie może przetwarzać ruchu z serwera proxy interfejsu API. Inne instancje Edge Microgateway uruchomione w różnych węzłach można skonfigurować tak, aby pobierały dane konfiguracji z bazy danych Redis, a nie z Apigee Edge. Wszystkie instancje mikrobram pobierają swoje dane konfiguracyjne z lokalnej bazy danych, więc mogą uruchamiać i przetwarzać żądania do interfejsu API nawet w przypadku przerw w działaniu internetu.

Konfigurowanie instancji synchronizatora

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

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

Na przykład:

edgemicro:
  redisHost: 192.168.4.77
  redisPort: 6379
  redisDb: 0
  redisPassword: codemaster
edge_config:
  synchronizerMode: 1
  redisBasedConfigCache: true
Option Opis
redisHost Host, na którym działa instancja Redis. Domyślnie: 127.0.0.1
redisPort Port instancji Redis. Domyślnie: 6379
redisDb Baza danych Redis do użycia. Wartość domyślna: 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

Po uruchomieniu synchronizatora możesz skonfigurować dodatkowe węzły Edge Microgateway, aby uruchamiać zwykłe instancje mikrobram, które przetwarzają ruch serwera proxy interfejsu API. Musisz jednak skonfigurować te instancje w taki sposób, aby pobierały ich dane konfiguracji z bazy danych Redis, a nie z Apigee Edge.

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

Dodaliśmy następujące właściwości konfiguracji, aby umożliwić korzystanie z synchronizatora:

Atrybut Wartości Opis
edge_config.synchronizerMode 0 lub 1

Jeśli ma wartość 0 (ustawienie domyślne), Edge Microgateway działa w trybie standardowym.

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

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

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

edgemicro.config_change_poll_interval Odstęp czasu w sekundach Określa interwał odpytywania, z którego synchronizator ma pobierać dane z Apigee Edge.

Konfigurowanie wykluczonych adresów URL wtyczek

Możesz skonfigurować mikrobramę tak, by pomijała przetwarzanie wtyczek dla określonych adresów URL. Możesz skonfigurować te wykluczanie adresów URL globalnie (dla wszystkich wtyczek) lub dla konkretnych wtyczek.

Na przykład:

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

W tym przykładzie wtyczki nie przetwarzają przychodzących wywołań interfejsu API ze ścieżkami /hello ani /proxy_one. Dodatkowo wtyczka json2xml zostanie pominięta w przypadku interfejsów API, których ścieżka zawiera parametr /hello/xml.

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

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

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

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

W tym przykładzie tag <n> wskazuje wartość całkowitą. Obsługiwane są tylko dodatnie liczby całkowite.

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

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

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