Hi,
as mentioned some weeks ago on the mailing list, I have a test case
using Mesos and Marathon (with Karaf & Cellar).
I didn't have time to complete the blog post, I will.
Regards
JB
On 01/12/2017 01:38 AM, Nick Baker 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:* [email protected]
*Sent:* January 11, 2017 7:19 PM
*To:* [email protected]
*Reply-to:* [email protected]
*Subject:* RE: karaf boot
This sounds very interesting. Would the Dockers then be deployed similar
to VertX?
*From:*Nick Baker [mailto:[email protected]]
*Sent:* Wednesday, January 11, 2017 11:31 AM
*To:* [email protected]
*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 <[email protected]
<mailto:[email protected]>> on behalf of Christian Schneider
<[email protected] <mailto:[email protected]>>
*Sent:* Wednesday, January 11, 2017 9:51:56 AM
*To:* [email protected] <mailto:[email protected]>
*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
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
