[Apiman-user] [DKIM] Re: publish api to specific gateway
Jon Huang
chttl582 at gmail.com
Thu Dec 13 01:54:22 EST 2018
Dear Eric
I spent some time to track this issue.
First I hit the status API (GATEWAY_API_URL/system/status) and got
following response:
{
"id": "apiman-gateway-api",
"name": "API Gateway REST API",
"description": "The API Gateway REST API is used by the API Manager to
publish APIs and register clients. You can use it directly if you wish,
but if you are utilizing the API Manager then it's probably best to avoid
invoking this API directly.",
"version": "1.5.2-SNAPSHOT",
"up": true
}
seems OK, then I hit the register client API (PUT GATEWAY_API_URL/clients)
to retrieve further information, which returned an ApiNotFoundException.
After reviewing the payload, I found the register client API sent every
contract info to the gateway endpoint. (ex: contract A & B to Gateway 2,
refer to following diagram)
{
"organizationId": "ORG",
"clientId": "CLIENT",
"version": "1.0",
"apiKey": "1763bc30-64af-4fd8-877e-1382c1a2cac2",
"contracts": [{
"apiOrgId": "ORG",
"apiId": "API1",
"apiVersion": "1.0",
"plan": "plan",
"policies": []
}, {
"apiOrgId": "ORG",
"apiId": "API2",
"apiVersion": "1.0",
"plan": "plan",
"policies": []
}
]
}
[image: image.png]
So if there is an contract's which its API publishing to another gateway
leads to 404 not found exception. (ex: contract A info sent to Gateway 2)
Maybe filtering the register client API payload or preventing API manager
UI from creating contract between APIs with different gateways can solve
this issue. (or is there any other solution?)
Thanks.
Eric Wittmann <eric.wittmann at redhat.com> 於 2018年12月6日 週四 下午9:47寫道：
> Your diagram looks exactly right. I don't know why you are getting a 404
> error when trying to register the client. My best guess is that your
> Gateway 2 configuration is actually incorrect and that the "Test Gateway"
> function is returning a false positive somehow. Can you post the
> configuration settings you are using for *BOTH* of your Gateways? (I
> assume you can successfully publish an API to Gateway 1).
>
> You should be able to manually confirm your Gateway settings using e.g.
> curl or postman. There is an endpoint on the Gateway API that you can hit:
>
> GATEWAY_API_URL/system/status
>
> You'll need to provide auth info for this to work, but it will return a
> JSON response like this:
>
> {
> "id": "xyz",
> "name": "Apiman Gateway API",
> "description": "... something here ...",
> "version": "x.y.z",
> "up": true
> }
>
> The UI should be checking that endpoint when you click the "Test Gateway"
> button, but perhaps there's a bug in that.
>
> If the above endpoint can be hit and verified, then I'm at a complete loss
> as to why you'd be getting a 404 when trying to publish! The implication
> is that the Gateway API endpoint that the UI is attempting to use is
> missing. But if /system/status can be found, then everything else should
> be available too!
>
> @Marc Savy <msavy at redhat.com> - any thoughts on this?
>
> -Eric
>
>
> On Thu, Dec 6, 2018 at 3:02 AM Jon Huang <chttl582 at gmail.com> wrote:
>
>> Dear Eric
>>
>> Thanks for your explanation.
>> I tried to deploy another gateway with a new storage(Elasticsearch) and
>> configure API to publish on the new one. (API manager version 1.5.1)
>> However when I tried to create a contract between API and client apps
>> then re-register client apps, error happened.
>> It seems API manager fails to connect to gateway2. (But UI-> Manage
>> Gateways -> Edit Gateway -> Test Gateway returns *Gateway Configuration
>> Valid*)
>> (io.apiman.manager.api.rest.contract.exceptions.ActionException: Failed
>> to register client.)
>> I put detail log in attachment if you are interested.
>> Thanks
>>
>> simple diagram for my deployment test.
>> [image: image.png]
>>
>>
>> Volk, Florian <Florian.Volk at scheer-group.com> 於 2018年11月30日 週五 下午10:24寫道：
>>
>>> Hi Eric,
>>>
>>>
>>>
>>> thanks for this detailed answer J
>>>
>>> This is quite interesting. We didn’t expected this behavior. Maybe it
>>> would be good to place this in the documentation, maybe with this picture ;)
>>>
>>>
>>>
>>> But this raises a few new questions for us. I try to explain:
>>>
>>>
>>>
>>> · Do we need for *alternate* setup two UIs if we don’t want to
>>> use the REST interface or CLI-Tool?
>>>
>>> o One for «Gateway Alpha» and one for «Gateway Beta»?
>>>
>>> o Because I think you can only connect one elasticseach instance with
>>> the UI. Am I right on this?
>>>
>>> o What about the metrics in this use case à leads to two UIs?
>>>
>>>
>>>
>>> · For the «one logical gateway»
>>>
>>> o If I understand you correctly this would mean that I also have to
>>> configure only one gateway in my UI and can add X more without adding them
>>> into the UI.
>>> I just have to point them against the same elasticsearch instance.
>>>
>>> I also post this mail to the github issue, so we can stay within the
>>> mailinglist.
>>>
>>>
>>>
>>> Thanks again,
>>>
>>> Florian
>>>
>>>
>>>
>>>
>>>
>>> *Von:* Eric Wittmann <eric.wittmann at redhat.com>
>>> *Gesendet:* Friday, 30 November 2018 14:57
>>> *An:* Volk, Florian <Florian.Volk at scheer-group.com>
>>> *Cc:* chttl582 at gmail.com; Marc Savy <marc.savy at redhat.com>; Kihm,
>>> Benjamin <Benjamin.Kihm at scheer-group.com>; Gebert, Alfred <
>>> Alfred.Gebert at scheer-group.com>; apiman-user at lists.jboss.org
>>> *Betreff:* Re: [Apiman-user] [DKIM] Re: publish api to specific gateway
>>>
>>>
>>>
>>> Sure no problem. The typical use-case for having multiple Gateway nodes
>>> is to scale the gateway layer horizontally and then put a load balancer in
>>> front of them. So for example you might start up 5 apiman gateway
>>> instances and configure them all to use the same Elasticsearch instance for
>>> persistence (i.e. where to store configuration info like which APIs have
>>> been published). In this use-case, every gateway instance has the same set
>>> of APIs "published" to it. You can publish an API from the UI/manager to
>>> **any** of the gateway instances and they will all know about that API.
>>> This is the "Single Logical Gateway" use-case -- the UI/manager and all
>>> consumers don't know or care how many gateway nodes there are - there could
>>> be 1 node, or there could be 100. It behaves the same logically.
>>>
>>>
>>>
>>> An **alternate** use case for having multiple gateways is when you
>>> actually want different APIs to be deployed to different gateways. So
>>> let's say you wanted Gateway Alpha to be able to proxy traffic to APIs A,
>>> B, and C. Then you have Gateway Beta which you want to proxy traffic to
>>> APIs C, D, and E. In that case, consumer traffic MUST be routed through
>>> Gateway Alpha in order to access APIs A and B. Consumer traffic MUST be
>>> routed through Gateway Beta to access APIs D and E. Finally, consumer
>>> traffic can be routed to **either** Gateway Alpha or Gateway Beta in order
>>> to access API C. Think of this as the "Two Logical Gateways" use-case.
>>>
>>>
>>>
>>> In order to achieve the "Two Logical Gateways" use-case, you will need
>>> **two** separate persistence stores (Elasticsearch instances). Then you
>>> configure Gateway Alpha to use persistence store #1 and configure Gateway
>>> Beta to use persistence store #2.
>>>
>>>
>>>
>>> Note that you can have multiple gateway nodes for EACH of the two
>>> logical gateways. So for example you could have 5 gateway instances all
>>> pointing to persistence store #1 - these 5 nodes would make up a single
>>> logical gateway called "Gateway Alpha". Then you could have 10 gateway
>>> instances all pointing to persistence store #2 - and these would be a
>>> single logical gateway called "Gateway Beta".
>>>
>>>
>>>
>>> Here is a diagram of what the architecture might look like:
>>>
>>>
>>>
>>> [image: image.png]
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Nov 30, 2018 at 8:38 AM Volk, Florian <
>>> Florian.Volk at scheer-group.com> wrote:
>>>
>>> Hi Eric,
>>>
>>>
>>>
>>> now I’m confused. We use Elasticsearch as backend. If I understand you
>>> correctly it would mean that we have to setup an Elasticsearch instance for
>>> each gateway?
>>>
>>> On the other point, if the gateways operate as logical unit, why is
>>> there a configuration option in the ui?
>>>
>>>
>>>
>>> Can you explain this a little bit more detailed? Maybe you have a
>>> configuration example.
>>>
>>>
>>>
>>> Regards,
>>> Florian
>>>
>>>
>>>
>>> *Von:* Eric Wittmann <eric.wittmann at redhat.com>
>>> *Gesendet:* Friday, 30 November 2018 14:22
>>> *An:* Volk, Florian <Florian.Volk at scheer-group.com>
>>> *Cc:* chttl582 at gmail.com; Marc Savy <marc.savy at redhat.com>; Kihm,
>>> Benjamin <Benjamin.Kihm at scheer-group.com>; Gebert, Alfred <
>>> Alfred.Gebert at scheer-group.com>; apiman-user at lists.jboss.org
>>> *Betreff:* Re: [Apiman-user] [DKIM] Re: publish api to specific gateway
>>>
>>>
>>>
>>> Are both gateways using the same persistent storage? Each gateway would
>>> need separate, independent persistence otherwise they will behave as a
>>> single "logical" gateway.
>>>
>>>
>>>
>>> -Eric
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Nov 30, 2018 at 4:39 AM Volk, Florian <
>>> Florian.Volk at scheer-group.com> wrote:
>>>
>>> Hello together,
>>>
>>>
>>>
>>> I was interested in this and made a short test in my loacal environment
>>> and I am able to reproduce this.
>>>
>>> I created a ticket on github for this (
>>> https://github.com/apiman/apiman/issues/711). We may can fix this
>>> shortly.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Florian
>>>
>>>
>>>
>>> *Von:* apiman-user-bounces at lists.jboss.org <
>>> apiman-user-bounces at lists.jboss.org> *Im Auftrag von *Jon Huang
>>> *Gesendet:* Friday, 30 November 2018 03:28
>>> *An:* marc.savy at redhat.com
>>> *Cc:* apiman-user at lists.jboss.org
>>> *Betreff:* [DKIM] Re: [Apiman-user] publish api to specific gateway
>>>
>>>
>>>
>>> Dear Marc
>>>
>>>
>>>
>>> Yes I untick another gateway however request towards both gateways still
>>> works.
>>>
>>> Besides I tried to publish API via admin REST API (post api version then
>>> put gateway info), both gateways forwards request too.
>>>
>>> Before filing a bug is there any apigw setting I shall check? (such as
>>> parameter in apiman.properties or etc...)
>>>
>>> Thanks for your help.
>>>
>>> Regards
>>>
>>> Marc Savy <marc.savy at redhat.com> 於 2018年11月21日 週三 下午9:35寫道：
>>>
>>> Apologies for the terribly slow reply. We've had so much spam I've
>>> missed legitimate emails like this.
>>>
>>>
>>>
>>> Did you explicitly untick the other gateway? Was this via the UI or the
>>> API?
>>>
>>>
>>>
>>> Did you resolve this issue? If not, please file a bug:
>>> https://github.com/apiman/apiman/issues
>>>
>>>
>>>
>>> On Thu, 4 Oct 2018 at 05:00, Jon Huang <chttl582 at gmail.com> wrote:
>>>
>>> Dears
>>>
>>>
>>>
>>> I had set up 2 gateways.
>>>
>>> When I new an API, I have to choose which gateway to publish. (select
>>> list at Gateway section in the implementation tab).
>>>
>>> However after creating a client app and contract for test, I found
>>> request via another gateway still works.
>>>
>>> (I guest when publishing to gateway 1 and request via gateway 2 shall
>>> fail)
>>>
>>> Am I misunderstanding or I miss some settings to make it work?
>>>
>>> Thanks
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20181213/a0547e74/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 18859 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20181213/a0547e74/attachment-0002.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32122 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20181213/a0547e74/attachment-0003.png
More information about the Apiman-user
mailing list