Re: [Apiman-user] Apiman & Loadbalancer F5 !

On 20 janv. 2016, at 11:25, Eric Wittmann <eric.wittmann(a)redhat.com&gt; wrote: That looks correct. -Eric > On 1/20/2016 3:26 AM, Charles Moulliard wrote: > Hi Eric, > > Here is a diagram that I have created based on your response. I think > that it should confirm what we have discussed - correct ? > > Regards, > > Charles >> On 19/01/16 15:47, Eric Wittmann wrote: >> Hi Charles. I'm not 100% certain I understand all aspects of your >> question - perhaps a diagram would help me, in case my answer doesn't >> make sense (and if you have the time). :) >> >> You are right that there is no 1..N mapping of an apiman service/api >> to a back-end endpoint URL. That is a feature we are contemplating >> for the future but it's certainly not available yet. >> >> Here are some thoughts that might be useful/relevant to this use case. >> First is that you could of course implement a custom policy that >> changed the back-end endpoint URL based on whatever criteria you see >> fit. The custom policy would simply have to change the value of the >> ApiRequest->Api:endpoint field. Doing that should be considered >> unsafe and a temporary workaround, as the Api object is globally >> scoped, and really should be either cloned (if we want to suppor this >> use-case) or immutable (if we don't). >> >> Another thing to note is that as of 1.2.0.Final we support system >> property and environment variable replacements in the API endpoint, >> endpoint properties, and all policy configurations. This means that >> you could install *identical* gateways on all the per fuse server, >> configured using the same shared registry. Then, when you configure >> the Service/API endpoint, you could set the value to something like: >> >> ${external_url} >> >> Then you could set a system property, which could be different for >> each gateway node, like so: >> >> (on gateway server 1) >> -Dexternal_url=http://fuse_server_1:port/ >> >> (on gateway server 2) >> -Dexternal_url=http://fuse_server_2:port/ >> >> That way your configuration is shared but certain aspects/properties >> of the configuration are *externalized*. >> >> This feature was originally meant to support more easily migrating >> data between dev/test/prod environments, but it would work fine for >> this as well. >> >> Did any of that help? >> >> -Eric >> >> >>> On 1/19/2016 5:30 AM, Charles Moulliard wrote: >>> Hi, >>> >>> If I use a loadbalancer (= F5) exposing a physical IP address (= routed >>> on internet) and calling one of our endpoints (REST, ...) running into >>> different integration servers (Fuse + Camel), can we design such >>> topology ? >>> >>> We setup an Apiman Manager (Front + ElasticSearch Database) to define >>> the plans, services, roles, policies of all the endpoints which are >>> running into different Fuse Servers. As the mapping between the incoming >>> request and the endpoint is managed by the Apiman Gateway, I'm thinking >>> to install one Apiman Gateway / Fuse Server. >>> Is it doable ? >>> >>> Client --> 192.168.1.1 (IP Address of the Server replying to a REST >>> Service) "Loadbalancer F5" --> NAT --> address of the gateway (= >>> 10.0.2.1) managing the mapping between the request and the physical >>> endpoint --> Camel REST Endpoint (10.0.1.1). The Apiman Manager could >>> run internally on this addess (10.0.2.100). >>> >>> To support high availability or workload distribution, it will be >>> required that at least each Camel REST / Web Service runs into multiple >>> instances of Fuse Servers. That means that their IP address will be >>> different (A REST service will be deployed on 10.0.1.1, 10.0.1.2, >>> 10.0.1.3, ...). >>> >>> Question : As the GUI interface of the Apiman Manager to encode the >>> address of the endpoint to map proposes one field (and no more if we >>> would like to distribute the requests to different servers), is there a >>> possibility to define a 1 to many relation into ApiMan Server (maybe if >>> we develop such a feature) or do I have also to install an Apiman >>> Manager / Gateway per Fuse Server and to encode the same info (plans, >>> services, ...) excepted the IP address of the server which is >>> different ? >>> >>> Regards, >>> >>> Charles >>> _______________________________________________ >>> Apiman-user mailing list >>> Apiman-user(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/apiman-user >