I'll address some of the things I'd like for microservices which may or may not be pertinent specifically to Karaf Boot. But I think are going to be necessary for the Karaf ecosystem and to ease of using microservices with Karaf. I'll have a better idea of the goals and current ideas of Karaf Boot by the end of the day. I apologize in advance if this isn't what is of interest.
With the slimmed down version of Karaf 4 using profiles to statically include dependencies for things like CXF and Camel, I can create a deployable that is only 30MB. So the perception of Karaf being a part of monolithic stacks like ServiceMix or Fuse goes away. Standard Karaf standalone appliances that do specific tasks can be created and made available much like Camel makes a large selection of precompiled bundles for components and endpoints. The microservice Karaf appliances can obviously use existing OSGi libraries to create commonly used deployable containers that only require configuration. Because the bundles are put into the Karaf container at compile time the need for the command line updating is gone. That's one less thing for newish developers to learn. Configuration compared to larger stacks is much easier as well. But with well-defined Maven/Java projects for various container types, it is then easy for developers to write their application code in a bundle(s) and modify a common Karaf appliance exemplar and get everything to compile, deploy to the container, and get zipped up. This is the sort of structure I've used and like although it is a first attempt and still joined at the hip with the demo hierarchy. https://github.com/Ranx0r0x/Panda-Vault/tree/master/developmentAppliance There's actually a pre-compiled zip there already for folks who might want to preview the functionality without have to pull the complete Maven repo and build. A lot of this is particular project will be aimed at end user developers so that. The nice thing about using microkaraf appliances is that in the same fashion that we use EIPs we could have Enterprise Integration Topology appliances (for lack of a better name). For example, a version of a "gateway" component that contains essentials for security/certificates and demonstrates how CXF annotated interfaces can be exposed for SOAP and REST, handle the unmarshaling and then send to Camel routes. That appliance might then have configuration file that lets one change the endpoint URI for that Camel route to use send the message to a dedicated microservice container. No real coding involved on the end user's part. Just a number of basic configurations. Other appliances might be for things like 80/20 testing where one would be able to use the appliance without any coding. Just configuration. Deploy a new version of some appliance you are working on and put a small Karaf 80/20 appliance between it and the caller to send 80% of the traffic to the old appliance and 20% to the new appliance to verify functionality but allow rapid reversal if things didn't work well. I think Christian was working on a remoting piece for PAX/Karaf to do something like that. One issue that client's complain about is finding good examples and exemplars on how to do certain tasks. If this were done the way I'm thinking about it, it might be more like how Camel endpoint bundles work. If you are using a library FTP bundle, it generally isn't necessary to crack the bundle open or pull the code from the repo and modify. Just make the requisite configuration changes. Providing libraries of common appliances like that would give a lot of good source code and Maven project structures for developers to use as springboards. For example, I'll commonly put a config.cfg in my Maven project and have a features file that installs it by PID name in the etc folder when deployed. That may or may not be a chose standard but it is quite common to find clients who do not understand how the cfg files map, nor how to use features. With appliances, that would simply be a natural mechanism that would then be used from the profiles. This sort of idea would permit us and other developers to create complete libraries of appliances (for lack of better name) that could be pulled, configured, and used with little or minimal code change. Obviously the developer will have to get to the point where they are developing code and functionality. Even that could have appliance templates that had a lot of standard One future issue will be creating auto-deployables so that when Jenkins kicks off and runs the zip file gets put in the Maven repo and then can be pushed or pulled to a location and unzipped. Short term that will probably be a bit much. The idea would be to have something like KIE Drools ability to pull or push bundles when rules change. Personally the deployment and specification of dependencies for devops is important to me. When I go into client's now and tell them they can deployment multiple instances of the Fuse stack I'll get funny looks and comments about licenses and the use of Spring Boot. -----Original Message----- From: Jean-Baptiste Onofré [mailto:[email protected]] Sent: Wednesday, January 11, 2017 8:08 AM To: [email protected] Subject: Re: karaf boot Hi guys, that's really great and we are looking for help and ideas there ! The early stage branch is there: https://github.com/jbonofre/karaf-boot And this one contains also some PoC: https://github.com/jbonofre/karaf-boot/tree/jpa Regards JB On 01/11/2017 01:41 PM, Nick Baker wrote: > We'd be interested in this as well. Beginning to move toward > Microservices deployments + Remote Services for interop. I'll have a > look at your branch JB! > > We've added support in our Karaf main for multiple instances from the > same install on disk. Cache directories segmented, port conflicts > handled. This of course isn't an issue in container-based cloud > deployments (Docker). Still, may be of use. > > -Nick Baker > > Sent via the BlackBerry Hub for Android > <http://play.google.com/store/apps/details?id=com.blackberry.hub> > *From:* [email protected] > *Sent:* January 11, 2017 12:54 AM > *To:* [email protected] > *Reply-to:* [email protected] > *Subject:* RE: karaf boot > > > Id be very interested in this project and will definitely give it a > look. Ive been using the Karaf 4 static profiles to create compact > microservices containers and it works well. Im not sure if thats > what the Karaf Boot project is aiming at since I havent had a chance > to look at it yet. But Ill definitely give it a look tomorrow. > > > > Brad > > > > *From:*Jean-Baptiste Onofré [mailto:[email protected]] > *Sent:* Tuesday, January 10, 2017 11:30 PM > *To:* [email protected] > *Subject:* Re: karaf boot > > > > Hi Scott > > There were a discussion in progress on the mailing list about Karaf boot. > A PoC branch is available on my GitHub in early stage. > > I would like to restart the discussion based on this branch. > > Regards > JB > > On Jan 11, 2017, at 02:25, Scott Lewis <[email protected] > <mailto:[email protected]>> wrote: > > The page about Karaf boot that I've found: > http://karaf.apache.org/projects.html#boot says 'not yet available'. Is > there an expected timeline for Karaf Boot? Also, is there a branch upon > which the Karaf boot work is being done? > > Thannksinadvance, > > Scott > -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
