yeah, this isn't just more than a raw dump of some ideas I had in mind but the service/object entitled to perform the registration to the cloud registry should have a sort of pluggable "local-address-resolver"
--- Luca Burgazzoli On Tue, Feb 7, 2017 at 1:52 AM, Willem Jiang <willem.ji...@gmail.com> wrote: > 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 >>
