karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Pratt <jpratt3...@gmail.com>
Subject Re: karaf boot
Date Thu, 12 Jan 2017 00:52:19 GMT
Do you have any examples on github for this?

Sent from my iPad

> On Jan 11, 2017, at 4:38 PM, Nick Baker <nbaker@pentaho.com> wrote:
> 
> We're deploying into Kubernetes (OpenShift), but it could be Mesos/Marathon, Docker Swarm,
etc. the only important thing is for each pod to know where to find zookeeper.
> 
> -Nick
> From: Jason.Pratt@windriver.com
> Sent: January 11, 2017 7:19 PM
> To: user@karaf.apache.org
> Reply-to: user@karaf.apache.org
> Subject: RE: karaf boot
> 
> This sounds very interesting. Would the Dockers then be deployed similar to VertX?
>  
> From: Nick Baker [mailto:nbaker@pentaho.com] 
> Sent: Wednesday, January 11, 2017 11:31 AM
> To: user@karaf.apache.org
> Subject: Re: karaf boot
>  
> Some background on what we've been playing with may be of use.
>  
> We've worked on a Kubenetes/OpenShift deployment of micro-service Karaf instances (pods).
Each pod simply runs a plain Karaf preconfigured with Remote Service support (ECF) and select
features of our own design.
>  
> This implementation leverages the OpenShift Source-to-image feature which transforms
a simple Karaf assembly template checked into a Git Repository into a Maven Karaf assembly,
which is then run to produce a Docker Image containing the Karaf assembly. The Fabric8 team
has done great work here and we used their S2I image as inspiration for our own.
>  
>  
> Templated Assembly
> I really like this templated assembly approach. We have a single configuration file specifying
which features are to be installed, optionally supplying new Feature repository URLs, and
environment variables. You can also supply extra CFG files and even artifacts to be placed
in the /deploy directory.
>  
> One aspect about containerized deployments and microservice practices to consider is
how they treat applications as static immutable images. You don't modify the capabilities
or even configuration of running instances. Indeed instances themselves are not to be manipulated
directly as the container environment will start/stop and scale out the base image as needed.
Rather if you want to extend the capabilities or change configuration, you would create a
new image or new version of an existing one and propagate that out to the cluster. 
>  
> That said one of the goals for our application is the ability to deploy a small footprint
instance and have it dynamically provision capabilities (features) as needed by the incoming
workload. These would seem to run counter to the trend of static instances, but I disagree
as the scope of what can be dynamically provisioned is controlled. Each of these runtime features
contributes to an existing one -plugins to an existing capability.
>  
> TLDR: Support easy assemblies from a very simplified configuration. I'd probably introduce
a command-line program to invoke the build and a maven plugin.
>  
>  
> Run my template
> Building off templated assemblies would be simple "run" support from the same configuration.
Another command for the command-line program, maven plugin. Put everything in java.io.tmpdir,
who cares.
>  
>  
> Run Programatically
> Another item I've wanted is a better Karaf Main class. Really, I would just like to use
PAX-Exam as a Runner. I know... it originated from pax-runner. Something simple. Specify Karaf
version, features, config, setup System Bundle packages, run. I guess if this was done it
could be used in concert with the build template to support the run-from-template above. 
>  
>  
> Health Checks
> We had to develop some custom health check code to ensure that all features and blueprint
containers successfully start. Legacy portions of our application need to wait for Karaf to
be fully realized before continuing execution. This was pretty important to our embedded Karaf
usage, but that's certainly rare. Regardless, Health Checks are vital to microservice / cloud
deployments. I recently found that the Fabric8 team pretty much already has this, and it's
just about exactly what we developed  This needs to be documented for others to find. 
>  
>  
> Boot Features 
> Boot Feature support in the assembly plugin is a Huge benefit for fast lightweight Karaf
instances. This would clearly be the preferred configuration for a Nano-like distribution
(shout-out to our Virgo brothers). Unfortunately, I've had varying success moving our assemblies
from startupFeatures to bootFeatures. It may have to do with our custom deployers. Honestly
I haven't looked into it too deeply.
>  
>  
> Easy Web Interface
> Hawtio is nice, but can be a bit overwhelming. An easy interface, especially for those
new to OSGI/Karaf would go a long way. 
>  
>  
> I've reached-out to our OSGI guys here for their thoughts and will post them here as
they come in.
>  
> -Nick Baker
> From: Christian Schneider <cschneider111@gmail.com> on behalf of Christian Schneider
<chris@die-schneider.net>
> Sent: Wednesday, January 11, 2017 9:51:56 AM
> To: user@karaf.apache.org
> Subject: Re: karaf boot
>  
> Sounds like you have a good case to validate karaf boot on.
> 
> Can you explain how you create your deployments now and what you are missing in current
karaf? Until now we only discussed internally about the scope and requirements of karaf boot.
It would be very valuable to get some input from a real world case.
> 
> Christian
> 
> On 11.01.2017 13:41, 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
> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
>  
> Open Source Architect
> http://www.talend.com

Mime
View raw message