Справочник по эксплуатации и настройке Edge Microgateway

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация

Edge Microgateway v. 3.2.x

В этом разделе обсуждается, как управлять и настраивать Edge Microgateway.

Обновление Edge Microgateway, если у вас есть подключение к Интернету

В этом разделе объясняется, как обновить существующую установку Edge Microgateway. Если вы работаете без подключения к Интернету, см. раздел Могу ли я установить Edge Microgateway без подключения к Интернету? .

Apigee рекомендует протестировать существующую конфигурацию с новой версией перед обновлением производственной среды.

1. Выполните следующую команду npm , чтобы обновить Edge Microgateway до последней версии:

   npm upgrade edgemicro -g

   Чтобы установить конкретную версию Edge Microgateway, вам необходимо указать номер версии в команде установки. Например, для установки версии 3.2.3 используйте следующую команду:

   npm install edgemicro@3.2.3 -g

2. Проверьте номер версии. Например, если вы установили версию 3.2.3:

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

3. Наконец, обновите прокси-сервер Edgemicro-auth до последней версии:

   edgemicro upgradeauth -o $ORG -e $ENV -u $USERNAME

Внесение изменений в конфигурацию

Файлы конфигурации, о которых вам нужно знать, включают:

• Файл конфигурации системы по умолчанию
• Файл конфигурации по умолчанию для вновь инициализированного экземпляра Edge Microgateway.
• Файл динамической конфигурации для запуска экземпляров

В этом разделе обсуждаются эти файлы и то, что вам нужно знать об их изменении.

Файл конфигурации системы по умолчанию

Когда вы устанавливаете Edge Microgateway, здесь размещается файл конфигурации системы по умолчанию:

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

Где prefix — это каталог префикса npm . См. раздел «Где установлен Edge Microgateway», если вы не можете найти этот каталог.

Если вы измените файл конфигурации системы, вам необходимо повторно инициализировать, перенастроить и перезапустить Edge Microgateway:

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

Файл конфигурации по умолчанию для вновь инициализированных экземпляров Edge Microgateway

Когда вы запускаете edgemicro init , файл конфигурации системы (описанный выше) default.yaml помещается в каталог ~/.edgemicro .

Если вы измените файл конфигурации в ~/.edgemicro , вам необходимо перенастроить и перезапустить Edge Microgateway:

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

Файл динамической конфигурации для запуска экземпляров

Когда вы запускаете edgemicro configure [params] , файл динамической конфигурации создается в ~/.edgemicro . Имя файла соответствует следующему шаблону: org - env -config.yaml , где org и env — это имена вашей организации Apigee Edge и среды. Вы можете использовать этот файл для внесения изменений в конфигурацию, а затем перезагрузить их без простоев. Например, если вы добавите и настроите плагин, вы сможете перезагрузить конфигурацию без простоев, как описано ниже.

Если Edge Microgateway работает (опция с нулевым временем простоя):

1. Перезагрузите конфигурацию Edge Microgateway:

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

   Где:

   • $ORG — это название вашей организации Edge (вы должны быть администратором организации).
   • $ENV — это среда вашей организации (например, «test» или «prod»).
   • $KEY — это ключ, возвращенный ранее командой configure.
   • $SECRET — это ключ, возвращенный ранее командой configure.

   Например

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

Если Edge Microgateway остановлен:

1. Перезапустите Edge Microgateway:

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

   Где:

   • $ORG — это название вашей организации Edge (вы должны быть администратором организации).
   • $ENV — это среда в вашей организации (например, «тестовая» или «рабочая»).
   • $KEY — это ключ, возвращенный ранее командой configure.
   • $SECRET — это ключ, возвращенный ранее командой configure.

   Например:

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

Вот пример файла конфигурации. Подробные сведения о настройках файла конфигурации см. в разделе Справочник по настройке 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

Установка переменных среды

Команды интерфейса командной строки, которым требуются значения для вашей организации и среды Edge, а также ключ и секрет, необходимые для запуска Edge Microgateway, могут храниться в следующих переменных среды:

• EDGEMICRO_ORG
• EDGEMICRO_ENV
• EDGEMICRO_KEY
• EDGEMICRO_SECRET

Установка этих переменных не является обязательной. Если вы их установите, вам не придется указывать их значения при использовании интерфейса командной строки (CLI) для настройки и запуска Edge Microgateway.

Настройка SSL на сервере Edge Microgateway

Посмотрите следующие видеоролики, чтобы узнать о настройке TLS в Apigee Edge Microgateway:

Видео	Описание
Настройка одностороннего TLS в северном направлении	Узнайте о настройке TLS в Apigee Edge Microgateway. В этом видеоролике представлен обзор TLS и его важности, представлена ​​TLS в Edge Microgateway и показано, как настроить односторонний TLS в северном направлении.
Настройка двустороннего TLS в северном направлении	Это второе видео о настройке TLS в Apigee Edge Microgateway. В этом видео объясняется, как настроить двусторонний TLS в северном направлении.
Настройка одностороннего и двустороннего TLS в южном направлении	В этом третьем видеоролике о настройке TLS в Apigee Edge Microgateway объясняется, как настроить односторонний и двусторонний TLS в южном направлении.

Вы можете настроить сервер Microgateway для использования SSL. Например, если настроен SSL, вы можете вызывать API через Edge Microgateway по протоколу https, например:

https://localhost:8000/myapi

Чтобы настроить SSL на сервере Microgateway, выполните следующие действия:

1. Создайте или получите сертификат и ключ SSL с помощью утилиты openssl или любого другого метода, который вы предпочитаете.
2. Добавьте атрибут edgemicro:ssl в файл конфигурации Edge Microgateway . Полный список опций смотрите в таблице ниже. Например:
   

   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. Перезапустите Edge Microgateway. Выполните действия, описанные в разделе «Внесение изменений в конфигурацию» , в зависимости от того, какой файл конфигурации вы редактировали: файл по умолчанию или файл конфигурации среды выполнения.

Вот пример раздела edgemicro файла конфигурации с настроенным 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

Вот список всех поддерживаемых опций сервера:

Вариант	Описание
key	Путь к файлу ca.key (в формате PEM).
cert	Путь к файлу ca.cert (в формате PEM).
pfx	Путь к файлу pfx , содержащему закрытый ключ, сертификат и сертификаты CA клиента в формате PFX.
passphrase	Строка, содержащая кодовую фразу для закрытого ключа или PFX.
ca	Путь к файлу, содержащему список доверенных сертификатов в формате PEM.
ciphers	Строка, описывающая используемые шифры, разделенная знаком ":".
rejectUnauthorized	Если это правда, сертификат сервера проверяется по списку предоставленных центров сертификации. Если проверка не удалась, возвращается ошибка.
secureProtocol	Используемый метод SSL. Например, SSLv3_method для принудительного использования SSL версии 3.
servername	Имя сервера для расширения TLS SNI (индикация имени сервера).
requestCert	верно для двустороннего SSL; false для одностороннего SSL

Использование параметров клиента SSL/TLS

Вы можете настроить Edge Microgateway в качестве клиента TLS или SSL при подключении к целевым конечным точкам. В файле конфигурации Microgateway используйте элемент target для установки параметров SSL/TLS. Обратите внимание, что вы можете указать несколько конкретных целей. Ниже приведен пример с несколькими целями.

В этом примере представлены настройки, которые будут применены ко всем хостам:

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

В этом примере настройки применяются только к указанному хосту:

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

Вот пример для TLS:

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

В случае, если вы хотите применить настройки TLS/SSL к нескольким конкретным целям, вы должны указать первый хост в конфигурации как «пустой», что включает универсальные запросы, а затем указать конкретные хосты в любом порядке. В этом примере настройки применяются к нескольким конкретным хостам:

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

Вот список всех поддерживаемых опций клиента:

Вариант	Описание
pfx	Путь к файлу pfx , содержащему закрытый ключ, сертификат и сертификаты CA клиента в формате PFX.
key	Путь к файлу ca.key (в формате PEM).
passphrase	Строка, содержащая кодовую фразу для закрытого ключа или PFX.
cert	Путь к файлу ca.cert (в формате PEM).
ca	Путь к файлу, содержащему список доверенных сертификатов в формате PEM.
ciphers	Строка, описывающая используемые шифры, разделенная знаком ":".
rejectUnauthorized	Если это правда, сертификат сервера проверяется по списку предоставленных центров сертификации. Если проверка не удалась, возвращается ошибка.
secureProtocol	Используемый метод SSL. Например, SSLv3_method для принудительного использования SSL версии 3.
servername	Имя сервера для расширения TLS SNI (индикация имени сервера).

Настройка прокси-сервера EdgeMicro-Auth

По умолчанию Edge Microgateway использует прокси-сервер, развернутый на Apigee Edge, для аутентификации OAuth2. Этот прокси-сервер развертывается при первом запуске edgemicro configure . Вы можете изменить конфигурацию этого прокси-сервера по умолчанию, чтобы добавить поддержку пользовательских утверждений в веб-токен JSON (JWT), настроить срок действия токена и создать токены обновления. Подробности см. на странице Edgemicro-auth на GitHub.

Использование пользовательской службы аутентификации

По умолчанию Edge Microgateway использует прокси-сервер, развернутый на Apigee Edge, для аутентификации OAuth2. Этот прокси-сервер развертывается при первом запуске edgemicro configure . По умолчанию URL-адрес этого прокси-сервера указан в файле конфигурации Edge Microgateway следующим образом:

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

Если вы хотите использовать собственную службу для аутентификации, измените значение authUri в файле конфигурации, чтобы оно указывало на вашу службу. Например, у вас может быть служба, использующая LDAP для проверки личности.

Управление файлами журналов

Edge Microgateway регистрирует информацию о каждом запросе и ответе. Файлы журналов предоставляют полезную информацию для отладки и устранения неполадок.

Где хранятся файлы журналов

По умолчанию файлы журналов хранятся в /var/tmp .

Как изменить каталог файла журнала по умолчанию

Каталог, в котором хранятся файлы журналов, указан в файле конфигурации Edge Microgateway. См. также Внесение изменений в конфигурацию .

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

Измените значение dir , чтобы указать другой каталог файла журнала.

Отправлять логи на консоль

Вы можете настроить ведение журнала так, чтобы информация журнала отправлялась на стандартный вывод, а не в файл журнала. Установите для флага to_console значение true следующим образом:

edgemicro:
  logging:
    to_console: true

При этой настройке журналы будут отправляться на стандартный выход. В настоящее время вы не можете отправлять журналы одновременно на стандартный вывод и в файл журнала.

Как установить уровень журналирования

Вы указываете уровень журнала, который будет использоваться в конфигурации edgemicro . Полный список уровней журналирования и их описания см. в разделе Атрибуты Edgemicro .

Например, следующая конфигурация устанавливает уровень ведения журнала для 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

Как изменить интервалы журнала

Эти интервалы можно настроить в файле конфигурации Edge Microgateway. См. также Внесение изменений в конфигурацию .

Настраиваемые атрибуты:

• stats_log_interval : (по умолчанию: 60) Интервал в секундах, в течение которого запись статистики записывается в файл журнала API.
• Rotate_interval : (по умолчанию: 24) Интервал ротации файлов журналов в часах. Например:

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

Как ослабить строгие права доступа к файлам журналов

По умолчанию Edge Microgateway создает файл журнала приложения ( api-log.log ) с уровнем разрешений файла, установленным на 0600. Этот уровень разрешений не позволяет внешним приложениям или пользователям читать файл журнала. Чтобы ослабить этот строгий уровень разрешений, установите logging:disableStrictLogFile значение true . Если этот атрибут имеет значение true , файл журнала создается с разрешением файла, установленным на 0755. Если значение false или атрибут не указан, разрешение по умолчанию равно 0600.

Добавлено в версии 3.2.3.

Например:

edgemicro:
 logging:
   disableStrictLogFile: true

Хорошие методы обслуживания файлов журналов

Поскольку данные файла журнала со временем накапливаются, Apigee рекомендует вам принять следующие меры:

• Поскольку файлы журналов могут стать довольно большими, убедитесь, что в каталоге файлов журналов достаточно места. См. следующие разделы «Где хранятся файлы журналов» и «Как изменить каталог файлов журналов по умолчанию» .
• Либо удаляйте, либо перемещайте файлы журналов в отдельный архивный каталог не реже одного раза в неделю.
• Если ваша политика предполагает удаление журналов, вы можете использовать команду CLI edgemicro log -c для удаления (очистки) старых журналов.

Соглашение об именовании файлов журнала

Каждый экземпляр Edge Microgateway создает файл журнала с расширением .log . Соглашение об именах файлов журналов следующее:

edgemicro- HOST_NAME - INSTANCE_ID -api.log

Например:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log

О содержимом файла журнала

Добавлено: v2.3.3

По умолчанию служба ведения журналов опускает JSON загруженных прокси-серверов, продуктов и веб-токен JSON (JWT). Если вы хотите вывести эти объекты на консоль, установите флаг командной строки DEBUG=* при запуске Edge Microgateway. Например:

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

Содержимое файла журнала «api»

Файл журнала API содержит подробную информацию о потоке запросов и ответов через Edge Microgateway. Файлы журнала «api» называются следующим образом:

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

Для каждого запроса к Edge Microgateway в файле журнала API фиксируются четыре события:

• Входящий запрос от клиента
• Исходящий запрос к цели
• Входящий ответ от цели
• Исходящий ответ клиенту

Каждая из этих отдельных записей представлена ​​в сокращенной записи, что помогает сделать файлы журналов более компактными. Вот четыре примера записей, представляющих каждое из четырех событий. В файле журнала они выглядят следующим образом (номера строк в документе приведены только для справки, в файле журнала они не отображаются).

