WSO2 APIM не обновляет опубликованный API в настройке кластера - PullRequest
Новая
       29

WSO2 APIM не обновляет опубликованный API в настройке кластера

0 голосов
/ 04 июня 2019

Настройка: два WSO2 APIM, указывающие на один и тот же MYSQL. Эти два экземпляра WSO2 находятся за LB, и сессия издателя является липкой. Сеанс API не является липким. Я опубликовал API "/public/1.0.0/abc", который ранее указывал на "/ api / app / v1 / xyz". Я обновил опубликованный API и теперь указываю на "/api/app/v1/abc".

Проблема: теперь после обновления, когда к опубликованному API обращаются через curl, время от времени возвращает ожидаемый результат, но в других случаях выдает ошибку 403. Кажется, обновление в одном случае не распространяется на другой? Приведенные ниже шаги, чтобы заставить его работать, означают простои, и мы стараемся избегать простоев.

Единственный способ сделать эту работу - сделать следующее: 

1. Shutdown the wso2am app on the working instance (Instance1)
2. Update the API again on WSO2 publisher so Instance2 picks up the change
3. Start back the Instance1 wso2am app

WSO2 Instance1 регистрирует, где работает вызов: 

==> /usr/lib64/wso2/wso2am/2.6.0/repository/logs/http_access_.log <==
- <private-subnet-ip> - - [04/Jun/2019:20:02:00 +0000] "GET /services/Version HTTP/1.1" - - "-" "ELB-HealthChecker/2.0"
<my-ip> <private-subnet-ip> - - [04/Jun/2019:20:02:22 +0000] "GET /public/1.0.0/abc HTTP/1.1" - - "-" "curl/7.54.0"
<my-ip> <private-subnet-ip> - - [04/Jun/2019:20:02:22 +0000] "GET /api/app/v1/abc HTTP/1.1" - - "-" "Synapse-PT-HttpComponents-NIO"
- <private-subnet-ip>  - [04/Jun/2019:20:02:00 +0000] "- - " 200 - "-" "-"
- <private-subnet-ip>  - [04/Jun/2019:20:02:22 +0000] "- - " 200 - "-" "-"
- <private-subnet-ip>  - [04/Jun/2019:20:02:22 +0000] "- - " 200 - "-" "-"

WSO2 Instance2 регистрирует, где вызов не работает: 

==> /usr/lib64/wso2/wso2am/2.6.0/repository/logs/wso2carbon.log <==
TID: [-1234] [] [2019-06-04 20:01:24,511]  WARN {org.apache.synapse.rest.API} -  Trying to access API : admin--PublicAPI on restricted transport chanel [https] {org.apache.synapse.rest.API}

==> /usr/lib64/wso2/wso2am/2.6.0/repository/logs/wso2-apigw-errors.log <==
2019-06-04 20:01:24,511 [-] [PassThroughMessageProcessor-123]  WARN API Trying to access API : admin--PublicAPI on restricted transport chanel [https]

==> /usr/lib64/wso2/wso2am/2.6.0/repository/logs/wso2carbon.log <==
TID: [-1234] [] [2019-06-04 20:01:24,511]  INFO {org.apache.synapse.mediators.builtin.LogMediator} -  STATUS = Message dispatched to the main sequence. Invalid URL., RESOURCE = /public/1.0.0/abc {org.apache.synapse.mediators.builtin.LogMediator}

==> /usr/lib64/wso2/wso2am/2.6.0/repository/logs/wso2-apigw-service.log <==
2019-06-04 20:01:24,511 [-] [PassThroughMessageProcessor-123]  INFO __SynapseService STATUS = Message dispatched to the main sequence. Invalid URL., RESOURCE = /public/1.0.0/abc

1 Ответ

0 голосов
/ 05 июня 2019

Это происходит, если вы не поделились артефактами API между двумя серверами. Только один сервер имеет обновленный артефакт. Когда вы публикуете API, он создает артефакт Synapse (API), который хранится в файловой системе сервера. Расположение: SERVER_HOME / хранилище / развертывание / сервер / синапс / по умолчанию / расположение API. Если вы используете более одного экземпляра, у вас должен быть механизм для синхронизации этих артефактов между серверами. Есть несколько вариантов.

  1. Использование общей файловой системы для узлов
  2. Опция Rsync - вы можете всегда указывать на узел 1 и публиковать API. Из узла 1 вы можете rsync данных на узел 2. В файле api-manager.xml APURGateway serverURL должен быть заменен на узел 1 в обоих узлах.
...