[Apiman-user] [DKIM] Re: publish api to specific gateway

Fri Nov 30 08:57:20 EST 2018

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/20181130/cfaeb6ee/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 92068 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20181130/cfaeb6ee/attachment-0001.png 