Эта страница переведена с помощью Cloud Translation API.

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

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

Edge Microgateway v. 2.4.x

Обзор

В этой теме рассматривается управление и настройка Edge Microgateway, включая мониторинг, ведение журналов и отладку.

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

К числу необходимых конфигурационных файлов относятся:

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

В этом разделе рассматриваются эти файлы и то, что вам нужно знать об их изменении. Подробную информацию о настройках конфигурационных файлов см. в справочнике по настройке 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 запущен (опция с нулевым временем простоя):

Перезагрузите конфигурацию Edge Microgateway:
```
edgemicro reload -o [org] -e [env] -k [key] -s [secret]
```
Где:
- org — это название вашей организации Edge (вы должны быть администратором организации).
- env — это среда в вашей организации (например, тестовая или производственная).
- key — это ключ, возвращенный ранее командой configure.
- secret — это ключ, возвращенный ранее командой configure.
Пример
```
edgemicro reload -o docs -e test -k 701e70ee718ce6dc188016b3c39177d64a88754d615c74e1f78b6181d000723 -s 05c14356e42ed136b8dd35cf8a18531ff52d7299134677e30ef4e34ab0cc824
```

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

Перезапустите 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 701e70ee718ce6dc188016b3c39177d64a88754d615c74e1f78b6181d000723 -s 05c14356e42ed136b8dd35cf8a18531ff52d7299134677e30ef4e34ab0cc824
```

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

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

https://localhost:8000/myapi

Для настройки SSL на сервере Microgateway выполните следующие действия:

Сгенерируйте или получите SSL-сертификат и ключ, используя утилиту openssl или любой другой удобный для вас способ.
Добавьте атрибут edgemicro:ssl в конфигурационный файл Edge Microgateway. Полный список параметров см. в таблице ниже. Подробную информацию об изменении конфигурации 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 
```
Примечание: Ключ, указанный в файле ключа SSL, не должен быть зашифрован .
Перезапустите 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` содержащему закрытый ключ, сертификат и сертификаты центра сертификации клиента в формате PFX.
`passphrase`	Строка, содержащая парольную фразу для закрытого ключа или PFX-файла.
`ca`	Путь к файлу, содержащему список доверенных сертификатов в формате PEM.
`ciphers`	Строка, описывающая используемые шифры, разделённые символом ":".
`rejectUnauthorized`	Если значение истинно, сертификат сервера проверяется по списку предоставленных центров сертификации. Если проверка не удается, возвращается ошибка.
`secureProtocol`	Метод SSL для использования. Например, SSLv3_method для принудительного использования SSL версии 3.
`servername`	Имя сервера для расширения TLS SNI (Server Name Indication).
`requestCert`	true для двустороннего SSL; false для одностороннего SSL

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

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

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

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

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

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:

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

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

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

Настройка прокси-сервера edgemicro-auth

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

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

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

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

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

edgeconfig:verify_api_key_url — Установите этот URL-адрес так, чтобы он указывал на конечную точку ключа API в вашей пользовательской службе аутентификации. В прокси-сервере edgemicro-auth по умолчанию этот URL-адрес выглядит следующим образом: https://myorg-myenv.apigee.net/edgemicro-auth/publicKey.
edgeconfig:products — Укажите этот URL-адрес, чтобы он указывал на конечную точку продуктов в вашей пользовательской службе аутентификации. В стандартном прокси-сервере edgemicro-auth этот URL-адрес выглядит так: https://myorg-myenv.apigee.net/edgemicro-auth/products.

Примечание: Важно: Если вы переопределяете прокси-сервер аутентификации по умолчанию, новый прокси-сервер или служба должны возвращать ответ в формате, идентичном формату ответа прокси-сервера edgemicro-auth по умолчанию.

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

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

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

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

Вы можете установить следующие уровни логирования: info , warn и error . Рекомендуется использовать уровень info. Он регистрирует все запросы и ответы API и является уровнем по умолчанию.

Как изменить интервалы логирования

Эти интервалы можно настроить в конфигурационном файле 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

Примечание: Архивированные файлы журналов не сжимаются. При начале интервала создается новый файл журнала с новой меткой времени.

Правильные методы ведения журналов событий.

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

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

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

Каждый экземпляр Edge Microgateway создает три типа файлов журналов:

api — Регистрирует все запросы и ответы, проходящие через Edge Microgateway. В этот файл также записываются счетчики API (статистика) и ошибки.
err - Записывает в лог всё, что отправляется в стандартный поток ошибок.
out - Выводит в лог все данные, отправляемые в стандартный поток вывода.

Вот существующая система именования:

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

Например:

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

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

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

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

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

Примечание: В Windows используйте SET DEBUG=*

Содержимое файла журнала "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 — Зависит от контекста. Может быть info, warn или error в зависимости от уровня логирования. Может быть stats для записи статистики, warn для предупреждений или error для ошибок.
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 — Зависит от контекста. Может быть info, warn или error в зависимости от уровня логирования. Может быть stats для записи статистики, warn для предупреждений или error для ошибок.
treq — Идентифицирует событие. В данном случае, целевой запрос.
m — HTTP-глагол, используемый в целевом запросе.
u - Часть URL-адреса, следующая за базовым путем.
h - Номер хоста и порта целевого бэкэнда.
i - Идентификатор записи в журнале. Все четыре записи событий будут иметь этот идентификатор.

3. Пример входящего ответа от целевого объекта.

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

1436403888651 - Метка даты Unix

info — Зависит от контекста. Может быть info, warn или error в зависимости от уровня логирования. Может быть stats для записи статистики, warn для предупреждений или error для ошибок.
tres — Идентифицирует событие. В данном случае, целевую реакцию.
s - Статус HTTP-ответа.
d - Длительность в миллисекундах. Время, затраченное целевым устройством на вызов API.
i - Идентификатор записи в журнале. Все четыре записи событий будут иметь этот идентификатор.

4. Пример исходящего ответа клиенту.

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

1436403888651 - Метка даты Unix

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

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

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

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

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

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

атрибуты edge_config

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

bootstrap : (по умолчанию: none) URL-адрес, указывающий на службу, специфичную для Edge Microgateway и работающую на Apigee Edge. Edge Microgateway использует эту службу для связи с Apigee Edge. Этот URL-адрес возвращается при выполнении команды для генерации пары открытого/закрытого ключей: edgemicro genkeys . См. раздел «Настройка и конфигурирование Edge Microgateway» для получения подробной информации.
jwt_public_key : (по умолчанию: none) URL-адрес, указывающий на прокси-сервер Edge Microgateway, развернутый на Apigee Edge. Этот прокси-сервер служит конечной точкой аутентификации для выдачи подписанных токенов доступа клиентам. Этот URL-адрес возвращается при выполнении команды развертывания прокси-сервера: edgemicro configure . См. раздел «Настройка и конфигурирование Edge Microgateway» для получения подробной информации.

атрибуты 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.
  - Предупреждение - Регистрирует только предупреждающие сообщения.
  - error - Регистрирует только сообщения об ошибках.
- dir : (по умолчанию: /var/tmp) Каталог, где хранятся файлы журналов.
- stats_log_interval : (по умолчанию: 60) Интервал в секундах, через который запись статистики записывается в файл журнала API.
- rotate_interval : (по умолчанию: 24) Интервал в часах, через который происходит ротация файлов журналов.

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

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

debug: Добавляет удаленную отладку в процесс Edge Microgateway.
- порт : Номер порта, на котором будет осуществляться прослушивание. Например, настройте отладчик вашей IDE на прослушивание этого порта.
- args : Аргументы для процесса отладки. Например: args --nolazy
config_change_poll_interval: (по умолчанию: 600 секунд) Edge Microgateway периодически загружает новую конфигурацию и выполняет перезагрузку, если что-либо изменилось. Опрос отслеживает любые изменения, внесенные в Edge (изменения в продуктах, прокси-серверы, поддерживающие Microgateway и т. д.), а также изменения, внесенные в локальный файл конфигурации.
disable_config_poll_interval: (по умолчанию: false) Установите значение true , чтобы отключить автоматический опрос изменений.
request_timeout : Устанавливает тайм-аут для целевых запросов. Тайм-аут задается в секундах. В случае превышения тайм-аута Edge Microgateway отвечает кодом состояния 504. (Добавлено в версии 2.4.x)

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

Эти настройки определяют, как обрабатываются определенные 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 без заголовка Authorization. Установите значение false, чтобы требовать заголовок Authorization (по умолчанию).
allowInvalidAuthorization : (по умолчанию: false) Если установлено значение true, вызовы API разрешаются, если токен, переданный в заголовке Authorization, недействителен или истек. Установите значение false, чтобы требовать действительные токены (по умолчанию).
authorization-header : (по умолчанию: Authorization: Bearer) Заголовок, используемый для отправки токена доступа в Edge Microgateway. Вы можете изменить значение по умолчанию в случаях, когда целевому устройству необходимо использовать заголовок Authorization для других целей.
api-key-header : (по умолчанию: x-api-key) Имя заголовка или параметра запроса, используемого для передачи ключа API в Edge Microgateway. См. также Использование ключа API .
keepAuthHeader : (по умолчанию: false) Если установлено значение true, заголовок Authorization, отправленный в запросе, передается целевому объекту (он сохраняется).
allowOAuthOnly — Если установлено значение true, каждый API должен содержать заголовок Authorization с токеном доступа Bearer. Позволяет разрешить только модель безопасности OAuth (с сохранением обратной совместимости). (Добавлено в версии 4.2.x)
allowAPIKeyOnly — Если установлено значение true, каждый API должен содержать заголовок x-api-key (или пользовательское местоположение) с ключом API. Позволяет разрешить только модель безопасности с использованием ключа API (с сохранением обратной совместимости). (Добавлено в версии 4.2.x)
Примечание: Не следует устанавливать значения allowOAuthOnly и allowAPIKeyOnly одновременно в true. По умолчанию оба флага установлены в false (для обратной совместимости).

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

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

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

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

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

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

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

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

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

Поддерживается версия 4.2.x

Если Edge Microgateway установлен за межсетевым экраном, он может не взаимодействовать с Apigee Edge. В этом случае можно рассмотреть два варианта:

Вариант 1:

Первый вариант — установить параметр edgemicro: proxy_tunnel в значение true в конфигурационном файле микрошлюза:

edge_config:

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

Если параметр proxy_tunnel имеет значение true , Edge Microgateway использует метод HTTP CONNECT для туннелирования HTTP-запросов через одно TCP-соединение. (То же самое справедливо, если в переменных среды для настройки прокси включена поддержка TLS).

Вариант 2:

Второй вариант — указать прокси-сервер и установить параметр proxy_tunnel в значение false в конфигурационном файле микрошлюза. Например:

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

В этом случае вы можете установить следующие переменные для управления хостами для каждого HTTP-прокси, который вы хотите использовать, или для определения того, какие хосты не должны обрабатывать прокси Edge Microgateway: HTTP_PROXY , HTTPS_PROXY и NO_PROXY .

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

export NO_PROXY='localhost,localhost:8080'

Установите переменные HTTP_PROXY и HTTPS_PROXY равными конечной точке HTTP-прокси, на которую Edge Microgateway может отправлять сообщения. Например:

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

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

Для получения более подробной информации об этих переменных см.:

https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables

См. также

Инструкция по настройке Edge Microgateway за корпоративным брандмауэром в сообществе Apigee.

Использование символов подстановки в прокси-серверах, поддерживающих Microgateway.

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

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

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

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

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

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

DEBUG=* edgemicro start -o myorg -e test -k db4e9e8a95aa7fabfdeacbb1169d0a8cbe42bec19c6b98129e02 -s 6e56af7c1b26dfe93dae78a735c8afc9796b077d105ae5618ce7ed
Примечание: В Windows используйте SET DEBUG=*
Запустите отладчик и настройте его на прослушивание порта, указанного в настройках отладки.
Теперь вы можете пошагово просматривать код Edge Microgateway, устанавливать точки останова, отслеживать выражения и так далее.

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

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

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

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

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

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

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

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

Подробную информацию об использовании токена OAuth с прокси-запросами см. в разделе Secure Edge Microgateway .

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

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

Примечание: Вы также можете передать ключ API в качестве параметра запроса. Например, где [key] — это ключ API, строка из букв и цифр:

curl "http://localhost:8000/hello?"x-api-key=[key]"

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

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

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