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
