karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Baker <nba...@pentaho.com>
Subject Re: karaf boot
Date Thu, 12 Jan 2017 00:38:18 GMT
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.

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<mailto:cschneider111@gmail.com>>
on behalf of Christian Schneider <chris@die-schneider.net<mailto:chris@die-schneider.net>>
Sent: Wednesday, January 11, 2017 9:51:56 AM
To: user@karaf.apache.org<mailto: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.


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


Open Source Architect

View raw message