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
>