Do you have any examples on github for this? Sent from my iPad
> On Jan 11, 2017, at 4:38 PM, Nick Baker <[email protected]> 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]> on behalf of Christian > Schneider <[email protected]> > Sent: Wednesday, January 11, 2017 9:51:56 AM > To: [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