(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

Давайте посмотрим на них один за другим:

1. Образец входящего запроса от клиента:

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

• 1436403888651 — отметка даты Unix
• info — уровень ведения журнала. Это значение зависит от контекста транзакции и уровня ведения журнала, установленного в конфигурации edgemicro . См . раздел «Как установить уровень ведения журнала» . Для записей статистики уровень установлен на stats . Записи статистики передаются через регулярные интервалы, установленные в конфигурации stats_log_interval . См. также Как изменить интервалы журнала .
• req — идентифицирует событие. В данном случае запрос от клиента.
• m — HTTP-глагол, используемый в запросе.
• u — часть URL-адреса, следующая за базовым путем.
• h — номер хоста и порта, на котором прослушивает Edge Microgateway.
• r — удаленный хост и порт, откуда поступил клиентский запрос.
• i — идентификатор запроса. Все четыре записи о событиях будут использовать этот идентификатор. Каждому запросу присваивается уникальный идентификатор запроса. Сопоставление записей журнала по идентификатору запроса может дать ценную информацию о задержке цели.
• d — продолжительность в миллисекундах с момента получения запроса Edge Microgateway. В приведенном выше примере ответ цели на запрос 0 был получен через 7 миллисекунд (строка 3), а ответ был отправлен клиенту еще через 4 миллисекунды (строка 4). Другими словами, общая задержка запроса составила 11 миллисекунд, из которых 7 миллисекунд заняла цель и 4 миллисекунды — сам Edge Microgateway.

2. Пример исходящего запроса к цели:

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

• 1436403888651 — отметка даты Unix
• info — уровень ведения журнала. Это значение зависит от контекста транзакции и уровня ведения журнала, установленного в конфигурации edgemicro . См . раздел «Как установить уровень ведения журнала» . Для записей статистики уровень установлен на stats . Записи статистики передаются через регулярные интервалы, установленные в конфигурации stats_log_interval . См. также Как изменить интервалы журнала .
• treq — идентифицирует событие. В данном случае целевой запрос.
• m — команда HTTP, используемая в целевом запросе.
• u — часть URL-адреса, следующая за базовым путем.
• h — хост и номер порта целевой серверной части.
• i — идентификатор записи журнала. Все четыре записи о событиях будут использовать этот идентификатор.

3. Образец входящего ответа от цели

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

1436403888651 — отметка даты Unix

• info — уровень ведения журнала. Это значение зависит от контекста транзакции и уровня ведения журнала, установленного в конфигурации edgemicro . См . раздел «Как установить уровень ведения журнала» . Для записей статистики уровень установлен на stats . Записи статистики передаются через регулярные интервалы, установленные в конфигурации stats_log_interval . См. также Как изменить интервалы журнала .
• tres — идентифицирует событие. В данном случае целевой ответ.
• s — статус ответа HTTP.
• d - Продолжительность в миллисекундах. Время, затраченное на вызов API целью.
• i — идентификатор записи журнала. Все четыре записи о событиях будут использовать этот идентификатор.

4. Образец исходящего ответа клиенту

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

1436403888651 — отметка даты Unix

• info — уровень ведения журнала. Это значение зависит от контекста транзакции и уровня ведения журнала, установленного в конфигурации edgemicro . См . раздел «Как установить уровень ведения журнала» . Для записей статистики уровень установлен на stats . Записи статистики передаются через регулярные интервалы, установленные в конфигурации stats_log_interval . См. также Как изменить интервалы журнала .
• res — Идентифицирует событие. В данном случае ответ клиенту.
• s — статус ответа HTTP.
• d - Продолжительность в миллисекундах. Это общее время, затраченное на вызов API, включая время, затраченное целевым API, и время, затраченное самим Edge Microgateway.
• i — идентификатор записи журнала. Все четыре записи о событиях будут использовать этот идентификатор.

Расписание файла журнала

Файлы журналов чередуются с интервалом, указанным в атрибуте конфигурации Rotate_interval . Записи будут продолжать добавляться в один и тот же файл журнала до истечения интервала ротации. Однако при каждом перезапуске Edge Microgateway он получает новый UID и создает новый набор файлов журналов с этим UID. См. также «Хорошие методы обслуживания файлов журналов» .

Сообщения об ошибках

Некоторые записи журнала будут содержать сообщения об ошибках. Чтобы определить, где и почему возникают ошибки, см. справочник по ошибкам Edge Microgateway .

Справочник по настройке Edge Microgateway

Расположение файла конфигурации

Атрибуты конфигурации, описанные в этом разделе, находятся в файле конфигурации Edge Microgateway. См. также Внесение изменений в конфигурацию .

Атрибуты Edge_config

Эти параметры используются для настройки взаимодействия между экземпляром Edge Microgateway и Apigee Edge.

• bootstrap : (по умолчанию: нет) URL-адрес, указывающий на службу Edge Microgateway, работающую в Apigee Edge. Edge Microgateway использует эту службу для связи с Apigee Edge. Этот URL-адрес возвращается при выполнении команды для создания пары открытого и закрытого ключей: edgemicro genkeys . Подробности см. в разделе Установка и настройка Edge Microgateway .
• jwt_public_key : (по умолчанию: нет) URL-адрес, указывающий на прокси-сервер Edge Microgateway, развернутый в Apigee Edge. Этот прокси-сервер служит конечной точкой аутентификации для выдачи клиентам подписанных токенов доступа. Этот URL-адрес возвращается при выполнении команды для развертывания прокси: Edgemicro configure . Подробности см. в разделе Установка и настройка Edge Microgateway .
• quotaUri : установите это свойство конфигурации, если вы хотите управлять квотами через прокси-сервер edgemicro-auth , развернутый в вашей организации. Если это свойство не задано, конечной точкой квоты по умолчанию будет внутренняя конечная точка Edge Microgateway.

  edge_config:
    quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
  

Атрибуты EdgeMicro

Эти параметры настраивают процесс Edge Microgateway.

• порт : (по умолчанию: 8000) Номер порта, который прослушивает процесс Edge Microgateway.
• max_connections : (по умолчанию: -1) Определяет максимальное количество одновременных входящих подключений, которые может принять Edge Microgateway. Если это число превышено, возвращается следующий статус:
  
  res.statusCode = 429; // Too many requests
  
• max_connections_hard : (по умолчанию: -1) Максимальное количество одновременных запросов, которые Edge Microgateway может получить перед отключением соединения. Этот параметр предназначен для предотвращения атак типа «отказ в обслуживании». Обычно установите его на число, большее, чем max_connections.
• регистрация :
  • уровень : (по умолчанию: ошибка)
    • info — (рекомендуется) Регистрирует все запросы и ответы, проходящие через экземпляр Edge Microgateway.
    • alert — регистрирует только предупреждающие сообщения.
    • error — регистрируются только сообщения об ошибках.
    • debug — регистрирует отладочные сообщения вместе с информацией, предупреждениями и сообщениями об ошибках.
    • трассировка — записывает в журнал информацию об ошибках, а также информацию, предупреждения и сообщения об ошибках.
    • нет — не создавать файл журнала.
  • dir : (по умолчанию: /var/tmp) Каталог, в котором хранятся файлы журналов.
  • stats_log_interval : (по умолчанию: 60) Интервал в секундах, в течение которого запись статистики записывается в файл журнала API.
  • Rotate_interval : (по умолчанию: 24) Интервал ротации файлов журналов в часах.

• плагины : плагины добавляют функциональность Edge Microgateway. Подробную информацию о разработке плагинов см. в разделе «Разработка пользовательских плагинов» .

• dir : Относительный путь от каталога ./gateway до каталога ./plugins или абсолютный путь.
• последовательность : список модулей плагинов, которые можно добавить в экземпляр Edge Microgateway. Модули будут выполняться в том порядке, в котором они указаны здесь.

• отладка: добавляет удаленную отладку в процесс Edge Microgateway.
  • порт : номер порта для прослушивания. Например, настройте отладчик IDE на прослушивание этого порта.
  • args : Аргументы процесса отладки. Например: args --nolazy
    
• config_change_poll_interval: (по умолчанию: 600 секунд) Edge Microgateway периодически загружает новую конфигурацию и выполняет перезагрузку, если что-то изменилось. Опрос фиксирует любые изменения, внесенные в Edge (изменения в продуктах, прокси-серверах с поддержкой микрошлюзов и т. д.), а также изменения, внесенные в локальный файл конфигурации.
  
• Disable_config_poll_interval: (по умолчанию: false) Установите значение true , чтобы отключить автоматический опрос изменений.
• request_timeout : устанавливает тайм-аут для целевых запросов. Таймаут задается в секундах. Если происходит тайм-аут, Edge Microgateway отвечает кодом состояния 504. (Добавлено v2.4.x)
• Keep_alive_timeout : это свойство позволяет вам установить тайм-аут Edge Microgateway (в миллисекундах). (По умолчанию: 5 секунд) (Добавлено v3.0.6)
• headers_timeout : этот атрибут ограничивает время (в миллисекундах), в течение которого парсер HTTP будет ждать получения полных заголовков HTTP.

  Например:

  edgemicro:
    keep_alive_timeout: 6000
    headers_timeout: 12000

  Внутри этот параметр устанавливает атрибут Node.js Server.headersTimeout для запросов. (По умолчанию: на 5 секунд больше, чем время, установленное с помощью edgemicro.keep_alive_timeout . Этот параметр по умолчанию предотвращает ошибочное разрыв соединения балансировщиками нагрузки или прокси-серверами.) (Добавлено v3.1.1)

• noRuleMatchAction: (String) Действие, которое необходимо предпринять (разрешить или запретить доступ), если правило соответствия, указанное в подключаемом модуле accesscontrol не разрешено (не соответствует). Допустимые значения: ALLOW или DENY Значение по умолчанию: ALLOW (добавлено: v3.1.7).
• EnableAnalytics: (по умолчанию: true) Установите для атрибута значение false, чтобы предотвратить загрузку плагина аналитики. В этом случае вызовы аналитики Apigee Edge осуществляться не будут. Если установлено значение true или этот атрибут не указан, плагин аналитики будет работать как обычно. Подробности см. в атрибутах Edgemicro . (Добавлено v3.1.8).

  Пример:

  edgemicro
    enableAnalytics=false|true

• on_target_response_abort : этот атрибут позволяет вам контролировать поведение Edge Microgateway, если соединение между клиентом (Edge Microgateway) и целевым сервером закрывается преждевременно.

  Ценить	Описание
  По умолчанию	Если on_target_response_abort не указан, то поведением по умолчанию является усечение ответа без отображения ошибки. В файлах журналов отображается предупреждающее сообщение с targetResponse aborted и кодом ответа 502.
  appendErrorToClientResponseBody	Клиенту возвращается пользовательская ошибка TargetResponseAborted . В файлах журналов отображается предупреждающее сообщение с targetResponse aborted и кодом ответа 502. Кроме того, регистрируется ошибка TargetResponseAborted с сообщением Target response ended prematurely.
  abortClientRequest	Edge Microgateway прерывает запрос, и в файлы журналов записывается предупреждение: TargetResponseAborted с кодом состояния запроса 502.

Пример:

edgemicro:
 on_target_response_abort: appendErrorToClientResponseBody | abortClientRequest

атрибуты заголовков

Эти параметры определяют, как обрабатываются определенные заголовки HTTP.

• x-forwarded-for : (по умолчанию: true) Установите значение false, чтобы предотвратить передачу заголовков x-forwarded-for цели. Обратите внимание: если в запросе присутствует заголовок x-forwarded-for, его значению будет присвоено значение client-ip в Edge Analytics.
• x-forwarded-host : (по умолчанию: true) Установите значение false, чтобы предотвратить передачу заголовков x-forwarded-host к цели.
• x-request-id : (по умолчанию: true) Установите значение false, чтобы предотвратить передачу заголовков x-request-id цели.
• x-response-time : (по умолчанию: true) Установите значение false, чтобы предотвратить передачу заголовков x-response-time в цель.
• via : (по умолчанию: true) Установите значение false, чтобы предотвратить передачу заголовков via в цель.

атрибуты oauth

Эти параметры определяют, как Edge Microgateway обеспечивает аутентификацию клиента.

• allowNoAuthorization : (по умолчанию: false). Если установлено значение true, вызовы API могут проходить через Edge Microgateway вообще без какого-либо заголовка авторизации. Установите для этого параметра значение false, чтобы требовать заголовок авторизации (по умолчанию).
• allowInvalidAuthorization : (по умолчанию: false) Если установлено значение true, вызовы API разрешаются, если токен, переданный в заголовке авторизации, недействителен или срок его действия истек. Установите для этого параметра значение false, чтобы требовать действительные токены (по умолчанию).
• авторизационный-заголовок : (по умолчанию: Авторизация: Носитель) Заголовок, используемый для отправки токена доступа в Edge Microgateway. Возможно, вы захотите изменить значение по умолчанию в тех случаях, когда целевому объекту необходимо использовать заголовок авторизации для какой-либо другой цели.
• api-key-header : (по умолчанию: x-api-key) Имя заголовка или параметра запроса, используемого для передачи ключа API в Edge Microgateway. См. также Использование ключа API .
• Keep-authorization-header : (по умолчанию: false) Если установлено значение true, заголовок авторизации, отправленный в запросе, передается цели (он сохраняется).
• allowOAuthOnly — если установлено значение true, каждый API должен содержать заголовок авторизации с токеном доступа к носителю. Позволяет разрешить только модель безопасности OAuth (с сохранением обратной совместимости). (Добавлено 2.4.x)
• allowAPIKeyOnly — если установлено значение true, каждый API должен содержать заголовок x-api-key (или пользовательское местоположение) с ключом API. Позволяет разрешить только модель безопасности ключа API (при сохранении обратной совместимости). (Добавлено 2.4.x)
• GracePeriod — этот параметр помогает предотвратить ошибки, вызванные небольшими расхождениями между системными часами и временем «Не раньше» (nbf) или «Выдано в» (iat), указанным в токене авторизации JWT. Установите для этого параметра количество секунд, позволяющее учитывать такие несоответствия. (Добавлено 2.5.7)

Атрибуты, специфичные для плагина

Подробную информацию о настраиваемых атрибутах для каждого плагина см. в разделе «Использование плагинов».

Фильтрация прокси

Вы можете отфильтровать, какие прокси-серверы с поддержкой микрошлюза будет обрабатывать экземпляр Edge Microgateway. При запуске Edge Microgateway он загружает все прокси-серверы с поддержкой микрошлюза в организации, с которой он связан. Используйте следующую конфигурацию, чтобы ограничить количество прокси-серверов, которые будет обрабатывать микрошлюз. Например, эта конфигурация ограничивает количество прокси-серверов, которые микрошлюз будет обрабатывать, до трех: edgemicro_proxy-1 , edgemicro_proxy-2 и edgemicro_proxy-3 :

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

Фильтрация товаров по названию

Используйте следующую конфигурацию, чтобы ограничить количество продуктов API, которые загружает и обрабатывает Edge Microgateway. Чтобы отфильтровать загруженные продукты, добавьте параметр запроса productnamefilter в API /products , указанный в файле Edge Microgateway *.config.yaml . Например:

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'

Обратите внимание, что значение параметра запроса должно быть указано в формате регулярного выражения и иметь URL-кодировку. Например, регулярное выражение ^[Ee]dgemicro.*$ улавливает такие имена, как «edgemicro-test-1», «edgemicro_demo» и «Edgemicro_New_Demo». Закодированное значение URL-адреса, подходящее для использования в параметре запроса: %5E%5BEe%5Ddgemicro.%2A%24 .

Следующие выходные данные отладки показывают, что были загружены только отфильтрованные продукты:

...
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":[

         ]
      }
   ]
}

Фильтрация товаров по пользовательским атрибутам

Чтобы фильтровать продукты по пользовательским атрибутам:

1. В пользовательском интерфейсе Edge выберите прокси-сервер Edgemicro_auth в организации/среде, где вы настроили Edge Microgateway.
2. На вкладке «Разработка» откройте в редакторе политику JavaCallout.
3. Добавьте настраиваемый атрибут с ключевым словом products.filter.attributes и списком имен атрибутов, разделенных запятыми. В Edge Microgateway будут возвращены только продукты, содержащие имена настраиваемых атрибутов.
4. При желании вы можете отключить проверку, чтобы узнать, включен ли продукт для текущей среды, установив для настраиваемого атрибута products.filter.env.enable значение false . (По умолчанию установлено значение true.)
5. (Только для частного облака) Если вы используете Edge для частного облака, установите для свойства org.noncps значение true чтобы получать продукты для сред, не поддерживающих CPS.

Например:

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

Настройка частоты отправки аналитики

Используйте эти параметры конфигурации, чтобы контролировать частоту, с которой Edge Microgateway отправляет аналитические данные в Apigee:

• ufferSize (необязательно): максимальное количество аналитических записей, которое может храниться в буфере, прежде чем самые старые записи начнут удаляться. По умолчанию: 10000
• BatchSize (необязательно): максимальный размер пакета аналитических записей, отправляемых в Apigee. По умолчанию: 500
• lushInterval (необязательно): количество миллисекунд между каждой очисткой пакета аналитических записей, отправляемых в Apigee. По умолчанию: 5000

Например:

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

Маскирование данных аналитики

Следующая конфигурация предотвращает отображение информации о пути запроса в аналитике Edge. Добавьте следующее в конфигурацию микрошлюза, чтобы замаскировать URI запроса и/или путь запроса. Обратите внимание, что URI состоит из имени хоста и пути запроса.

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

Разделение вызовов API в Edge Analytics

Вы можете настроить плагин аналитики для разделения определенного пути API, чтобы он отображался как отдельный прокси на панелях мониторинга Edge Analytics. Например, вы можете выделить API проверки работоспособности на панели мониторинга, чтобы не путать его с реальными вызовами прокси-сервера API. На панели управления Analytics отдельные прокси-серверы имеют следующий шаблон именования:

edgemicro_proxyname-health

На следующем изображении показаны два отдельных прокси-сервера на панели мониторинга Analytics: edgemicro_hello-health и edgemicro_mock-health :

Используйте эти параметры, чтобы разделить относительные и абсолютные пути на панели мониторинга Analytics как отдельные прокси:

• относительный путь (необязательно): указывает относительный путь для разделения на панели мониторинга Analytics. Например, если вы укажете /healthcheck , все вызовы API, содержащие путь /healthcheck будут отображаться на информационной панели как edgemicro_ proxyname -health . Обратите внимание, что этот флаг игнорирует базовый путь прокси. Для разделения на основе полного пути, включая базовый путь, используйте флаг proxyPath .
• proxyPath (необязательно): указывает полный путь прокси-сервера API, включая базовый путь прокси-сервера, для разделения на панели аналитики. Например, если вы укажете /mocktarget/healthcheck , где /mocktarget — это базовый путь прокси-сервера, все вызовы API с путем /mocktarget/healthcheck будут отображаться на панели мониторинга как edgemicro_ proxyname -health .

