I just have a security littler concern of the 0.0.0.0 which could bind all the possible network interface according to recent malicious attacks on unsecured instances of MongoDB.
Maybe we can add a feature to let the serviceRegistry to look up a certain address for access. Willem Jiang Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Mon, Feb 6, 2017 at 5:50 PM, Luca Burgazzoli <lburgazz...@gmail.com> wrote: > Hi, > > as today we have a ServiceCall EIP that makes it easy to call external > services in a cloud environment leveraging external service registry > such as kubernetes, consul, etcd & co so I'm thinking about adding a > way for a route to register itself in such registries and be available > as a service for other to consume. > > Something like: > > // programmatic config > from("jetty:http://0.0.0.0:8001/service1";) > .serviceRegistry() > .name("service-1") > .host("....") > .port(8001) > .meta("camel.protocol", "http") > .meta("camel.component", "jetty") > .meta("camel.context.path", "/service1") > .end() > .to("direct:service-1") > > // Inherit from a global config and eventually override it > from("jetty:http://0.0.0.0:8002/service2";) > .serviceRegistry("service-2") > .configRef("service-registry-conf") > .port(8002) > .to("direct:service-2") > > // Smart auto configuration > from("jetty:http://0.0.0.0:8003/service3";) > .serviceRegistry("service-3") > .to("direct:service-3") > > Beside making camel play better in cloud environment, you can use the > service call to connect camel based micro services with minimal > configuration as the registration may provide some additional meta > data that the service call can use for auto-configuration (of course > not all the registries can do it). > > The future Health API/Service may then also be configured to remove > or invalidate the service if the route is reported as not healthy. > > > Make sense for you ? > > --- > Luca Burgazzoli >
