[Apiman-user] [DKIM] Re: publish api to specific gateway
Eric Wittmann
eric.wittmann at redhat.com
Thu Dec 13 15:29:59 EST 2018
Very interesting, thanks Jon. So if I understand correctly, the problem is
that the Client has a contract for API1 (published to GW1) and a contract
for API2 (published to GW2). And so when registering a client, we're
trying to send Contracts for APIs that don't exist on the GW. So yeah,
filtering the list of Contracts during registration makes sense. We should
file this as a bug in Apiman (on GitHub). Would you be willing to do that?
https://github.com/apiman/apiman/issues
-Eric
On Thu, Dec 13, 2018 at 1:54 AM Jon Huang <chttl582 at gmail.com> wrote:
> 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/df9d3c66/attachment-0001.html
More information about the Apiman-user
mailing list