Например, в следующей конфигурации любой путь API, содержащий /healthcheck будет отделен плагином аналитики. Это означает, что /foo/healthcheck и /foo/bar/healthcheck будут выделены в отдельный прокси-сервер с именем edgemicro_ proxyname -health на панели аналитики.

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

В следующей конфигурации любой API с путем к прокси-серверу /mocktarget/healthcheck будет выделен как отдельный прокси-сервер с именем edgemicro_ proxyname -health на панели аналитики.

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

Настройка Edge Microgateway за брандмауэром компании

Используйте HTTP-прокси для связи с Apigee Edge.

Добавлено в версии 3.1.2.

Чтобы использовать HTTP-прокси для связи между Edge Microgateway и Apigee Edge, выполните следующие действия:

1. Установите переменные среды HTTP_PROXY , HTTPS_PROXY и NO_PROXY . Эти переменные управляют хостами для каждого HTTP-прокси, которые вы хотите использовать для связи с Apigee Edge, или какие хосты не должны обрабатывать связь с Apigee Edge. Например:

   export HTTP_PROXY='http://localhost:3786'
   export HTTPS_PROXY='https://localhost:3786'
   export NO_PROXY='localhost,localhost:8080'

   Обратите внимание, что NO_PROXY может представлять собой список доменов, разделенных запятыми, к которым Edge Microgateway не следует использовать прокси.

   Дополнительную информацию об этих переменных см. на странице https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables .

2. Перезапустите Edge Microgateway.

Используйте HTTP-прокси для целевого взаимодействия.

Добавлено в версии 3.1.2.

Чтобы использовать HTTP-прокси для связи между Edge Microgateway и внутренними объектами, выполните следующие действия:

1. Добавьте следующую конфигурацию в файл конфигурации микрошлюза:

   edgemicro:
     proxy:
       tunnel: true | false
       url: proxy_url
       bypass: target_host # target hosts to bypass the proxy.
       enabled: true | false

   Где:

   • туннель : (Необязательно) Если установлено значение true, Edge Microgateway использует метод HTTP CONNECT для туннелирования HTTP-запросов через одно TCP-соединение. (То же самое верно, если для переменных среды, как указано ниже, для настройки прокси-сервера включен TLS). По умолчанию: false
   • url : URL-адрес HTTP-прокси.
   • bypass : (Необязательно) Указывает один или несколько URL-адресов целевого хоста, разделенных запятыми, которые должны обходить HTTP-прокси. Если это свойство не установлено, используйте переменную среды NO_PROXY, чтобы указать, какие целевые URL-адреса следует обходить.
   • включено : если установлено значение true и proxy.url , используйте значение proxy.url для HTTP-прокси. Если true и proxy.url не установлены, используйте прокси, указанные в переменных среды HTTP-прокси HTTP_PROXY и HTTPS_PROXY , как описано в разделе Использование HTTP-прокси для связи с Apigee Edge .

   Например:

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

2. Перезапустите Edge Microgateway.

Использование подстановочных знаков в прокси-серверах с поддержкой Microgateway

Вы можете использовать один или несколько подстановочных знаков «*» в базовом пути прокси-сервера Edgemicro_* (с поддержкой Microgateway). Например, базовый путь /team/*/members позволяет клиентам вызывать https://[host]/team/blue/members и https://[host]/team/green/members без необходимости создавать новые API-прокси для поддержки новых команд. Обратите внимание, что /**/ не поддерживается.

