karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Johnson" <bradj...@redhat.com>
Subject RE: karaf boot
Date Wed, 11 Jan 2017 17:23:21 GMT
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:jb@nanthrax.net] 
Sent: Wednesday, January 11, 2017 8:08 AM
To: user@karaf.apache.org
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:* bradjohn@redhat.com
> *Sent:* January 11, 2017 12:54 AM
> *To:* user@karaf.apache.org
> *Reply-to:* user@karaf.apache.org
> *Subject:* RE: karaf boot
>
>
> I’d be very interested in this project and will definitely give it a 
> look.  I’ve been using the Karaf 4 static profiles to create compact 
> microservices containers and it works well.  I’m not sure if that’s 
> what the Karaf Boot project is aiming at since I haven’t had a chance 
> to look at it yet.  But I’ll definitely give it a look tomorrow.
>
>
>
> Brad
>
>
>
> *From:*Jean-Baptiste Onofré [mailto:jb@nanthrax.net]
> *Sent:* Tuesday, January 10, 2017 11:30 PM
> *To:* user@karaf.apache.org
> *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 <slewis@composent.com 
> <mailto:slewis@composent.com>> 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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Mime
View raw message