Apiman & Loadbalancer F5 !
by Charles Moulliard
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
8 years, 4 months
Rate-limit policy does not work in APIMan cluster
by Vax, Uri
Hi
I'm using APIMan 1.1.9.
It seems like Rate-limit policy does not work properly when there are several nodes (node1, node2).
The scenario:
* Setup up an APIMan cluster with two nodes (node1 , node2).
* Create a service with a rate-limit policy of 5 request per minute
* Send requests to the service using postman (or any other http client):
o Send requests to node1 until rate limit is exceeded
o Send another request to node2 - APIMan will pass the request to the service end-point API instead of returning the "Rate limit exceeded" response
Thanks,
Uri
8 years, 4 months
Property placeholder within policy does not resolve in the gateway (v1.2.0.Final / APIMAN-831)
by Ton Swieb
Hi,
I tried to take the property placeholder functionality for a test drive,
which should be available as of v1.2.0.Final. See JIRA:
https://issues.jboss.org/browse/APIMAN-831
But for some reason I do not get it to work. Did I configure something
wrong or am I running into a bug?
I use the property placeholder in the keycloak plugin which is
preconfigured in a Docker image.
I defined the realm property of the Keycloak plugin as
${external_url}/auth/realms/apiman
I started my Docker image with the -e external_url=
https://192.168.99.100:8443 parameter to set the environment variable
within the Docker container.
When I try to access the API I get a failure in Keycloak Plugin saying:
{
"type": "Authentication",
"failureCode": 11004,
"responseCode": 401,
"message": "Token audience doesn't match domain. Token issuer is
https://192.168.99.100:8443/auth/realms/apiman, but URL from
configuration is ${external_url}/auth/realms/apiman",
"headers": {}
}
It looks like the property placeholder did not get resolved correctly.
When I have a look in the Docker image using docker exec -ti <name>
/binbash and do a list of the environment variables. The environment
variable is correctly defined:
MacBook-Pro-van-Ton:~ ton$ docker exec -ti tiny_wilson /bin/bash
[jboss@43c099aae441 ~]$ export
declare -x APIMAN_VERSION="1.2.0.Final"
....
declare -x external_url="https://192.168.99.100:8443"
I also tried setting the property to ${external_url} without the
'/auth/realms/apiman' suffix. I figured that it might perhaps will do a
full String comparison, but that did not work either.
Any ideas?
Regards, Ton
8 years, 4 months
Apiman & Loadbalancer F5
by Charles Moulliard
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
8 years, 4 months
Anyone interested in Prometheus metrics for apiman?
by Marc Savy
Hi All,
Is anyone interested in Prometheus metrics/monitoring for apiman?
There's currently a PoC implementation for the Vert.x 3 gateway (which
none of you are likely using!), however it's probably of limited
practical use in the wild.
The nature of Prometheus is rather different to any of the other engines
we've worked with, in that you must define which measures you're
interested in a priori, rather than spitting out raw data and analysing
it later.
Clearly, this requires substantial decisions to be made in advance as to
what kind of metrics are important to you, and indeed which ones you
don't want.
I think in many cases we'll just have to provide a base class which can
be extended so you can implement your own measures in a way that suits you.
However, it would be good to provide a default implementation which has
a useful set of measures which will cover a least a substantial portion
of usecases.
Therefore, my questions are:
- Should we provide a default implementation of Prometheus metrics. Or
are requirements too diverse to make it worthwhile?
- If yes, which measures should we provide by default?
- Would there be an argument for having engines like Prometheus to be
run concurrently with another one (e.g. elaticsearch metrics), because
it serves a different purpose. What's your use case?
Regards,
Marc
8 years, 4 months
Cannot publish Service with Basic Auth API Security
by Joe Strathern
Hello APIMan Community,
I am trying to create and publish a service within APIMan that is secured
by basic authentication, however i am encountering errors whenever i set
the Implementation to Basic Auth and then try to publish.
I am currently using APIMan 1.1.9 within Wildfly 8.2.0.Final
The Service will publish without issues if i set the Implementation to
None, however as soon as i set it to BASIC (with the correct username/pass)
I get a Server Error 500 page with the following stack trace:
io.apiman.manager.api.rest.contract.exceptions.ActionException: Failed
to publish service.
at io.apiman.manager.api.rest.impl.util.ExceptionFactory.actionException(ExceptionFactory.java:308)
at io.apiman.manager.api.rest.impl.ActionResourceImpl.publishService(ActionResourceImpl.java:201)
at io.apiman.manager.api.rest.impl.ActionResourceImpl.performAction(ActionResourceImpl.java:103)
at io.apiman.manager.api.rest.impl.ActionResourceImpl$Proxy$_$$_WeldClientProxy.performAction(Unknown
Source)
at sun.reflect.GeneratedMethodAccessor157.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
at io.apiman.common.servlet.RootResourceFilter.doFilter(RootResourceFilter.java:59)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
at io.apiman.manager.api.war.TransactionWatchdogFilter.doFilter(TransactionWatchdogFilter.java:57)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
at io.apiman.manager.api.security.impl.DefaultSecurityContextFilter.doFilter(DefaultSecurityContextFilter.java:56)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
at io.apiman.common.servlet.DisableCachingFilter.doFilter(DisableCachingFilter.java:59)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
at io.apiman.common.servlet.ApimanCorsFilter.doFilter(ApimanCorsFilter.java:71)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
at io.apiman.common.servlet.LocaleFilter.doFilter(LocaleFilter.java:61)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: io.apiman.gateway.engine.beans.exceptions.PublishingException
at io.apiman.manager.api.gateway.rest.GatewayClient.readPublishingException(GatewayClient.java:273)
at io.apiman.manager.api.gateway.rest.GatewayClient.publish(GatewayClient.java:216)
at io.apiman.manager.api.gateway.rest.RestGatewayLink.publishService(RestGatewayLink.java:162)
at io.apiman.manager.api.rest.impl.ActionResourceImpl.publishService(ActionResourceImpl.java:189)
... 66 more
Caused by: java.lang.NullPointerException
at java.lang.Throwable.setStackTrace(Throwable.java:864)
at io.apiman.manager.api.gateway.rest.GatewayClient.readPublishingException(GatewayClient.java:271)
... 69 more
If anyone has seen this before and has a possible workaround/solution,
please let me know.
Thanks,
Joe
8 years, 4 months
Re: [Apiman-user] HTTP request/response logging from the Apiman gateway to back-end services
by Ton Swieb
Hi Eric,
Good to know. I logged: https://issues.jboss.org/browse/APIMAN-897
Regards, Ton
2016-01-12 14:58 GMT+01:00 Eric Wittmann <eric.wittmann(a)redhat.com>:
> We don't currently have a feature to log the back-end request/response.
> I'd love it if you would open a feature request ticket in JIRA for that
> (seems like a nice thing to have).
>
> In the short term you could implement a custom policy that would Sys.out
> the ServiceRequest and ServiceResponse objects (note: in 1.2.x these are
> called ApiRequest and ApiResponse). If you do this, make sure to put that
> policy *last* in the chain.
>
> -Eric
>
> On 1/12/2016 5:07 AM, Ton Swieb wrote:
>
>> Hi,
>>
>> I would like to see the HTTP request/response logging between the Apiman
>> gateway and the back-end services.
>>
>> Is this possible in Apiman? If so, how can I activate it?
>>
>> I already tried enabling the RequestDumpHandler in Undertow, but that
>> only logs the inbound HTTP request/response to the Apiman gateway. So
>> the communication between the API client and the API gateway, but I
>> would like to see the outbound HTTP request/response logging.
>>
>> Regards,
>>
>> Ton
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
8 years, 4 months
HTTP request/response logging from the Apiman gateway to back-end services
by Ton Swieb
Hi,
I would like to see the HTTP request/response logging between the Apiman
gateway and the back-end services.
Is this possible in Apiman? If so, how can I activate it?
I already tried enabling the RequestDumpHandler in Undertow, but that only
logs the inbound HTTP request/response to the Apiman gateway. So the
communication between the API client and the API gateway, but I would like
to see the outbound HTTP request/response logging.
Regards,
Ton
8 years, 4 months
apiman-gateway.public-endpoint property
by Paul Blair
The Production Guide mentions that one should set the API Gateway public endpoint using the apiman-gateway.public-endpoint property. Since I see it in the Wildfly8Platform.java on 1.2.0.Final I'm assuming this is still operative for the new release.
Question: Is this property needed for the API Manager, or just for the API Gateway?
8 years, 4 months
Status of 1.2.0?
by Paul Blair
I'm noticing in Github there is a 1.2.0.Final tag based on commit a commit with message "Prepared apiman for release: 1.2.0.Final". Is the release good to go if I build it from source?
(I'm getting an exception when publishing an API but unfortunately it's not giving me interesting information because of a NullPointerException in the GatewayClient's exception handler for PublishingException. I noticed that this exception handler is fixed in the 1.2 stream, so I'm eager to grab that release.)
8 years, 4 months
