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

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

Edge Microgateway версии 3.1.5 и более поздних версий

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

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

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

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

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

   npm upgrade edgemicro -g

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

   npm upgrade edgemicro@3.1.0 -g

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

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

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:

Вы можете настроить сервер 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

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

Использование параметров клиента 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

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

Настройка прокси-сервера 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

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

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

Вы можете установить следующие уровни журнала: info , alert и error . Рекомендуется уровень информации. Он регистрирует все запросы и ответы 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 — Регистрирует все, отправленное на stderr.
• 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 (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
• информация - Зависит от контекста. Может быть информация, предупреждение или ошибка, в зависимости от уровня журнала. Это может быть статистика для записи статистики, предупреждение для предупреждений или ошибка для ошибок.
• 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
• информация - Зависит от контекста. Может быть информация, предупреждение или ошибка, в зависимости от уровня журнала. Это может быть статистика для записи статистики, предупреждение для предупреждений или ошибка для ошибок.
• treq — идентифицирует событие. В данном случае целевой запрос.
• m — команда HTTP, используемая в целевом запросе.
• u — часть URL-адреса, следующая за базовым путем.
• h — хост и номер порта целевой серверной части.
• i — идентификатор записи журнала. Все четыре записи о событиях будут использовать этот идентификатор.

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

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

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

• информация - Зависит от контекста. Может быть информация, предупреждение или ошибка, в зависимости от уровня журнала. Это может быть статистика для записи статистики, предупреждение для предупреждений или ошибка для ошибок.
• tres — идентифицирует событие. В данном случае целевой ответ.
• s — статус ответа HTTP.
• d - Продолжительность в миллисекундах. Время, затраченное на вызов API целью.
• i — идентификатор записи журнала. Все четыре записи о событиях будут использовать этот идентификатор.

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

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

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

• информация - Зависит от контекста. Может быть информация, предупреждение или ошибка, в зависимости от уровня журнала. Это может быть статистика для записи статистики, предупреждение для предупреждений или ошибка для ошибок.
• 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 — регистрируются только сообщения об ошибках.
  • 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

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

Эти параметры определяют, как обрабатываются определенные заголовки 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 см. Generate токен .

Что такое поворот ключа?

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

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

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

• private_key - последний (совсем недавно созданный) RSA Private Key, используемый для подписи JWTS.

• public_key - последний (совсем недавно созданный) сертификат, используемый для проверки JWTS, подписанный с private_key.

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

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

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

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

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

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

Чтобы получить токен обновления, сделайте призыв 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 возвращает токен доступа и токен обновления. Ответ выглядит похоже на это:

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

2. Теперь вы можете использовать токен обновления, чтобы получить новый токен доступа, вызывая /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

Наконец, сохраните файл конфигурации и запустите экземпляр 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

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

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

Настройка исключения 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>