Важно: Apigee НЕ поддерживает использование подстановочного знака «*» в качестве первого элемента базового пути. Например, НЕ поддерживается: /*/ search.

Вращение ключей JWT

Через некоторое время после первоначального создания JWT вам может потребоваться изменить пару открытого и закрытого ключей, хранящуюся в KVM, зашифрованном Edge. Этот процесс создания новой пары ключей называется ротацией ключей.

Как Edge Microgateway использует JWT

JSON Web Token (JWT) — это стандарт токена, описанный в RFC7519 . JWT предоставляет способ подписать набор утверждений, который может быть надежно проверен получателем JWT.

Вы можете создать JWT с помощью CLI и использовать его в заголовке авторизации вызовов API вместо ключа API. Например:

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

Информацию о создании JWT с помощью CLI см. в разделе Создание токена .

Что такое ротация ключей?

Через некоторое время после первоначального создания JWT вам может потребоваться изменить пару открытого и закрытого ключей, хранящуюся в KVM, зашифрованном Edge. Этот процесс создания новой пары ключей называется ротацией ключей. При ротации ключей создается новая пара частного/открытого ключей, которая сохраняется в KVM «микрошлюза» в вашей организации/среде Apigee Edge. Кроме того, старый открытый ключ сохраняется вместе с исходным значением идентификатора ключа.

Для создания JWT Edge использует информацию, хранящуюся в зашифрованном KVM. KVM под названием microgateway был создан и заполнен ключами при первоначальной установке (настройке) Edge Microgateway. Ключи KVM используются для подписи и шифрования JWT.

Ключи KVM включают в себя:

• Private_key — последний (последний созданный) закрытый ключ RSA, используемый для подписи JWT.

• public_key — последний (последний созданный) сертификат, используемый для проверки JWT, подписанных с помощью частного_ключа.

• Private_key_kid — последний (последний созданный) идентификатор закрытого ключа. Этот идентификатор ключа связан со значением Private_key и используется для поддержки ротации ключей.

• public_key1_kid — последний (последний созданный) идентификатор открытого ключа. Этот ключ связан со значением public_key1 и используется для поддержки ротации ключей. Это значение такое же, как и у закрытого ключа kid.

• public_key1 — последний (самый последний созданный) открытый ключ.

При выполнении ротации ключей существующие значения ключей заменяются на карте и добавляются новые ключи, чтобы сохранить старые открытые ключи. Например:

• public_key2_kid — старый идентификатор открытого ключа. Этот ключ связан со значением public_key2 и используется для поддержки ротации ключей.

• public_key2 — старый открытый ключ.

JWT, представленные на проверку, будут проверены с использованием нового открытого ключа. Если проверка не удалась, будет использоваться старый открытый ключ до истечения срока действия JWT (после интервала token_expiry*, по умолчанию 30 минут). Таким образом, вы можете «чередовать» ключи, не нарушая при этом трафик API.

Как сделать ротацию ключей

В этом разделе объясняется, как выполнить поворот клавиш.

1. Чтобы обновить KVM, используйте команду edgemicro upgradekvm . Подробную информацию о запуске этой команды см. в разделе «Обновление KVM» . Вам нужно сделать этот шаг только один раз.
2. Чтобы обновить прокси-сервер Edgemicro-oauth , используйте команду edgemicro upgradeauth . Подробные сведения о запуске этой команды см. в разделе Обновление прокси-сервера Edgemicro-auth . Вам нужно сделать этот шаг только один раз.
3. Добавьте следующую строку в файл ~/.edgemicro/org-env-config.yaml , где вы должны указать ту же организацию и среду, которые вы настроили для использования микрошлюзом:

   jwk_public_keys: 'https://$ORG-$ENV.apigee.net/edgemicro-auth/jwkPublicKeys'

4. Запустите команду вращения клавиш, чтобы повернуть клавиши. Подробности об этой команде см. в разделе «Вращение клавиш» .

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

   Например:

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

После ротации ключей Edge возвращает несколько ключей в Edge Microgateway. Обратите внимание, что в следующем примере каждый ключ имеет уникальное значение «ребенок» (идентификатор ключа). Затем микрошлюз использует эти ключи для проверки токенов авторизации. Если проверка токена не удалась, микрошлюз проверяет, есть ли в наборе ключей более старый ключ, и пробует использовать этот ключ. Формат возвращаемых ключей — JSON Web Key (JWK). Прочитать об этом формате можно в 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"
    }
  ]
}

Настройка задержки «не раньше»

Для версий 3.1.5 и более ранних новый закрытый ключ, созданный командой rotatekey вступал в силу немедленно, и новые созданные токены подписывались новым закрытым ключом. Однако новый открытый ключ был доступен экземплярам Edge Microgateway только каждые 10 минут (по умолчанию) при обновлении конфигурации микрошлюза. Из-за этой задержки между подписанием токена и обновлением экземпляра микрошлюза токены, подписанные последним ключом, будут отклоняться до тех пор, пока все экземпляры не получат последний открытый ключ.

В случаях, когда существует несколько экземпляров микрошлюза, задержка открытого ключа иногда приводила к периодическим ошибкам времени выполнения со статусом 403, поскольку проверка токена проходила в одном экземпляре, но завершалась неудачно в другом экземпляре до тех пор, пока все экземпляры не были обновлены.

Начиная с версии 3.1.6, новый флаг в команде rotatekey позволяет указать задержку вступления в силу нового закрытого ключа, давая время всем экземплярам микрошлюза обновиться и получить новый открытый ключ. Новый флаг — --nbf , что означает «не раньше». Этот флаг принимает целое значение — количество минут задержки.

В следующем примере задержка установлена ​​на 15 минут:

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

Обратите внимание, что хорошей практикой является установка задержки, превышающей значение параметра конфигурации config_change_poll_internal , которое по умолчанию составляет 10 минут. См. также атрибуты Edgemicro .

Фильтрация загруженных прокси

По умолчанию Edge Microgateway загружает все прокси-серверы в вашей организации Edge, имена которых начинаются с префикса «edgemicro_». Вы можете изменить это значение по умолчанию, чтобы загружать прокси, имена которых соответствуют шаблону.

1. Откройте файл конфигурации Edge Micro: ~/.edgemicro/org-env-config.yaml
2. Добавьте элемент proxyPattern в файл Edge_config. Например, следующий шаблон загрузит такие прокси, как Edgemicro_foo, Edgemicro_fast и Edgemicro_first.

   edge_config:
   …
   proxyPattern: edgemicro_f*

Указание продуктов без API-прокси

В Apigee Edge вы можете создать продукт API, который не содержит прокси-серверов API. Эта конфигурация продукта позволяет ключу API, связанному с этим продуктом, работать с любым прокси-сервером, развернутым в вашей организации. Начиная с версии 2.5.4 Edge Microgateway поддерживает эту конфигурацию продукта.

Отладка и устранение неполадок

Подключение к отладчику

Вы можете запустить Edge Microgateway с помощью отладчика, например node-inspector . Это полезно для устранения неполадок и отладки пользовательских плагинов.

1. Перезапустите Edge Microgateway в режиме отладки. Для этого добавьте DEBUG=* в начало команды start :

   DEBUG=* edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET

   Чтобы направить вывод отладки в файл, вы можете использовать эту команду:

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

2. Запустите отладчик и настройте его на прослушивание номера порта для процесса отладки.
3. Теперь вы можете выполнять код Edge Microgateway, устанавливать точки останова, просматривать выражения и т. д.

Вы можете указать стандартные флаги Node.js, относящиеся к режиму отладки. Например, --nolazy помогает при отладке асинхронного кода.

Проверка файлов журналов

Если у вас возникли проблемы, обязательно просмотрите файлы журналов на предмет подробностей выполнения и информации об ошибках. Подробности см. в разделе «Управление файлами журналов» .

Использование безопасности ключа API

Ключи API предоставляют простой механизм аутентификации клиентов, отправляющих запросы к Edge Microgateway. Вы можете получить ключ API, скопировав значение Consumer Key (также называемое Client ID) из продукта Apigee Edge, который включает прокси-сервер аутентификации Edge Microgateway.

Кэширование ключей

Ключи API обмениваются на токены на предъявителя, которые кэшируются. Вы можете отключить кеширование, установив заголовок Cache-Control: no-cache во входящих запросах к Edge Microgateway.

Использование ключа API

Вы можете передать ключ API в запросе API либо в качестве параметра запроса, либо в заголовке. По умолчанию имя параметра заголовка и запроса — x-api-key .

Пример параметра запроса:

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

Пример заголовка:

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

Настройка имени ключа API

По умолчанию x-api-key — это имя, используемое как для заголовка ключа API, так и для параметра запроса. Вы можете изменить это значение по умолчанию в файле конфигурации, как описано в разделе «Внесение изменений в конфигурацию» . Например, чтобы изменить имя на apiKey :

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

В этом примере и параметр запроса, и имя заголовка изменяются на apiKey . Имя x-api-key больше не будет работать в любом случае. См. также Внесение изменений в конфигурацию .

Например:

curl http://localhost:8000/foobar -H "apiKey:JG616Gjz7xs4t0dvpvVsGdI49G34xGsz"

Дополнительные сведения об использовании ключей API с запросами прокси см. в разделе Secure Edge Microgateway .

Включить коды ответа восходящего потока

По умолчанию плагин oauth возвращает только коды ошибок 4xx, если ответ не имеет статуса 200. Вы можете изменить это поведение, чтобы оно всегда возвращало точный код 4xx или 5xx, в зависимости от ошибки.

Чтобы включить эту функцию, добавьте свойство oauth.useUpstreamResponse: true в конфигурацию Edge Microgateway. Например:

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

Использование токена безопасности OAuth2

В этом разделе объясняется, как получить токены доступа OAuth2 и токены обновления. Токены доступа используются для безопасных вызовов API через микрошлюз. Токены обновления используются для получения новых токенов доступа.

Как получить токен доступа

В этом разделе объясняется, как использовать прокси-сервер edgemicro-auth для получения токена доступа.

Вы также можете получить токен доступа с помощью команды CLI edgemicro token . Подробную информацию о CLI см. в разделе «Управление токенами» .

API 1: отправка учетных данных в качестве параметров тела

Замените названия своей организации и среды в URL-адресе, а также замените значения Consumer Id и Consumer Secret, полученные из приложения разработчика в Apigee Edge, на параметры тела client_id и 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: отправка учетных данных в заголовке базовой аутентификации.

Отправьте учетные данные клиента в качестве заголовка базовой аутентификации и grant_type в качестве параметра формы. Эта форма команды также обсуждается в RFC 6749: The OAuth 2.0 Authorization Framework .

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

Пример вывода

API возвращает ответ в формате JSON. Обратите внимание, что между свойствами token и access_token нет никакой разницы. Вы можете использовать любой из них. Обратите внимание, что expires_in — это целочисленное значение, указанное в секундах.

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

Как получить токен обновления

Чтобы получить токен обновления, выполните вызов API к конечной точке /token прокси-сервера edgemicro-auth . Вы ДОЛЖНЫ выполнить этот вызов API с типом предоставления password . Следующие шаги описывают этот процесс.

1. Получите токен доступа и обновления с помощью API /token . Обратите внимание, что тип предоставления — 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"
   }'

   API возвращает токен доступа и токен обновления. Ответ выглядит примерно так. Обратите внимание, что expires_in имеет целые значения и указывается в секундах.

   {
       "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. Теперь вы можете использовать токен обновления, чтобы получить новый токен доступа, вызвав конечную точку /refresh того же API. Например:

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

   API возвращает новый токен доступа. Ответ выглядит примерно так:

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

Постоянный мониторинг

Forever — это инструмент Node.js, который автоматически перезапускает приложение Node.js в случае сбоя процесса или возникновения ошибки. Edge Microgateway имеет файл ever.json , который можно настроить, чтобы контролировать, сколько раз и с какими интервалами следует перезапускать Edge Microgateway. Этот файл настраивает службу Forever под названием Forever-monitor , которая управляет Forever программно.

Вы можете найти файл ever.json в корневом каталоге установки Edge Microgateway. См. раздел Где установлен Edge Microgateway . Подробную информацию о параметрах конфигурации можно найти в документации Forever-Monitor .

Команда edgemicro forever включает флаги, которые позволяют указать расположение файла forever.json (флаг -f ) и запустить/остановить процесс мониторинга Forever (флаг -a ). Например:

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

Для получения дополнительной информации см. мониторинг Forever в справочнике по CLI.

Указание конечной точки файла конфигурации

Если вы используете несколько экземпляров Edge Microgateway, возможно, вам захочется управлять их конфигурациями из одного места. Это можно сделать, указав конечную точку HTTP, откуда Edge Micro сможет загрузить файл конфигурации. Вы можете указать эту конечную точку при запуске Edge Micro, используя флаг -u .

Например:

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

где конечная точка mgconfig возвращает содержимое вашего файла конфигурации. Это файл, который по умолчанию находится в ~/.edgemicro и имеет соглашение об именах: org-env-config.yaml .

Отключение буферизации данных TCP-соединения

Вы можете использовать атрибут конфигурации nodelay , чтобы отключить буферизацию данных для TCP-соединений, используемых Edge Microgateway.

По умолчанию TCP-соединения используют алгоритм Нэгла для буферизации данных перед их отправкой. Установка nodelay в true отключает это поведение (данные будут немедленно отправляться каждый раз, когда вызывается socket.write() ). Дополнительные сведения см. также в документации Node.js.

Чтобы включить nodelay , отредактируйте файл конфигурации Edge Micro следующим образом:

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

Запуск Edge Microgateway в автономном режиме

Вы можете запустить Edge Microgateway полностью отключенным от любой зависимости Apigee Edge. Этот сценарий, называемый автономным режимом, позволяет запускать и тестировать Edge Microgateway без подключения к Интернету.

В автономном режиме не работают следующие функции, поскольку для них требуется подключение к Apigee Edge:

• OAuth и ключ API
• Квота
• Аналитика

С другой стороны, пользовательские плагины и спайк-арест работают нормально, поскольку не требуют подключения к Apigee Edge. Кроме того, новый плагин extauth позволяет авторизовать вызовы API к микрошлюзу с помощью JWT в автономном режиме.

Настройка и запуск шлюза

Чтобы запустить Edge Microgateway в автономном режиме:

1. Создайте файл конфигурации со следующим именем: $HOME/.edgemicro/ $ORG - $ENV -config.yaml

   Например:

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

2. Вставьте в файл следующий код:

   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. Экспортируйте следующую переменную среды со значением «1»:

   export EDGEMICRO_LOCAL=1

4. Выполните следующую команду start , в которой вы указываете значения для создания экземпляра локального прокси:

   edgemicro start -o $ORG -e $ENV -a $LOCAL_PROXY_NAME \
     -v $LOCAL_PROXY_VERSION -t $TARGET_URL -b $BASE_PATH

   Где:

   • $ORG — это имя «org», которое вы использовали в имени файла конфигурации.
   • $ENV — это имя «env», которое вы использовали в имени файла конфигурации.
   • $LOCAL_PROXY_NAME — это имя локального прокси, который будет создан. Вы можете использовать любое имя, какое захотите.
   • $LOCAL_PROXY_VERSION — номер версии прокси.
   • $TARGET_URL — это URL-адрес цели прокси. ( Целью является служба, которую вызывает прокси.)
   • $BASE_PATH — это базовый путь прокси. Это значение должно начинаться с косой черты. Для корневого базового пути укажите только косую черту; например, "/".

   Например:

   edgemicro start -o local -e test -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /

5. Проверьте конфигурацию.

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

   Поскольку плагин extauth находится в файле foo-bar-config.yaml , вы получаете ошибку «missing_authorization». Этот плагин проверяет JWT, который должен присутствовать в заголовке авторизации вызова API. В следующем разделе вы получите JWT, который позволит выполнять вызовы API без ошибок.

Пример: Получение токена авторизации

В следующем примере показано, как получить JWT из конечной точки JWT Edge Microgateway в Apigee Edge ( edgemicro-auth/jwkPublicKeys ). Эта конечная точка развертывается при выполнении стандартной установки и настройки Edge Microgateway. Чтобы получить JWT от конечной точки Apigee, вам необходимо сначала выполнить стандартную настройку Edge Microgateway и подключиться к Интернету. Конечная точка Apigee используется здесь только в качестве примера и не является обязательной. Если хотите, вы можете использовать другую конечную точку токена JWT. Если да, то вам нужно будет получить JWT, используя API, предоставленный для этой конечной точки.

Следующие шаги объясняют, как получить токен с помощью конечной точки edgemicro-auth/jwkPublicKeys :.

1. Вам необходимо выполнить стандартную установку и настройку Edge Microgateway, чтобы развернуть прокси-сервер edgemicro-auth в вашей организации/среде на Apigee Edge. Если вы уже выполнили этот шаг ранее, повторять его не нужно.
2. Если вы развернули Edge Microgateway в облаке Apigee, вы должны быть подключены к Интернету, чтобы вы могли получить JWT из этой конечной точки.
3. Остановить пограничный микрошлюз:

   edgemicro stop

4. В созданном ранее файле конфигурации ( $HOME/.edgemicro / org - env -config.yaml ) укажите атрибут extauth:publickey_url на конечную точку edgemicro-auth/jwkPublicKeys в вашей организации/среде Apigee Edge. Например:

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

5. Перезапустите Edge Microgateway, как вы это делали ранее, используя имена org/env, которые вы использовали в имени файла конфигурации. Например:

   edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /

6. Получите токен JWT из конечной точки авторизации. Поскольку вы используете конечную точку edgemicro-auth/jwkPublicKeys , вы можете использовать следующую команду CLI:

Вы можете создать JWT для Edge Microgateway с помощью команды edgemicro token или API. Например:

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

Где:

• your_org — это имя вашей организации Apigee, для которой вы ранее настроили Edge Microgateway.
• your_env — это среда в организации.
• Параметр i указывает ключ потребителя из приложения разработчика, в котором есть продукт, включающий прокси-сервер edgemicro-auth .
• Параметр s указывает секрет потребителя из приложения разработчика, в котором есть продукт, включающий прокси-сервер edgemicro-auth .

Эта команда просит Apigee Edge сгенерировать JWT, который затем можно использовать для проверки вызовов API.

См. также Создание токена .

Проверьте автономную конфигурацию

Чтобы протестировать конфигурацию, вызовите API с добавленным в заголовок авторизации токеном следующим образом:

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

Пример:

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

Пример вывода:

{
   "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":""
}

Использование режима локального прокси

В режиме локального прокси Edge Microgateway не требует развертывания прокси -сервера с поддержкой микрошлюза на Apigee Edge. Вместо этого вы настраиваете «локальный прокси», предоставляя имя локального прокси, базовый путь и целевой URL-адрес при запуске микрошлюза. Вызовы API к микрошлюзу затем отправляются на целевой URL-адрес локального прокси-сервера. Во всем остальном режим локального прокси работает точно так же, как и запуск Edge Microgateway в обычном режиме. Аутентификация работает так же, как и арест пиков, принудительное соблюдение квот, пользовательские плагины и т. д.

Вариант использования и пример

Режим локального прокси-сервера полезен, когда вам нужно связать только один прокси-сервер с экземпляром Edge Microgateway. Например, вы можете внедрить Edge Microgateway в Kubernetes в качестве дополнительного прокси-сервера, где микрошлюз и служба работают в одном модуле и где микрошлюз управляет трафиком, поступающим и исходящим от сопутствующей службы. На следующем рисунке показана эта архитектура, в которой Edge Microgateway действует как дополнительный прокси-сервер в кластере Kubernetes. Каждый экземпляр микрошлюза взаимодействует только с одной конечной точкой сопутствующего сервиса:

Преимущество этого стиля архитектуры заключается в том, что Edge Microgateway обеспечивает управление API для отдельных сервисов, развернутых в контейнерной среде, например в кластере Kubernetes.

Настройка режима локального прокси

Чтобы настроить Edge Microgateway для работы в режиме локального прокси, выполните следующие действия:

1. Запустите edgemicro init чтобы настроить локальную среду конфигурации точно так же, как при обычной настройке Edge Microgateway. См. также раздел Настройка Edge Microgateway .
2. Запустите edgemicro configure , как при обычной процедуре установки Edge Microgateway. Например:

   edgemicro configure -o your_org -e your_env -u your_apigee_username

   Эта команда развертывает политику Edgemicro-auth в Edge и возвращает ключ и секрет, которые вам понадобятся для запуска микрошлюза. Если вам нужна помощь, см. раздел Настройка Edge Microgateway .

3. В Apigee Edge создайте продукт API со следующими обязательными требованиями к конфигурации (всеми остальными конфигурациями вы можете управлять по своему усмотрению):
   • В продукт необходимо добавить прокси-сервер EdgeMicro-Auth . Этот прокси-сервер был развернут автоматически при запуске edgemicro configure .
   • Вы должны указать путь к ресурсу. Apigee рекомендует добавить к продукту следующий путь: /** . Дополнительные сведения см. в разделе Настройка поведения пути к ресурсу . См. также раздел «Создание продуктов API» в документации Edge.

4. В Apigee Edge создайте разработчика или, если хотите, можете использовать существующего разработчика. Для получения справки см. Добавление разработчиков с помощью пользовательского интерфейса управления Edge .

5. В Apigee Edge создайте приложение для разработчика. Вы должны добавить продукт API, который вы только что создали, в приложение. Для получения справки см. Регистрация приложения в пользовательском интерфейсе управления Edge .
6. На компьютере, где установлен Edge Microgateway, экспортируйте следующую переменную среды со значением «1».

   export EDGEMICRO_LOCAL_PROXY=1

7. Выполните следующую команду 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

   Где:

   • your_org — ваша организация Apigee.
   • your_environment — это среда в вашей организации.
   • your_key — это ключ, который был возвращен при запуске edgemicro configure .
   • your_secret — это секрет, который был возвращен при запуске edgemicro configure .
   • local_proxy_name — имя локального прокси, который будет создан.
   • local_proxy_version — это номер версии прокси.
   • target_url — URL-адрес цели прокси (службы, которую будет вызывать прокси).
   • base_path — это базовый путь прокси. Это значение должно начинаться с косой черты. Для корневого базового пути укажите только косую черту; например, "/".

   Например:

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

Тестирование конфигурации

Вы можете проверить конфигурацию локального прокси-сервера, вызвав конечную точку прокси-сервера. Например, если вы указали базовый путь /echo , вы можете вызвать прокси следующим образом:

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

Этот первоначальный вызов API привел к ошибке, поскольку вы не предоставили действительный ключ API. Вы можете найти ключ в созданном вами ранее приложении разработчика. Откройте приложение в пользовательском интерфейсе Edge, скопируйте ключ потребителя и используйте его следующим образом:

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

Например:

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

Пример вывода:

{
  "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":""
}

Использование синхронизатора

В этом разделе объясняется, как использовать синхронизатор — дополнительную функцию, которая повышает отказоустойчивость Edge Microgteway, позволяя ему получать данные конфигурации из Apigee Edge и записывать их в локальную базу данных Redis. При работающем экземпляре синхронизатора другие экземпляры Edge Microgateway, работающие на разных узлах, могут получать свою конфигурацию непосредственно из этой базы данных.

Функция синхронизатора в настоящее время поддерживается для работы с Redis 5.0.x.

Что такое синхронизатор?

Синхронизатор обеспечивает уровень устойчивости Edge Microgateway. Это помогает гарантировать, что каждый экземпляр Edge Microgateway использует одну и ту же конфигурацию и что в случае сбоя в работе Интернета экземпляры Edge Microgateway смогут запуститься и работать правильно.

По умолчанию экземпляры Edge Microgateway должны иметь возможность взаимодействовать с Apigee Edge для получения и обновления данных своей конфигурации, таких как прокси-сервер API и конфигурации продуктов API. Если подключение к Интернету с Edge прерывается, экземпляры микрошлюза могут продолжать работать, поскольку последние данные конфигурации кэшируются. Однако новые экземпляры микрошлюза не могут запуститься без четкого соединения. Кроме того, сбой в работе Интернета может привести к тому, что один или несколько экземпляров микрошлюза будут работать с информацией о конфигурации, которая не синхронизирована с другими экземплярами.

Синхронизатор Edge Microgateway предоставляет экземплярам Edge Microgateway альтернативный механизм для получения данных конфигурации, необходимых им для запуска и обработки прокси-трафика API. Данные конфигурации, полученные в результате вызовов Apigee Edge, включают: вызов jwk_public_keys , вызов jwt_public_key , вызов начальной загрузки и вызов продуктов API. Синхронизатор позволяет всем экземплярам Edge Microgateway, работающим на разных узлах, правильно запускаться и оставаться синхронизированными, даже если интернет-соединение между Edge Microgateway и Apigee Edge нарушено.

Синхронизатор — это специально настроенный экземпляр Edge Microgateway. Его единственная цель — опрос Apigee Edge (время настраивается), получение данных конфигурации и запись их в локальную базу данных Redis. Сам экземпляр синхронизатора не может обрабатывать трафик прокси-сервера API. Другие экземпляры Edge Microgateway, работающие на разных узлах, можно настроить для получения данных конфигурации из базы данных Redis, а не из Apigee Edge. Поскольку все экземпляры микрошлюзов извлекают данные конфигурации из локальной базы данных, они могут запускаться и обрабатывать запросы API даже в случае сбоя в работе Интернета.

Настройка экземпляра синхронизатора

Добавьте следующую конфигурацию в файл org-env /config.yaml для установки Edge Microgateway, который вы хотите использовать в качестве синхронизатора:

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

Например:

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

Вариант	Описание
redisHost	Хост, на котором работает ваш экземпляр Redis. По умолчанию: 127.0.0.1
redisPort	Порт экземпляра Redis. По умолчанию: 6379
redisDb	Используемая база данных Redis. По умолчанию: 0
redisPassword	Пароль вашей базы данных.

Наконец, сохраните файл конфигурации и запустите экземпляр Edge Microgateway. Он начнет опрашивать Apigee Edge и сохранять загруженные данные конфигурации в базе данных Redis.

Настройка обычных экземпляров Edge Microgateway

При работающем синхронизаторе вы можете настроить дополнительные узлы Edge Microgateway для запуска обычных экземпляров микрошлюза, обрабатывающих прокси-трафик API. Однако вы настраиваете эти экземпляры для получения данных конфигурации из базы данных Redis, а не из Apigee Edge.

Добавьте следующую конфигурацию в файл org-env /config.yaml каждого дополнительного узла Edge Microgateway. Обратите внимание, что для свойства synchronizerMode установлено значение 0 . Это свойство позволяет экземпляру работать как обычный экземпляр Edge Microgateway, который обрабатывает трафик прокси-сервера API, и экземпляр будет получать данные конфигурации из базы данных Redis.

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

Например:

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

Свойства конфигурации

Для поддержки использования синхронизатора были добавлены следующие свойства конфигурации:

Атрибут	Ценности	Описание
edge_config.synchronizerMode	0 или 1	Если 0 (по умолчанию) Edge Microgateway работает в своем стандартном режиме. Если 1, запустите экземпляр Edge Microgateway, чтобы работать как синхронизатор. В этом режиме экземпляр будет извлекать данные конфигурации из Apigee Edge и сохранить их в базе данных Local Redis. Этот экземпляр не может обрабатывать запросы прокси API; Единственная цель - опросить Edge Apigee для данных конфигурации и записать его в локальную базу данных. Затем вы должны настроить другие экземпляры Microgateway для чтения из базы данных.
edge_config.redisBasedConfigCache	правда или ложь	Если true, экземпляр Edge Microgateway извлекает свои данные конфигурации из базы данных REDIS вместо Apigee Edge. База данных REDIS должна быть той же самой, которую настроен синхронизатор. Если база данных Redis недоступна или если база данных пуста, Microgateway ищет существующий файл cache-config.yaml для его конфигурации. Если false (по умолчанию), экземпляр Edge Microgateway извлекает данные конфигурации от Apigee Edge, как обычно.
edgemicro.config_change_poll_interval	Интервал времени, в секунды	Определяет интервал опроса для синхронизатора, чтобы извлечь данные из Apigee Edge.

Настройка исключения URL -адресов для плагинов

Вы можете настроить Microgateway, чтобы пропустить обработку плагинов для указанных URL -адресов. Вы можете настроить эти URL -адреса «исключать» глобально (для всех плагинов) или для конкретных плагинов.

Например:

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

В этом примере плагины не будут обрабатывать входящие прокси -вызовы API с помощью Paths /hello или /proxy_one . Кроме того, плагин json2xml будет пропущен для API с /hello/xml на их пути.

Настройка атрибутов конфигурации со значениями переменных среды

Вы можете указать переменные среды, используя теги в файле конфигурации. Указанные теги переменной среды заменяются фактическими значениями переменной среды. Замены хранятся только в памяти и не хранятся в исходных файлах конфигурации или кэша.

В этом примере key атрибута заменяется значением переменной среды TARGETS_SSL_CLIENT_KEY и т. Д.

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

В этом примере тег <n> используется для указания целочисленного значения. Поддерживаются только положительные целые числа.

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

В этом примере тег <b> используется для обозначения логического (то есть истинного или ложного) значения.

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

,

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация

Edge Microgateway v. 3.2.x

В этом разделе обсуждается, как управлять и настраивать Edge Microgateway.

Обновление Edge Microgateway, если у вас есть подключение к Интернету

В этом разделе объясняется, как обновить существующую установку Edge Microgateway. Если вы работаете без подключения к Интернету, см. раздел Могу ли я установить Edge Microgateway без подключения к Интернету? .

Apigee рекомендует протестировать существующую конфигурацию с новой версией перед обновлением производственной среды.

1. Выполните следующую команду npm , чтобы обновить Edge Microgateway до последней версии:

   npm upgrade edgemicro -g

   Чтобы установить определенную версию Edge Microgateway, вам необходимо указать номер версии в команде установки. Например, чтобы установить в версию 3.2.3, используйте следующую команду:

   npm install edgemicro@3.2.3 -g

2. Проверьте номер версии. Например, если вы установили версию 3.2.3:

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

3. Наконец, обновите прокси-сервер Edgemicro-auth до последней версии:

   edgemicro upgradeauth -o $ORG -e $ENV -u $USERNAME

Внесение изменений в конфигурацию

Файлы конфигурации, о которых вам нужно знать, включают:

• Файл конфигурации системы по умолчанию
• Файл конфигурации по умолчанию для вновь инициализированного экземпляра Edge Microgateway.
• Файл динамической конфигурации для запуска экземпляров

В этом разделе обсуждаются эти файлы и то, что вам нужно знать об их изменении.

Файл конфигурации системы по умолчанию

Когда вы устанавливаете Edge Microgateway, здесь размещается файл конфигурации системы по умолчанию:

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

Где prefix — это каталог префикса npm . См. раздел «Где установлен Edge Microgateway», если вы не можете найти этот каталог.

Если вы измените файл конфигурации системы, вам необходимо повторно инициализировать, перенастроить и перезапустить Edge Microgateway:

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

Файл конфигурации по умолчанию для вновь инициализированных экземпляров Edge Microgateway

Когда вы запускаете edgemicro init , файл конфигурации системы (описанный выше) default.yaml помещается в каталог ~/.edgemicro .

Если вы измените файл конфигурации в ~/.edgemicro , вам необходимо перенастроить и перезапустить Edge Microgateway:

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

Файл динамической конфигурации для запуска экземпляров

Когда вы запускаете edgemicro configure [params] , файл динамической конфигурации создается в ~/.edgemicro . Имя файла соответствует следующему шаблону: org - env -config.yaml , где org и env — это имена вашей организации Apigee Edge и среды. Вы можете использовать этот файл для внесения изменений в конфигурацию, а затем перезагрузить их без простоев. Например, если вы добавите и настроите плагин, вы сможете перезагрузить конфигурацию без простоев, как описано ниже.

Если Edge Microgateway работает (опция с нулевым временем простоя):

1. Перезагрузите конфигурацию Edge Microgateway:

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

   Где:

   • $ORG — это название вашей организации Edge (вы должны быть администратором организации).
   • $ENV — это среда вашей организации (например, «test» или «prod»).
   • $KEY — это ключ, возвращенный ранее командой configure.
   • $SECRET — это ключ, возвращенный ранее командой configure.

   Например

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

Если Edge Microgateway остановлен:

1. Перезапустите Edge Microgateway:

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

   Где:

   • $ORG — это название вашей организации Edge (вы должны быть администратором организации).
   • $ENV — это среда в вашей организации (например, «тестовая» или «рабочая»).
   • $KEY — это ключ, возвращенный ранее командой configure.
   • $SECRET — это ключ, возвращенный ранее командой configure.

   Например:

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

Вот пример файла конфигурации. Подробные сведения о настройках файла конфигурации см. в разделе Справочник по настройке 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

Установка переменных среды

Команды интерфейса командной строки, которым требуются значения для вашей организации и среды Edge, а также ключ и секрет, необходимые для запуска Edge Microgateway, могут храниться в следующих переменных среды:

• EDGEMICRO_ORG
• EDGEMICRO_ENV
• EDGEMICRO_KEY
• EDGEMICRO_SECRET

Установка этих переменных не является обязательной. Если вы их установите, вам не придется указывать их значения при использовании интерфейса командной строки (CLI) для настройки и запуска Edge Microgateway.

Настройка SSL на сервере Edge Microgateway

Посмотрите следующие видеоролики, чтобы узнать о настройке TLS в Apigee Edge Microgateway:

Видео	Описание
Настройка одностороннего TLS в северном направлении	Узнайте о настройке TLS в Apigee Edge Microgateway. В этом видеоролике представлен обзор TLS и его важности, представлена ​​TLS в Edge Microgateway и показано, как настроить односторонний TLS в северном направлении.
Настройка двухсторонних TLS на север	Это второе видео о настройке TLS в Apigee Edge Microgateway. В этом видео объясняется, как настроить двусторонний TLS в северном направлении.
Настройка одностороннего и двустороннего TLS в южном направлении	В этом третьем видеоролике о настройке TLS в Apigee Edge Microgateway объясняется, как настроить односторонний и двусторонний TLS в южном направлении.

Вы можете настроить сервер Microgateway для использования SSL. Например, если настроен SSL, вы можете вызывать API через Edge Microgateway по протоколу https, например:

https://localhost:8000/myapi

Чтобы настроить SSL на сервере Microgateway, выполните следующие действия:

1. Создайте или получите сертификат и ключ SSL с помощью утилиты openssl или любого другого метода, который вы предпочитаете.
2. Добавьте атрибут edgemicro:ssl в файл конфигурации Edge Microgateway . Полный список опций смотрите в таблице ниже. Например:
   

   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. Перезапустите Edge Microgateway. Выполните действия, описанные в разделе «Внесение изменений в конфигурацию» , в зависимости от того, какой файл конфигурации вы редактировали: файл по умолчанию или файл конфигурации среды выполнения.

Вот пример раздела edgemicro файла конфигурации с настроенным 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

Вот список всех поддерживаемых опций сервера:

Вариант	Описание
key	Путь к файлу ca.key (в формате PEM).
cert	Путь к файлу ca.cert (в формате PEM).
pfx	Путь к файлу pfx , содержащему закрытый ключ, сертификат и сертификаты CA клиента в формате PFX.
passphrase	Строка, содержащая кодовую фразу для закрытого ключа или PFX.
ca	Путь к файлу, содержащему список доверенных сертификатов в формате PEM.
ciphers	Строка, описывающая используемые шифры, разделенная знаком ":".
rejectUnauthorized	Если это правда, сертификат сервера проверяется по списку предоставленных центров сертификации. Если проверка не удалась, возвращается ошибка.
secureProtocol	Используемый метод SSL. Например, SSLv3_method для принудительного использования SSL версии 3.
servername	Имя сервера для расширения TLS SNI (индикация имени сервера).
requestCert	верно для двустороннего SSL; false для одностороннего SSL

Использование параметров клиента SSL/TLS

Вы можете настроить Edge Microgateway в качестве клиента TLS или SSL при подключении к целевым конечным точкам. В файле конфигурации Microgateway используйте элемент target для установки параметров SSL/TLS. Обратите внимание, что вы можете указать несколько конкретных целей. Многоцелевой пример включен ниже.

В этом примере представлены настройки, которые будут применены ко всем хостам:

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

В этом примере настройки применяются только к указанному хосту:

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

Вот пример для TLS:

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

В случае, когда вы хотите применить настройки TLS/SSL к нескольким конкретным целям, необходимо указать первый хост в конфигурации как «пустой», который позволяет универсальные запросы, а затем указать конкретные хост в любом порядке. В этом примере настройки применяются к нескольким конкретным хостам:

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

Вот список всех поддерживаемых опций клиента:

Вариант	Описание
pfx	Путь к файлу pfx , содержащему закрытый ключ, сертификат и сертификаты CA клиента в формате PFX.
key	Путь к файлу ca.key (в формате PEM).
passphrase	Строка, содержащая кодовую фразу для закрытого ключа или PFX.
cert	Путь к файлу ca.cert (в формате PEM).
ca	Путь к файлу, содержащему список доверенных сертификатов в формате PEM.
ciphers	Строка, описывающая используемые шифры, разделенная знаком ":".
rejectUnauthorized	Если это правда, сертификат сервера проверяется по списку предоставленных центров сертификации. Если проверка не удалась, возвращается ошибка.
secureProtocol	Используемый метод SSL. Например, SSLv3_method для принудительного использования SSL версии 3.
servername	Имя сервера для расширения TLS SNI (индикация имени сервера).

Настройка прокси-сервера EdgeMicro-Auth

По умолчанию Edge Microgateway использует прокси-сервер, развернутый на Apigee Edge, для аутентификации OAuth2. Этот прокси-сервер развертывается при первом запуске edgemicro configure . Вы можете изменить конфигурацию этого прокси-сервера по умолчанию, чтобы добавить поддержку пользовательских утверждений в веб-токен JSON (JWT), настроить срок действия токена и создать токены обновления. Подробности см. на странице Edgemicro-auth на GitHub.

Использование пользовательской службы аутентификации

По умолчанию Edge Microgateway использует прокси-сервер, развернутый на Apigee Edge, для аутентификации OAuth2. Этот прокси-сервер развертывается при первом запуске edgemicro configure . По умолчанию URL-адрес этого прокси-сервера указан в файле конфигурации Edge Microgateway следующим образом:

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

Если вы хотите использовать собственную службу для аутентификации, измените значение authUri в файле конфигурации, чтобы оно указывало на вашу службу. Например, у вас может быть служба, использующая LDAP для проверки личности.

Управление файлами журналов

Edge Microgateway регистрирует информацию о каждом запросе и ответе. Файлы журналов предоставляют полезную информацию для отладки и устранения неполадок.

Где хранятся файлы журнала

По умолчанию файлы журналов хранятся в /var/tmp .

Как изменить каталог файла журнала по умолчанию

Каталог, в котором хранятся файлы журналов, указан в файле конфигурации Edge Microgateway. См. также Внесение изменений в конфигурацию .

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

Измените значение dir , чтобы указать другой каталог файла журнала.

Отправить журналы в консоли

Вы можете настроить ведение журнала так, чтобы информация журнала отправлялась на стандартный вывод, а не в файл журнала. Установите для флага to_console значение true следующим образом:

edgemicro:
  logging:
    to_console: true

При этой настройке журналы будут отправляться на стандартный выход. В настоящее время вы не можете отправлять журналы одновременно на стандартный вывод и в файл журнала.

Как установить уровень журналирования

Вы указываете уровень журнала для использования в конфигурации edgemicro . Для полного списка уровней журнала и их описаний см. Edgemicro Attributes .

Например, следующая конфигурация устанавливает уровень журнала для 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

Как изменить интервалы журнала

Эти интервалы можно настроить в файле конфигурации Edge Microgateway. См. также Внесение изменений в конфигурацию .

Настраиваемые атрибуты:

• stats_log_interval : (по умолчанию: 60) Интервал в секундах, в течение которого запись статистики записывается в файл журнала API.
• Rotate_interval : (по умолчанию: 24) Интервал ротации файлов журналов в часах. Например:

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

Как расслабить строгие разрешения файла журнала

По умолчанию Edge Microgateway генерирует файл журнала приложений ( api-log.log ) с уровнем разрешения файла, установленным на 0600. Этот уровень разрешения не позволяет внешним приложениям или пользователям читать файл журнала. Чтобы расслабить этот строгий уровень разрешения, установите logging:disableStrictLogFile в true . Когда этот атрибут true , файл журнала создается с разрешением файла, установленным 0755. Если false или если атрибут не предоставлен, разрешение по умолчанию по умолчанию на 0600.

Добавлено в V3.2.3.

Например:

edgemicro:
 logging:
   disableStrictLogFile: true

Хорошие методы обслуживания файлов журналов

Поскольку данные файла журнала со временем накапливаются, Apigee рекомендует вам принять следующие меры:

• Поскольку файлы журнала могут стать довольно большими, убедитесь, что каталог файлов журнала имеет достаточное пространство. См. следующие разделы «Где хранятся файлы журналов» и «Как изменить каталог файлов журналов по умолчанию» .
• Либо удаляйте, либо перемещайте файлы журналов в отдельный архивный каталог не реже одного раза в неделю.
• Если ваша политика предполагает удаление журналов, вы можете использовать команду CLI edgemicro log -c для удаления (очистки) старых журналов.

Соглашение об именовании файлов журнала

Каждый экземпляр Edge Microgateway создает файл журнала с расширением .log . Конвенция об именах для файлов журнала следующее:

edgemicro- HOST_NAME - INSTANCE_ID -api.log

Например:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log

О содержимом файла журнала

Добавлено: v2.3.3

По умолчанию служба ведения журналов опускает JSON загруженных прокси-серверов, продуктов и веб-токен JSON (JWT). Если вы хотите вывести эти объекты в консоли, установите командную линию DEBUG=* когда вы запускаете Edge Microgateway. Например:

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

Содержимое файла журнала «api»

Файл журнала API содержит подробную информацию о потоке запросов и ответов через Edge Microgateway. Файлы журнала «api» называются следующим образом:

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

Для каждого запроса к Edge Microgateway в файле журнала API фиксируются четыре события:

• Входящий запрос от клиента
• Исходящий запрос к цели
• Входящий ответ от цели
• Исходящий ответ клиенту

Каждая из этих отдельных записей представлена ​​в сокращенной записи, что помогает сделать файлы журналов более компактными. Вот четыре примера записей, представляющих каждое из четырех событий. В файле журнала они выглядят следующим образом (номера строк в документе приведены только для справки, в файле журнала они не отображаются).

(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

Давайте посмотрим на них один за другим:

1. Образец входящего запроса от клиента:

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

• 1436403888651 — отметка даты Unix
• Информация - уровень ведения журнала. Это значение зависит от контекста транзакции и уровня журнала, установленного в конфигурации edgemicro . Посмотрите , как установить уровень журнала . Для записей статистики уровень устанавливается на stats . Статистические записи сообщаются в обычном интервале с конфигурацией stats_log_interval . Смотрите также , как изменить интервалы журнала .
• req — идентифицирует событие. В данном случае запрос от клиента.
• m — HTTP-глагол, используемый в запросе.
• u — часть URL-адреса, следующая за базовым путем.
• h — номер хоста и порта, на котором прослушивает Edge Microgateway.
• r — удаленный хост и порт, откуда поступил клиентский запрос.
• i — идентификатор запроса. Все четыре записи о событиях будут использовать этот идентификатор. Каждому запросу присваивается уникальный идентификатор запроса. Сопоставление записей журнала по идентификатору запроса может дать ценную информацию о задержке цели.
• d — продолжительность в миллисекундах с момента получения запроса Edge Microgateway. В приведенном выше примере ответ цели на запрос 0 был получен через 7 миллисекунд (строка 3), а ответ был отправлен клиенту еще через 4 миллисекунды (строка 4). Другими словами, общая задержка запроса составила 11 миллисекунд, из которых 7 миллисекунд заняла цель и 4 миллисекунды — сам Edge Microgateway.

2. Пример исходящего запроса к цели:

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

• 1436403888651 — отметка даты Unix
• Информация - уровень ведения журнала. Это значение зависит от контекста транзакции и уровня журнала, установленного в конфигурации edgemicro . Посмотрите , как установить уровень журнала . Для записей статистики уровень устанавливается на stats . Статистические записи сообщаются в обычном интервале с конфигурацией stats_log_interval . Смотрите также , как изменить интервалы журнала .
• treq — идентифицирует событие. В данном случае целевой запрос.
• M - HTTP -глагол, используемый в целевом запросе.
• u — часть URL-адреса, следующая за базовым путем.
• h — хост и номер порта целевой серверной части.
• i — идентификатор записи журнала. Все четыре записи о событиях будут использовать этот идентификатор.

3. Образец входящего ответа от цели

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

1436403888651 — отметка даты Unix

• Информация - уровень ведения журнала. Это значение зависит от контекста транзакции и уровня журнала, установленного в конфигурации edgemicro . Посмотрите , как установить уровень журнала . Для записей статистики уровень устанавливается на stats . Статистические записи сообщаются в обычном интервале с конфигурацией stats_log_interval . Смотрите также , как изменить интервалы журнала .
• tres — идентифицирует событие. В данном случае целевой ответ.
• s — статус ответа HTTP.
• d - Продолжительность в миллисекундах. Время, затраченное на вызов API целью.
• i — идентификатор записи журнала. Все четыре записи о событиях будут использовать этот идентификатор.

4. Образец исходящего ответа клиенту

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

1436403888651 — отметка даты Unix

• Информация - уровень ведения журнала. Это значение зависит от контекста транзакции и уровня журнала, установленного в конфигурации edgemicro . Посмотрите , как установить уровень журнала . Для записей статистики уровень устанавливается на stats . Статистические записи сообщаются в обычном интервале с конфигурацией stats_log_interval . Смотрите также , как изменить интервалы журнала .
• res — Идентифицирует событие. В данном случае ответ клиенту.
• s — статус ответа HTTP.
• d - Продолжительность в миллисекундах. Это общее время, затраченное на вызов API, включая время, затраченное целевым API, и время, затраченное самим Edge Microgateway.
• i — идентификатор записи журнала. Все четыре записи о событиях будут использовать этот идентификатор.

Расписание файла журнала

Файлы журналов чередуются с интервалом, указанным в атрибуте конфигурации Rotate_interval . Записи будут продолжать добавляться в один и тот же файл журнала до истечения интервала ротации. Однако при каждом перезапуске Edge Microgateway он получает новый UID и создает новый набор файлов журналов с этим UID. См. также «Хорошие методы обслуживания файлов журналов» .

Сообщения об ошибках

Некоторые записи журнала будут содержать сообщения об ошибках. Чтобы определить, где и почему возникают ошибки, см. справочник по ошибкам Edge Microgateway .

Справочник по настройке Edge Microgateway

Расположение файла конфигурации

Атрибуты конфигурации, описанные в этом разделе, находятся в файле конфигурации Edge Microgateway. См. также Внесение изменений в конфигурацию .

Атрибуты Edge_config

Эти параметры используются для настройки взаимодействия между экземпляром Edge Microgateway и Apigee Edge.

• bootstrap : (по умолчанию: нет) URL-адрес, указывающий на службу Edge Microgateway, работающую в Apigee Edge. Edge Microgateway использует эту службу для связи с Apigee Edge. Этот URL-адрес возвращается при выполнении команды для создания пары открытого и закрытого ключей: edgemicro genkeys . Подробности см. в разделе Установка и настройка Edge Microgateway .
• jwt_public_key : (по умолчанию: нет) URL-адрес, указывающий на прокси-сервер Edge Microgateway, развернутый в Apigee Edge. Этот прокси-сервер служит конечной точкой аутентификации для выдачи клиентам подписанных токенов доступа. Этот URL-адрес возвращается при выполнении команды для развертывания прокси: Edgemicro configure . Подробности см. в разделе Установка и настройка Edge Microgateway .
• quotaUri : установите это свойство конфигурации, если вы хотите управлять квотами через прокси-сервер edgemicro-auth , развернутый в вашей организации. Если это свойство не задано, конечной точкой квоты по умолчанию будет внутренняя конечная точка Edge Microgateway.

  edge_config:
    quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
  

Атрибуты EdgeMicro

Эти параметры настраивают процесс Edge Microgateway.

• порт : (по умолчанию: 8000) Номер порта, который прослушивает процесс Edge Microgateway.
• max_connections : (по умолчанию: -1) Определяет максимальное количество одновременных входящих подключений, которые может принять Edge Microgateway. Если это число превышено, возвращается следующий статус:
  
  res.statusCode = 429; // Too many requests
  
• max_connections_hard : (по умолчанию: -1) Максимальное количество одновременных запросов, которые Edge Microgateway может получить перед отключением соединения. Этот параметр предназначен для предотвращения атак типа «отказ в обслуживании». Обычно установите его на число, большее, чем max_connections.
• регистрация :
  • уровень : (по умолчанию: ошибка)
    • Информация - (рекомендуется) регистрирует все запросы и ответы, которые проходят через экземпляр Edge Microgateway.
    • alert — регистрирует только предупреждающие сообщения.
    • error — регистрируются только сообщения об ошибках.
    • DEBUG - журналы отладка сообщений вместе с информацией, предупреждением и сообщениями об ошибках.
    • Trace - журналы трассировки Информации по ошибкам вместе с информацией, предупреждением и сообщениями об ошибках.
    • Нет - не создавайте файл журнала.
  • dir : (по умолчанию: /var/tmp) Каталог, в котором хранятся файлы журналов.
  • stats_log_interval : (по умолчанию: 60) Интервал в секундах, в течение которого запись статистики записывается в файл журнала API.
  • Rotate_interval : (по умолчанию: 24) Интервал ротации файлов журналов в часах.

• плагины : плагины добавляют функциональность Edge Microgateway. Подробную информацию о разработке плагинов см. в разделе «Разработка пользовательских плагинов» .

• Dir : относительный путь от каталога ./gateway до каталога ./plugins или абсолютного пути.
• последовательность : список модулей плагинов, которые можно добавить в экземпляр Edge Microgateway. Модули будут выполняться в том порядке, в котором они указаны здесь.

• отладка: добавляет удаленную отладку в процесс Edge Microgateway.
  • порт : номер порта для прослушивания. Например, настройте отладчик IDE на прослушивание этого порта.
  • args : Аргументы процесса отладки. Например: args --nolazy
    
• config_change_poll_interval: (по умолчанию: 600 секунд) Edge Microgateway периодически загружает новую конфигурацию и выполняет перезагрузку, если что-то изменилось. Опрос фиксирует любые изменения, внесенные в Edge (изменения в продуктах, прокси-серверах с поддержкой микрошлюзов и т. д.), а также изменения, внесенные в локальный файл конфигурации.
  
• Disable_config_poll_interval: (по умолчанию: false) Установите значение true , чтобы отключить автоматический опрос изменений.
• request_timeout : устанавливает тайм-аут для целевых запросов. Таймаут задается в секундах. Если происходит тайм-аут, Edge Microgateway отвечает кодом состояния 504. (Добавлено v2.4.x)
• Keep_alive_timeout : это свойство позволяет вам установить тайм-аут Edge Microgateway (в миллисекундах). (По умолчанию: 5 секунд) (Добавлено v3.0.6)
• headers_timeout : этот атрибут ограничивает время (в миллисекундах), в течение которого парсер HTTP будет ждать получения полных заголовков HTTP.

  Например:

  edgemicro:
    keep_alive_timeout: 6000
    headers_timeout: 12000

  Внутри этот параметр устанавливает атрибут Node.js Server.headersTimeout для запросов. (По умолчанию: на 5 секунд больше, чем время, установленное с помощью edgemicro.keep_alive_timeout . Этот параметр по умолчанию предотвращает ошибочное разрыв соединения балансировщиками нагрузки или прокси-серверами.) (Добавлено v3.1.1)

• NoruleMatchAction: (String) Действие, которое необходимо предпринять (разрешить или отклонить доступ), если правило соответствия, указанное в плагине accesscontrol , не разрешено (не имеет себе равных). Допустимые значения: ALLOW или DENY по умолчанию: ALLOW (добавлено: v3.1.7)
• EnableAnalytics: (по умолчанию: true) Установите атрибут FALSE, чтобы предотвратить загрузка плагина Analytics. В этом случае не будет сделано никаких призывов к аналитике Apigee Edge. Если установить на TRUE , или когда этот атрибут не будет предоставлен, плагин Analytics будет работать как обычно. Смотрите атрибуты Edgemicro для деталей. (Добавлен v3.1.8).

  Пример:

  edgemicro
    enableAnalytics=false|true

• ON_TARGET_RESPONSE_ABORT : этот атрибут позволяет управлять тем, как ведет себя Edge Microgateway, если соединение между клиентом (Edge Microgateway) и целевым сервером закрывается преждевременно.

  Ценить	Описание
  По умолчанию	Если on_target_response_abort не определен, то поведение по умолчанию состоит в том, чтобы усекнуть ответ, не показывая ошибку. В файлах журнала предупреждающее сообщение отображается с targetResponse aborted и кодом ответа 502.
  appendErrorToClientResponseBody	Пользовательская ошибка TargetResponseAborted возвращается клиенту. В файлах журнала предупреждающее сообщение отображается с targetResponse aborted и кодом ответа 502. Кроме того, ошибка TargetResponseAborted регистрируется с Target response ended prematurely.
  abortClientRequest	Edge Microgateway прерывает запрос, и предупреждение записывается в файлы журнала: TargetResponseAborted с кодом состояния запроса 502.

Пример:

edgemicro:
 on_target_response_abort: appendErrorToClientResponseBody | abortClientRequest

атрибуты заголовков

Эти параметры определяют, как обрабатываются определенные заголовки HTTP.

• x-forwarded-for : (по умолчанию: true) Установите значение false, чтобы предотвратить передачу заголовков x-forwarded-for цели. Обратите внимание: если в запросе присутствует заголовок x-forwarded-for, его значению будет присвоено значение client-ip в Edge Analytics.
• x-forwarded-host : (по умолчанию: true) Установите значение false, чтобы предотвратить передачу заголовков x-forwarded-host к цели.
• x-request-id : (по умолчанию: true) Установите значение false, чтобы предотвратить передачу заголовков x-request-id цели.
• x-response-time : (по умолчанию: true) Установите значение false, чтобы предотвратить передачу заголовков x-response-time в цель.
• via : (по умолчанию: true) Установите значение false, чтобы предотвратить передачу заголовков via в цель.

атрибуты oauth

Эти параметры определяют, как Edge Microgateway обеспечивает аутентификацию клиента.

• AllownoAuthorization : (по умолчанию: false) Если установлено в True, вызовы API могут проходить через Edge Microgateway без какого -либо заголовка авторизации вообще. Установите для этого параметра значение false, чтобы требовать заголовок авторизации (по умолчанию).
• allowInvalidAuthorization : (по умолчанию: false) Если установлено значение true, вызовы API разрешаются, если токен, переданный в заголовке авторизации, недействителен или срок его действия истек. Установите для этого параметра значение false, чтобы требовать действительные токены (по умолчанию).
• авторизационный-заголовок : (по умолчанию: Авторизация: Носитель) Заголовок, используемый для отправки токена доступа в Edge Microgateway. Возможно, вы захотите изменить значение по умолчанию в тех случаях, когда целевому объекту необходимо использовать заголовок авторизации для какой-либо другой цели.
• api-key-header : (по умолчанию: x-api-key) Имя заголовка или параметра запроса, используемого для передачи ключа API в Edge Microgateway. См. также Использование ключа API .
• Keep-authorization-header : (по умолчанию: false) Если установлено значение true, заголовок авторизации, отправленный в запросе, передается цели (он сохраняется).
• allowOAuthOnly — если установлено значение true, каждый API должен содержать заголовок авторизации с токеном доступа к носителю. Позволяет разрешить только модель безопасности OAuth (с сохранением обратной совместимости). (Добавлено 2.4.x)
• allowAPIKeyOnly — если установлено значение true, каждый API должен содержать заголовок x-api-key (или пользовательское местоположение) с ключом API. Позволяет разрешить только модель безопасности ключа API (при сохранении обратной совместимости). (Добавлено 2.4.x)
• GracePeriod — этот параметр помогает предотвратить ошибки, вызванные небольшими расхождениями между системными часами и временем «Не раньше» (nbf) или «Выдано в» (iat), указанным в токене авторизации JWT. Установите для этого параметра количество секунд, позволяющее учитывать такие несоответствия. (Добавлено 2.5.7)

Атрибуты, специфичные для плагина

Подробную информацию о настраиваемых атрибутах для каждого плагина см. в разделе «Использование плагинов».

Фильтрация прокси

Вы можете отфильтровать, какие прокси-серверы с поддержкой микрошлюза будет обрабатывать экземпляр Edge Microgateway. При запуске Edge Microgateway он загружает все прокси-серверы с поддержкой микрошлюза в организации, с которой он связан. Используйте следующую конфигурацию, чтобы ограничить количество прокси-серверов, которые будет обрабатывать микрошлюз. Например, эта конфигурация ограничивает количество прокси-серверов, которые микрошлюз будет обрабатывать, до трех: edgemicro_proxy-1 , edgemicro_proxy-2 и edgemicro_proxy-3 :

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

Фильтрация продуктов по имени

Используйте следующую конфигурацию, чтобы ограничить количество продуктов API, которые загружает и обрабатывает Edge Microgateway. Чтобы отфильтровать загруженные продукты, добавьте параметр запроса productnamefilter в API /products , указанный в файле Edge Microgateway *.config.yaml . Например:

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'

Обратите внимание, что значение параметра запроса должно быть указано в формате регулярного выражения и иметь URL-кодировку. Например, регулярное выражение ^[Ee]dgemicro.*$ улавливает такие имена, как «edgemicro-test-1», «edgemicro_demo» и «Edgemicro_New_Demo». Закодированное значение URL-адреса, подходящее для использования в параметре запроса: %5E%5BEe%5Ddgemicro.%2A%24 .

Следующие выходные данные отладки показывают, что были загружены только отфильтрованные продукты:

...
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":[

         ]
      }
   ]
}

Фильтрация продуктов по пользовательским атрибутам

Чтобы фильтровать продукты на основе пользовательских атрибутов:

1. В пользовательском интерфейсе Edge выберите прокси Edgemicro_auth в организации/среде, где вы настроили Edge Microgateway.
2. В разработке Tap откройте политику Javacallout в редакторе.
3. Добавьте пользовательский атрибут с ключевыми products.filter.attributes Filter.attributes с разделенным запятыми списком имен атрибутов. Только продукты, которые содержат любое из пользовательских имен атрибутов, будут возвращены в Edge Microgateway.
4. При желании вы можете отключить чек false чтобы увидеть, включен ли продукт для текущей среды, установив пользовательские products.filter.env.enable . (По умолчанию это правда.)
5. (Только частное облако) Если вы находитесь на грани для частного облака, установите свойство org.noncps на true , чтобы вытащить продукты для среда не CPS.

Например:

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

Настройка частоты отправки аналитики

Используйте эти параметры конфигурации, чтобы управлять частотой, с которой Edge Microgateway отправляет аналитические данные в Apigee:

• ufferSize (необязательно): максимальное количество аналитических записей, которое может храниться в буфере, прежде чем самые старые записи начнут удаляться. По умолчанию: 10000
• BatchSize (необязательно): максимальный размер пакета аналитических записей, отправляемых в Apigee. По умолчанию: 500
• lushInterval (необязательно): количество миллисекунд между каждой очисткой пакета аналитических записей, отправляемых в Apigee. По умолчанию: 5000

Например:

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

Маскировать данные аналитики

Следующая конфигурация предотвращает отображение информации о пути запроса в аналитике Edge. Добавьте следующее в конфигурацию микрошлюза, чтобы замаскировать URI запроса и/или путь запроса. Обратите внимание, что URI состоит из имени хоста и пути запроса.

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

Разделение вызовов API в Edge Analytics

Вы можете настроить плагин аналитики для разделения определенного пути API, чтобы он отображался как отдельный прокси на панелях мониторинга Edge Analytics. Например, вы можете выделить API проверки работоспособности на панели мониторинга, чтобы не путать его с реальными вызовами прокси-сервера API. На панели управления Analytics отдельные прокси-серверы имеют следующий шаблон именования:

edgemicro_proxyname-health

На следующем изображении показаны два отдельных прокси-сервера на панели мониторинга Analytics: edgemicro_hello-health и edgemicro_mock-health :

Используйте эти параметры, чтобы разделить относительные и абсолютные пути на панели мониторинга Analytics как отдельные прокси:

• относительный путь (необязательно): указывает относительный путь для разделения на панели мониторинга Analytics. Например, если вы укажете /healthcheck , все вызовы API, содержащие путь /healthcheck будут отображаться на информационной панели как edgemicro_ proxyname -health . Обратите внимание, что этот флаг игнорирует базовый путь прокси. Чтобы разделить на основе полного пути, включая базовый, используйте флаг proxyPath .
• proxyPath (необязательно): указывает полный путь прокси-сервера API, включая базовый путь прокси-сервера, для разделения на панели аналитики. Например, если вы укажете /mocktarget/healthcheck , где /mocktarget — это базовый путь прокси-сервера, все вызовы API с путем /mocktarget/healthcheck будут отображаться на панели мониторинга как edgemicro_ proxyname -health .

Например, в следующей конфигурации любой путь API, содержащий /healthcheck будет отделен плагином аналитики. Это означает, что /foo/healthcheck и /foo/bar/healthcheck будут выделены в отдельный прокси-сервер с именем edgemicro_ proxyname -health на панели аналитики.

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

В следующей конфигурации любой API с путем к прокси-серверу /mocktarget/healthcheck будет выделен как отдельный прокси-сервер с именем edgemicro_ proxyname -health на панели аналитики.

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

Настройка Edge Microgateway за брандмауэром компании

Используйте HTTP-прокси для связи с Apigee Edge.

Добавлено в версии 3.1.2.

Чтобы использовать HTTP-прокси для связи между Edge Microgateway и Apigee Edge, выполните следующие действия:

1. Установите переменные среды HTTP_PROXY , HTTPS_PROXY и NO_PROXY . Эти переменные управляют хостами для каждого HTTP-прокси, которые вы хотите использовать для связи с Apigee Edge, или какие хосты не должны обрабатывать связь с Apigee Edge. Например:

   export HTTP_PROXY='http://localhost:3786'
   export HTTPS_PROXY='https://localhost:3786'
   export NO_PROXY='localhost,localhost:8080'

   Обратите внимание, что NO_PROXY может представлять собой список доменов, разделенных запятыми, к которым Edge Microgateway не следует использовать прокси.

   Дополнительную информацию об этих переменных см. на странице https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables .

2. Перезапустите Edge Microgateway.

Используйте HTTP-прокси для целевого взаимодействия.

Добавлено в версии 3.1.2.

Чтобы использовать HTTP-прокси для связи между Edge Microgateway и внутренними объектами, выполните следующие действия:

1. Добавьте следующую конфигурацию в файл конфигурации микрошлюза:

   edgemicro:
     proxy:
       tunnel: true | false
       url: proxy_url
       bypass: target_host # target hosts to bypass the proxy.
       enabled: true | false

   Где:

   • туннель : (Необязательно) Если установлено значение true, Edge Microgateway использует метод HTTP CONNECT для туннелирования HTTP-запросов через одно TCP-соединение. (То же самое верно, если для переменных среды, как указано ниже, для настройки прокси-сервера включен TLS). По умолчанию: false
   • url : URL-адрес HTTP-прокси.
   • bypass : (Необязательно) Указывает один или несколько URL-адресов целевого хоста, разделенных запятыми, которые должны обходить HTTP-прокси. Если это свойство не установлено, используйте переменную среды NO_PROXY, чтобы указать, какие целевые URL-адреса следует обходить.
   • включено : если установлено значение true и proxy.url , используйте значение proxy.url для HTTP-прокси. Если true и proxy.url не установлены, используйте прокси, указанные в переменных среды HTTP-прокси HTTP_PROXY и HTTPS_PROXY , как описано в разделе Использование HTTP-прокси для связи с Apigee Edge .

   Например:

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

2. Перезапустите Edge Microgateway.

Использование подстановочных знаков в прокси-серверах с поддержкой Microgateway

Вы можете использовать один или несколько подстановочных знаков «*» в базовом пути прокси-сервера Edgemicro_* (с поддержкой Microgateway). Например, базовый путь /team/*/members позволяет клиентам вызывать https://[host]/team/blue/members и https://[host]/team/green/members без необходимости создавать новые API-прокси для поддержки новых команд. Обратите внимание, что /**/ не поддерживается.

Важно: Apigee НЕ поддерживает использование подстановочного знака «*» в качестве первого элемента базового пути. Например, НЕ поддерживается: /*/ search.

Вращение ключей JWT

Через некоторое время после первоначального создания JWT вам может потребоваться изменить пару открытого и закрытого ключей, хранящуюся в KVM, зашифрованном Edge. Этот процесс создания новой пары ключей называется ротацией ключей.

Как Edge Microgateway использует jwts

JSON Web Token (JWT) — это стандарт токена, описанный в RFC7519 . JWT предоставляет способ подписать набор утверждений, который может быть надежно проверен получателем JWT.

Вы можете генерировать JWT с помощью CLI и использовать его в заголовке авторизации вызовов API вместо ключа API. Например:

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

Для получения информации о создании JWT с CLI см. Generate токен .

Что такое ротация ключей?

Через некоторое время после первоначального создания JWT вам может потребоваться изменить пару открытого и закрытого ключей, хранящуюся в KVM, зашифрованном Edge. Этот процесс создания новой пары ключей называется ротацией ключей. При ротации ключей создается новая пара частного/открытого ключей, которая сохраняется в KVM «микрошлюза» в вашей организации/среде Apigee Edge. Кроме того, старый открытый ключ сохраняется вместе с исходным значением идентификатора ключа.

Чтобы сгенерировать JWT, Edge использует информацию, хранящуюся в зашифрованном KVM. KVM под названием microgateway был создан и заполнен ключами при первоначальной установке (настройке) Edge Microgateway. Ключи KVM используются для подписи и шифрования JWT.

Ключи KVM включают в себя:

• Private_key — последний (последний созданный) закрытый ключ RSA, используемый для подписи JWT.

• public_key — последний (последний созданный) сертификат, используемый для проверки JWT, подписанных с помощью частного_ключа.

• Private_key_kid — последний (последний созданный) идентификатор закрытого ключа. Этот идентификатор ключа связан со значением Private_key и используется для поддержки ротации ключей.

• public_key1_kid — последний (последний созданный) идентификатор открытого ключа. Этот ключ связан со значением public_key1 и используется для поддержки ротации ключей. Это значение такое же, как и у закрытого ключа kid.

• public_key1 — последний (самый последний созданный) открытый ключ.

Когда вы выполняете вращение ключей, существующие значения ключей заменяются на карте, а новые ключи добавляются, чтобы сохранить старые общественные ключи. Например:

• public_key2_kid - старый идентификатор публичного ключа. Этот ключ связан со значением public_key2 и используется для поддержки вращения ключей.

• public_key2 - старый открытый ключ.

JWTS, представленные для проверки, будут проверены с использованием нового открытого ключа. Если проверка не удается, тогда будет использоваться старый открытый ключ, пока не истекает jwt (после интервала token_expiry*, по умолчанию 30 минут). Таким образом, вы можете «повернуть» клавиши, не сразу нарушая трафик API.

Как сделать ключевое вращение

В этом разделе объясняется, как выполнить вращение ключа.

1. Чтобы обновить KVM, используйте команду edgemicro upgradekvm . Для получения подробной информации о запуске этой команды см. Обновление KVM . Вам нужно сделать этот шаг только один раз.
2. Чтобы обновить прокси Edgemicro-OAuth , используйте команду edgemicro upgradeauth . Для получения подробной информации о запуске этой команды см. Ugaring the Edgemicro-Auth Proxy . Вам нужно сделать этот шаг только один раз.
3. Добавьте следующую строку в свой файл ~/.edgemicro/org-env-config.yaml , где вы должны указать ту же организацию и среду, что и на настроек Microgateway для использования:

   jwk_public_keys: 'https://$ORG-$ENV.apigee.net/edgemicro-auth/jwkPublicKeys'

4. Запустите команду поворота ключа, чтобы повернуть клавиши. Для получения подробной информации об этой команде см. Вращающиеся ключи .

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

   Например:

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

После вращения ключей Edge возвращает несколько клавиш в Edge Microgateway. ПРИМЕЧАНИЕ В следующем примере каждый ключ имеет уникальное значение «Kid» (ID ключа). Затем Microgateway использует эти ключи для проверки токенов авторизации. Если проверка токена не удается, Microgateway смотрит, есть ли более старый ключ в наборе ключей, и пытается этот ключ. Форматом возвращаемых ключей является веб -ключ JSON (JWK). Вы можете прочитать об этом формате в 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"
    }
  ]
}

Настройка задержки «не раньше»

Для версий 3.1.5 и до того, как новый личный ключ, сгенерированный командой rotatekey вступил в силу немедленно, и сгенерированные новые токены были подписаны с новым закрытым ключом. Тем не менее, новый общедоступный ключ был доступен только для экземпляров Microgateway каждые 10 минут (по умолчанию), когда конфигурация Microgateway была обновлена. Из -за этого задержки между обновлением экземпляра Microgateway, подписанными с последним ключом, будут отклонены до тех пор, пока все экземпляры Microgateway будут отклонены до тех пор, пока все экземпляры не получили публичный последний ключ.

В тех случаях, когда существуют многочисленные экземпляры микрогейтвея, задержка открытого ключа иногда приводила к прерывистым ошибкам времени выполнения со состоянием 403, потому что проверка токена проходила бы один экземпляр, но не удастся в другом экземпляре, пока все экземпляры не будут обновлены.

Начиная с версии 3.1.6, новый флаг в команде rotatekey позволяет вам указать задержку для нового частного ключа, что позволяет обновить все экземпляры Microgateway и получить новый открытый ключ. Новый флаг --nbf , который означает «не раньше». Этот флаг требует целочисленного значения, количество минут задержки.

В следующем примере задержка установлена ​​на 15 минут:

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

Обратите внимание, что хорошая практика - установить задержку, чтобы быть больше, чем настройка конфигурации config_change_poll_internal , которая по умолчанию составляет 10 минут. Смотрите также атрибуты Edgemicro .

Фильтрация загруженных прокси

По умолчанию Edge Microgateway загружает все прокси в вашей организации Edge, которые начинаются с префикса именования "Edgemicro_". Вы можете изменить это значение по умолчанию, чтобы загрузить прокси, чьи имена соответствуют шаблону.

1. Откройте свой файл Micro конфигурации Edge: ~/.edgemicro/org-env-config.yaml
2. Добавьте элемент ProxyPattern в Edge_Config. Например, следующий шаблон будет загружать прокси, такие как edgemicro_foo, edgemicro_fast и edgemicro_first.

   edge_config:
   …
   proxyPattern: edgemicro_f*

Определение продуктов без прокси API

В Apigee Edge вы можете создать продукт API, который не содержит никаких прокси API. Эта конфигурация продукта позволяет клавишу API, связанного с этим продуктом, для работы с любым прокси, развернутым в вашей организации. Начиная с версии 2.5.4, Edge Microgateway поддерживает эту конфигурацию продукта.

Отладка и устранение неполадок

Подключение к отладчику

Вы можете запустить Edge Microgateway с отладчиком, таким как Node-Inspector . Это полезно для устранения неполадок и отладки пользовательских плагинов.

1. Перезапустите Edge Microgateway в режиме отладки. Для этого добавьте DEBUG=* в начало команды start :

   DEBUG=* edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET

   Чтобы направить вывод отладки в файл, вы можете использовать эту команду:

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

2. Начните свой отладчик и установите его для прослушивания на номере порта для процесса отладки.
3. Теперь вы можете пройти через код Edge Microgateway, установить точки останова, смотреть выражения и так далее.

Вы можете указать стандартные флаги Node.js, связанные с режимом отладки. Например, --nolazy помогает в отладке асинхронного кода.

Проверка файлов журналов

Если у вас возникли проблемы, обязательно изучите файлы журнала для получения данных выполнения и информации об ошибках. Подробности см. в разделе «Управление файлами журналов» .

Использование безопасности ключа API

Ключи API обеспечивают простой механизм для аутентификации клиентов, которые выполняют запросы на Edge Microgateway. Вы можете получить ключ API, копируя ключ потребителя (также называемый идентификатор клиента) из продукта Apigee Edge, который включает в себя прокси -сервер аутентификации Edge Microgateway.

Кэширование ключей

Ключи API обмениваются на токены для носителей, которые кэшируются. Вы можете отключить кэширование, установив Cache-Control: no-cache на входящих запросах на Edge Microgateway.

Использование ключа API

Вы можете передать ключ API в запросе API в качестве параметра запроса или в заголовке. По умолчанию название заголовка и параметров запроса-это x-api-key .

Пример параметра запроса:

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

Пример заголовка:

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

Настройка имени ключа API

По умолчанию x-api-key -это имя, используемое как для заголовка ключа API, так и для параметра запроса. Вы можете изменить это по умолчанию в файле конфигурации, как объяснено при внесении изменений конфигурации . Например, чтобы изменить имя на Apikey :

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

В этом примере как параметр запроса, так и имя заголовка изменены на apiKey . Имя x-api-key больше не будет работать ни в одном случае. См. также Внесение изменений в конфигурацию .

Например:

curl http://localhost:8000/foobar -H "apiKey:JG616Gjz7xs4t0dvpvVsGdI49G34xGsz"

Для получения дополнительной информации об использовании клавиш API с прокси -запросами см. Secure Edge Microgateway .

Включить коды ответов вверх по течению

По умолчанию плагин oauth возвращает только коды состояния ошибки 4xx, если ответ не составляет 200 статуса. Вы можете изменить это поведение, чтобы он всегда возвращал точный код 4xx или 5xx, в зависимости от ошибки.

Чтобы включить эту функцию, добавьте oauth.useUpstreamResponse: true Product в вашу конфигурацию Microgateway. Например:

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

Использование безопасности токена OAuth2

В этом разделе объясняется, как получить токены доступа OAuth2 и обновить токены. Токены доступа используются для выполнения безопасных вызовов API через микрогейт. Токены обновления используются для получения новых токенов доступа.

Как получить токен доступа

В этом разделе объясняется, как использовать прокси edgemicro-auth чтобы получить токен доступа.

Вы также можете получить токен доступа, используя команду CLI edgemicro token . Для получения подробной информации о CLI см. Управление токенами .

API 1: Отправить учетные данные в качестве параметров тела

Замените имена своих организаций и средств в URL и замените идентификатор потребителя и секретные значения потребителей, полученные из приложения разработчика на Apigee Edge для параметров корпуса client_id и 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: Отправить учетные данные в основном заголовке Auth

Отправьте клиентские учетные данные в качестве основного заголовка аутентификации и grant_type в качестве параметра формы. Эта командная форма также обсуждается в RFC 6749: Структура авторизации 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"

Пример вывода

API возвращает ответ JSON. Обратите внимание, что нет разницы между свойствами token и access_token . Вы можете использовать любой из них. Примечание, которое expires_in - это целочисленное значение, указанное в секундах.

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

Как получить токен обновления

Чтобы получить токен обновления, сделайте призыв API в конечную точку /token edgemicro-auth . Вы должны сделать этот вызов API с типом гранта password . Следующие шаги проходят через процесс.

1. Получите доступ к доступу и обновите с помощью API /token . Обратите внимание, что тип гранта является 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"
   }'

   API возвращает токен доступа и токен обновления. Ответ выглядит похоже на это. Обратите внимание, что expires_in значений с истечками натуральных значений и указан в секундах.

   {
       "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. Теперь вы можете использовать токен обновления, чтобы получить новый токен доступа, вызывая /refresh конечную точку того же API. Например:

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

   API возвращает новый токен доступа. Ответ выглядит похоже на это:

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

Постоянный мониторинг

Forever - это инструмент node.js, который автоматически перезапускает приложение Node.js в случае, если процесс снизится или имеет ошибку. Edge Microgateway имеет файл forever.json , который вы можете настроить для управления, сколько раз и с какими интервалами Edge Microgateway следует перезапустить. Этот файл настраивает службу Forever, называемую Forever-Monitor , которая управляет программно навсегда.

Вы можете найти файл forever.json в каталоге установки RODE Microgateway. Посмотрите , где установлен Edge Microgateway . Для получения подробной информации о параметрах конфигурации см. В документации Forever Monitor .

Команда edgemicro forever включает флаги, которые позволяют вам указать местоположение файла forever.json (флаг -f ) и запустить/остановить процесс мониторинга вечного мониторинга (флаг -a ). Например:

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

Для получения дополнительной информации см. Forever Monitoring в ссылке CLI.

Указание конечной точки файла конфигурации

Если вы запускаете несколько экземпляров Microgateway, вы можете управлять их конфигурациями из одного места. Вы можете сделать это, указав конечную точку HTTP, где Edge Micro может загрузить свой файл конфигурации. Вы можете указать эту конечную точку, когда вы запускаете Edge Micro, используя флаг -U .

Например:

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

где конечная точка MGConfig возвращает содержимое вашего файла конфигурации. Это файл, который по умолчанию находится в ~/.edgemicro и имеет соглашение об именах: org-env-config.yaml .

Отключение буферизации данных подключения TCP

Вы можете использовать атрибут конфигурации nodelay , чтобы отключить буферизацию данных для соединений TCP, используемых Edge Microgateway.

По умолчанию подключения TCP используйте алгоритм Nagle для буферизации данных перед отправкой. Установка nodelay на true , отключает это поведение (данные немедленно срабатывают данные каждый раз, когда называется socket.write() . Смотрите также документацию Node.js для более подробной информации.

Чтобы включить nodelay , отредактируйте файл Micro Config Edge следующим образом:

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

Запуск Edge Microgateway в автономном режиме

Вы можете запустить Edge Microgateway, полностью отключенные от любой зависимости от краев Apigee. Этот сценарий, называемый автономным режимом, позволяет запустить и проверять Microgateway без подключения к Интернету.

В автономном режиме следующие функции не работают, поскольку они требуют подключения к Apigee Edge:

• Oauth и api -ключ
• Квота
• Аналитика

С другой стороны, пользовательские плагины и арест шипа обычно работают, потому что им не требуется соединение с Apigee Edge. Кроме того, новый плагин под названием extauth позволяет авторизовать вызовы API в Microgateway с помощью JWT, находящегося в автономном режиме.

Настройка и запуск шлюза

Чтобы запустить Edge Microgateway в автономном режиме:

1. Создайте файл конфигурации, названный следующим образом: $HOME/.edgemicro/ $ORG - $ENV -config.yaml

   Например:

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

2. Вставьте следующий код в файл:

   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. Экспортируйте следующую переменную среды со значением «1»:

   export EDGEMICRO_LOCAL=1

4. Выполните следующую команду start , где вы предоставляете значения для создания локального прокси:

   edgemicro start -o $ORG -e $ENV -a $LOCAL_PROXY_NAME \
     -v $LOCAL_PROXY_VERSION -t $TARGET_URL -b $BASE_PATH

   Где:

   • $ORG - это имя «org», которое вы использовали в имени файла конфигурации.
   • $ENV - это имя «env», которое вы использовали в имени файла конфигурации.
   • $LOCAL_PROXY_NAME - это название локального прокси, которое будет создано. Вы можете использовать любое имя, какое захотите.
   • $LOCAL_PROXY_VERSION - это номер версии для прокси.
   • $TARGET_URL является URL для цели прокси. ( Цель - это сервис, который вызывает прокси.)
   • $BASE_PATH - это базовый путь прокси. Это значение должно начинаться с прямого сброса. Для корневого базового пути укажите только прямую черту; например, "/".

   Например:

   edgemicro start -o local -e test -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /

5. Проверьте конфигурацию.

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

   Поскольку плагин extauth находится в файле foo-bar-config.yaml , вы получаете ошибку «пропущенная_ауторизация». Этот плагин проверяет JWT, который должен присутствовать в заголовке авторизации вызова API. В следующем разделе вы получите JWT, который позволит API -вызовам проходить без ошибки.

Пример: получение токена авторизации

В следующем примере показано, как получить JWT от Edge Microgateway JWT Endpoint на Apigee Edge ( edgemicro-auth/jwkPublicKeys ). Эта конечная точка развернута при выполнении стандартной настройки и конфигурации Edge Microgateway. Чтобы получить JWT из конечной точки Apigee, вы должны сначала выполнить стандартную настройку Microgateway и подключаться к Интернету. Конечная точка Apigee используется здесь, например, только цели и не требуется. Вы можете использовать еще одну конечную токен JWT, если хотите. Если вы это сделаете, то вам нужно получить JWT, используя API, предоставленный для этой конечной точки.

Следующие шаги объясняют, как получить токен с использованием конечной точки edgemicro-auth/jwkPublicKeys :.

1. Вы должны выполнить стандартную настройку и конфигурацию Edge Microgateway для развертывания прокси edgemicro-auth для вашей организации/среды на Apigee Edge. Если вы сделали этот шаг ранее, вам не нужно повторять его.
2. Если вы развернули Edge Microgateway в Apigee Cloud, вы должны быть подключены к Интернету, чтобы вы могли получить JWT из этой конечной точки.
3. Stop Edge Microgateway:

   edgemicro stop

4. В ранее созданном файле конфигурации ( $HOME/.edgemicro / org env -config.yaml ), укажите атрибут extauth:publickey_url к конечной точке edgemicro-auth/jwkPublicKeys в вашей организации Apigee Edge/Environment. Например:

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

5. Перезапустите Edge Microgateway, как вы это делали, используя имена ORG/ENV, которые вы использовали в имени файла конфигурации. Например:

   edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /

6. Получите токен JWT от конечной точки авторизации. Поскольку вы используете конечную точку edgemicro-auth/jwkPublicKeys , вы можете использовать эту команду CLI:

Вы можете создать JWT для Edge Microgateway с помощью команды edgemicro token или API. Например:

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

Где:

• your_org - это название вашей организации Apigee, для которой вы ранее настроили Edge Microgateway.
• your_env - это среда в организации.
• Опция i указывает ключ потребителя из приложения разработчика, в котором есть продукт, который включает в себя прокси edgemicro-auth .
• Опция s указывает на потребительский секрет приложения разработчика, в котором есть продукт, который включает в себя прокси edgemicro-auth .

Эта команда просит Apigee Edge сгенерировать JWT, который затем можно использовать для проверки вызовов API.

См. Также Создайте токен .

Проверьте автономную конфигурацию

Чтобы проверить конфигурацию, вызовите API с токеном, добавленным в заголовке авторизации следующим образом:

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

Пример:

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

Пример вывода:

{
   "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":""
}

Использование локального прокси -режима

В локальном прокси-режиме Edge Microgateway не требует развертывания прокси -сервера Microgateway Aware на Edge. Вместо этого вы настраиваете «локальный прокси», предоставляя локальное имя прокси, BasePath и Target URL при запуске Microgateway. Вызовы API в Microgateway отправляются на целевой URL -адрес локального прокси. Во всех других отношениях локальный прокси -режим работает точно так же, как и работает Microgateway в его обычном режиме. Аутентификация работает так же, как и соблюдение ареста и квот, пользовательские плагины и так далее.

Использование и пример

Локальный прокси -режим полезен, когда вам нужно только связать один прокси с экземпляром Microgateway. Например, вы можете внедрить Edge Microgateway в Kubernetes в качестве прокси -сервера коляска, где микрогейт и сервис, каждый из которых работает в одном стручке, и где Microgateway управляет трафиком в его сопутствующий сервис и обратно. Следующий рисунок иллюстрирует эту архитектуру, где Edge Microgateway функционирует в качестве прокси -сервера коляска в кластере Kubernetes. Каждый экземпляр Microgateway разговаривает только с одной конечной точкой на его сопутствующей службе:

Преимущество этого стиля архитектуры заключается в том, что Edge Microgateway предоставляет управление API для отдельных услуг, развернутых в контейнерной среде, такой как кластер Kubernetes.

Настройка локального прокси -режима

Чтобы настроить Edge Microgateway для запуска в локальном прокси -режиме, выполните следующие действия:

1. Запустите edgemicro init , чтобы настроить свою локальную среду конфигурации, точно так же, как в типичной настройке Microgateway. См. Также Configure Edge Microgateway .
2. Запустите edgemicro configure , как в типичной процедуре настройки Microgateway. Например:

   edgemicro configure -o your_org -e your_env -u your_apigee_username

   Эта команда развертывает политику Edgemicro-Auth для Edge и возвращает ключ и секрет, что вам нужно будет запустить Microgateway. Если вам нужна помощь, см. Configure Edge Microgateway .

3. На Apigee Edge создайте продукт API и со следующими обязательными требованиями конфигурации (вы можете управлять всеми другими конфигурациями, как хотите):
   • Вы должны добавить прокси-сервер Edgemicro-Auth в продукт. Этот прокси был развернут автоматически, когда вы запустили edgemicro configure .
   • Вы должны предоставить путь ресурса. Apigee рекомендует добавить этот путь к продукту: /** . Чтобы узнать больше, см. Настройку поведения пути ресурса . См. Также Создайте продукты API в документации по краю.

4. На Apigee Edge создайте разработчика, или вы можете использовать существующего разработчика, если хотите. Для получения помощи см. Добавление разработчиков с использованием пользовательского интерфейса управления Edge .

5. На Apigee Edge создайте приложение разработчика. Вы должны добавить только что созданный вами продукт API в приложение. Для получения помощи см. Зарегистрирование приложения в пользовательском интерфейсе управления Edge .
6. На машине, где установлен Edge Microgateway, экспортируйте следующую переменную среды со значением «1».

   export EDGEMICRO_LOCAL_PROXY=1

7. Выполнить следующую команду 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

   Где:

   • your_org - ваша организация Apigee.
   • your_environment - это среда в вашей организации.
   • your_key - это ключ, который был возвращен, когда вы запустили edgemicro configure .
   • your_secret - это секрет, который был возвращен, когда вы запускали edgemicro configure .
   • local_proxy_name - это имя локальной прокси, которая будет создана.
   • local_proxy_version - это номер версии для прокси.
   • target_url - это URL для цели прокси (служба, которую позвонит прокси).
   • base_path - это базовый путь прокси. Это значение должно начинаться с прямого сброса. Для корневого базового пути укажите только прямую черту; например, "/".

   Например:

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

Тестирование конфигурации

Вы можете проверить локальную конфигурацию прокси, вызвав конечную точку прокси. Например, если вы указали базе /echo , вы можете вызвать прокси следующим образом:

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

Этот первоначальный вызов API создал ошибку, потому что вы не предоставили действительный ключ API. Вы можете найти ключ в приложении разработчика, которое вы создали ранее. Откройте приложение в пользовательском интерфейсе Edge, скопируйте ключ потребителя и используйте этот ключ следующим образом:

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

Например:

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

Пример вывода:

{
  "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":""
}

Используя синхронизатор

В этом разделе объясняется, как использовать синхронизатор, необязательную функцию, которая повышает устойчивость краевого микрогтеве, позволяя ему получить данные конфигурации из Apigee Edge и записать его в локальную базу данных Redis. С запуском экземпляра синхронизатора другие экземпляры Microgateway, работающие на разных узлах, могут извлечь свою конфигурацию непосредственно из этой базы данных.

Функция Syncrhonizer в настоящее время поддерживается для работы с Redis 5.0.x.

Что такое синхронизатор?

Синхронизатор обеспечивает уровень устойчивости для Edge Microgateway. Это помогает гарантировать, что каждый экземпляр Edge Microgateway использует ту же конфигурацию, и что в случае нарушения Интернета экземпляры Microgateway могут запускаться и работать должным образом.

По умолчанию экземпляры Microgateway должны быть в состоянии общаться с Apigee Edge, чтобы извлечь и обновлять данные их конфигурации, такие как Proxy API и конфигурации продукта API. Если подключение к интернету с краем нарушено, экземпляры Microgateway могут продолжать функционировать, потому что последние данные конфигурации кэшируются. Тем не менее, новые экземпляры Microgateway не могут запуститься без четкого соединения. Кроме того, может привести к тому, что нарушение в Интернете может привести к одному или нескольким экземплярам микрогатуэй, работающим с информацией о конфигурации, которая не синхронизирована с другими экземплярами.

Синхронизатор Edge Microgateway обеспечивает альтернативный механизм для экземпляров Edge Microgateway для извлечения данных конфигурации, которые им требуются для запуска и обработки прокси -трафика API. Данные конфигурации, полученные из вызовов в Apigee Edge, включают в себя: вызов jwk_public_keys , вызов jwt_public_key , вызов начальной загрузки и вызов продуктов API. Синхронизатор делает возможным для всех экземпляров Edge Microgateway, работающих на разных узлах, чтобы запустить должным образом и оставаться в синхронизации, даже если интернет -соединение между Edge Microgateway и Apigee Edge нарушено.

Синхронизатор - это специально настроенный экземпляр Edge Microgateway. Его единственная цель - опросить Apigee Edge (время настраивается), извлечь данные конфигурации и записать его в базу данных локальной Redis. Сам экземпляр синхронизатора не может обрабатывать прокси -трафик API. Другие экземпляры Edge Microgateway, работающие на разных узлах, могут быть настроены для извлечения данных конфигурации из базы данных Redis, а не от Apigee Edge. Поскольку все экземпляры Microgateway извлекают данные своей конфигурации из локальной базы данных, они могут запустить и обрабатывать запросы API даже в случае нарушения в Интернете.

Настройка экземпляра синхронизатора

Добавьте следующую конфигурацию в файл org-env /config.yaml для установки Edge Microgateway, которую вы хотите использовать в качестве синхронизатора:

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

Например:

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

Вариант	Описание
redisHost	Хост, на котором работает ваш экземпляр Redis. По умолчанию: 127.0.0.1
redisPort	Порт экземпляра Redis. По умолчанию: 6379
redisDb	Используемая база данных Redis. По умолчанию: 0
redisPassword	Ваша пароль базы данных.

Наконец, сохраните файл конфигурации и запустите экземпляр Edge Microgateway. Он начнет опрос Apigee Edge и хранит загруженные данные конфигурации в базе данных Redis.

Настройка регулярных экземпляров Microgateway

С помощью работающего синхронизатора вы можете настроить дополнительные узлы Edge Microgateway для запуска регулярных экземпляров Microgateway, которые обрабатывают прокси -трафик API. Тем не менее, вы настраиваете эти экземпляры для получения данных о конфигурации из базы данных Redis, а не от Apigee Edge.

Добавьте следующую конфигурацию в каждый дополнительный файл orge Microgateway Node org-env /config.yaml . Обратите внимание, что свойство synchronizerMode установлено на 0 . Это свойство устанавливает экземпляр для работы в качестве обычного экземпляра Microgateway, который обрабатывает прокси -трафик API, и экземпляр получит свои данные конфигурации из базы данных Redis.

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

Например:

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

Свойства конфигурации

Следующие свойства конфигурации были добавлены, чтобы поддержать использование синхронизатора:

Атрибут	Ценности	Описание
edge_config.synchronizerMode	0 или 1	Если 0 (по умолчанию) Edge Microgateway работает в своем стандартном режиме. Если 1, запустите экземпляр Edge Microgateway, чтобы работать как синхронизатор. В этом режиме экземпляр будет извлекать данные конфигурации из Apigee Edge и сохранить их в базе данных Local Redis. Этот экземпляр не может обрабатывать запросы прокси API; Единственная цель - опросить Edge Apigee для данных конфигурации и записать его в локальную базу данных. Затем вы должны настроить другие экземпляры Microgateway для чтения из базы данных.
edge_config.redisBasedConfigCache	правда или ложь	Если true, экземпляр Edge Microgateway извлекает свои данные конфигурации из базы данных REDIS вместо Apigee Edge. База данных REDIS должна быть той же самой, которую настроен синхронизатор. Если база данных Redis недоступна или если база данных пуста, Microgateway ищет существующий файл cache-config.yaml для его конфигурации. Если false (по умолчанию), экземпляр Edge Microgateway извлекает данные конфигурации от Apigee Edge, как обычно.
edgemicro.config_change_poll_interval	Интервал времени, в секунды	Определяет интервал опроса для синхронизатора, чтобы извлечь данные из Apigee Edge.

Настройка исключения URL -адресов для плагинов

Вы можете настроить Microgateway, чтобы пропустить обработку плагинов для указанных URL -адресов. Вы можете настроить эти URL -адреса «исключать» глобально (для всех плагинов) или для конкретных плагинов.

Например:

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

В этом примере плагины не будут обрабатывать входящие прокси -вызовы API с помощью Paths /hello или /proxy_one . Кроме того, плагин json2xml будет пропущен для API с /hello/xml на их пути.

Настройка атрибутов конфигурации со значениями переменных среды

Вы можете указать переменные среды, используя теги в файле конфигурации. Указанные теги переменной среды заменяются фактическими значениями переменной среды. Замены хранятся только в памяти и не хранятся в исходных файлах конфигурации или кэша.

В этом примере key атрибута заменяется значением переменной среды TARGETS_SSL_CLIENT_KEY и т. Д.

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

В этом примере тег <n> используется для указания целочисленного значения. Поддерживаются только положительные целые числа.

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

В этом примере тег <b> используется для обозначения логического (то есть истинного или ложного) значения.

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